idnits 2.17.1 draft-moskowitz-hip-ipnhip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2003], [RFC2004], [RFC7401]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2016) is 2731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD-IANA' is mentioned on line 234, but not defined == Outdated reference: A later version (-02) exists of draft-moskowitz-gpcomp-00 == Outdated reference: A later version (-02) exists of draft-moskowitz-ssls-hip-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft X. Xu 4 Intended status: Standards Track B. Liu 5 Expires: April 30, 2017 Huawei 6 October 27, 2016 8 Encapsulation of IP within IP managed by HIP 9 draft-moskowitz-hip-ipnhip-01.txt 11 Abstract 13 This document defines how to encapsulate IP within IP when the tunnel 14 is managed with HIPv2 [RFC7401]. The goal is reduced header size and 15 improved security over IPnIP [RFC2003] and [RFC2004]. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 30, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 54 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The advantage of a HIP managed IP-within-IP Tunnel . . . . . 3 56 4. IPnHIP Header Format . . . . . . . . . . . . . . . . . . . . 3 57 5. HIP parameters to negotiate IPnHIP . . . . . . . . . . . . . 5 58 5.1. IPnHIP_INFO . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. IPnHIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 5 60 6. HIP IPnHIP Security Association Setup . . . . . . . . . . . . 6 61 7. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Packet Compression . . . . . . . . . . . . . . . . . . . 7 64 8.2. Processing Application Data . . . . . . . . . . . . . . . 7 65 8.3. Processing HIP Packets . . . . . . . . . . . . . . . . . 7 66 9. ESP or Minimal IPnIP or IPnHIP . . . . . . . . . . . . . . . 7 67 9.1. Encapsulation cost in bytes . . . . . . . . . . . . . . . 8 68 9.2. Encapsulation cost in processing . . . . . . . . . . . . 8 69 9.3. Security posture . . . . . . . . . . . . . . . . . . . . 8 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 13.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 MobileIP has opted for a simple IP within IP tunneling mechanism 81 without any tunnel security. The justification for this approach 82 over secure tunneling mechanisms like ESP [RFC4303] is outside the 83 scope of this document. The approach here is to define a IPnIP 84 header that leverages the HIP Security Association and is 85 potentiality smaller than RFC2004 [RFC2004] as well as provides for a 86 higher security posture. 88 The IPnHIP header defined here also supports the per-packet 89 compression, GPCOMP [I-D.moskowitz-gpcomp], which offers further 90 gains in transmission efficiency. 92 Implementors are expected to be familiar with both HIPv2 and ESP with 93 HIP [RFC7402]. This document draws heavily on RFC7402 to the extent 94 that much of the flow process is not duplicated here. 96 2. Terms and Definitions 98 2.1. Requirements Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2.2. Definitions 106 IPnHIP: The short name for IP-within-IP managed by HIP. 108 SPI: The Security Parameter Index. 110 3. The advantage of a HIP managed IP-within-IP Tunnel 112 HIP maps the peer address pair into two 32 bit uni-directional 113 Security Parameter Indexes (SPI). It is only necessary for a tunnel 114 to include the SPI that indicates the traffic direction. The HIP 115 layer provides the translation between the SPI and the addresses. 116 The resultant header is thus almost always smaller than with RFC2004. 118 This results that an attacker will have to learn about this SPI to 119 addressing mapping to execute an attack against the higher layers 120 within the tunnel. 122 The addition of an ESP-styled sequence number further reduces the 123 attack window as the attacker must know the current sequence number 124 window. The inclusion of a 32 bit sequence number enlarges the 125 header, but for IPv4 it is still in line with the size for RFC2004 126 and for IPv6 it is still considerably smaller. 128 4. IPnHIP Header Format 130 The Protocol field in the IP header is replaced by protocol number 131 TBD for the IPnHIP encapsulation protocol. 133 The format of the IP-within-IP-with-HIP header is as follows: 135 0 1 2 3 136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Protocol | Flags | Header Checksum | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | SPI | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Sequence Number | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1 - Header Format 147 Protocol 149 Copied from the Protocol field in the original IP header. 151 Flags 153 Is a set of 8 options flags. 155 Header Checksum 157 The 16-bit one's complement of the one's complement sum of all 158 16-bit words in this header. For purposes of computing the 159 checksum, the value of the checksum field is 0. The IP header 160 and IP payload (after the minimal forwarding header) are not 161 included in this checksum computation. 163 SPI 165 The SPI as defined in section SPI. 167 Sequence Number 169 As defined in RFC 4303. 171 Flags is a set of 8 options flags. Bit 7 is the GPComp 172 [I-D.moskowitz-gpcomp] bit compression option bit. 174 0 1 2 3 4 5 6 7 175 +-+-+-+-+-+-+-+-+ 176 | C| 177 +-+-+-+-+-+-+-+-+ 179 Figure 2 - Flags Field 181 5. HIP parameters to negotiate IPnHIP 183 Two HIP parameters are defined for setting up IPnHIP tunnel format 184 associations in HIP communication and for restarting existing ones. 186 Parameter Type Length Data 188 IPnHIP_INFO [TBD-IANA] 8 Remote's old SPI, new SPI 189 IPnHIP_TRANSFORM [TBD-IANA] variable IP Encapsulation in IP 191 5.1. IPnHIP_INFO 193 0 1 2 3 194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | OLD SPI | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | NEW SPI | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Type [TBD-IANA] 204 Length 8 205 OLD SPI old SPI for data sent to address(es) associated 206 with this SA. If this is an initial SA setup, the 207 OLD SPI value is zero. 208 NEW SPI new SPI for data sent to address(es) associated 209 with this SA. 211 The processing of IPnHIP_INFO is similar to ESP_INFO, section 5.1.1 212 of RFC7402 [RFC7402], without the KEYMAT generation. 214 5.2. IPnHIP_TRANSFORM 216 The IPnHIP_TRANSFORM parameter is used during IPnHIP SA 217 establishment. The first party sends a selection of transform 218 families in the IPnHIP_TRANSFORM parameter, and the peer must select 219 one of the proposed values and include it in the response 220 IPnHIP_TRANSFORM parameter. 222 0 1 2 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved | Suite ID #1 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Suite ID #2 | Suite ID #3 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Suite ID #n | Padding | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Type [TBD-IANA] 235 Length length in octets, excluding Type, Length, and 236 padding. 237 Reserved zero when sent, ignored when received. 238 Suite ID defines the IPnHIP Suite to be used. 240 The following Suite IDs can be used: 242 Suite ID Value 244 RESERVED 0 [this draft] 245 IPnHIP 1 [sec IPnHIP1] 247 The sender of an IPnHIP transform parameter MUST make sure that there 248 are no more than six (6) Suite IDs in one IPnHIP transform parameter. 249 Conversely, a recipient MUST be prepared to handle received transform 250 parameters that contain more than six Suite IDs. The limited number 251 of Suite IDs sets the maximum size of the IPnHIP_TRANSFORM parameter. 252 As the default configuration, the IPnHIP_TRANSFORM parameter MUST 253 contain at least one of the mandatory Suite IDs. There MAY be a 254 configuration option that allows the administrator to override this 255 default. 257 Currently only one IPnHIP_TRANSFORM is defined. Future work may 258 define others. 260 6. HIP IPnHIP Security Association Setup 262 The IPnHIP Security Association is set up during the base exchange. 263 The following subsections define the IPnHIP SA setup procedure using 264 both base exchange messages (R1, I2, R2) and UPDATE messages. 266 The IPnHIP Security Association follows the same process as that of 267 the ESP Security Association (sec 5.2 RFC7402 [RFC7402] except for 268 the KEYMAT. 270 IPnHIP SA does not have any keying material, and thus those processes 271 are not needed. 'Rekeying' to assign new SPIs is still needed to 272 manage the sequence numbering. 274 7. ICMP Messages 276 ICMP Message handling is the same as sec 5.4 RFC7402 [RFC7402]. 278 8. Packet Processing 280 Packet processing is mainly defined in sec 6 RFC7402 [RFC7402] with 281 following changes. 283 8.1. Packet Compression 285 Packet compression is negotiated by HIP using the GPCOMP_INFO 286 parameter defined in [I-D.moskowitz-ssls-hip]. 288 IPnHIP uses the Implied Structure of GPCOMP [I-D.moskowitz-gpcomp] 289 and follows the Compress/Uncompresing process defined there in. 291 8.2. Processing Application Data 293 IPnHIP sequence number processing follows RFC4303 [RFC4303]. With 294 the extended 64 bit sequence number, the rarely will be the need to 295 update the SPI to reset the sequence number. Any resetting the SPI 296 will be driven by privacy concerns. The rest of the packet 297 processing follows RFC2004 [RFC2004]. 299 8.3. Processing HIP Packets 301 HIP packet processing is the same as sec 6 RFC7402 [RFC7402] without 302 the keying parameter handling. 304 9. ESP or Minimal IPnIP or IPnHIP 306 There are at least three ways to compare these encapsulation 307 protocols: 309 o Encapsulation cost in bytes 311 o Encapsulation cost in processing 313 o Security posture 315 9.1. Encapsulation cost in bytes 317 From the analysis below, IPnHIP is consistently the cheapest option. 319 o ESP adds 9 bytes + pad (0 - 3 bytes) + ICV. For GMAC-96 this is 320 17 bytes + pad. 322 o Minimal IPnIP is 4 bytes + 2 * IP address length. For IPv4 this 323 is 12 bytes and for IPv6 36 bytes. 325 o IPnHIP is 12 bytes (Note: Can use GPCOMP with Implied Structure, 326 i.e. no header cost, for further savings.) 328 9.2. Encapsulation cost in processing 330 o ESP with GMAC-96 is perhaps the computationally lightest 331 transform. GMAC has only 2 AES operations + n GHASH operations. 333 o Minimal IPnIP has no cryptographic processing overhead. 335 o IPnHIP has no cryptographic processing overhead. GPCOMP does add 336 the compression processing. 338 9.3. Security posture 340 o ESP traffic is fully protected up to the strength of the 341 cryptographic transform used. Plus the HIP SA is protection 342 against MITM attacks provided there is authentication of the HITs 343 used. 345 o Minimal IPnIP has no security protection. A party that discovers 346 IPnIP flow can interject any traffic desired. 348 o IPnHIP masks the internal identities by only including the HIP SA 349 SPIs and a sequence number. This presents a number of challenges 350 to an attacker. They have to know the sequence number window and 351 what the SPI maps to. This is not as strong as ESP, but more 352 protection that IPnIP provides. 354 10. IANA Considerations 356 The IP protocol number of NN for IPnHIP is assigned by IANA. 358 The following change to the "Host Identity Protocol (HIP) Parameters" 359 registries has been made: 361 IPnHIP_INFO: This document defines the new IPnHIP_INFO parameter 362 (see Section 5.1). The parameter value will be assigned by IANA. 363 Its value should come from the 66-127 range. 365 IPnHIP_TRANSFORM: This document defines the new IPnHIP_TRANSFORM 366 parameter (see Section 5.2). The parameter value will be assigned 367 by IANA. Its value should come from the 4096-4480 range. 369 11. Security Considerations 371 IPnHIP lacks the protections provided by ESP. ESP with the GMAC 372 transform should be seriously considered for a fast, Integrity only 373 mode instead of IPnHIP. GMAC has only 2 AES block operations per ESP 374 payload. 376 There are policy cases where only a non-securable tunnel will be 377 permitted. IPnHIP provides a high level of tunnel management 378 security through HIP and better privacy and spoofing and replay 379 resiliency than IPnIP due to its use of a sequence number scheme and 380 an SPI instead of the internal IP addresses. 382 HIP fast Mobility provides the high trust provided by HIP for address 383 remapping without needing triangular data routing. 385 GPCOMP, like ESP, is not believed to be subject to the TLS BEAST 386 attack. 388 12. Acknowledgments 390 Sue Hares of Huawei contributed to the clarity in this document. 392 13. References 394 13.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 402 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 403 RFC 7401, DOI 10.17487/RFC7401, April 2015, 404 . 406 13.2. Informative References 408 [I-D.moskowitz-gpcomp] 409 Moskowitz, R., Hares, S., Faynberg, I., Lu, H., and P. 410 Giacomin, "GPCOMP", draft-moskowitz-gpcomp-00 (work in 411 progress), March 2016. 413 [I-D.moskowitz-ssls-hip] 414 Moskowitz, R., Xia, L., Faynberg, I., Hares, S., and P. 415 Giacomin, "Secure Session Layer Services KMP via HIP", 416 draft-moskowitz-ssls-hip-00 (work in progress), October 417 2016. 419 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 420 DOI 10.17487/RFC2003, October 1996, 421 . 423 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 424 DOI 10.17487/RFC2004, October 1996, 425 . 427 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 428 RFC 4303, DOI 10.17487/RFC4303, December 2005, 429 . 431 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 432 Encapsulating Security Payload (ESP) Transport Format with 433 the Host Identity Protocol (HIP)", RFC 7402, 434 DOI 10.17487/RFC7402, April 2015, 435 . 437 Authors' Addresses 439 Robert Moskowitz 440 Huawei 441 Oak Park, MI 48237 442 USA 444 Email: rgm@labs.htt-consult.com 446 Xiaohu Xu 447 Huawei 448 Huawei Bld, No.156 Beiqing Rd. 449 Beijing, Hai-Dian District 100095 450 China 452 Email: xuxiaohu@huawei.com 453 Bingyang Liu 454 Huawei 455 Huawei Bld, No.156 Beiqing Rd. 456 Beijing, Hai-Dian District 100095 457 China 459 Email: xuxiaohu@huawei.com