idnits 2.17.1 draft-mglt-ipsecme-clone-ike-sa-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 : ---------------------------------------------------------------------------- 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 (July 21, 2014) is 3565 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 Orange 4 Intended status: Standards Track V. Smyslov 5 Expires: January 22, 2015 ELVIS-PLUS 6 July 21, 2014 8 Clone IKE SA Extension 9 draft-mglt-ipsecme-clone-ike-sa-02.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 peers has multiple interfaces. 16 With the current IKEv2 protocol, the outer IP addresses of the VPN 17 are determined by those used by IKEv2 SA. As a result using multiple 18 interfaces requires to set up an IKEv2 SA on each interface, or on 19 each path if both the VPN Client and the security gateway have 20 multiple interfaces. Setting each IKEv2 SA involves authentications 21 which might require multiple round trips as well as activity from the 22 VPN User and thus would delay the VPN establishment. In addition 23 multiple authentications unnecessarily increase the load on the VPN 24 client and the authentication infrastructure. 26 This document presents the Clone IKE SA extension, where an 27 additional IKEv2 SA is derived from an existing IKEv2 SA. The newly 28 created IKEv2 SA is set without the IKEv2 authentication exchange. 29 The newly created IKEv2 SA can later be assigned to another interface 30 using MOBIKE protocol. 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 January 22, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 71 5.1. Support Negotiation . . . . . . . . . . . . . . . . . . . 5 72 5.2. Cloning the IKE SA . . . . . . . . . . . . . . . . . . . 6 73 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 6 74 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 10.2. Informational References . . . . . . . . . . . . . . . . 9 81 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 10 82 Appendix B. Setting a VPN on Multiple Interfaces . . . . . . . . 10 83 B.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 10 84 B.2. Creating an additional IKEv2 Channel . . . . . . . . . . 12 85 B.3. Creation of the Child SA for VPN_1 . . . . . . . . . . . 12 86 B.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 establishing VPN with a Security Gateway when at least one of the 99 peers has multiple interfaces. Figure 1 represents the case when the 100 VPN End User has multiple interfaces, Figure 2 represents the case 101 when the Security Gateway has multiple interfaces, and Figure 3 102 represents the case when both the VPN End User and the Security 103 Gateway have multiple interfaces. With Figure 1 and Figure 2, one of 104 the peers has n = 2 interfaces and the other has a single interface. 105 This results in creating of up to n = 2 VPNs. With Figure 3, the VPN 106 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 protocol 143 [I-D.kivinen-ipsecme-ikev2-rfc5996bis], each VPN requires an IKEv2 144 SA, and setting an IKEv2 SA requires an authentication. 145 Authentication might require multiple round trips and an activity 146 from the End User (like EAP-SIM [RFC4186] or EAP-TLS [RFC5216]) as 147 well as crypto operations that would introduce an additional delay. 149 This document presents the Clone IKE SA extension. The main idea is 150 that the peer with multiple interfaces sets the first IKEv2 SA as 151 usual. Then it takes advantage of the fact that this IKE SA is 152 completed and derives as many new parallel IKEv2 SAs from it as the 153 desired number of VPNs. On each IKEv2 SA a VPN is negotiated. This 154 results in coexisting parallel VPNs. Then the VPN End User moves 155 each VPN to its proper location using MOBIKE [RFC4555]. 156 Alternatively, the VPN End User may first move the IKEv2 SAs and then 157 negotiate the VPNs. 159 Combining the Clone IKE SA extension with MOBIKE [RFC4555] for IPsec 160 communications with multiple interfaces provides the following 161 advantages. First, the Clone IKE SA extension requires very few 162 modifications to already existing IKEv2 implementations. Then, it 163 takes advantage of already existing and widely deployed MOBIKE 164 protocol. Finally, it keeps a dedicated IKEv2 SA for each VPN which 165 simplifies reachability tests and VPN maintenance. 167 Note also that the Clone IKE SA extension is independent from MOBIKE 168 and MAY also address other future scenarios. 170 3. Terminology 172 This section defines terms and acronyms used in this document. 174 - VPN End User: designates the end user that initiates the VPN with 175 a Security Gateway. This end user may be mobile and moves its 176 VPN from one Security Gateway to another. 178 - Security Gateway: designates a point of attachment for the VPN 179 service. In this document, the VPN service is provided by 180 multiple Security Gateways. Each Security Gateway may be 181 considered as a specific hardware. 183 - IKE SA: The IKEv2 SA (IKEv2 Security Association) is defined in 184 [I-D.kivinen-ipsecme-ikev2-rfc5996bis]. 186 4. Protocol Overview 188 The goal of the document is to specify how to create a new IKEv2 SA 189 without performing an authentication. In order to achieve this goal, 190 the document proposes that the two peers agree they support the Clone 191 IKE SA extension. This is done during the IKE_AUTH exchange by 192 exchanging the CLONE_IKE_SA_SUPPORTED Notifications. To create a new 193 parallel IKE SA, one of the peers initiates a CREATE_CHILD_SA 194 exchange as if it would rekey the IKE SA. In order to indicate the 195 current IKE SA must not be deleted, the initiator includes the 196 CLONE_IKE_SA Notification in the CREATE_CHILD_SA exchange. This 197 results in two parallel IKE SAs. 199 Note, that without the CLONE_IKE_SA Notification the old IKE SA would 200 be deleted after the rekey is successfully completed (as specified in 201 Section 2.8 of [I-D.kivinen-ipsecme-ikev2-rfc5996bis]. 203 5. Protocol Details 205 5.1. Support Negotiation 207 The initiator and the responder indicate their support for the Clone 208 IKE SA extension by exchanging the CLONE_IKE SA_SUPPORTED 209 Notifications. This notification MUST be sent in the IKE_AUTH 210 exchange (in case of multiple IKE_AUTH exchanges, in the message 211 containing the SA payload). If both initiator and responder send 212 this notification during the IKE_AUTH exchange, peers MAY use the 213 Clone IKE SA extension. In the other case the Clone IKE SA extension 214 MUST NOT be used. 216 Initiator Responder 217 ------------------------------------------------------------------- 218 HDR, SAi1, KEi, Ni --> 219 <-- HDR, SAr1, KEr, Nr 220 HDR, SK { IDi, CERT, AUTH, 221 CP(CFG_REQUEST), 222 SAi2, TSi, TSr, 223 N(CLONE_IKE_SA_SUPPORTED) } 224 <-- HDR, SK { IDr, CERT, AUTH, 225 CP(CFG_REPLY), SAr2, TSi, TSr, 226 N(CLONE_IKE_SA_SUPPORTED) } 228 5.2. Cloning the IKE SA 230 The initiator of the rekey exchange includes the CLONE_IKE_SA 231 Notification in a CREATE_CHILD_SA request for rekeying the IKE SA. 232 The CLONE_IKE_SA Notification indicates that the current IKE SA MUST 233 NOT be deleted. Instead two parallel IKEv2 SAs are expected to 234 coexist. The current IKE SA becomes the old IKE SA and the newly 235 negotiated IKE SA becomes the new IKE SA. The CLONE_IKE_SA 236 Notification MUST appear only in request message of the 237 CREATE_CHILD_SA exchange concerning the IKE SA rekey. If the 238 CLONE_IKE_SA Notification appears in any other message, it MUST be 239 ignored. 241 Initiator Responder 242 ------------------------------------------------------------------- 243 HDR, SK { N(CLONE_IKE_SA), SA, Ni, KEi } --> 245 If the CREATE_CHILD_SA request concerns an IKE SA rekey and contains 246 the CLONE_IKE_SA Notification, the Responder proceeds to the IKE SA 247 rekey, creates the new IKE SA, and keeps the old IKE SA. No 248 additional Notify Payload is included in the CREATE_CHILD_SA response 249 as represented below: 251 <-- HDR, SK { SA, Nr, KEr } 253 When using Clone IKE SA Extension peers MUST NOT transfer existing 254 Child SAs, that were created by the old IKE SA, to the newly created 255 IKE SA. So, all signalling messages, concerning those Child SAs MUST 256 continue to be send over the old IKE SA. This is different from the 257 regular IKE SA rekey. 259 5.3. Error Handling 261 There may be conditions when responder for some reason is unable or 262 unwilling to perform IKE SA cloning. This inability may be temporary 263 or permanent. 265 Temporary inability occurs when responder doesn't have enough 266 resources at the moment to clone IKE SA or when IKE SA is being 267 deleted by responder. In this case the responder SHOULD reject 268 request to clone IKE SA with the TEMPORARY_FAILURE notification. 270 <-- HDR, SK { N(TEMPORARY_FAILURE) } 272 After receiving this notification the initiator MAY retry its request 273 after waiting some period of time. See Section 2.25 of 274 [I-D.kivinen-ipsecme-ikev2-rfc5996bis] for details. 276 In some cases responder may have restrictions on the number of co- 277 existing IKE SAs with one peer. These restrictions may be either 278 implicit (some devices may have enough resources to handle only a few 279 IKE SAs) or explicit (provided by some configuration parameter). If 280 the initiator wants to clone more IKE SAs, than responder is able or 281 is configured to handle, the responder SHOULD reject the request with 282 the NO_ADDITIONAL_SAS notification. 284 <-- HDR, SK { N(NO_ADDITIONAL_SAS) } 286 This condition is considered permanent and the initiator SHOULD NOT 287 retry to clone IKE SA until some of existing IKE SAs with the 288 responder are deleted. 290 6. Payload Description 292 Figure 4 illustrates the Notify Payload packet format as described in 293 section 3. 10 of [I-D.kivinen-ipsecme-ikev2-rfc5996bis]. This format 294 is used for both the CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED 295 notifications. 297 The CLONE_IKE_SA_SUPPORTED Notification is used in an IKEv2 exchange 298 of type IKE_AUTH and the CLONE_IKE_SA is used in an IKEv2 exchange of 299 type CREATE_CHILD_SA. 301 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Next Payload |C| RESERVED | Payload Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Protocol ID | SPI Size | Notify Message Type | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 4: Notify Payload 311 The fields Next Payload, Critical Bit, RESERVED and Payload Length 312 are defined in [I-D.kivinen-ipsecme-ikev2-rfc5996bis]. Specific 313 fields defined in this document are: 315 - Protocol ID (1 octet): set to zero. 317 - SPI Size (1 octet): set to zero. 319 - Notify Message Type (2 octets): Specifies the type of notification 320 message. It is set to for the CLONE_IKE_SA 321 notification or to for the CLONE_IKE_SA_SUPPORTED 322 Notification. 324 7. IANA Considerations 326 IANA is requested to allocate two values in the IKEv2 Notify Message 327 Types - Status Types registry: 329 IKEv2 Notify Message Types - Status Types 330 ----------------------------------------- 331 CLONE_IKE_SA_SUPPORTED - TBA 332 CLONE_IKE_SA - TBA 334 8. Security Considerations 336 The protocol defined in this document does not modify IKEv2. 337 Security considerations for Clone IKE SA extension are mostly the 338 same as those for base IKEv2 protocol described in 339 [I-D.kivinen-ipsecme-ikev2-rfc5996bis]. 341 This extension provides the ability for an initiator to clone 342 existing IKE SAs. As a result it may influence any accounting or 343 control mechanisms based on a single IKE SA per authentication. 345 Suppose a system has a limit on the number of IKE SAs it can handle. 346 In this case, the Clone IKE SA extension may provide a way for 347 resource exhaustion, as a single end user may populate multiple IKE 348 SAs. 350 Suppose a system shares the IPsec resources by limiting the number of 351 Child SAs per IKE SA. With a single IKE SA per end user, this 352 provides an equal resource sharing. The Clone IKE SA provides means 353 for an end user to overpass this limit. Such system should evaluate 354 the number of Child SAs over the number of all IKE SAs associated to 355 an end user. 357 Note, that these issues are not unique for Clone IKE SA extensions, 358 as multiple IKE SAs between two peers may be created without this 359 extension. Note also, that implementation can always limit the 360 number of cloned IKE SAs. 362 Suppose VPN or any other IPsec based service monitoring is based on 363 the liveliness of the first IKE SA. Such system considers a service 364 is accessed or used from the time IKE performs an authentication to 365 the time the IKE SA is deleted. Such accounting methods were fine as 366 any IKE SA required an authentication exchange. As the Clone IKE SA 367 skips the authentication phase, Clone IKE SA may make possible to 368 delete the initial IKE SA while the service is being used on the 369 cloned IKE SA. Such accountings method should considers the service 370 is being used from the first IKE SA establishment to until the last 371 IKE SA is being removed. 373 9. Acknowledgments 375 The ideas of this draft came from various inputs from the ipsecme WG 376 and from discussions with Tero Kivinen and Michael Richardson. Yaron 377 Sheffer, Tero Kivinen provided significant inputs to set the current 378 design of the protocol as well as its designation. 380 10. References 382 10.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 388 (MOBIKE)", RFC 4555, June 2006. 390 10.2. Informational References 392 [I-D.kivinen-ipsecme-ikev2-rfc5996bis] 393 Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 394 Kivinen, "Internet Key Exchange Protocol Version 2 395 (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-04 (work 396 in progress), June 2014. 398 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 399 Protocol Method for Global System for Mobile 400 Communications (GSM) Subscriber Identity Modules (EAP- 401 SIM)", RFC 4186, January 2006. 403 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 404 Authentication Protocol", RFC 5216, March 2008. 406 Appendix A. Document Change Log 408 [RFC Editor: This section is to be removed before publication] 410 -02: Clarification, editing. 412 -01: Valery Smyslov is now a co-author. 414 1. Exchange of CLONE_IKE_SA_SUPPORTED notifications made limited to 415 IKE_AUTH exchange only. 417 2. Some clarifications about processing CLONE_IKE_SA notification 418 are added. 420 3. Some words that with Clone IKE SA existing Child SAs must not be 421 transferred to newly created IKE SA (unlike regular rekey) are added. 423 4. Reduced exchanges (combined IKE_AUTH with cloning IKE SA and 424 CREATE_CHILD_SA with transferring to different IPs) are removed. 426 5. Error handling while clonoing IKE SA is described. 428 -00: Comments from Valery Smyslov, Tero Kivinen and Yaron Sheffer. 429 SUPPORTED Notify Payload can be placed in a INFORMATIONAL or IKE_AUTH 430 exchange. CLONE_IKE_SA is sent in a CREATE_CHILD_SA exchange and is 431 provided both in the query and in the response. 433 -00: First version published. draft-mglt-ipsecme-keep-old-ike-sa-00 435 Appendix B. Setting a VPN on Multiple Interfaces 437 This section is informational and exposes how a VPN End User as 438 illustrated in Figure 1 can build two VPNs on its two interfaces 439 without multiple authentications. Other cases represented in 440 Figure 2 and Figure 3 are similar and can be easily derived from this 441 case. The mechanism is based on the Clone IKE SA extension and the 442 MOBIKE extension [RFC4555]. 444 B.1. Setting VPN_0 446 First, the VPN End User negotiates a VPN using one interface. This 447 involves regular IKEv2 exchanges. In addition, the VPN End User and 448 the Security Gateway advertise their support for MOBIKE. At the end 449 of the IKE_AUTH exchange, VPN_0 is set as represented in Figure 5. 451 +------------+ +------------+ 452 | | Interface_0 : VPN_0 | | 453 | =================== | Security | 454 | VPN | v | Gateway | 455 | End User | ============== | 456 | = | | 457 | | Interface_1 | | 458 +------------+ +------------+ 460 Figure 5: VPN End User Establishing VPN_0 462 The exchanges are completely described in 463 [I-D.kivinen-ipsecme-ikev2-rfc5996bis] and [RFC4555]. First, peers 464 negotiate IKE SA parameters and exchange nonces and public keys in 465 IKE_SA_INIT exchange. In the figure below they also proceed to NAT 466 detection because of the use of MOBIKE. 468 Initiator Responder 469 ------------------------------------------------------------------- 470 (IP_I0:500 -> IP_R:500) 471 HDR, SAi1, KEi, Ni, 472 N(NAT_DETECTION_SOURCE_IP), 473 N(NAT_DETECTION_DESTINATION_IP) --> 475 <-- (IP_R:500 -> IP_I0:500) 476 HDR, SAr1, KEr, Nr, 477 N(NAT_DETECTION_SOURCE_IP), 478 N(NAT_DETECTION_DESTINATION_IP) 480 Then the initiator and the responder proceed to the IKE_AUTH 481 exchange, advertise their support for MOBIKE and for the Clone IKE SA 482 extension - with the MOBIKE_SUPPORTED and the CLONE_IKE_SA_SUPPORTED 483 Notifications - and negotiate the Child SA for VPN_0. Optionally, 484 the initiator and the Security Gateway MAY advertise their multiple 485 interfaces using the ADDITIONAL_IP4_ADDRESS and/or 486 ADDITIONAL_IP6_ADDRESS Notify Payload. 488 (IP_I0:4500 -> IP_R:4500) 489 HDR, SK { IDi, CERT, AUTH, 490 CP(CFG_REQUEST), 491 SAi2, TSi, TSr, 492 N(CLONE_IKE_SA_SUPPORTED) 493 N(MOBIKE_SUPPORTED), 494 N(ADDITIONAL_IP*_ADDRESS)+ } --> 496 <-- (IP_R:4500 -> IP_I0:4500) 497 HDR, SK { IDr, CERT, AUTH, 498 CP(CFG_REPLY), 499 SAr2, TSi, TSr, 500 N(CLONE_IKE_SA_SUPPORTED) 501 N(MOBIKE_SUPPORTED), 502 N(ADDITIONAL_IP*_ADDRESS)+} 504 B.2. Creating an additional IKEv2 Channel 506 In our case the the initiator wants to establish a VPN with its 507 Interface_1 between the VPN End User and the Security Gateway. The 508 VPN End User will first establish a parallel IKE SA using a 509 CREATE_CHILD_SA that concerns an IKE SA rekey associated to a 510 CLONE_IKE_SA Notify Payload. This results in two different IKE SAs 511 between the VPN End User and the Security Gateway. Currently both 512 IKE SAs are set using Interface 0 of the VPN End User. 514 Initiator Responder 515 ------------------------------------------------------------------- 516 (IP_I0:4500 -> IP_R:4500) 517 HDR, SK { N(CLONE_IKE_SA), 518 SA, Ni, KEi} --> 519 <-- (IP_R:4500 -> IP_I0:4500) 520 HDR, SK { N(CLONE_IKE_SA), 521 SA, Nr, KEr} 523 B.3. Creation of the Child SA for VPN_1 525 Once the new IKEv2 SA has been created, the VPN End User MAY initiate 526 a CREATE_CHILD_SA exchange that concerns the creation of a Child SA 527 for VPN_1. The newly created VPN_1 will use Interface_0 of the VPN 528 End User. 530 It is out of scope of the document to define how the VPN End User 531 handles traffic with multiple interfaces. The VPN End User MAY use 532 the same IP inner address on its multiple interfaces. In this case, 533 the same Traffic Selectors (that is the IP address used for VPN_0 and 534 VPN_1) MAY match for both VPNs VPN_0 and VPN_1. The end user VPN 535 SHOULD be aware of such match and be able to manage it. It MAY for 536 example use distinct Traffic Selectors on both VPNs using different 537 ports, manage the order of its SPD or have SPD defined per 538 interfaces. Defining these mechanisms are out of scope of this 539 document. Alternatively, the VPN End User MAY use a different IP 540 address for each interface. 542 The creation of VPN_1 is performed via the newly created IKE SA as 543 follows: 545 Initiator Responder 546 ------------------------------------------------------------------- 547 (IP_I0:4500 -> IP_R:4500) 548 HDR(new), SK(new) { [CP(CFG_REQUEST)], 549 SAi2, TSi, TSr } --> 551 <-- (IP_R:4500 -> IP_I0:4500) 552 HDR(new), SK(new) { [CP(CFG_REPLY)], 553 SAr2, TSi, TSr} 555 The resulting configuration is depicted in Figure 6. VPN_0 and VPN_1 556 have been created, but both are using the same Interface: 557 Interface_0. 559 +------------+ +------------+ 560 | | Interface_0 : VPN_0, VPN_1 | | 561 | =================== | Security | 562 | VPN ================= v | Gateway | 563 | End User | v ============== | 564 | = ================== | 565 | | Interface_1 | | 566 +------------+ +------------+ 568 Figure 6: VPN End User Establishing VPN_0 and VPN_1 570 B.4. Moving VPN_1 on Interface_1 572 In this section, MOBIKE is used to move VPN_1 on interface_1. The 573 exchange is described in [RFC4555]. All exchanges use the new IKE 574 SA. Eventually, the VPN End User MAY check if the Security Gateway 575 is reachable via Interface_1. The exchanges are described below: 577 Initiator Responder 578 ------------------------------------------------------------------- 579 (IP_I1:4500 -> IP_R:4500) 580 HDR(new), SK(new) { N(NAT_DETECTION_SOURCE_IP), 581 N(NAT_DETECTION_DESTINATION_IP) } 583 <-- (IP_R:4500 -> IP_I1:4500) 584 HDR(new), SK(new) { 585 N(NAT_DETECTION_SOURCE_IP), 586 N(NAT_DETECTION_DESTINATION_IP) } 588 After that initiator requests the peer to switch to new addresses. 590 (IP_I1:4500 -> IP_R:4500) 591 HDR(new), SK(new) { N(UPDATE_SA_ADDRESSES), 592 N(NAT_DETECTION_SOURCE_IP), 593 N(NAT_DETECTION_DESTINATION_IP), 594 N(COOKIE2) } --> 596 <-- (IP_R:4500 -> IP_I1:4500) 597 HDR(new), SK(new) { 598 N(NAT_DETECTION_SOURCE_IP), 599 N(NAT_DETECTION_DESTINATION_IP), 600 N(COOKIE2) } 602 This results in the situation as described in Figure 7. 604 +------------+ +------------+ 605 | | Interface_0 : VPN_0 | | 606 | =================== | Security | 607 | VPN | v | Gateway | 608 | End User | ============== | 609 | ========================^ | | 610 | | Interface_1 : VPN_1 | | 611 +------------+ +------------+ 613 Figure 7: VPN End User with Multiple Interfaces 615 Authors' Addresses 616 Daniel Migault 617 Orange 618 38 rue du General Leclerc 619 92794 Issy-les-Moulineaux Cedex 9 620 France 622 Phone: +33 1 45 29 60 52 623 Email: daniel.migault@orange.com 625 Valery Smyslov 626 ELVIS-PLUS 627 PO Box 81 628 Moscow (Zelenograd) 124460 629 Russian Federation 631 Phone: +7 495 276 0211 632 Email: svan@elvis.ru