idnits 2.17.1 draft-smyslov-ipsecme-ikev2-r-mobike-04.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 ([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 31, 2019) is 1785 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: 'RFC6311' is defined on line 355, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 (if approved) May 31, 2019 5 Intended status: Standards Track 6 Expires: December 2, 2019 8 Responder Initiated IP Addresses Update in MOBIKE 9 draft-smyslov-ipsecme-ikev2-r-mobike-04 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]. 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 2, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. MOBIKE_SUPPORTED Notification . . . . . . . . . . . . . . 7 64 5.2. SWITCH_TO_IP_ADDRESS Notification . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The Internet Key Exchange protocol version 2 (IKEv2), specified in 75 [RFC7296], is a key part of the IP Security (IPsec) architecture. It 76 allows peers to perform authenticated key exchange, which results in 77 establishing IKE Security Association (IKE SA) and to create a data 78 protection channels called IPsec Security Associations (IPsec SAs). 79 In original IKEv2 the IKE and IPsec SAs are established between the 80 IP addresses used in IKEv2 negotiation. The IKEv2 Mobility and 81 Multihoming Protocol (MOBIKE), specified in [RFC4555], extends the 82 IKEv2 functionality by allowing peers to dynamically change IP 83 addresses of the established SAs without the need to re-establish 84 these SAs. 86 The main use case for the MOBIKE protocol is a remote access user 87 that travels and moves from one IP address to another without re- 88 establishing existing SAs with the VPN gateway. However, the MOBIKE 89 also supports more complex scenarios when VPN gateway is multihomed 90 and its addresses may change over time. 92 In the MOBIKE it is the original Initiator of the IKE SA (e.g. the 93 remote access client) who is responsible for detecting the working IP 94 addresses pairs and for deciding which pair to use. In other words, 95 the Responder (e.g. the VPN gateway) plays a passive role and could 96 neither initiate the IP address update process nor tell the Initiator 97 which IP address is preferred to use. This limitation makes use of 98 complex scenarios less efficient and decreases the value of MOBIKE 99 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 new IKE SA to be 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 periodically 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. Once the 165 Initiator completes an exchange containing SWITCH_TO_IP_ADDRESS 166 notification, it immediately initiates standard MOBIKE procedure for 167 updating SA addresses by starting the INFORMATIONAL exchange 168 containing UPDATE_SA_ADDRESSES notification. 170 4. Protocol Description 172 4.1. Capability Advertising 174 According to [RFC4555], the peers must exchange MOBIKE_SUPPORTED 175 notifications in the IKE_AUTH exchange before they can use the MOBIKE 176 protocol. If the Initiator supports this specification and is 177 willing to use it, then it MUST include a single octet 0x52 ('R') in 178 the notification data of the MOBIKE_SUPPORTED notification sent to 179 the Responder. There is no need for the Initiator to know whether 180 the Responder supports this specification or not, so the 181 MOBIKE_SUPPORTED notification sent by the Responder has an empty 182 notification data. 184 Note, that [RFC4555] specifies that MOBIKE_SUPPORTED notification 185 must contains no data when sending and the content of the 186 notification data must be ignored while parsing. So, if the 187 Responder doesn't support this specification, it will just ignore the 188 content of the MOBIKE_SUPPORTED notification and will use MOBIKE 189 without this extension. 191 (IP_I1:500 -> IP_R1:500) 192 HDR, SAi1, KEi, Ni, 193 N(NAT_DETECTION_SOURCE_IP), 194 N(NAT_DETECTION_DESTINATION_IP) --> 196 <-- (IP_R1:500 -> IP_I1:500) 197 HDR, SAr1, KEr, Nr, 198 N(NAT_DETECTION_SOURCE_IP), 199 N(NAT_DETECTION_DESTINATION_IP) 201 (IP_I1:4500 -> IP_R1:4500) 202 HDR, SK { IDi, CERT, AUTH, 203 SAi2, TSi, TSr, 204 N(MOBIKE_SUPPORTED('R')) } --> 206 <-- (IP_R1:4500 -> IP_I1:4500) 207 HDR, SK { IDr, CERT, AUTH, 208 SAr2, TSi, TSr, 209 N(MOBIKE_SUPPORTED), 210 N(ADDITIONAL_IP4_ADDRESS) } 212 4.2. Responder Initiated IP Address Update 214 If the Initiator advertised its support for this specification during 215 the initial exchange as described in Section 4.1, then the Responder 216 is free to initiate IP Address Update request at any time. If the 217 Initiator doesn't indicate its support for this extension, then the 218 Responder MUST NOT initiate IP Address Update request. The IP 219 Address Update request NUST NOT be initiated by the Initiator, the 220 Responder MUST NOT take any action if it receives such a request 221 (apart from sending an empty response message to complete the 222 exchange). 224 It is up to the Responder to decide when to initiate an IP Address 225 request and what new address to include into it. Some of the 226 possible reasons are: 228 o Responder is multihomed and wishes to switch SA to a different IP 229 address 231 o Responder is a cluster and wishes to move SA to a different node 232 having its own IP address 234 The Responder requests the Initiator to update SA Address by 235 initiating the INFORMATIONAL exchange containing a new status type 236 notification SWITCH_TO_IP_ADDRESS. Its notification data contains a 237 new IP address the Responder requests the Initiator to use for the 238 IKE SA and its Child SAs. In the example below the SA was 239 established using IP_I1 and IP_R1 addresses for the Initiator and 240 Responder respectively, and the Responder wishes to change the 241 address of its end of the SA to IP_R2. So, it initiates the 242 INFORMATIONAL exchange from IP_R1 address containing the 243 SWITCH_TO_IP_ADDRESS notification with IP_R2 address. 245 <-- (IP_R1:4500 -> IP_I1:4500) 246 HDR, SK { N(SWITCH_TO_IP_ADDRESS(IP_R2)) } 247 (IP_I1:4500 -> IP_R1:4500) 248 HDR, SK {} --> 250 Upon receiving the SWITCH_TO_IP_ADDRESS notification the Initiator 251 extracts its content and makes a decision whether the received IP 252 address is appropriate for the SA. If the received IP address is 253 among the addresses previously received from the Responder in 254 ADDITIONAL_IP4_ADDRESS or ADDITIONAL_IP6_ADDRESS notifications, then 255 it is definitely appropriate for the SA. Otherwise local policy must 256 be consulted to decide whether the received IP is appropriate. If 257 the address is considered inappropriate, then the Initiator MUST 258 current address. It is RECOMMENDED that the Initiator immediately 259 initiates Liveness Check exchange to ensure that the Responder is 260 able to operate using its current address. 262 If the Initiator makes a decision that the received address is 263 appropriate the Initiator initiates an IP address update procedure 264 according to the MOBIKE specification by sending an INFORMATIONAL 265 exchange request message containing the UPDATE_SA_ADDRESSES 266 notification. See [RFC4555] for details. As a result, the remote IP 267 address of the SA is changed from IP_R1 to IP_R2. Note that only the 268 IP address is changed, the port remains the same. 270 (IP_I1:4500 -> IP_R2:4500) 271 HDR, SK { N(UPDATE_SA_ADDRESSES), 272 N(NAT_DETECTION_SOURCE_IP), 273 N(NAT_DETECTION_DESTINATION_IP), 274 N(COOKIE2) } --> 276 <-- (IP_R2:4500 -> IP_I1:4500) 277 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 278 N(NAT_DETECTION_DESTINATION_IP), 279 N(COOKIE2) } 281 The Responder MUST NOT change IP addresses of the SA until it 282 receives the UPDATE_SA_ADDRESSES notification from the Initiator. 284 5. Payload Formats 286 5.1. MOBIKE_SUPPORTED Notification 288 The MOBIKE_SUPPORTED Notification is defined in [RFC4555], 289 Section 4.2.1 with the Notify Message Type 16396. This definition 290 requires the notification data to be empty while sending and to be 291 ignored when notification is received. 293 This document updates the definition from [RFC4555]. Exchange 294 Initiator sets the notification data of the MOBIKE_SUPPORTED 295 Notification to a single octet 0x52 ('R') to indicate that this 296 specification is supported. 298 5.2. SWITCH_TO_IP_ADDRESS Notification 300 The Notify Message Type for this notification is . The 301 notification data contains new Responder's IP address. 303 For IPv4, the notification data is 4 octets long and is defined as 304 follows: 306 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | New Responder's IPv4 Address | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 For IPv6, the notification data is 16 octets long and is defined as 313 follows: 315 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 | New Responder's IPv6 Address | 320 | | 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 The Protocol ID and SPI Size fields are set to zero. 326 6. Security Considerations 328 This specification is an extension of the MOBIKE protocol, so the 329 Security Considerations described in [RFC4555] are applied. 331 7. IANA Considerations 333 This document defines new Notify Message Types in the "IKEv2 Notify 334 Message Types - Status Types" registry: 336 SWITCH_TO_IP_ADDRESS 338 8. References 340 8.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, . 347 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 348 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 349 May 2017, . 351 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 352 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 353 . 355 [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. 356 Zhang, "Protocol Support for High Availability of IKEv2/ 357 IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, 358 . 360 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 361 Kivinen, "Internet Key Exchange Protocol Version 2 362 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 363 2014, . 365 8.2. Informative References 367 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 368 the Internet Key Exchange Protocol Version 2 (IKEv2)", 369 RFC 5685, DOI 10.17487/RFC5685, November 2009, 370 . 372 [RFC7791] Migault, D., Ed. and V. Smyslov, "Cloning the IKE Security 373 Association in the Internet Key Exchange Protocol Version 374 2 (IKEv2)", RFC 7791, DOI 10.17487/RFC7791, March 2016, 375 . 377 Author's Address 379 Valery Smyslov 380 ELVIS-PLUS 381 PO Box 81 382 Moscow (Zelenograd) 124460 383 Russian Federation 385 Phone: +7 495 276 0211 386 Email: svan@elvis.ru