idnits 2.17.1 draft-moskowitz-hip-fast-mobility-03.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 draft header indicates that this document updates RFC8046, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 April 2020) is 1476 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Updates: 8046 (if approved) S. Card 5 Intended status: Standards Track A. Wiethuechter 6 Expires: 5 October 2020 AX Enterprize 7 3 April 2020 9 Fast HIP Host Mobility 10 draft-moskowitz-hip-fast-mobility-03 12 Abstract 14 This document describes mobility scenarios and how to aggressively 15 support them in HIP. The goal is minimum lag in the mobility event. 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 https://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 5 October 2020. 34 Copyright Notice 36 Copyright (c) 2020 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 (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 10.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 This document expands on HIP Host Mobility [RFC8046] to describe a 86 set of mobility scenarios that can be addressed by mechanisms that 87 accelerate the basic HIP mobility UPDATE exchange. 89 HIP Host Mobility [RFC8046] performs a return address validation to 90 ensure that the UPDATE address is reachable by the peer. Two reasons 91 are given for this approach: middleboxes blocking return reachability 92 and malicious peers providing false address updates to flood a 93 target. 95 The approach here is to start using the new address while it is being 96 validated. Worst case is a few packets are lost or sent to a wrong 97 target. These are acceptable risks while gaining a fast address 98 update that works in most cases. 100 One mechanism used is to piggyback data using Next Header even while 101 the mobile peer address is flagged UNVERIFIED. This is practical as 102 the new peer address is authenticated by the HIP_MAC in UPDATE. The 103 UPDATE can neither be forged nor can it be replayed. The 104 verification is more to ensure reverse reachability particularly 105 across NATs and firewalls. 107 Another mechanism expands the use of the VIA_RVS parameter to 108 "shotgun" mobility UPDATEs. These and other optimizations will be 109 covered in detail. 111 2. Terms and Definitions 113 2.1. Requirements Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 2.2. Definitions 123 MTU: The Maximum Transmit Unit or maximum number of bytes in a 124 datagram that the Interface supports. 126 SPI: The Security Parameter Index. 128 3. Problem Space 130 3.1. Time to complete move 132 Most mobility environments are built with a "break then make" model 133 for connectivity. Thus there is measurable time between the old 134 address being unusable and the new address being functional. Adding 135 mobility convergence times just further aggravates the delay which 136 negatively impacts the user experience. 138 The "make then break" model for connectivity is supported via HIP 139 multihoming and is the subject of a separate recommendation. 141 HIP mobility relies on a 3 packet UPDATE exchange which in some cases 142 can be optimized to 2 packets. This can be further delayed in a 143 "double-jump" scenario with waiting for the direct connection to fail 144 before falling over to contacting the peer's RVS. These processes 145 have resulted in other technologies to be preferred over HIP as they 146 have faster convergence even if they achieve this while sacrificing 147 security. 149 3.2. Apriori move knowledge 151 A HIP Host that has the potential to 'move' (acquire a new address 152 for an interface) during the lifetime of a HIP association SHOULD be 153 registered to an RVS. Such a HIP host SHOULD always inform its peer 154 of its RVS address, as it may experience a "Double-Jump" move as in 155 Section 6. 157 In an RVS assisted base exchange, the Responder ensures the Initiator 158 knows its RVS with the VIA_RVS parameter in the R1 as specified in 159 HIP Rendezvous Extension [RFC8004]. However, the Responder has no 160 mechanism to learn the Initiator's RVS address. Additionally, it is 161 possible for an Initiator to directly contact the Responder and thus 162 not learn about the Responder's RVS in the base exchange. 164 A host may not publish its RVS if it does not wish to be easily 165 discovered. It still should notify its peers of its RVS if it 166 expects to be found in some move scenarios. 168 The HIP base exchange needs to include more RVS information. 170 4. Enhanced availability of VIA_RVS 172 The VIA_RVS parameter is defined in HIP Rendezvous Extension 173 [RFC8004] for use in R1, but only identifies the Responder's RVS to 174 the Initiator when the I1 was routed through the RVS. 176 Firstly, a Responder SHOULD always provide its VIA_RVS information in 177 R1 even when the I1 came directly from the Initiator. Secondly, the 178 Initiator SHOULD always provide its VIA_RVS information in I2. The 179 VIA_RVS address is always maintained as part of the HIT to IP 180 addressing information. Through these two expansions in the 181 availability of VIA_RVS, the hosts are assured to possess their 182 peer's RVS address to "shotgun" UPDATEs and thus accelerate mobility. 184 5. Single move mobility 186 Data traffic between host A and B may use ESP with HIP [RFC7402] or 187 any other tunneling protocol. In ESP the relationship of the tunnel 188 SAs with the HIP SA puts a high level of trust on the following fast 189 mobility. 191 5.1. Piggybacking impact on transport window size 193 The following sections define the operation of a HIP UPDATE payload 194 followed by some transport (e.g. TCP or UDP) payload in a single IP 195 datagram. This multicontent IP datagram works best with a smaller 196 window size for the higher layer. The normal operation is to compare 197 the size of the transport datagram plus HIP UPDATE payload and ensure 198 it is less than the MTU. An implementation may be able to adjust the 199 transport window size downward so that the higher layer could still 200 fill it and the whole piece then still fit within the MTU. 202 5.2. Environment 204 * Host A is mobile. 206 * Host B may be mobile, but not changing IP address at this time. 208 * Only Host A is moving in the network and changing its IP address. 210 * Host A and B share a HIP Security Association. 212 * Host A and B are registered to a RVS server, not necessarily the 213 same and each has the others RVS address. 215 5.3. Scenario 1: Neither host has data to transmit 217 Host A triggers a HIP mobility UPDATE with Locator to inform Host B 218 of new address. Host B, upon validating Host A HIP UPDATE, continues 219 with Address Verification. 221 5.4. Scenario 2: Host A has data to transmit 223 5.4.1. IPv6 datagram + HIP UPDATE > MTU 225 Host A triggers a HIP mobility UPDATE with Locator to inform Host B 226 of new address. As the UPDATE + datagram would exceed the MTU, the 227 datagram is sent separately after receipt of the HIP UPDATE from Host 228 B. 230 The HIP UPDATE packets vary in length as follows: 232 Move notification: 302 bytes - UPDATE(ESP_INFO, LOCATOR, SEQ, HMAC, 233 HIP_SIGNATURE) 235 Move verification: 286 bytes - UPDATE(ESP_INFO, SEQ, ACK, HMAC, 236 HIP_SIGNATURE, ECHO_REQUEST_UNSIGNED) 238 Verification ack: 262 bytes - UPDATE(ESP_INFO, ACK, HMAC, 239 HIP_SIGNATURE, ECHO_RESPONSE_UNSIGNED) 241 5.4.2. IPv6 datagram + HIP UPDATE <= MTU 243 Host A sends HIP UPDATE with Locator to inform Host B of new address. 244 Datagram is appended to HIP UPDATE using Next Header. Host B, upon 245 validating Host A HIP UPDATE, sends next header to proper module and 246 continues with Address Verification. This datagram is processed even 247 though the address is UNVERIFIED. 249 The ESP anti-replay window managed by its envelope sequence number 250 can protect against replayed UPDATE+ESP packets prior to address 251 verification. 253 5.5. Scenario 3: Host B has data to transmit 255 After Host B receives a HIP mobility UPDATE from A it has data to 256 send to A. Or Host B may have been sending data to Host A while Host 257 A was moving. The old data may have been lost; for example the data 258 is over UDP with no keepalives during the move time. The old data 259 may be in a retransmission state; for example the data is over TCP. 260 Or the data reached the interface from the higher layer at the same 261 time that the HIP UPDATE with new locator was successfully processed. 263 5.5.1. IPv6 datagram + HIP UPDATE > MTU 265 Host B sends the HIP UPDATE validation followed by the IPv6 datagram. 266 Host B may place the address in ACTIVE state or wait from HIP UPDATE 267 confirmation from Host A. 269 5.5.2. IPv6 datagram + HIP UPDATE <= MTU 271 Host B sends the HIP UPDATE validation within the IPv6 datagram. 272 Host B may place the address in ACTIVE state or wait from HIP UPDATE 273 confirmation from Host A. 275 6. Double-Jump mobility 277 The HIP mobility UPDATE will fail without the use of RVS. In fact 278 both RVS are needed for both UPDATEs to find its peer. This is why 279 the "shotgun" acceleration SHOULD always be used when the peer's RVS 280 is known. 282 6.1. Environment 284 * Both host A and B are mobile. 286 * Host A and B share a HIP Security Association. 288 * Both hosts move in the network and change their IP addresses. 289 Before either receives the others HIP mobility UPDATE. 291 * Host A and B are registered to a RVS server, not necessarily the 292 same and each has the others RVS address. 294 6.2. Shotgunning UPDATEs 296 Shotgunning is the process of sending the same UPDATE to more than 297 one LOCATOR. In particular it refers to sending the UPDATE to at 298 least the peer's last known IP address and to its RVS address learned 299 from the VIA_RVS for either the R1 or I2 packet. 301 A host MUST be prepared to receive and discard multiple HIP mobility 302 UPDATEs. The duplicates will be readily identified as having the 303 same SEQ (UPDATE sequence umber). 305 Shotgunning SHOULD always be used when an RVS is known. A peer never 306 knows of a "double-jump" event until after it receives its peer's 307 UPDATE. 309 6.3. Neither host has data to transmit 311 Host A triggers a HIP mobility UPDATE with Locator to inform Host B 312 of new address. Host B, upon validating Host A HIP UPDATE, continues 313 with Address Verification. 315 No attempt should be made to piggyback the two UPDATE processes. 316 They may run simultaneously but not in the same IP datagrams. 318 6.4. Either host has data to transmit 320 The following acceleration advice presents a number of challenges. 321 The best rule of thumb is to send the data as soon as possible. 323 6.4.1. IPv6 datagram + HIP UPDATE > MTU 325 Same process as Section 6.3 327 6.4.2. IPv6 datagram + HIP UPDATE <= MTU 329 Host A sends HIP UPDATE with Locator to inform Host B of new address. 330 Datagram is appended to HIP UPDATE using Next Header. Host B, may 331 have already sent a datagram with its original HIP UPDATE. If since 332 then a receipt of Host A's UPDATE it has more data to transmit, upon 333 validating Host A HIP UPDATE, sends next header to proper module and 334 continues with Address Verification. This datagram is processed even 335 though the address is UNVERIFIED. 337 7. IANA Considerations 339 The following change to the "Host Identity Protocol (HIP) Parameters" 340 registries has been made: 342 The PAYLOAD_MIC parameter used here is defined in HICCUPS which is an 343 Experimental RFC. Here it is being used in a Standards Track 344 document. 346 8. Security Considerations 348 HIP fast mobility does not introduce any new security considerations 349 beyond that in HIP Host Mobility [RFC8046]. If anything its 350 requirement to know and use the RVS for a peer improve the frequency 351 of a successful mobility notification. 353 9. Acknowledgments 355 The term "shotgun" for fast mobility comes from the InfraHIP project. 356 The HIP UPDATE lengths were supplied by Jeff Ahrenholz. 358 Sue Hares of Huawei and Jeff Ahrenholz of Tempered Networks 359 contributed to the clarity in this document. 361 10. References 363 10.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 371 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 372 May 2017, . 374 10.2. Informative References 376 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 377 Encapsulating Security Payload (ESP) Transport Format with 378 the Host Identity Protocol (HIP)", RFC 7402, 379 DOI 10.17487/RFC7402, April 2015, 380 . 382 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 383 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 384 October 2016, . 386 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 387 with the Host Identity Protocol", RFC 8046, 388 DOI 10.17487/RFC8046, February 2017, 389 . 391 Authors' Addresses 393 Robert Moskowitz 394 HTT Consulting 395 Oak Park, MI 48237 396 United States of America 398 Email: rgm@labs.htt-consult.com 400 Stuart W. Card 401 AX Enterprize 402 4947 Commercial Drive 403 Yorkville, NY 13495 404 United States of America 406 Email: stu.card@axenterprize.com 408 Adam Wiethuechter 409 AX Enterprize 410 4947 Commercial Drive 411 Yorkville, NY 13495 412 United States of America 414 Email: adam.wiethuechter@axenterprize.com