idnits 2.17.1 draft-mglt-ipsecme-clone-ike-sa-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 (March 13, 2014) is 3669 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 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 Orange 4 Intended status: Standards Track V. Smyslov 5 Expires: September 14, 2014 ELVIS-PLUS 6 March 13, 2014 8 Clone IKE SA Extension 9 draft-mglt-ipsecme-clone-ike-sa-01.txt 11 Abstract 13 This document considers a VPN End User setting a VPN with a security 14 gateway where at least one of the peer has multiple interfaces. 16 With the current IKEv2, the outer IP addresses of the VPN are 17 determined by those used by IKEv2 channel. As a result using 18 multiple interfaces requires to set an IKEv2 channel on each 19 interface, or on each paths if both the VPN Client and the security 20 gateway have multiple interfaces. Setting multiple IKEv2 channel 21 involves multiple authentications which may each require multiple 22 round trips and delay the VPN establishment. In addition multiple 23 authentications unnecessarily increase load to the VPN client and the 24 authentication infrastructure. 26 This document presents the Clone IKE SA extension, where an 27 additional IKEv2 channel is derived from an already authenticated 28 IKEv2 channel. The newly created IKEv2 channel is set without the 29 IKEv2 authentication exchange. The newly created IKEv2 channel can 30 then be assigned to another interface using MOBIKE. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 14, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Support Negotiation . . . . . . . . . . . . . . . . . . . 6 72 5.2. Cloning IKE SA . . . . . . . . . . . . . . . . . . . . . 6 73 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 7 74 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 10.2. Informational References . . . . . . . . . . . . . . . . 10 81 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 10 82 Appendix B. Setting a VPN on Multiple Interfaces . . . . . . . . 11 83 B.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 11 84 B.2. Creating an additional IKEv2 Channel . . . . . . . . . . 13 85 B.3. Creation of the Child SA for VPN_1 . . . . . . . . . . . 13 86 B.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Requirements notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 97 The main scenario that motivated this document is a VPN End User 98 setting its VPN with a Security Gateway, and at least one of the 99 peers has multiple interfaces. Figure 1 represents the case where 100 the VPN End User has multiple interfaces, Figure 2 represents the 101 case where the Security Gateway has multiple interfaces, and Figure 3 102 represents the case where both the VPN End User and the Security 103 Gateway have multiple interfaces. With Figure 1 and Figure 2, one of 104 the peer has n = 2 interfaces and the other has a single interface. 105 This results in the creating of up to n = 2 VPNs. With Figure 3, the 106 VPN End User has n = 2 interfaces and the Security Gateway has m = 2 107 interfaces. This may lead to up to m x n VPNs. 109 +------------+ +------------+ 110 | | Interface_0 : VPN_0 | | 111 | =================== | Security | 112 | VPN | v | Gateway | 113 | End User | ============== | 114 | ========================^ | | 115 | | Interface_1 : VPN_1 | | 116 +------------+ +------------+ 118 Figure 1: VPN End User with Multiple Interfaces 120 +------------+ +------------+ 121 | | Interface_0 : VPN_0 | | 122 | | ============= Security | 123 | VPN | v | Gateway | 124 | End User =================== | | 125 | | ^ ============ | 126 | | Interface_1 : VPN_1 | | 127 +------------+ +------------+ 129 Figure 2: Security Gateway with Multiple Interfaces 131 +------------+ +------------+ 132 | | Interface_0 Interface_0' | | 133 | ================================= Security | 134 | VPN | \\ // | Gateway | 135 | End User | // \\ | | 136 | ================================= | 137 | | Interface_1 Interface_1' | | 138 +------------+ +------------+ 140 Figure 3: VPN End User and Security Gateway with Multiple Interfaces 142 With the current IKEv2 [RFC5996], each VPN requires an IKEv2 channel, 143 and setting an IKEv2 channel requires an authentication. 144 Authentication may involve multiple round trips like EAP-SIM 145 [RFC4186] as well as crypto operations that may delay the 146 connectivity. 148 This document presents the Clone IKE SA extension. The main idea is 149 that the peer with multiple interfaces sets the first authenticated 150 IKEv2 channel. Then it takes advantage of this authentication and 151 derives as many parallel IKEv2 channels as the number of VPNs. On 152 each IKEv2 channel a VPN is negotiated. This results in parallel 153 VPNs. Then the VPN End User moves the VPNs to their proper places 154 using MOBIKE [RFC4555]. Alternatively, the VPN End User may first 155 move the IKEv2 channels and then negotiate the VPNs. 157 Several documents have addressed the issue of IPsec and multiple 158 interfaces. [I-D.mglt-mif-security-requirements] provides a problem 159 statement for IPsec and multiple interfaces. 160 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] and 161 [I-D.mglt-ipsecme-alternate-outer-address] have been proposed to 162 allow tunnel outer IP addresses to differ from those of the IKEv2 163 channel. 165 The advantage of the Clone IKE SA extension is that it requires very 166 few modifications to already existing IKEv2 implementations. Then, 167 it reuses already existing and widely deployed protocol MOBIKE 168 [RFC4555]. Finally by keeping a dedicated IKEv2 channel for each 169 VPN, it eases reachability tests and VPN maintenance. 171 Note also that the Clone IKE SA extension is independent from MOBIKE 172 and MAY also address other future scenarios. 174 3. Terminology 176 This section defines terms and acronyms used in this document. 178 - VPN End User: designates the end user that initiates the VPN with 179 a Security Gateway. This end user may be mobile and moves its 180 VPN from one Security Gateway to another. 182 - Security Gateway: designates a point of attachment for the VPN 183 service. In this document, the VPN service is provided by 184 multiple Security Gateways. Each Security Gateway may be 185 considered as a specific hardware. 187 - IKE SA: The IKE SA (IKE Security Association) is defined in 188 [RFC5996]. 190 4. Protocol Overview 192 The goal of the document is to specify how to create a new IKEv2 193 channel without performing authentication. In order to achieve this 194 goal, the document proposes that the two peers agree they support the 195 Clone IKE SA extension. This is done during the IKE_AUTH exchange 196 using CLONE_IKE_SA_SUPPORTED Notify Payload. To create a new 197 parallel IKE SA, one of the peers initiates a CREATE_CHILD_SA 198 exchange as if it would rekey the IKE SA. In order to indicate the 199 current IKE SA MUST NOT be deleted, the initiator includes a 200 CLONE_IKE_SA Notify Payload in the CREATE_CHILD_SA exchange. This 201 results in two parallel IKE SA. 203 IKEv2 [RFC5996] specifies the CREATE_CHILD_SA exchange that makes 204 possible to rekey an IKE SA, create or rekey a new Child SA. The 205 difference between rekeying an IKE SA and creating a new IKE SA is 206 that the old IKE SA must not be deleted. Deleting of the current IKE 207 SA can be done either by sending a Delete Payload or be an 208 implementation design of IKEv2. 210 Note that IKEv2 [RFC5996] Section 1.3.2 and Section 2.18 do not 211 explicitly mention that the old IKE SA must be deleted. However, 212 there are currently no signaling advertising that the IKE SA must not 213 be deleted. The purpose of this document is to avoid this 214 uncertainty when rekeying the IKE SA. In other words, the document 215 avoids the situation when one peer expects an additional IKE SA to be 216 created whereas the other simply proceeds to a replacement of the old 217 IKE SA. 219 Currently, one may check whether or not the old IKE SA has been 220 deleted by waiting a for some time and then initiating an empty 221 INFORMATIONAL exchange using the old IKE SA. The absence of response 222 will indicate that the old IKE SA has been removed. 224 5. Protocol Details 226 5.1. Support Negotiation 228 The initiator and the responder indicate their support for the Clone 229 IKE SA extension by exchanging the CLONE_IKE SA_SUPPORTED 230 Notifications. This notification MUST be sent in the IKE_AUTH 231 exchange (in case of multiple IKE_AUTH exchanges, in the message 232 containing the SA payload). If both initiator and responder send 233 this notification during IKE_AUTH exchange, peers MAY use the Clone 234 IKE SA extension, explicitly specifying when an IKE SA is being 235 rekeyed, if the IKE SA has to be be cloned, or may be deleted. In 236 the other case the Clone IKE SA extension MUST NOT be used. 238 Initiator Responder 239 ------------------------------------------------------------------- 240 HDR, SAi1, KEi, Ni --> 241 <-- HDR, SAr1, KEr, Nr 242 HDR, SK { IDi, CERT, AUTH, 243 CP(CFG_REQUEST), 244 SAi2, TSi, TSr, 245 N(CLONE_IKE_SA_SUPPORTED) } 246 <-- HDR, SK { IDr, CERT, AUTH, 247 CP(CFG_REPLY), SAr2, TSi, TSr, 248 N(CLONE_IKE_SA_SUPPORTED) } 250 5.2. Cloning IKE SA 252 The initiator of the rekey exchange sends the CLONE_IKE_SA 253 Notification in a CREATE_CHILD_SA request for rekeying the IKE SA. 254 The CLONE_IKE_SA Notification indicates that the current IKE SA MUST 255 NOT be deleted. Instead two parallel IKEv2 channels are expected to 256 coexist. The current IKE SA becomes the old IKE SA and the newly 257 negotiated IKE SA becomes the new IKE SA. Peers MUST NOT send 258 CLONE_IKE_SA (and MUST ignore it if the other party sends it) if 259 support for the Clone IKE SA extension wasn't previously negotiated 260 in IKE_AUTH exchange. The CLONE_IKE_SA Notification MUST appear only 261 in request message of CREATE_CHILD_SA exchange concerning IKE SA 262 rekey. If the CLONE_IKE_SA Notification appears in any other 263 message, it MUST be ignored. 265 Initiator Responder 266 ------------------------------------------------------------------- 267 HDR, SK { N(CLONE_IKE_SA), SA, Ni, KEi } --> 268 If the CREATE_CHILD_SA request concerns an IKE SA rekey and contains 269 CLONE_IKE_SA Notification, the Responder proceeds to the IKE SA 270 rekey, creates the new IKE SA, and keeps the old IKE SA. No 271 additional Notify Payload is included in the CREATE_CHILD_SA response 272 as represented below: 274 <-- HDR, SK { SA, Nr, KEr } 276 When using Clone IKE SA Extension peers MUST NOT transfer existing 277 Child SAs, that were created by old IKE SA, to newly created IKE SA. 278 So, all signalling messages, concerning those Child SAs MUST continue 279 to be send over old IKE SA. This is different from regular IKE SA 280 rekey. 282 5.3. Error Handling 284 There may be conditions when responder for some reason is unable or 285 unwilling to perform IKE SA cloning. This inability may be temporary 286 or permanent. 288 Temporary inability occurs when responder doesn't have enough 289 resources at the moment to clone IKE SA or when IKE SA is being 290 deleted by responder. In this case responder SHOULD reject request 291 to clone IKE SA with TEMPORARY_FAILURE notification. 293 <-- HDR, SK { N(TEMPORARY_FAILURE) } 295 After receiving this notification initiator MAY retry its request 296 after waiting some period of time. See Section 2.25 of [RFC5996] for 297 details. 299 In some cases responder may have restrictions on the number of co- 300 existing IKE SAs with one peer. These restrictions may be either 301 implicit (some devices may have enough resources to handle only a few 302 IKE SAs) or explicit (provided by some configuration parameter). If 303 initiator wants to clone more IKE SAs, than responder is able or is 304 configured to handle, the responder SHOULD reject the request with 305 NO_ADDITIONAL_SAS notification. 307 <-- HDR, SK { N(NO_ADDITIONAL_SAS) } 309 This condition is considered permanent and initiator SHOULD NOT retry 310 to clone IKE SA until some of existing IKE SAs with the responder are 311 deleted. 313 6. Payload Description 315 Figure 4 illustrates the Notify Payload packet format as described in 316 section 3. 10 of [RFC5996]. This is the format we use for both the 317 CLONE_IKE_SA or CLONE_IKE_SA_SUPPORTED notifications. 319 The CLONE_IKE_SA_SUPPORTED Notify Payload is used in an IKEv2 320 exchange of type IKE_AUTH and the CLONE_IKE_SA is used in an IKEv2 321 exchange of type CREATE_CHILD_SA. 323 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Next Payload |C| RESERVED | Payload Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Protocol ID | SPI Size | Notify Message Type | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 4: Notify Payload 333 - Next Payload (1 octet): Indicates the type of payload that follows 334 after the header. 336 - Critical Bit (1 bit): Indicates how the responder handles the 337 Notify Payload. As notify payload is mandatory to support in 338 IKEv2, the Critical Bit is not set. 340 - RESERVED (7 bits): MUST be set to zero; MUST be ignored on 341 receipt. 343 - Payload Length (2 octet): Length in octets of the current payload, 344 including the generic payload header. 346 - Protocol ID (1 octet): set to zero. 348 - SPI Size (1 octet): set to zero. 350 - Notify Message Type (2 octets): Specifies the type of notification 351 message. It is set to for CLONE_IKE_SA 352 notification or to for CLONE_IKE_SA_SUPPORTED 353 Notification. 355 7. IANA Considerations 357 IANA is requested to allocate two values in IKEv2 Notify Message 358 Types - Status Types registry: 360 IKEv2 Notify Message Types - Status Types 361 ----------------------------------------- 362 CLONE_IKE_SA_SUPPORTED - TBA 363 CLONE_IKE_SA - TBA 365 8. Security Considerations 367 The protocol defined in this document does not modify IKEv2. 368 Security considerations for Clone IKE SA extension are mostly the 369 same as those for base IKEv2 protocol described in [RFC5996]. 371 This extension provides the ability for an initiator to clone 372 existing IKE SAs. As a result it may influence any accounting or 373 control mechanisms based on a single IKE SA per authentication. 375 Suppose a system has a limit on the number of IKE SAs it can handle. 376 In this case, the Clone IKE SA extension may provide a way for 377 resource exhaustion, as a single end user may populate multiple IKE 378 SAs. 380 Suppose a system shares the IPsec resources by limiting the number of 381 Child SAs per IKE SA. With a single IKE SA per end user, this 382 provides an equal resource sharing. The Clone IKE SA provides means 383 for a end user to overpass this limit. Such system should evaluate 384 the number of Child SAs over the number of all IKE SAs associated to 385 an end user. 387 Note, that these issues are not unique for Clone IKE SA extensions, 388 as multiple IKE SAs between two peers may be created without this 389 extension. Note also, that implementation can always limit the 390 number of cloned IKE SAs. 392 Suppose VPN or any other IPsec based service monitoring is based on 393 the liveliness of the first IKE SA. Such system considers a service 394 is accessed or used from the time IKE performs an authentication to 395 the time the IKE SA is deleted. Such accounting methods were fine as 396 any IKE SA required an authentication exchange. As the Clone IKE SA 397 skips the authentication phase, Clone IKE SA may make possible to 398 delete the initial IKE SA while the service is being used on the 399 cloned IKE SA. Such accounting method should consider the service is 400 being used from the first IKE SA establishment to until the last IKE 401 SA is being removed. 403 9. Acknowledgments 405 The ideas of this draft came from various inputs from the ipsecme and 406 discussions with Tero Kivinen and Michael Richardson. Yaron Sheffer, 407 Tero Kivinen provided significant inputs to set the current design of 408 the protocol as well as its designation. 410 10. References 412 10.1. Normative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, March 1997. 417 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 418 (MOBIKE)", RFC 4555, June 2006. 420 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 421 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 422 5996, September 2010. 424 10.2. Informational References 426 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] 427 Arora, J. and P. Kumar, "Alternate Tunnel Addresses for 428 IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00 429 (work in progress), April 2010. 431 [I-D.mglt-ipsecme-alternate-outer-address] 432 Migault, D., "IKEv2 Alternate Outer IP Address Extension", 433 draft-mglt-ipsecme-alternate-outer-address-00 (work in 434 progress), February 2013. 436 [I-D.mglt-mif-security-requirements] 437 Migault, D. and C. Williams, "IPsec Multiple Interfaces 438 Problem Statement", draft-mglt-mif-security- 439 requirements-03 (work in progress), November 2012. 441 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 442 Protocol Method for Global System for Mobile 443 Communications (GSM) Subscriber Identity Modules (EAP- 444 SIM)", RFC 4186, January 2006. 446 Appendix A. Document Change Log 448 [RFC Editor: This section is to be removed before publication] 450 -01: Valery Smyslov is now a co-author. 452 1. Exchange of CLONE_IKE_SA_SUPPORTED notifications made limited to 453 IKE_AUTH exchange only. 455 2. Some clarifications about processing CLONE_IKE_SA notification 456 are added. 458 3. Some words that with Clone IKE SA existing Child SAs must not be 459 transferred to newly created IKE SA (unlike regular rekey) are added. 461 4. Reduced exchanges (combined IKE_AUTH with cloning IKE SA and 462 CREATE_CHILD_SA with transferring to different IPs) are removed. 464 5. Error handling while cloning IKE SA is described. 466 6. Clarification text thanks to Tero's comments 468 7. Section Security Considerations enhanced with Tero's suggestions. 470 8. NO_ADDITIONAL_SAS is added in the error handling section. 472 -00: Comments from Valery Smyslov, Tero Kivinen and Yaron Sheffer. 473 SUPPORTED Notify Payload can be placed in a INFORMATIONAL or IKE_AUTH 474 exchange. CLONE_IKE_SA is sent in a CREATE_CHILD_SA exchange and is 475 provided both in the query and in the response. 477 -00: First version published. draft-mglt-ipsecme-keep-old-ike-sa-00 479 Appendix B. Setting a VPN on Multiple Interfaces 481 This section is informational and exposes how a VPN End User as 482 illustrated in Figure 1 can builds two VPNs on its two interfaces 483 without multiple authentications. Other cases represented in 484 Figure 2 and Figure 3 are similar and can be easily derived from this 485 case. The mechanism is based on the CLONE_IKE_SA extension and the 486 MOBIKE extension [RFC4555]. 488 B.1. Setting VPN_0 490 First, the VPN End User negotiates a VPN using one interface. This 491 involves a regular IKEv2 exchanges. In addition, the VPN End User 492 and the Security Gateway advertise their support for MOBIKE. At the 493 end of the IKE_AUTH exchange, VPN_0 is set as represented in 494 Figure 5. 496 +------------+ +------------+ 497 | | Interface_0 : VPN_0 | | 498 | =================== | Security | 499 | VPN | v | Gateway | 500 | End User | ============== | 501 | = | | 502 | | Interface_1 | | 503 +------------+ +------------+ 505 Figure 5: VPN End User Establishing VPN_0 507 The exchanges are completely described in [RFC5996] and [RFC4555]. 508 First, peers negotiate IKE SA parameters and exchange nonces and 509 public keys in IKE_SA_INIT exchange. In the figure below they also 510 proceed to NAT detection because of the use of MOBIKE. 512 Initiator Responder 513 ------------------------------------------------------------------- 514 (IP_I0:500 -> IP_R:500) 515 HDR, SAi1, KEi, Ni, 516 N(NAT_DETECTION_SOURCE_IP), 517 N(NAT_DETECTION_DESTINATION_IP) --> 519 <-- (IP_R:500 -> IP_I0:500) 520 HDR, SAr1, KEr, Nr, 521 N(NAT_DETECTION_SOURCE_IP), 522 N(NAT_DETECTION_DESTINATION_IP) 524 Then the initiator and the responder proceed to the IKE_AUTH 525 exchange, advertise their support for MOBIKE and for the Clone IKE SA 526 extension - with the MOBIKE_SUPPORTED and the CLONE_IKE_SA_SUPPORTED 527 Notifications - and negotiate the Child SA for VPN_0. Optionally, 528 the initiator and the Security Gateway MAY advertise their multiple 529 interfaces using the ADDITIONAL_IP4_ADDRESS and/or 530 ADDITIONAL_IP6_ADDRESS Notify Payload. 532 (IP_I0:4500 -> IP_R:4500) 533 HDR, SK { IDi, CERT, AUTH, 534 CP(CFG_REQUEST), 535 SAi2, TSi, TSr, 536 N(CLONE_IKE_SA_SUPPORTED) 537 N(MOBIKE_SUPPORTED), 538 N(ADDITIONAL_IP*_ADDRESS)+ } --> 540 <-- (IP_R:4500 -> IP_I0:4500) 541 HDR, SK { IDr, CERT, AUTH, 542 CP(CFG_REPLY), 543 SAr2, TSi, TSr, 544 N(CLONE_IKE_SA_SUPPORTED) 545 N(MOBIKE_SUPPORTED), 546 N(ADDITIONAL_IP*_ADDRESS)+} 548 B.2. Creating an additional IKEv2 Channel 550 In our case the the initiator wants to establish a VPN with its 551 Interface_1 between the VPN End User and the Security Gateway. The 552 VPN End User will first establish a parallel IKE SA using a 553 CREATE_CHILD_SA that concerns an IKE SA rekey associated to a 554 CLONE_IKE_SA Notify Payload. This results in two different IKE SAs 555 between the VPN End User and the Security Gateway. Currently both 556 IKE SAs are set using Interface 0 of the VPN End User. 558 Initiator Responder 559 ------------------------------------------------------------------- 560 (IP_I0:4500 -> IP_R:4500) 561 HDR, SK { N(CLONE_IKE_SA), 562 SA, Ni, KEi} --> 563 <-- (IP_R:4500 -> IP_I0:4500) 564 HDR, SK { N(CLONE_IKE_SA), 565 SA, Nr, KEr} 567 B.3. Creation of the Child SA for VPN_1 569 Once the new IKEv2 channel has been created, the VPN End User MAY 570 initiate a CREATE_CHILD_SA exchange that concerns the creation of a 571 Child SA for VPN_1. The newly created VPN_1 will use Interface_0 of 572 the VPN End User. 574 It is out of scope of the document to define how the VPN End User 575 handles traffic with multiple interfaces. The VPN End User MAY use 576 the same IP inner address on its multiple interfaces. In this case, 577 the same Traffic Selectors (that is the IP address used for VPN_0 and 578 VPN_1) MAY match for both VPNs VPN_0 and VPN_1. The end user VPN 579 SHOULD be aware of such match and be able to manage it. It MAY for 580 example use distinct Traffic Selectors on both VPNs using different 581 ports, manage the order of its SPD or have SPD defined per 582 interfaces. Defining these mechanisms are out of scope of this 583 document. Alternatively, the VPN End User MAY use a different IP 584 address for each interface. In the latter case, if the inner IP 585 address is assigned by the Security Gateway, the Configuration 586 Payload (CP) MUST be placed before the SA Payload as specified in 587 [RFC5996] Section 2.19. 589 The creation of VPN_1 is performed via the newly created IKE SA as 590 follows: 592 Initiator Responder 593 ------------------------------------------------------------------- 594 (IP_I0:4500 -> IP_R:4500) 595 HDR(new), SK(new) { [CP(CFG_REQUEST)], 596 SAi2, TSi, TSr } --> 598 <-- (IP_R:4500 -> IP_I0:4500) 599 HDR(new), SK(new) { [CP(CFG_REPLY)], 600 SAr2, TSi, TSr} 602 The resulting configuration is depicted in Figure 6. VPN_0 and VPN_1 603 have been created, but both are using the same Interface: 604 Interface_0. 606 +------------+ +------------+ 607 | | Interface_0 : VPN_0, VPN_1 | | 608 | =================== | Security | 609 | VPN ================= v | Gateway | 610 | End User | v ============== | 611 | = ================== | 612 | | Interface_1 | | 613 +------------+ +------------+ 615 Figure 6: VPN End User Establishing VPN_0 and VPN_1 617 B.4. Moving VPN_1 on Interface_1 619 In this section, MOBIKE is used to move VPN_1 on interface_1. The 620 exchange is described in [RFC4555]. All exchanges use the new IKE 621 SA. Eventually, the VPN End User MAY check if the Security Gateway 622 is reachable via Interface_1. The exchanges are described below: 624 Initiator Responder 625 ------------------------------------------------------------------- 626 (IP_I1:4500 -> IP_R:4500) 627 HDR(new), SK(new) { N(NAT_DETECTION_SOURCE_IP), 628 N(NAT_DETECTION_DESTINATION_IP) } 630 <-- (IP_R:4500 -> IP_I1:4500) 631 HDR(new), SK(new) { 632 N(NAT_DETECTION_SOURCE_IP), 633 N(NAT_DETECTION_DESTINATION_IP) } 635 After that initiator requests the peer to switch to new addresses. 637 (IP_I1:4500 -> IP_R:4500) 638 HDR(new), SK(new) { N(UPDATE_SA_ADDRESSES), 639 N(NAT_DETECTION_SOURCE_IP), 640 N(NAT_DETECTION_DESTINATION_IP), 641 N(COOKIE2) } --> 643 <-- (IP_R:4500 -> IP_I1:4500) 644 HDR(new), SK(new) { 645 N(NAT_DETECTION_SOURCE_IP), 646 N(NAT_DETECTION_DESTINATION_IP), 647 N(COOKIE2) } 649 This results in the situation as described in Figure 7. 651 +------------+ +------------+ 652 | | Interface_0 : VPN_0 | | 653 | =================== | Security | 654 | VPN | v | Gateway | 655 | End User | ============== | 656 | ========================^ | | 657 | | Interface_1 : VPN_1 | | 658 +------------+ +------------+ 660 Figure 7: VPN End User with Multiple Interfaces 662 Authors' Addresses 663 Daniel Migault 664 Orange 665 38 rue du General Leclerc 666 92794 Issy-les-Moulineaux Cedex 9 667 France 669 Phone: +33 1 45 29 60 52 670 Email: daniel.migault@orange.com 672 Valery Smyslov 673 ELVIS-PLUS 674 PO Box 81 675 Moscow (Zelenograd) 124460 676 Russian Federation 678 Phone: +7 495 276 0211 679 Email: svan@elvis.ru