idnits 2.17.1 draft-smyslov-ipsecme-ikev2-r-mobike-07.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 (November 30, 2020) is 1236 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 (if approved) November 30, 2020 5 Intended status: Standards Track 6 Expires: June 3, 2021 8 Responder Initiated IP Addresses Update in MOBIKE 9 draft-smyslov-ipsecme-ikev2-r-mobike-07 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 https://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 June 3, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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. 147 Obviously, this limitation comes from the fact that there might be 148 middleboxes on the path like Network Address Translators (NAT) or 149 firewalls, that might disallow IP packets to come from VPN gateway to 150 the client unless the client first contacts the VPN gateway. For 151 example, the client might reside behind a dynamic NAT that creates a 152 mapping when IP packet first come from the client to the gateway. If 153 the gateway tries to send an IP packet to the client from different 154 IP address, the packet would be dropped since the NAT box has no 155 corresponding mapping. 157 This specification provides the following solution to the described 158 problem. When the Responder decides that its end of existing SA 159 should be switched from its original IP address IP_R1 to a new 160 address IP_R2, it initiates an INFORMATIONAL exchange containing a 161 new notification SWITCH_TO_IP_ADDRESS, that contains IP_R2. Once the 162 Initiator completes an exchange containing SWITCH_TO_IP_ADDRESS 163 notification, it immediately initiates standard MOBIKE procedure for 164 updating SA addresses by starting the INFORMATIONAL exchange 165 containing UPDATE_SA_ADDRESSES notification. 167 4. Protocol Description 169 4.1. Capability Advertising 171 According to [RFC4555], the peers must exchange MOBIKE_SUPPORTED 172 notifications in the IKE_AUTH exchange before they can use the MOBIKE 173 protocol. If the Initiator supports this specification and is 174 willing to use it, then it MUST include a single octet 0x52 ('R') in 175 the notification data of the MOBIKE_SUPPORTED notification sent to 176 the Responder. There is no need for the Initiator to know whether 177 the Responder supports this specification or not, so the 178 MOBIKE_SUPPORTED notification sent by the Responder has an empty 179 notification data. 181 Note, that [RFC4555] specifies that MOBIKE_SUPPORTED notification 182 must contains no data when sending and the content of the 183 notification data must be ignored while parsing. So, if the 184 Responder doesn't support this specification, it will just ignore the 185 content of the MOBIKE_SUPPORTED notification and will use MOBIKE 186 without this extension. 188 (IP_I1:500 -> IP_R1:500) 189 HDR, SAi1, KEi, Ni, 190 N(NAT_DETECTION_SOURCE_IP), 191 N(NAT_DETECTION_DESTINATION_IP) --> 193 <-- (IP_R1:500 -> IP_I1:500) 194 HDR, SAr1, KEr, Nr, 195 N(NAT_DETECTION_SOURCE_IP), 196 N(NAT_DETECTION_DESTINATION_IP) 198 (IP_I1:4500 -> IP_R1:4500) 199 HDR, SK { IDi, CERT, AUTH, 200 SAi2, TSi, TSr, 201 N(MOBIKE_SUPPORTED('R')) } --> 203 <-- (IP_R1:4500 -> IP_I1:4500) 204 HDR, SK { IDr, CERT, AUTH, 205 SAr2, TSi, TSr, 206 N(MOBIKE_SUPPORTED), 207 N(ADDITIONAL_IP4_ADDRESS) } 209 4.2. Responder Initiated IP Address Update 211 If the Initiator advertised its support for this specification during 212 the initial exchange as described in Section 4.1, then the Responder 213 is free to initiate IP Address Update request at any time. If the 214 Initiator doesn't indicate its support for this extension, then the 215 Responder MUST NOT initiate IP Address Update request. The IP 216 Address Update request NUST NOT be initiated by the Initiator, the 217 Responder MUST NOT take any action if it receives such a request 218 (apart from sending an empty response message to complete the 219 exchange). 221 It is up to the Responder to decide when to initiate an IP Address 222 request and what new address to include into it. Some of the 223 possible reasons are: 225 o Responder is multihomed and wishes to switch SA to a different IP 226 address 228 o Responder is a cluster and wishes to move SA to a different node 229 having its own IP address 231 The Responder requests the Initiator to update SA Address by 232 initiating the INFORMATIONAL exchange containing a new status type 233 notification SWITCH_TO_IP_ADDRESS. Its notification data contains a 234 new IP address the Responder requests the Initiator to use for the 235 IKE SA and its Child SAs. In the example below the SA was 236 established using IP_I1 and IP_R1 addresses for the Initiator and 237 Responder respectively, and the Responder wishes to change the 238 address of its end of the SA to IP_R2. So, it initiates the 239 INFORMATIONAL exchange from IP_R1 address containing the 240 SWITCH_TO_IP_ADDRESS notification with IP_R2 address. 242 <-- (IP_R1:4500 -> IP_I1:4500) 243 HDR, SK { N(SWITCH_TO_IP_ADDRESS(IP_R2)) } 244 (IP_I1:4500 -> IP_R1:4500) 245 HDR, SK {} --> 247 Upon receiving the SWITCH_TO_IP_ADDRESS notification the Initiator 248 extracts its content and makes a decision whether the received IP 249 address is appropriate for the SA. If the received IP address is 250 among the addresses previously received from the Responder in 251 ADDITIONAL_IP4_ADDRESS or ADDITIONAL_IP6_ADDRESS notifications, then 252 it is definitely appropriate for the SA. Otherwise local policy must 253 be consulted to decide whether the received IP is appropriate. If 254 the address is considered inappropriate, then the Initiator MUST 255 current address. It is RECOMMENDED that the Initiator immediately 256 initiates Liveness Check exchange to ensure that the Responder is 257 able to operate using its current address. 259 If the Initiator makes a decision that the received address is 260 appropriate the Initiator initiates an IP address update procedure 261 according to the MOBIKE specification by sending an INFORMATIONAL 262 exchange request message containing the UPDATE_SA_ADDRESSES 263 notification. See [RFC4555] for details. As a result, the remote IP 264 address of the SA is changed from IP_R1 to IP_R2. Note that only the 265 IP address is changed, the port remains the same. 267 (IP_I1:4500 -> IP_R2:4500) 268 HDR, SK { N(UPDATE_SA_ADDRESSES), 269 N(NAT_DETECTION_SOURCE_IP), 270 N(NAT_DETECTION_DESTINATION_IP), 271 N(COOKIE2) } --> 273 <-- (IP_R2:4500 -> IP_I1:4500) 274 HDR, SK { N(NAT_DETECTION_SOURCE_IP), 275 N(NAT_DETECTION_DESTINATION_IP), 276 N(COOKIE2) } 278 The Responder MUST NOT change IP addresses of the SA until it 279 receives the UPDATE_SA_ADDRESSES notification from the Initiator. 281 5. Payload Formats 283 5.1. MOBIKE_SUPPORTED Notification 285 The MOBIKE_SUPPORTED Notification is defined in [RFC4555], 286 Section 4.2.1 with the Notify Message Type 16396. This definition 287 requires the notification data to be empty while sending and to be 288 ignored when notification is received. 290 This document updates the definition from [RFC4555]. Exchange 291 Initiator sets the notification data of the MOBIKE_SUPPORTED 292 Notification to a single octet 0x52 ('R') to indicate that this 293 specification is supported. 295 5.2. SWITCH_TO_IP_ADDRESS Notification 297 The Notify Message Type for this notification is . The 298 notification data contains new Responder's IP address. 300 For IPv4, the notification data is 4 octets long and is defined as 301 follows: 303 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | New Responder's IPv4 Address | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 For IPv6, the notification data is 16 octets long and is defined as 310 follows: 312 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 | New Responder's IPv6 Address | 317 | | 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 The Protocol ID and SPI Size fields are set to zero. 323 6. Security Considerations 325 This specification is an extension of the MOBIKE protocol, so the 326 Security Considerations described in [RFC4555] are applied. 328 7. IANA Considerations 330 This document defines new Notify Message Types in the "IKEv2 Notify 331 Message Types - Status Types" registry: 333 SWITCH_TO_IP_ADDRESS 335 8. References 337 8.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 349 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 350 . 352 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 353 Kivinen, "Internet Key Exchange Protocol Version 2 354 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 355 2014, . 357 8.2. Informative References 359 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 360 the Internet Key Exchange Protocol Version 2 (IKEv2)", 361 RFC 5685, DOI 10.17487/RFC5685, November 2009, 362 . 364 [RFC7791] Migault, D., Ed. and V. Smyslov, "Cloning the IKE Security 365 Association in the Internet Key Exchange Protocol Version 366 2 (IKEv2)", RFC 7791, DOI 10.17487/RFC7791, March 2016, 367 . 369 Author's Address 370 Valery Smyslov 371 ELVIS-PLUS 372 PO Box 81 373 Moscow (Zelenograd) 124460 374 Russian Federation 376 Phone: +7 495 276 0211 377 Email: svan@elvis.ru