idnits 2.17.1 draft-smyslov-ipsecme-ikev2-r-mobike-02.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 ([RFC6311], [RFC4555]), 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 (Using the creation date from RFC4555, updated by this document, for RFC5378 checks: 2005-06-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 30, 2018) is 2158 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: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Updates: 4555, 6311 (if approved) May 30, 2018 5 Intended status: Standards Track 6 Expires: December 1, 2018 8 Responder Initiated IP Addresses Update in MOBIKE 9 draft-smyslov-ipsecme-ikev2-r-mobike-02 11 Abstract 13 IKEv2 Mobility and Multihoming Protocol (MOBIKE), defined in 14 [RFC4555] allows peers to update their IP addresses without re- 15 establishing IKE and IPsec Security Associations (SAs). In the 16 MOBIKE protocol it is the Initiator of the IKE SA, who is responsible 17 for selecting new SA addresses and for initiating the IP addresses 18 update procedure. This document presents an extension to the MOBIKE 19 protocol that allows the Responder to initiate IP address update. 20 The document updates [RFC4555] and [RFC6311]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 1, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Capability Advertising . . . . . . . . . . . . . . . . . 4 61 4.2. Responder Initiated IP Address Update . . . . . . . . . . 5 62 4.2.1. High Availability Cluster Scenario . . . . . . . . . 7 63 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. MOBIKE_SUPPORTED Notification . . . . . . . . . . . . . . 8 65 5.2. SWITCH_TO_IP_ADDRESS Notification . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 The Internet Key Exchange protocol version 2 (IKEv2), specified in 76 [RFC7296], is a key part of the IP Security (IPsec) architecture. It 77 allows peers to perform authenticated key exchange, which results in 78 establishing IKE Security Association (IKE SA) and to create a data 79 protection channels called IPsec Security Associations (IPsec SAs). 80 In original IKEv2 the IKE and IPsec SAs are established between the 81 IP addresses used in IKEv2 negotiation. The IKEv2 Mobility and 82 Multihoming Protocol (MOBIKE), specified in [RFC4555], extends the 83 IKEv2 functionality by allowing peers to dynamically change IP 84 addresses of the established SAs without the need to re-establish 85 these SAs. 87 The main use case for the MOBIKE protocol is a remote access user 88 that travels and moves from one from one IP address to another 89 without re-establishing existing SAs with the VPN gateway. However, 90 the MOBIKE also supports more complex scenarios when VPN gateway is 91 multihomed and its addresses may change over time. 93 In the MOBIKE it is the Initiator (e.g. the remote access client) who 94 is responsible for detecting the working IP addresses pairs and for 95 deciding which pair to use. In other words, the Responder (e.g. the 96 VPN gateway) plays a passive role and could neither initiate the IP 97 address update process nor tell the Initiator which IP address is 98 preferred to use. This limitation makes use of complex scenarios 99 less efficient and decreases the value of MOBIKE protocol. 101 For example, if the VPN gateway is a load sharing cluster where each 102 node has its own IP address, then the cluster must be able to move SA 103 between nodes depending on their current load. Currently Redirect 104 Mechanism for IKEv2 [RFC5685] can accomplish this task, however it 105 requires IKE SA to be re-established, that is very inefficient. 106 Another possible solution is to use IKE SA Cloning along with the 107 MOBIKE (see [RFC7791] for scenario description), but the limitation 108 of the MOBIKE protocol makes this problematic. Obviously, the client 109 has insufficient information to select when and to which of cluster 110 IP addresses to move an SA to and the VPN gateway has no means to 111 provide the client with this information. 113 This specification extends the MOBIKE protocol by adding ability for 114 the Responder to ask the Initiator for IP address update and to 115 provide it with the new IP address to use. 117 2. Terminology and Notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 In this document the term "Initiator" means the party who originally 126 initiated the first IKE SA (in a series of possibly several rekeyed 127 IKE SAs), and "Responder" means the other party. This is consistent 128 with a way these terms are used in [RFC4555]. Note, that in 129 [RFC7296] the terms "original initiator" and "original responder" 130 mean the party, who initiated (or responded to) the latest IKE SA in 131 a series of possibly several rekeyed IKE SAs. 133 3. Protocol Overview 135 The MOBIKE protocol is designed in such a way, that it is the IKE SA 136 Initiator, who is responsible for performing the actions concerned 137 with the selecting of a working IP addresses pair and for initiating 138 an IP addresses update exchange. Usually the Initiator selects an IP 139 addresses pair by continuously probing different pairs and choosing 140 the working one. If several pairs work then the choice between them 141 is arbitrary. The Responder cannot influence the process of 142 selecting and cannot ask the client to immediately switch to a 143 particular gateway's address. As a result the process of selection a 144 new pair takes substantial time and may ends up with a suboptimal 145 path. Moreover, in case the Responder isn't multihomed (and thus 146 doesn't provide the Initiator with a list of additional IP 147 addresses), the change of its IP address cannot be handled by the 148 MOBIKE. 150 Obviously, this limitation comes from the fact that there might be 151 middleboxes on the path (like Network Address Translators (NAT) or 152 firewalls) that might disallow IP packets to come from VPN gateway to 153 the client unless the client first contacts the VPN gateway. For 154 example, the client might reside behind a dynamic NAT that creates a 155 mapping when IP packet first come from the client to the gateway. If 156 the gateway tries to send an IP packet to the client from different 157 IP address, the packet would be dropped since the NAT box has no 158 corresponding mapping. 160 This specification provides the following solution to the described 161 problem. When the Responder decides that its end of existing SA 162 should be switched from its original IP address IP_R1 to a new 163 address IP_R2, it initiates an INFORMATIONAL exchange containing a 164 new notification SWITCH_TO_IP_ADDRESS, that contains IP_R2. The 165 request message of this exchange is sent from IP_R1 address, so that 166 an existing middlebox mappings are used and the message can reach the 167 Initiator. However, the response message is sent to a newly 168 presented IP_R2 address, so that a new middlebox mappings are 169 created. Once the Initiator completes exchange containing 170 SWITCH_TO_IP_ADDRESS notification, it immediately initiates standard 171 MOBIKE procedure for updating SA addresses by starting the 172 INFORMATIONAL exchange containing UPDATE_SA_ADDRESSES notification. 174 4. Protocol Description 176 4.1. Capability Advertising 178 According to [RFC4555], the peers must exchange MOBIKE_SUPPORTED 179 notifications in the IKE_AUTH exchange before they can use the MOBIKE 180 protocol. If the Initiator supports this specification and is 181 willing to use it, then it MUST include a single octet 0x52 ('R') in 182 the notification data of the MOBIKE_SUPPORTED notification sent to 183 the Responder. There is no need for the Initiator to know whether 184 the Responder supports this specification or not, so the 185 MOBIKE_SUPPORTED notification sent by the Responder has an empty 186 notification data. 188 Note, that [RFC4555] specifies that MOBIKE_SUPPORTED notification 189 must contains no data when sending and the content of the 190 notification data must be ignored while parsing. So, So, if the 191 Responder doesn't support this specification, it will just ignore the 192 content of the MOBIKE_SUPPORTED notification and will use MOBIKE 193 without this extension. 195 (IP_I1:500 -> IP_R1:500) 196 HDR, SAi1, KEi, Ni, 197 N(NAT_DETECTION_SOURCE_IP), 198 N(NAT_DETECTION_DESTINATION_IP) --> 200 <-- (IP_R1:500 -> IP_I1:500) 201 HDR, SAr1, KEr, Nr, 202 N(NAT_DETECTION_SOURCE_IP), 203 N(NAT_DETECTION_DESTINATION_IP) 205 (IP_I1:4500 -> IP_R1:4500) 206 HDR, SK { IDi, CERT, AUTH, 207 SAi2, TSi, TSr, 208 N(MOBIKE_SUPPORTED('R')) } --> 210 <-- (IP_R1:4500 -> IP_I1:4500) 211 HDR, SK { IDr, CERT, AUTH, 212 SAr2, TSi, TSr, 213 N(MOBIKE_SUPPORTED), 214 N(ADDITIONAL_IP4_ADDRESS) } 216 4.2. Responder Initiated IP Address Update 218 If the Initiator advertised its support for this specification during 219 the initial exchange as described in Section 4.1, then the Responder 220 is free to initiate IP Address Update request at any time. If the 221 Initiator doesn't indicate its support for this extension, then the 222 Responder MUST NOT initiate IP Address Update request. The IP 223 Address Update request NUST NOT be initiated by the Initiator, the 224 Responder MUST take no action if it receives such a request (apart 225 from sending an empty response message to complete the exchange). 227 It is up to the Responder to decide when to initiate an IP Address 228 request and what new address to include into it. Some of the 229 possible reasons are: 231 o Responder is multihomed and wishes to switch SA to a different IP 232 address 234 o Responder is a cluster and wishes to move SA to a different node 235 having its own IP address 237 The Responder requests the Initiator to update SA Address by 238 initiating the INFORMATIONAL exchange containing a new status type 239 notification SWITCH_TO_IP_ADDRESS. The notification data of this 240 notification contains a new IP address the Responder requests the 241 Initiator to use for the IKE SA and its Child SAs. Note, that the 242 exchange request message MUST be sent using old SA addresses. In the 243 example below the SA was established using IP_I1 and IP_R1 addresses 244 for the Initiator and Responder respectively, and the Responder 245 wishes to change the address of its end of the SA to IP_R2. So, it 246 initiates the INFORMATIONAL exchange from IP_R1 address containing 247 the SWITCH_TO_IP_ADDRESS notification with IP_R2 address. However, 248 since the response message should come on a new address (IP_R2), at 249 this point the Responder MUST be able to receive packets on the IP 250 address it included in the SWITCH_TO_IP_ADDRESS notification. 252 <-- (IP_R1:4500 -> IP_I1:4500) 253 HDR, SK { N(SWITCH_TO_IP_ADDRESS(IP_R2)) } 255 Since the request is sent using old SA addresses, it is expected to 256 pass through the middleboxes and reach the Initiator because it must 257 use existing mappings. 259 Upon receiving the SWITCH_TO_IP_ADDRESS notification the Initiator 260 extracts its content and makes a decision whether the received IP 261 address is appropriate for the SA. If the received IP address is 262 among the addresses previously received from the Responder in 263 ADDITIONAL_IP4_ADDRESS or ADDITIONAL_IP6_ADDRESS notifications, then 264 it is definitely appropriate for the SA. Otherwise local policy must 265 be consulted to decide whether the received IP is appropriate. If 266 the address is considered inappropriate, then the Initiator MUST 267 complete the exchange by sending an empty message to an old address 268 (IP_R1) and continue to use this address. It is RECOMMENDED that the 269 Initiator immediately initiates Liveness Check exchange to ensure 270 that the Responder is able to operate using old address. 272 (IP_I1:4500 -> IP_R1:4500) 273 HDR, SK {} --> 275 If the Initiator decides that the received address is appropriate, it 276 completes the exchange by sending an empty response message to the 277 newly received address (IP_R2). Since the response message to the 278 new Responder's address flows in the original direction (from the 279 Initiator to the Responder), it should create new mappings in 280 middleboxes, thus allowing further communication between them. After 281 the response message is sent the Initiator MUST immediately initiate 282 an IP address update procedure according to the MOBIKE specification 283 by sending the INFORMATIONAL exchange request message containing the 284 UPDATE_SA_ADDRESSES notification. See [RFC4555] for details. As a 285 result, the remote IP address of the SA is changed from IP_R1 to 286 IP_R2. Note that only the IP address is changed, the port remains 287 the same. 289 (IP_I1:4500 -> IP_R2:4500) 290 HDR, SK {} --> 292 (IP_I1:4500 -> IP_R2:4500) 293 HDR, SK { N(UPDATE_SA_ADDRESSES), 294 N(NAT_DETECTION_SOURCE_IP), 295 N(NAT_DETECTION_DESTINATION_IP), 296 N(COOKIE2) } --> 298 <-- (IP_R2:4500 -> IP_I1:4500) 299 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 300 N(NAT_DETECTION_DESTINATION_IP), 301 N(COOKIE2) } 303 The Responder MUST NOT change IP address of the SA until it receives 304 the UPDATE_SA_ADDRESSES notification from the Initiator. Note, that 305 there is no need for the Responder to perform Return Routability 306 check once the addresses are updated since it itself requested to 307 change IP address of the SA and it successfully received a response 308 from the Initiator sent to the new address. However, depending on 309 the Responder's policy, the Return Routability check MAY be 310 performed. 312 If the Responder doesn't receive a response message on a request 313 containing the SWITCH_TO_IP_ADDRESS notification after several 314 retransmissions, then it means that either request or response 315 message cannot use the new path and pass through the middleboxes. In 316 this case the Responder's behavior depends on whether it advertised 317 additional IP addresses before and whether old SA address is still 318 available. 320 If old SA address is unavailable and no alternative addresses were 321 advertised before, then the IKE SA and all associated Child SAs MUST 322 be torn down. Otherwise the SA MAY be kept in an anticipation that 323 the Initiator after some time detects the old IP address failure 324 itself and performs IP addresses update. 326 4.2.1. High Availability Cluster Scenario 328 In case a VPN gateway is a cluster consisting of several nodes each 329 having its own IP address, both Load Sharing (LS) and High 330 Availability (HA) goals may be achieved. For the purposes of HA all 331 the nodes share an IKE SA state while only one of them communicate 332 with an IKE SA peer at any given time. If an active node fails, the 333 other nodes detect this fact and select a new active node for the SAs 334 the failed node served. The selected node must then instruct the 335 failed node peers to switch their SAs to a new IP address using this 336 specification. 338 Since some exchanges might be in progress when the active node fails, 339 special measures must be taken to ensure that the IKE SA state is 340 synchronized between the new active cluster node and the client. 341 Protocol Support for High Availability of IKEv2/IPsec [RFC6311] 342 describes the necessary measures. In particular, the new active node 343 initiates the INFORMATIONAL exchange containing the 344 IKEV2_MESSAGE_ID_SYNC notification and optionally the 345 IPSEC_REPLAY_COUNTER_SYNC notification. [RFC6311] states that no 346 other payload must be included in this exchange. However, in case 347 the IP address of the new active node differs from the IP address of 348 the failed active node it is necessary to combine the 349 IKEV2_MESSAGE_ID_SYNC and the SWITCH_TO_IP_ADDRESS notifications in 350 one exchange. So, this specification updates [RFC6311] in this 351 regard: if HA cluster nodes have different IP addresses then in case 352 of failover the request to synchronize Message IDs and the request to 353 change IP address MUST be sent together in the same INFORMATIONAL 354 exchange. 356 <-- (IP_R1:4500 -> IP_I1:4500) 357 HDR, SK { N(SWITCH_TO_IP_ADDRESS(IP_R2)) 358 N(IKEV2_MESSAGE_ID_SYNC), 359 [N(IPSEC_REPLAY_COUNTER_SYNC)] } 361 (IP_I1:4500 -> IP_R2:4500) 362 HDR, SK { N(IKEV2_MESSAGE_ID_SYNC) } --> 364 Once this exchange is completed the client MUST immediately perform 365 an IP address update procedure according to the MOBIKE specification 366 as described in Section 4.2. 368 5. Payload Formats 370 5.1. MOBIKE_SUPPORTED Notification 372 The MOBIKE_SUPPORTED Notification is defined in [RFC4555], 373 Section 4.2.1 with the Notify Message Type 16396. This definition 374 requires the notification data to be empty while sending and to be 375 ignored when notification is received. 377 This document updates the definition from [RFC4555]. Exchange 378 Initiator sets the notification data of the MOBIKE_SUPPORTED 379 Notification to a single octet 0x52 ('R') to indicate that this 380 specification is supported. 382 5.2. SWITCH_TO_IP_ADDRESS Notification 384 The Notify Message Type for this notification is . The 385 notification data contains new Responder's IP address. 387 For IPv4, the notification data is 4 octets long and is defined as 388 follows: 390 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | New Responder's IPv4 Address | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 For IPv6, the notification data is 16 octets long and is defined as 397 follows: 399 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 | New Responder's IPv6 Address | 404 | | 405 | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 The Protocol ID and SPI Size fields are set to zero. 410 6. Security Considerations 412 This specification is an extension of the MOBIKE protocol, so the 413 Security Considerations described in [RFC4555] are applied. 415 7. IANA Considerations 417 This document defines new Notify Message Types in the "IKEv2 Notify 418 Message Types - Status Types" registry: 420 SWITCH_TO_IP_ADDRESS 422 8. References 424 8.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, . 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 433 May 2017, . 435 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 436 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 437 . 439 [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. 440 Zhang, "Protocol Support for High Availability of IKEv2/ 441 IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, 442 . 444 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 445 Kivinen, "Internet Key Exchange Protocol Version 2 446 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 447 2014, . 449 8.2. Informative References 451 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 452 the Internet Key Exchange Protocol Version 2 (IKEv2)", 453 RFC 5685, DOI 10.17487/RFC5685, November 2009, 454 . 456 [RFC7791] Migault, D., Ed. and V. Smyslov, "Cloning the IKE Security 457 Association in the Internet Key Exchange Protocol Version 458 2 (IKEv2)", RFC 7791, DOI 10.17487/RFC7791, March 2016, 459 . 461 Author's Address 463 Valery Smyslov 464 ELVIS-PLUS 465 PO Box 81 466 Moscow (Zelenograd) 124460 467 Russian Federation 469 Phone: +7 495 276 0211 470 Email: svan@elvis.ru