idnits 2.17.1 draft-moskowitz-hip-fast-mobility-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 : ---------------------------------------------------------------------------- No issues found here. 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) == Unused Reference: 'RFC7343' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC7401' is defined on line 417, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-moskowitz-hip-ipnhip-00 Summary: 0 errors (**), 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 Fast HIP Host Mobility 9 draft-moskowitz-hip-fast-mobility-01.txt 11 Abstract 13 This document describes mobility scenarios and how to aggressively 14 support them in HIP. The goal is minimum lag in the mobility event. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 30, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 53 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Time to complete move . . . . . . . . . . . . . . . . . . 3 56 3.2. Apriori move knowledge . . . . . . . . . . . . . . . . . 4 57 4. Enhanced availability of VIA_RVS . . . . . . . . . . . . . . 4 58 5. Single move mobility . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Piggybacking impact on transport window size . . . . . . 5 60 5.2. Environment . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.3. Scenario 1: Neither host has data to transmit . . . . . . 5 62 5.4. Scenario 2: Host A has data to transmit . . . . . . . . . 5 63 5.4.1. IPv6 datagram + HIP UPDATE > MTU . . . . . . . . . . 5 64 5.4.2. IPv6 datagram + HIP UPDATE <= MTU . . . . . . . . . . 6 65 5.5. Scenario 3: Host B has data to transmit . . . . . . . . . 6 66 5.5.1. IPv6 datagram + HIP UPDATE > MTU . . . . . . . . . . 6 67 5.5.2. IPv6 datagram + HIP UPDATE <= MTU . . . . . . . . . . 6 68 6. Double-Jump mobility . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Environment . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.2. Shotgunning UPDATEs . . . . . . . . . . . . . . . . . . . 7 71 6.3. Neither host has data to transmit . . . . . . . . . . . . 7 72 6.4. Either host has data to transmit . . . . . . . . . . . . 7 73 6.4.1. IPv6 datagram + HIP UPDATE > MTU . . . . . . . . . . 7 74 6.4.2. IPv6 datagram + HIP UPDATE <= MTU . . . . . . . . . . 8 75 7. Special considerations when used with IPnHIP . . . . . . . . 8 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 11.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 This document expands on HIP Host Mobility [I-D.ietf-hip-rfc5206-bis] 87 to describe a set of mobility scenarios that can be addressed by 88 mechanisms that accelerate the basic HIP mobility UPDATE exchange. 90 HIP Host Mobility [I-D.ietf-hip-rfc5206-bis] performs a return 91 address validation to ensure that the UPDATE address is reachable by 92 the peer. Two reasons are given for this approach: middleboxes 93 blocking return reachablity and malicious peers providing false 94 address updates to flood a target. 96 The approach here is to start using the new address while it is being 97 validated. Worst case is a few packets are lost or sent to a wrong 98 target. These are acceptable risks while gaining a fast address 99 update that works in most cases. 101 One mechanism used is to piggyback data using Next Header even while 102 the mobile peer address is flagged UNVERIFIED. This is practical as 103 the new peer address is authenticated by the HIP_MAC in UPDATE. The 104 UPDATE can neither be forged nor can it be replayed. The 105 verification is more to ensure reverse reachability particularly 106 across NATs and firewalls. 108 Another mechanism expands the use of the VIA_RVS parameter to 109 "shotgun" mobility UPDATEs. These and other optimizations will be 110 covered in detail. 112 2. Terms and Definitions 114 2.1. Requirements Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2.2. Definitions 122 IPnHIP: The short name for IP-within-IP managed by HIP. 124 MTU: The Maximum Transmit Unit or maximum number of bytes in a 125 datagram that the Interface supports. 127 SPI: The Security Parameter Index. 129 3. Problem Space 131 3.1. Time to complete move 133 Most mobility environments are built with a "break then make" model 134 for connectivity. Thus there is measurable time between the old 135 address being unusable and the new address being functional. Adding 136 mobility convergence times just further aggravates the delay which 137 negatively impacts the user experience. 139 The "make then break" model for connectivity is supported via HIP 140 multihoming and is the subject of a separate recommendation. 142 HIP mobility relies on a 3 packet UPDATE exchange which in some cases 143 can be optimized to 2 packets. This can be further delayed in a 144 "double-jump" scenario with waiting for the direct connection to fail 145 before falling over to contacting the peer's RVS. These processes 146 have resulted in other technologies to be preferred over HIP as they 147 have faster convergence even if they achieve this while sacrificing 148 security. 150 3.2. Apriori move knowledge 152 A HIP Host that has the potential to 'move' (acquire a new address 153 for an interface) during the lifetime of a HIP association SHOULD be 154 registered to an RVS. Such a HIP host SHOULD always inform its peer 155 of its RVS address, as it may experience a "Double-Jump" move as in 156 Section 6. 158 In an RVS assisted base exchange, the Responder ensures the Initiator 159 knows its RVS with the VIA_RVS parameter in the R1 as specified in 160 HIP Rendezvous Extension [RFC8004]. However, the Responder has no 161 mechanism to learn the Initiator's RVS address. Additionally, it is 162 possible for an Initiator to directly contact the Responder and thus 163 not learn about the Responder's RVS in the base exchange. 165 A host may not publish its RVS if it does not wish to be easily 166 discovered. It still should notify its peers of its RVS if it 167 expects to be found in some move scenarios. 169 The HIP base exchange needs to include more RVS information. 171 4. Enhanced availability of VIA_RVS 173 The VIA_RVS parameter is defined in HIP Rendezvous Extension 174 [RFC8004] for use in R1, but only identifies the Responder's RVS to 175 the Initiator when the I1 was routed through the RVS. 177 Firstly, a Responder SHOULD always provide its VIA_RVS information in 178 R1 even when the I1 came directly from the Initiator. Secondly, the 179 Initiator SHOULD always provide its VIA_RVS information in I2. The 180 VIA_RVS address is always maintained as part of the HIT to IP 181 addressing information. Through these two expansions in the 182 availability of VIA_RVS, the hosts are assured to possess their 183 peer's RVS address to "shotgun" UPDATEs and thus accelerate mobility. 185 5. Single move mobility 187 Data traffic between host A and B may use ESP with HIP [RFC7402], 188 IPnIP [RFC2004], IPnHIP [I-D.moskowitz-hip-ipnhip] or any other 189 tunneling protocol. If ESP, or to some extent IPnHIP, the 190 relationship of the tunnel SAs with the HIP SA puts a high level of 191 trust on the following fast mobility. With IPnIP, the risk is 192 similar to MIPv6. Adding a MAC of the IPnIP or IPnHIP datagram into 193 the HIP UPDATE as in Section 7 adds an additional level of validation 194 during the fast mobility. 196 5.1. Piggybacking impact on transport window size 198 The following sections define the operation of a HIP UPDATE payload 199 followed by some transport (e.g. TCP or UDP) payload in a single IP 200 datagram. This multicontent IP datagram works best with a smaller 201 window size for the higher layer. The normal operation is to compare 202 the size of the transport datagram plus HIP UPDATE payload and ensure 203 it is less than the MTU. An implementation may be able to adjust the 204 transport window size downward so that the higher layer could still 205 fill it and the whole piece then still fit within the MTU. 207 5.2. Environment 209 o Host A is mobile. 211 o Host B may be mobile, but not changing IP address at this time. 213 o Only Host A is moving in the network and changing its IP address. 215 o Host A and B share a HIP Security Association. 217 o Host A and B are registered to a RVS server, not necessarily the 218 same and each has the others RVS address. 220 5.3. Scenario 1: Neither host has data to transmit 222 Host A triggers a HIP mobility UPDATE with Locator to inform Host B 223 of new address. Host B, upon validating Host A HIP UPDATE, continues 224 with Address Verification. 226 5.4. Scenario 2: Host A has data to transmit 228 5.4.1. IPv6 datagram + HIP UPDATE > MTU 230 Host A triggers a HIP mobility UPDATE with Locator to inform Host B 231 of new address. As the UPDATE + datagram would exceed the MTU, the 232 datagram is sent separately after receipt of the HIP UPDATE from Host 233 B. 235 The HIP UPDATE packets vary in length as follows: 237 Move notification: 302 bytes - UPDATE(ESP_INFO, LOCATOR, SEQ, HMAC, 238 HIP_SIGNATURE) 240 Move verification: 286 bytes - UPDATE(ESP_INFO, SEQ, ACK, HMAC, 241 HIP_SIGNATURE, ECHO_REQUEST_UNSIGNED) 243 Verification ack: 262 bytes - UPDATE(ESP_INFO, ACK, HMAC, 244 HIP_SIGNATURE, ECHO_RESPONSE_UNSIGNED) 246 5.4.2. IPv6 datagram + HIP UPDATE <= MTU 248 Host A sends HIP UPDATE with Locator to inform Host B of new address. 249 Datagram is appended to HIP UPDATE using Next Header. Host B, upon 250 validating Host A HIP UPDATE, sends next header to proper module and 251 continues with Address Verification. This datagram is processed even 252 though the address is UNVERIFIED. 254 The ESP and IPnHIP anti-replay window managed by their envelope 255 sequence number can protect against replayed UPDATE+ESP packets prior 256 to address verification. 258 5.5. Scenario 3: Host B has data to transmit 260 After Host B receives a HIP mobility UPDATE from A it has data to 261 send to A. Or Host B may have been sending data to Host A while Host 262 A was moving. The old data may have been lost; for example the data 263 is over UDP with no keepalives during the move time. The old data 264 may be in a retransmission state; for example the data is over TCP. 265 Or the data reached the interface from the higher layer at the same 266 time that the HIP UPDATE with new locator was successfully processed. 268 5.5.1. IPv6 datagram + HIP UPDATE > MTU 270 Host B sends the HIP UPDATE validation followed by the IPv6 datagram. 271 Host B may place the address in ACTIVE state or wait from HIP UPDATE 272 confirmation from Host A. 274 5.5.2. IPv6 datagram + HIP UPDATE <= MTU 276 Host B sends the HIP UPDATE validation within the IPv6 datagram. 277 Host B may place the address in ACTIVE state or wait from HIP UPDATE 278 confirmation from Host A. 280 6. Double-Jump mobility 282 The HIP mobility UPDATE will fail without the use of RVS. In fact 283 both RVS are needed for both UPDATEs to find its peer. This is why 284 the "shotgun" acceleration SHOULD always be used when the peer's RVS 285 is known. 287 6.1. Environment 289 o Both host A and B are mobile. 291 o Host A and B share a HIP Security Association. 293 o Both hosts move in the network and change their IP addresses. 294 Before either receives the others HIP mobility UPDATE. 296 o Host A and B are registered to a RVS server, not necessarily the 297 same and each has the others RVS address. 299 6.2. Shotgunning UPDATEs 301 Shotgunning is the process of sending the same UPDATE to more than 302 one LOCATOR. In particular it refers to sending the UPDATE to at 303 least the peer's last known IP address and to its RVS address learned 304 from the VIA_RVS for either the R1 or I2 packet. 306 A host MUST be prepared to receive and discard multiple HIP mobility 307 UPDATEs. The duplicates will be readily identified as having the 308 same SEQ (UPDATE sequence umber). 310 Shotgunning SHOULD always be used when an RVS is known. A peer never 311 knows of a "double-jump" event until after it receives its peer's 312 UPDATE. 314 6.3. Neither host has data to transmit 316 Host A triggers a HIP mobility UPDATE with Locator to inform Host B 317 of new address. Host B, upon validating Host A HIP UPDATE, continues 318 with Address Verification. 320 No attempt should be made to piggyback the two UPDATE processes. 321 They may run simultaneously but not in the same IP datagrams. 323 6.4. Either host has data to transmit 325 The following acceleration advice presents a number of challenges. 326 The best rule of thumb is to send the data as soon as possible. 328 6.4.1. IPv6 datagram + HIP UPDATE > MTU 330 Same process as Section 6.3 332 6.4.2. IPv6 datagram + HIP UPDATE <= MTU 334 Host A sends HIP UPDATE with Locator to inform Host B of new address. 335 Datagram is appended to HIP UPDATE using Next Header. Host B, may 336 have already sent a datagram with its original HIP UPDATE. If since 337 then a receipt of Host A's UPDATE it has more data to transmit, upon 338 validating Host A HIP UPDATE, sends next header to proper module and 339 continues with Address Verification. This datagram is processed even 340 though the address is UNVERIFIED. 342 7. Special considerations when used with IPnHIP 344 IPnHIP [I-D.moskowitz-hip-ipnhip] has superior resiliency to attack 345 over IPnIP [RFC2004] as it uses an ESP-styled sequence number and the 346 HIP SPI rather than the encapsulated IP addresses. Still a host 347 SHOULD use the PAYLOAD_MIC from HICCUPS [RFC6078] whenever an IPnHIP 348 datagram is appended to a HIP mobility UPDATE. This effectively 349 blocks any substitution attack. It also lengthens the HIP UPDATE by 350 24 bytes which may result in NOT being able to append the IPnHIP 351 datagram and stay within the MTU. 353 Use of the PAYLOAD_MIC is a recommendation and not a requirement. 354 The risk of bloating the UPDATE packet such that the IPnHIP payload 355 cannot be carried in the same datagram may be reason enough not to 356 use it. 358 8. IANA Considerations 360 The following change to the "Host Identity Protocol (HIP) Parameters" 361 registries has been made: 363 The PAYLOAD_MIC parameter used here is defined in HICCUPS which is an 364 Experimental RFC. Here it is being used in a Standards Track 365 document. 367 9. Security Considerations 369 HIP fast mobility does not introduce any new security considerations 370 beyond that in HIP Host Mobility [I-D.ietf-hip-rfc5206-bis]. If 371 anything its requirement to know and use the RVS for a peer improve 372 the frequency of a successful mobility notification. 374 10. Acknowledgments 376 The term "shotgun" for fast mobility comes from the InfraHIP project. 377 The HIP UPDATE lengths were supplied by Jeff Ahrenholz. 379 Sue Hares of Huawei and Jeff Ahrenholz of Tempered Networks 380 contributed to the clarity in this document. 382 11. References 384 11.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 11.2. Informative References 393 [I-D.ietf-hip-rfc5206-bis] 394 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 395 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-14 396 (work in progress), October 2016. 398 [I-D.moskowitz-hip-ipnhip] 399 Moskowitz, R. and X. Xu, "Encapsulation of IP within IP 400 managed by HIP", draft-moskowitz-hip-ipnhip-00 (work in 401 progress), September 2016. 403 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 404 DOI 10.17487/RFC2004, October 1996, 405 . 407 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) 408 Immediate Carriage and Conveyance of Upper-Layer Protocol 409 Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, 410 January 2011, . 412 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 413 Routable Cryptographic Hash Identifiers Version 2 414 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 415 2014, . 417 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 418 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 419 RFC 7401, DOI 10.17487/RFC7401, April 2015, 420 . 422 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 423 Encapsulating Security Payload (ESP) Transport Format with 424 the Host Identity Protocol (HIP)", RFC 7402, 425 DOI 10.17487/RFC7402, April 2015, 426 . 428 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 429 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 430 October 2016, . 432 Authors' Addresses 434 Robert Moskowitz 435 Huawei 436 Oak Park, MI 48237 437 USA 439 Email: rgm@labs.htt-consult.com 441 Xiaohu Xu 442 Huawei 443 Huawei Bld, No.156 Beiqing Rd. 444 Beijing, Hai-Dian District 100095 445 China 447 Email: xuxiaohu@huawei.com 449 Bingyang Liu 450 Huawei 451 Huawei Bld, No.156 Beiqing Rd. 452 Beijing, Hai-Dian District 100095 453 China 455 Email: xuxiaohu@huawei.com