idnits 2.17.00 (12 Aug 2021) /tmp/idnits43570/draft-mglt-ipsecme-mobikev2-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 (February 17, 2015) is 2643 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault (Ed) 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. Palomares 5 Expires: August 21, 2015 Orange/LIP6 6 February 17, 2015 8 MOBIKEv2: MOBIKE extension for Transport mode 9 draft-mglt-ipsecme-mobikev2-01.txt 11 Abstract 13 MOBIKE, the IKEv2 Mobility and Multihoming Protocol is defined only 14 for CHILD_SA using the tunnel mode. This document describes MOBIKEv2 15 that extends MOBIKE for CHILD_SA using also transport mode. 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 http://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 August 21, 2015. 34 Copyright Notice 36 Copyright (c) 2015 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 55 5. IKE_AUTH Exchange with MOBIKEv2 . . . . . . . . . . . . . . . 5 56 6. Updating IP addresses with MOBIKEv2 . . . . . . . . . . . . . 6 57 7. IPsec Databases Impacts . . . . . . . . . . . . . . . . . . . 7 58 7.1. Security Policy Database (SPD) . . . . . . . . . . . . . 8 59 7.2. Security Association Database (SAD) . . . . . . . . . . . 8 60 7.3. Peer Authentication Database (PAD) . . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Requirements notation 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. Terminology 74 This document uses the following terminology: 76 - Initiator: The Initiator is the peer that initiates an exchange. 77 It starts by sending a message towards the Responder. Note 78 that if two peers are connected, the Initiator of one exchange 79 can be the Responder of another exchange. 81 - Responder: The Responder is the peer receiving an exchange. The 82 message is sent from the Initiator. 84 - Security Policy (SP): is defined in section 4 of [RFC4301]. As 85 mobility or multihoming concerns an already established 86 session, SP mostly designate Security Policy in the SPD cache. 87 The SP contains the processing information like the IPsec mode, 88 the protocol to use as well as encryption and authorization 89 algorithms. SP also contains a binding to the appropriated 90 CHILD_SA. Binding between SP and CHILD_SA is described in 91 section 4.4.2.2 of [RFC4301] and in annex 1 of [RFC4555]. In 92 most cases the binding is performed using addresses of 93 implementation specific structures. 95 - Security Policy Database (SPD): is defined is defined in section 96 4.4.1.2 of [RFC4301]. In this document we are mostly focused 97 on the SPD cache. The SPD contains all SP. SP match for 98 outbound packet is performed through Traffic Selectors usually 99 composed of the IP addresses and ports. 101 - Security Association (SA): is defined in section 4 of [RFC4301]. 102 SA are stored in the Security Association Database. The SA 103 carries the processing information (cryptographic keys, 104 counters, tunnel IP addresses when the tunnel mode is used), as 105 well as the SPD Traffic Selectors used to check the processed 106 inbound packet matches the SP the SA is derived from. SA are 107 also designated by CHILD_SA in this document 109 - Security Associations Database (SAD): is defined in section 110 4.4.1.2 of [RFC4301]. The SAD contains all CHILD_SA. The 111 CHILD_SA is indexed by Selectors (Security Parameters Index 112 (SPI) as well as the IP addresses of the inbound packet). 114 - Peer Authorization Database (PAD): is defined in section 4.4.3 of 115 [RFC4301]. 117 - MOBIKE: designates MOBIKE as described in [RFC4555]. 119 - MOBIKEv2: designates the protocol described in this document, 120 that is MOBIKE version 2. 122 3. Introduction 124 Currently, MOBIKE [RFC4555] provides mobility and multihoming 125 capabilities only for CHILD_SA using the tunnel mode. On the other 126 hand, a large set of VPN solutions rely on GRE/IP tunnels and IPsec 127 protection of these tunnels uses the transport mode. Similarly, for 128 example when traffic is offloaded from Radio Access Network to public 129 WLAN, IPsec may also be used to secure application. Some 130 applications, like the DNS, may prefer the transport mode instead of 131 the tunnel mode. In any case, the use of the transport mode prevents 132 these connection to benefit from mobility and multihoming otherwise 133 provided by MOBIKE. 135 This document specifies MOBIKEv2 that extends MOBIKE [RFC4555] to the 136 transport mode. By doing so, communication protected with IPsec 137 transport mode can also benefit from multihoming and mobility 138 capabilities. 140 The remaining of the document is as follows. Section 5 specifies how 141 to negotiate the support of MOBIKEv2 with the creation of an CHILD_SA 142 using the transport mode. Section 6 describes how updates and 143 additional IP addresses are handled with the transport mode. 144 Section 7 details how IP updates on CHILD_SA impact the databases. 146 We assume the reader is familiar with IPsec [RFC4301], IKEv2 147 [RFC7296] and with MOBIKE [RFC4555]. 149 4. Problem Statement 151 [RFC4555] section 3.2 states that the use of MOBIKE is indicated with 152 the MOBIKE_SUPPORTED Notify Payload in the IKE_AUTH exchange. 153 [RFC7296] section 1.3.1 states that the use of the transport mode is 154 indicated by the USE_TRANSPORT_MODE Notify Payload in a Create Child 155 exchange. 157 MOBIKE [RFC4555] section 1.2 considers outside its scope the use of 158 mobility and multihoming with a CHILD_SA using the transport mode. 159 As result, an Initiator is not supposed to send both an 160 MOBIKE_SUPPORTED and a USE_TRANSPORT_MODE Notify Payload in its 161 IKE_AUTH, and this case is left undefined. In case the Initiator 162 sends these two payloads, possible Responder's behaviors may be: 164 - 1) The Responder responds with MOBIKE_SUPPORTED and 165 USE_TRANSPORT_MODE. In this case, MOBIKE may only be provided 166 for the IKE_SA, the CHILD_SA is using the transport mode and no 167 mobility or multihoming facilities are provided for the 168 CHILD_SA. 170 - 2) The Responder responds with MOBIKE_SUPPORTED only, in which 171 case, it indicates it supports MOBIKE and refuses the transport 172 mode for the CHILD_SA. One reason for refusing the transport 173 mode may be that MOBIKE has only been defined for the tunnel 174 mode. Such situation may results from prioritizing extensions. 176 - 3) The Responder responds with USE_TRANSPORT_MODE only, in which 177 case it indicates it supports the transport mode for the 178 CHILD_SA, but not MOBIKE. This case may be similar to case 2 179 with a different prioritization. 181 - 4) The Responder may ignore both Notify Payloads as this case has 182 not been specified. 184 As a result, the use MOBIKEv2 with CHILD_SA using the transport mode 185 requires to clarify the combination of the MOBIKE_SUPPORTED and the 186 USE_TRANSPORT_MODE Notify Payload in an IKE_AUTH exchange. This is 187 the purpose of Section 5 189 MOBIKE updates the IP addresses using an UPDATE_SA_ADDRESSES Notify 190 Payload. At the reception of the UPDATE_SA_ADDRESSES Notify Payload, 191 the Responder identifies the concerned IKE_SA and associated 192 CHILD_SA(s). The IP addresses of the Initiator is replaced in both 193 the IKE_SA and the CHILD_SA(s) with the IP address of the IP header 194 used to carry UPDATE_SA_ADDRESSES Notify Payload. The IKE_SA is 195 actually stored in the IKEv2 application, whereas CHILD_SAs are in 196 the SAD. 198 When MOBIKE is activated, the CHILD_SAs are using the tunnel mode of 199 IPsec. Thus, updating the IP address requires the tunnel to be 200 updated within the CHILD_SA as well as the Selectors (SPI, IP 201 addresses) of the CHILD_SA in the SAD. MOBIKEv2 supports CHILD_SA 202 with transport mode. In this case, updating the IP address requires 203 updating the SPD Traffic Selectors within the CHILD_SA as well as the 204 Selectors of the SAD. In addition, the Traffic Selectors of the SPD 205 cache also need to be updated. This is the major change of MOBIKEv2 206 versus MOBIKE. Section 6 specifies the protocol details of MOBIKEv2 207 and Section 7 clarifies the impact on the various IPsec databases. 209 5. IKE_AUTH Exchange with MOBIKEv2 211 With MOBIKEv2 support of mobility and multihoming for a CHILD_SA 212 using the transport mode results from the combination of the 213 USE_TRANSPORT_MODE and MOBIKE_SUPPORTED Notify Payload within the 214 IKE_AUTH exchange in the message containing the SA Payload. Outside 215 of this scope MOBIKE_SUPPORTED Notify Payload is not expected as 216 defined in [RFC4555] section 3.2. 218 With MOBIKEv2 the Initiator may initiate an IKE_AUTH exchange with 219 the following combinations of the USE_TRANSPORT_MODE and 220 MOBIKE_SUPPORTED Notify Payload. 222 - 1) The presence of the USE_TRANSPORT_MODE and MOBIKE_SUPPORTED 223 Notify Payload indicates a request for both a CHILD_SA with the 224 transport mode and the support for MOBIKEv2 for this CHILD_SA. 225 This support is only provided by MOBIKEv2 and is not specified 226 by MOBIKE [RFC4555]. 228 - 2) The presence of the USE_TRANSPORT_MODE and the absence of the 229 MOBIKE_SUPPORTED Notify Payload indicates a request for a 230 CHILD_SA with the transport mode and no support for MOBIKE. 231 This case is specified in [RFC7296] and MOBIKEv2 leave this 232 specification unchanged. 234 - 3) The absence of the USE_TRANSPORT_MODE and the presence of the 235 MOBIKE_SUPPORTED Notify Payload indicates a request for a 236 CHILD_SA with the tunnel mode and the support for MOBIKEv2. 237 This case is specified in [RFC4555] and MOBIKEv2 leave the 238 specification unchanged. 240 - 4) The absence of both the USE_TRANSPORT_MODE and the 241 MOBIKE_SUPPORTED Notify Payload indicates a request for a 242 CHILD_SA with the tunnel mode and no support for MOBIKE. This 243 case is specified in [RFC4555] and MOBIKEv2 leave the 244 specification unchanged. 246 As specified by IKEv2 [RFC7296] in section 1.3.1 and in MOBIKE 247 [RFC4555] section 3.2, the Responder can respond with a 248 USE_TRANSPORT_MODE or MOBIKE_SUPPORTED Notify Payload only if such 249 payload has been previously provided by the Initiator while 250 initiating a CHILD_SA negotiation during the IKE_AUTH exchange. 251 Given these restrictions, with MOBIKEv2 the Responder may respond 252 with the following combination of the USE_TRANSPORT_MODE and 253 MOBIKE_SUPPORTED Notify Payload. 255 - 1) The presence of the USE_TRANSPORT_MODE and MOBIKE_SUPPORTED 256 Notify Payload indicates the CHILD_SA uses the transport mode 257 and the support for MOBIKEv2 for this CHILD_SA. This support 258 is only provided by MOBIKEv2 and is not specified by MOBIKE 259 [RFC4555]. 261 - 2) The presence of the USE_TRANSPORT_MODE and the absence of the 262 MOBIKE_SUPPORTED Notify Payload indicates the CHILD_SA uses the 263 transport mode and no support for MOBIKE is provided. This 264 case is specified in [RFC7296] and MOBIKEv2 leave this 265 specification unchanged. 267 - 3) The absence of the USE_TRANSPORT_MODE and the presence of the 268 MOBIKE_SUPPORTED Notify Payload indicates the CHILD_SA uses the 269 tunnel mode and support for MOBIKEv2 is provided. This case is 270 specified in [RFC4555] and MOBIKEv2 leave the specification 271 unchanged. 273 - 4) The absence of both the USE_TRANSPORT_MODE and the 274 MOBIKE_SUPPORTED Notify Payload indicates the CHILD_SA uses the 275 tunnel mode and no support for MOBIKE is provided. This case 276 is specified in [RFC4555] and MOBIKEv2 leave the specification 277 unchanged. 279 In case the response does not satisfy the Initiator, it MUST delete 280 the CHILD_SA as specified in [RFC7296] section 1.3.1. 282 6. Updating IP addresses with MOBIKEv2 284 CHILD_SAs may be updated when a UPDATE_SA_ADDRESSES Notify Payload is 285 received or when the other peer become unreachable, in which case, 286 the newly assigned IP address has been provided by an 287 ADDITIONAL_*_ADDRESS Notify Payload. This section details how 288 CHILD_SA MUST be updated when the CHILD_SA uses the transport mode. 290 Updating the IP address of the CHILD_SA using the transport mode 291 impacts the SPD cache. As a result, IP address MUST be checked 292 against the SPD and the PAD before performing any update of the 293 CHILD_SA, or before communication the IP address as an alternate IP 294 address. More specifically: 296 - 1) The Initiator MUST NOT send an UPDATE_SA_ADDRESSES if the newly 297 acquired IP does not match the SPD and the PAD. 299 - 2) The Initiator MUST NOT send an IP address in an 300 ADDITIONAL_*_ADDRESS if the IP address does not match the SPD 301 and the PAD. 303 - 3) The Initiator and Responder MUST check an IP address match the 304 SPD and the PAD before updating the CHILD_SA. 306 - 4) The Responder MUST send an UNACCEPTABLE_ADDRESS Notify Payload 307 described in section 4.1.1 of [RFC4555] if the IP address does 308 not match the SPD and the PAD. 310 Similarly to MOBIKE, the appropriated IP address is the newly 311 acquired IP address considered by the Initiator (either when a 312 mobility occurs or when an additional IP address is used). This IP 313 address is provided by the Initiator to the Responder via the IP 314 header of the UPDATE_SA_ADDRESSES Notify Payload. 316 Updating a CHILD_SA using the transport mode with a new IP address 317 involves updating: 319 - 1) SPD Traffic Selectors in the CHILD_SA. Note that with the 320 tunnel mode these selectors remain unchanged so this update is 321 specific to the transport mode. 323 - 2) SA Selectors in the SAD. This update is similar as with MOBIKE 324 except that the IP address is not the one of the tunnel. 326 - 3) Traffic Selectors of the SPD cache MUST also be updated with 327 the appropriated IP address. Note that with the tunnel mode 328 these selectors remain unchanged so this update is specific to 329 the transport mode. 331 7. IPsec Databases Impacts 333 This section discusses the impact of MOBIKEv2 on the IPsec databases. 334 Since implementation vary widely, we do not discuss how these updates 335 MUST be performed. 337 7.1. Security Policy Database (SPD) 339 The SPD MUST NOT be modified. Only the SPD cache needs to be 340 modified. MOBIKE did not necessarily require update on the SDP 341 cache, mostly because the Traffic Selectors are left unchanged with 342 the tunnel mode. In fact, SPD Cache also have the outer IP addresses 343 in its processing information (cf. section 4.1.2 of [RFC4301]). This 344 information MAY be also defined in conjunction of the PAD, and 345 eventually MAY be derived from the IP header of the IKE_INIT. 346 However, this information is mostly used to negotiate the 347 corresponding CHILD_SA, and for this reason, does not necessarily 348 require to be updated. On the other hand as discussed in 349 Appendix A.1 of [RFC4555], if this information is used to link the 350 SPD cache entry to the CHILD_SA, then this information MUST be 351 updated properly. 353 With MOBIKEv2 for CHILD_SA using the transport mode, the SPD Traffic 354 Selectors MUST be updated, and as such, the SPD MUST be updated. For 355 this reason the IP address MUST match the SPD and PAD before 356 performing the update. 358 7.2. Security Association Database (SAD) 360 MOBIKE requires to update the Selector of the CHILD_SA as well as the 361 content of the CHILD_SA (the Tunnel outer IP addresses). With 362 MOBIKEv2 for CHILD_SA using the transport mode, there is no tunnel 363 outer IP addresses to update. Instead the SDP Selectors in the 364 CHILD_SA as well as the Selector of the CHILD_SA MUST be updated. 366 7.3. Peer Authentication Database (PAD) 368 The PAD MUST NOT be updated. 370 8. Security Considerations 372 Security Considerations regarding mobility and multihoming have 373 already been expressed in [RFC4555]. 375 The use of the transport mode makes visible and unprotected the IP 376 header of the carried IP packet. This. This discloses privacy 377 related information as the IP header indicates the end points 378 communicating. This could be avoided with the tunnel mode as the end 379 point was the Security Gateway. 381 9. IANA Considerations 383 They is no IANA consideration. The signaling provided by MOBIKE is 384 sufficient. 386 10. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 392 Internet Protocol", RFC 4301, December 2005. 394 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 395 (MOBIKE)", RFC 4555, June 2006. 397 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 398 Kivinen, "Internet Key Exchange Protocol Version 2 399 (IKEv2)", STD 79, RFC 7296, October 2014. 401 Authors' Addresses 403 Daniel Migault 404 Ericsson 405 8400 boulevard Decarie 406 Montreal, QC H4P 2N2 407 Canada 409 Email: mglt.ietf@gmail.com 411 Daniel Palomares 412 Orange/LIP6 413 38 rue du General Leclerc 414 92794 Issy-les-Moulineaux Cedex 9 415 France 417 Phone: +33 1 45 29 51 16 418 Email: daniel.palomares@orange.com