idnits 2.17.1 draft-mglt-ipsecme-clone-ike-sa-00.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 13, 2014) is 3726 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 February 13, 2014 5 Expires: August 17, 2014 7 Clone IKE SA Extension 8 draft-mglt-ipsecme-clone-ike-sa-00.txt 10 Abstract 12 This document considers a VPN End User setting a VPN with a security 13 gateway where at least one of the peer has multiple interfaces. 15 With the current IKEv2, the outer IP addresses of the VPN are 16 determined by those used by IKEv2 channel. As a result using 17 multiple interfaces requires to set an IKEv2 channel on each 18 interface, or on each paths if both the VPN Client and the security 19 gateway have multiple interfaces. Setting multiple IKEv2 channel 20 involves multiple authentications which MAY each require multiple 21 round trips and delay the VPN establishment. In addition multiple 22 authentications unnecessarily load the VPN client and the 23 authentication infrastructure. 25 This document presents the Clone IKE_SA extension, where an 26 additional IKEv2 channel is derived from an already authenticated 27 IKEv2 channel. The newly created IKEv2 channel is set without the 28 IKEv2 authentication exchange. The newly created IKEv2 channel can 29 then be assigned to another interface using MOBIKE. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 17, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Payload Description . . . . . . . . . . . . . . . . . . . . . 6 70 6. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 71 6.1. CLONE_IKE_SA_SUPPORTED Notify Payload . . . . . . . . . . 7 72 6.2. CLONE_IKE_SA Notify Payload . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 10.2. Informational References . . . . . . . . . . . . . . . . 9 79 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 9 80 Appendix B. Setting a VPN on Multiple Interfaces . . . . . . . . 9 81 B.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 10 82 B.2. Creating an additional IKEv2 Channel . . . . . . . . . . 11 83 B.3. Creation of the Child SA for VPN_1 . . . . . . . . . . . 11 84 B.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 12 85 B.5. Reduced Exchange . . . . . . . . . . . . . . . . . . . . 13 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 The main scenario that motivated this document is a VPN End User 97 setting its VPN with a Security Gateway, and at least one of the 98 peers has multiple interfaces. Figure 1 represents the case where 99 the VPN has multiple interfaces, figure 2 represents the case where 100 the Security Gateway has multiple interfaces, and figure 3 represents 101 the case where both the VPN End User and the Security Gateway has 102 multiple interfaces. With figure 1 and figure 2, one of the peer has 103 n = 2 interfaces and the other has a single interface. This results 104 in the creating of up to n = 2 VPNs. With figure 3, the VPN End User 105 has n = 2 interfaces and the Security Gateway has m = 2 interfaces. 106 This can lead to up to m x n VPNs. 108 +------------+ +------------+ 109 | | Interface_0 : VPN_0 | | 110 | =================== | Security | 111 | VPN | v | Gateway | 112 | End User | ============== | 113 | ========================^ | | 114 | | Interface_1 : VPN_1 | | 115 +------------+ +------------+ 117 Figure 1: VPN End User with Multiple Interfaces 119 +------------+ +------------+ 120 | | Interface_0 : VPN_0 | | 121 | | ============= Security | 122 | VPN | v | Gateway | 123 | End User =================== | | 124 | | ^ ============ | 125 | | Interface_1 : VPN_1 | | 126 +------------+ +------------+ 128 Figure 2: Security Gateway with Multiple Interfaces 130 +------------+ +------------+ 131 | | Interface_0 Interface_0' | | 132 | ================================= Security | 133 | VPN | \\ // | Gateway | 134 | End User | // \\ | | 135 | ================================= | 136 | | Interface_1 Interface_1' | | 137 +------------+ +------------+ 139 Figure3: VPN End User and Security Gateway 140 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 can 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 an first authenticated 150 IKEv2 channel. Then it takes advantage of this authentication and 151 derives as many parallel IKEv2 channels as VPNs. On each IKEv2 152 channel a VPN is negotiated. This results in parallel VPNS. Then 153 the VPN End User moves the VPNs to their proper places using MOBIKE. 154 Alternatively, the VPN End User can also move the IKEv2 channels and 155 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 so 162 tunnel outer IP address can differ from those of the IKEv2 channel. 164 The advantage of the Clone IKE SA extension is that is requires very 165 few modifications to already existing IKEv2 implementations. Then, 166 it reuses already existing and widely deployed protocol such as 167 MOBIKE [RFC4555]. Finally by keeping a dedicated IKEv2 channel for 168 each VPN, it eases reachability tests. 170 Note also that that the Clone IKE SA extension is independent of 171 MOBIKE and MAY also address other future scenarios. 173 3. Terminology 175 This section defines terms and acronyms used in this document. 177 - VPN End User: designates the end user that initiates the VPN with 178 a Security Gateway. This end user may be mobile and moves its 179 VPN from on Security Gateway to the other. 181 - Security Gateway: designates a point of attachment for the VPN 182 service. In this document, the VPN service is provided by 183 multiple Security Gateways. Each Security Gateway may be 184 considered as a specific hardware. 186 - Security Association (SA): The Security Association is defined in 187 [RFC4301]. 189 4. Protocol Overview 191 The goal of the document is to specify how to create a new IKEv2 192 channel. IKEv2 [RFC5996] specifies the CREATE_CHILD_SA that makes 193 possible to rekey an IKE_SA, create or rekey a new Child SA. 195 The difference between rekeying an IKE_SA and creating a new IKE_SA 196 is that the old IKE_SA MUST NOT be deleted, either by starting a 197 Delete exchange or removing the IKE_SA without the Delete exchange. 199 Note that IKEv2 [RFC5996] Section 1.3.2 or Section 2.18 does not 200 explicitly mentions that the old IKE_SA MUST be deleted. However, 201 there are currently no signaling advertising the IKE_SA has not been 202 deleted. The purpose of this document is to avoid this uncertainty 203 when rekeying the IKE_SA. In other words, the document avoids that 204 one peer expects a additional IKE_SA to be created whereas the other 205 simply proceeds to a replacement of the old IKE_SA. 207 Currently, one MAY check whether or not the old IKE_SA has been 208 deleted or not by waiting a for a given time and then initiate and 209 empty INFORMATIONAL exchange using the old IKE_SA. The absence of 210 response MAY indicate the old IKE_SA has been removed. 212 The initiator and the responder indicate they support the Clone IKE 213 SA extension with CLONE_IKE_SA_SUPPORTED Notify Payload. These 214 Notify Payloads can be sent at any time after the IKE_SA has been 215 negotiated. In the example below, the CLONE_IKE_SA_SUPPORTED 216 exchange is performed during the IKEv2 negotiation. The initiator 217 and the responder support the Clone IKE SA extension, which means 218 both peers can explicitly specify, when a IKE_SA is rekeyed, if the 219 IKE SA MUST be cloned, or MAY be removed. The CLONE_IKE_SA_SUPPORTED 220 Notify Payload can be sent in IKE_AUTH or INFORMATIONAL IKEv2 221 exchange. 223 Initiator Responder 224 ------------------------------------------------------------------- 225 HDR, SAi1, KEi, Ni --> 226 <-- HDR, SAr1, KEr, Nr 227 HDR, SK { IDi, CERT, AUTH, 228 CP(CFG_REQUEST), 229 SAi2, TSi, TSr, 230 N(CLONE_IKE_SA_SUPPORTED) } 231 <-- HDR, SK { IDr, CERT, AUTH, 232 CP(CFG_REPLY), SAr2, TSi, TSr, 233 N(CLONE_IKE_SA_SUPPORTED) } 235 The initiator of the rekey exchange sends the CLONE_IKE_SA Notify 236 Payload in a CREATE_CHILD_SA request for rekeying the IKE_SA. The 237 CLONE_IKE_SA Notify Payload indicates the current IKE_SA MUST NOT be 238 deleted. Instead two parallel IKEv2 channel are expected to coexist. 239 The current IKE_SA becomes the old IKE_SA and the newly negotiated 240 IKE_SA becomes the new IKE_SA. If the Initiator does not want or 241 does not care that two parallel IKE SA exists, the CLONE_IKE_SA 242 Notify Payload SHOULD be omitted. The CLONE_IKE_SA Notify Payload is 243 always part of a CREATE_CHILD_SA IKEv2 exchange. 245 Initiator Responder 246 ------------------------------------------------------------------- 247 HDR, SK {N(CLONE_IKE_SA) SA, Ni, KEi} --> 249 The responder supports the CLONE_IKE_SA Notify Payload as it provided 250 a CLONE_IKE_SA_SUPPORTED Notify Payload. If the CREATE_CHILD_SA 251 request concerns a IKE_SA rekey. The responder MUST proceed to the 252 IKE_SA rekey, create the new IKE_SA, and keep the old IKE_SA and 253 respond with a CLONE_IKE_SA Notify Payload as represented below: 255 <-- HDR, SK { N(CLONE_IKE_SA) 256 SA, Nr, KEr} 258 If the CLONE_IKE_SA Notify Payload is not associated to a IKE_SA 259 rekey, the responder MUST return an INVALID_SYNTAX Notification as 260 described in section 3.10.1 of [RFC5996]. The exchange will be: 262 <-- HDR, SK {SA, Nr, KEr 263 N(INVALID_SYNTAX)} 265 5. Payload Description 267 Figure 7 illustrates the Notify Payload packet format as described in 268 section 3. 10 of [RFC5996]. This is the format we use for both the 269 CLONE_IKE_SA or CLONE_IKE_SA_SUPPORTED Notify Payload. 271 The CLONE_IKE_SA_SUPPORTED Notify Payload is used in an IKEv2 272 exchange of type INFORMATIONAL or IKE_AUTH and the CLONE_IKE_SA is 273 used in an IKEv2 exchange of type CREATE_CHILD_SA. 275 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Next Payload |C| RESERVED | Payload Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Protocol ID | SPI Size | Notify Message Type | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 7: Notify Payload 285 - Next Payload (1 octet): Indicates the type of payload that follows 286 after the header. 288 - Critical Bit (1 bit): Indicates how the responder handles the 289 Notify Payload. In this document the Critical Bit is not set. 291 - RESERVED (7 bits): MUST be set as zero; MUST be ignored on 292 receipt. 294 - Payload Length (2 octet): Length in octets of the current payload, 295 including the generic payload header. 297 - Protocol ID (1 octet): set to zero. 299 - SPI Size (1 octet): set to zero. 301 - Notify Message Type (2 octets): Specifies the type of notification 302 message. It is set to CLONE_IKE_SA or CLONE_IKE_SA_SUPPORTED 303 in this document. 305 6. Protocol Description 307 6.1. CLONE_IKE_SA_SUPPORTED Notify Payload 309 The CLONE_IKE_SA_SUPPORTED Notify Payload is sent by the initiator of 310 the INFORMATIONAL or IKE_AUTH exchange to announce its support of the 311 Clone IKE SA extension. 313 If the CLONE_IKE_SA_SUPPORTED in not send in a message of type 314 INFORMATIONAL or IKE_AUTH, the responder SHOULD send an 315 INVALID_SYNTAX Notify Payload. 317 Upon reception of the CLONE_IKE_SA_SUPPORTED Notify Payload, the 318 responder that supports the Clone IKE SA extension SHOULD sent a 319 CLONE_IKE_SA_SUPPORTED Notify Payload as a response. This indicates 320 the initiator the responder also supports the Clone IKE SA extension. 321 A responder that does not support the Clone IKE SA extension MUST 322 ignore the CLONE_IKE_SA_SUPPORTED Notify Payload as specified in 323 [RFC5996]. 325 The Clone IKE SA extension is considered supported by both peers if 326 and only if the initiator and the responder have sent and received a 327 CLONE_IKE_SA_SUPPORTED Notify Payload. In any other case the 328 extension is considered not supported and SHOULD NOT be used in 329 latter exchanges. 331 6.2. CLONE_IKE_SA Notify Payload 333 The CLONE_IKE_SA Notify Payload SHOULD be used only if the Clone IKE 334 SA extension is supported by the two peers. 336 The CLONE_IKE_SA Notify Payload MUST always been sent in a 337 CREATE_CHILD_SA message that concerns an IKE_SA rekey as described in 338 section 1.3.2 of [RFC5996]. If not, a INVALID_SYNTAX Notify Payload 339 MUST be sent. 341 Upon reception of a CLONE_IKE_SA Notify Payload from the responder, 342 the initiator got the confirmation two parallel IKE_SA have been 343 created on the responder. 345 7. IANA Considerations 347 The new fields and number are the following: 349 IKEv2 Notify Message Types - Status Types 350 ----------------------------------------- 351 CLONE_IKE_SA - TBD 352 CLONE_IKE_SA_SUPPORTED - TBD 354 8. Security Considerations 356 The protocol defined in this document does not modifies IKEv2. It 357 signalizes what has been implementation dependent on how to manage an 358 old IKE_SA after a rekey. 360 9. Acknowledgment 362 The ideas of this draft came from various inputs from the ipsecme and 363 discussions with Tero Kivinen and Michael Richardson. Yaron Sheffer, 364 Tero Kivinen and Valery Smyslov provided significant inputs to set 365 the current design of the protocol as well as its designation. 367 10. References 369 10.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 375 Internet Protocol", RFC 4301, December 2005. 377 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 378 (MOBIKE)", RFC 4555, June 2006. 380 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 381 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 382 5996, September 2010. 384 10.2. Informational References 386 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] 387 Arora, J. and P. Kumar, "Alternate Tunnel Addresses for 388 IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00 389 (work in progress), April 2010. 391 [I-D.mglt-ipsecme-alternate-outer-address] 392 Migault, D., "IKEv2 Alternate Outer IP Address Extension", 393 draft-mglt-ipsecme-alternate-outer-address-00 (work in 394 progress), February 2013. 396 [I-D.mglt-mif-security-requirements] 397 Migault, D. and C. Williams, "IPsec Multiple Interfaces 398 Problem Statement", draft-mglt-mif-security- 399 requirements-03 (work in progress), November 2012. 401 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 402 Protocol Method for Global System for Mobile 403 Communications (GSM) Subscriber Identity Modules (EAP- 404 SIM)", RFC 4186, January 2006. 406 Appendix A. Document Change Log 408 [RFC Editor: This section is to be removed before publication] 410 -00: Comments from Valery Smyslov, Tero Kivinen and Yaron Sheffer. 411 SUPPORTED Notify Payload can be placed in a INFORMATIONAL or IKE_AUTH 412 exchange. CLONE_IKE_SA is sent in a CREATE_CHILD_SA exchange and is 413 provided both in the query and in the response. 415 -00: First version published. draft-mglt-ipsecme-keep-old-ike-sa-00 417 Appendix B. Setting a VPN on Multiple Interfaces 419 This section is informational and exposes how a VPN End User as 420 illustrated in Figure 1 can builds two VPNs on its two interfaces 421 without multiple authentications. Other cases represented in figure 422 2 and 3 are similar and can be easily derived from the case. The 423 mechanism is based on the CLONE_IKE_SA extension and the MOBIKE 424 extension [RFC4555]. 426 B.1. Setting VPN_0 428 First, the VPN End User negotiates a VPN using one interface. This 429 involves a regular IKEv2 setting. In addition, the VPN End User and 430 the Security Gateway advertise they support MOBIKE. At the end of 431 the exchange, VPN_0 is set as represented in figure 4. 433 +------------+ +------------+ 434 | | Interface_0 : VPN_0 | | 435 | =================== | Security | 436 | VPN | v | Gateway | 437 | End User | ============== | 438 | = | | 439 | | Interface_1 | | 440 +------------+ +------------+ 442 Figure 4: VPN End User Establishing VPN_0 444 The exchange is completely described in [RFC4555]. First the 445 negotiates the IKE_SA. In the figure below peers also proceed to NAT 446 detection because of the use of MOBIKE. 448 Initiator Responder 449 ------------------------------------------------------------------- 450 (IP_I1:500 -> IP_R1:500) 451 HDR, SAi1, KEi, Ni, 452 N(NAT_DETECTION_SOURCE_IP), 453 N(NAT_DETECTION_DESTINATION_IP) --> 455 <-- (IP_R1:500 -> IP_I1:500) 456 HDR, SAr1, KEr, Nr, 457 N(NAT_DETECTION_SOURCE_IP), 458 N(NAT_DETECTION_DESTINATION_IP) 460 The initiators and the responder proceed to the authentication 461 exchange, advertise they support MOBIKE and the Clone IKE SA 462 extension - with the MOBIKE_SUPPORTED and the CLONE_IKE_SA_SUPPORTED 463 Notify Payloads - and negotiate the SA for VPN_0. Optionally, the 464 initiator and the Security Gateway MAY advertise their multiple 465 interfaces using the ADDITIONAL_IP4_ADDRESS and/or 466 ADDITIONAL_IP6_ADDRESS Notify Payload. 468 (IP_I1:4500 -> IP_R1:4500) 469 HDR, SK { IDi, CERT, AUTH, 470 CP(CFG_REQUEST), 471 SAi2, TSi, TSr, 472 N(CLONE_IKE_SA_SUPPORTED) 473 N(MOBIKE_SUPPORTED), 474 N(ADDITIONAL_IP*_ADDRESS)+ } --> 476 <-- (IP_R1:4500 -> IP_I1:4500) 477 HDR, SK { IDr, CERT, AUTH, 478 CP(CFG_REPLY), 479 SAr2, TSi, TSr, 480 N(CLONE_IKE_SA_SUPPORTED) 481 N(MOBIKE_SUPPORTED), 482 N(ADDITIONAL_IP*_ADDRESS)+} 484 B.2. Creating an additional IKEv2 Channel 486 In our case the the initiator wants to set establish a VPN with its 487 Interface_1 between the VPN End User and the Security Gateway. The 488 VPN End User will first establish a parallel IKE_SA using a 489 CREATE_CHILD_SA that concerns an IKE_SA rekey associated to a 490 CLONE_IKE_SA Notify Payload. This results in two different IKE_SA 491 between the VPN End User and the Security Gateway. Currently both 492 IKE_SA are set using Interface 0 of the VPN End User. 494 Initiator Responder 495 ------------------------------------------------------------------- 496 (IP_I1:4500 -> IP_R1:4500) 497 HDR, SK { N(CLONE_IKE_SA), 498 SA, Ni, KEi} --> 499 <-- (IP_R1:4500 -> IP_I1:4500) 500 HDR, SK { N(CLONE_IKE_SA), 501 SA, Nr, KEr} 503 B.3. Creation of the Child SA for VPN_1 505 Once the new IKEv2 channel has been created, the VPN End User MAY 506 initiate a CREATE_CHILD_SA exchange that concerns the creation of a 507 Child SA for VPN_1. The newly created VPN_1 will use Interface_0 of 508 the VPN End User. 510 It is out of scope of the document to define how the VPN End User 511 handles traffic with multiple interfaces. The VPN End User MAY use 512 the same IP inner address on its multiple interfaces. In this case, 513 the same Traffic Selectors (that is the IP address used for VPN_0 and 514 VPN_1) MAY match for both VPNs VPN_0 and VPN_1. The end user VPN 515 SHOULD be aware of such match and be able to manage it. It MAY for 516 example use distinct Traffic Selectors on both VPNs using different 517 ports, manage the order of its SPD or have SPD defined per 518 interfaces. Defining these mechanisms are out of scope of this 519 document. Alternatively, the VPN End User MAY uses a different IP 520 address for each interface. In the latter case, if the inner IP 521 address is assigned by the Security Gateway, the Configuration 522 Payload (CP) MUST be placed before the SA Payload as specified in 523 [RFC5996] Section 2.19. 525 The creation of VPN_1 is performed via the newly created IKE_SA as 526 follows: 528 Initiator Responder 529 ------------------------------------------------------------------- 530 (IP_I1:4500 -> IP_R1:4500) 531 HDR(new), SK(new) { [CP(CFG_REQUEST)], 532 SAi2, TSi, TSr } --> 534 <-- (IP_R1:4500 -> IP_I1:4500) 535 HDR(new), SK(new) { [CP(CFG_REPLY)], 536 SAr2, TSi, TSr} 538 The resulting configuration is depicted in figure 5. VPN_0 and VPN_1 539 have been created, but both are using the same Interface: 540 Interface_0. 542 +------------+ +------------+ 543 | | Interface_0 : VPN_0, VPN_1 | | 544 | =================== | Security | 545 | VPN ================= v | Gateway | 546 | End User | v ============== | 547 | = ================== | 548 | | Interface_1 | | 549 +------------+ +------------+ 551 Figure 5: VPN End User Establishing VPN_0 and VPN_1 553 B.4. Moving VPN_1 on Interface_1 555 In this section, MOBIKE is used to move VPN_1 on interface_1. The 556 exchange is described in [RFC4555]. All exchanges are using the new 557 IKE_SA. Eventually, the VPN End User MAY check if the Security 558 Gateway is reachable via Interface_1. The exchanges are described 559 below: 561 Initiator Responder 562 ------------------------------------------------------------------- 563 (IP_I2:4500 -> IP_R1:4500) 564 HDR(new), SK(new) { N(NAT_DETECTION_SOURCE_IP), 565 N(NAT_DETECTION_DESTINATION_IP) } 567 <-- (IP_R2:4500 -> IP_I1:4500) 568 HDR(new), SK(new) { 569 N(NAT_DETECTION_SOURCE_IP), 570 N(NAT_DETECTION_DESTINATION_IP) } 572 (This worked, and the initiator requests the peer to switch to new 573 addresses.) 575 (IP_I2:4500 -> IP_R1:4500) 576 HDR(new), SK(new) { N(UPDATE_SA_ADDRESSES), 577 N(NAT_DETECTION_SOURCE_IP), 578 N(NAT_DETECTION_DESTINATION_IP), 579 N(COOKIE2) } --> 581 <-- (IP_R1:4500 -> IP_I2:4500) 582 HDR(new), SK(new) { 583 N(NAT_DETECTION_SOURCE_IP), 584 N(NAT_DETECTION_DESTINATION_IP), 585 N(COOKIE2) } 587 This results in the situation as described in figure 6. 589 +------------+ +------------+ 590 | | Interface_0 : VPN_0 | | 591 | =================== | Security | 592 | VPN | v | Gateway | 593 | End User | ============== | 594 | ========================^ | | 595 | | Interface_1 : VPN_1 | | 596 +------------+ +------------+ 598 Figure 6: VPN End User with Multiple Interfaces 600 B.5. Reduced Exchange 602 The previous sections detail the various exchanges between the VPN 603 End User and the Security Gateway. This section shows an example 604 where the number of exchanges are limited, thus limiting the delay to 605 set up a multiple interface VPN communication. 607 Initiator Responder 608 ------------------------------------------------------------------- 610 (IP_I1:500 -> IP_R1:500) 611 HDR, SAi1, KEi, Ni, 612 N(NAT_DETECTION_SOURCE_IP), 613 N(NAT_DETECTION_DESTINATION_IP) --> 615 <-- (IP_R1:500 -> IP_I1:500) 616 HDR, SAr1, KEr, Nr, 617 N(NAT_DETECTION_SOURCE_IP), 618 N(NAT_DETECTION_DESTINATION_IP) 619 (IP_I1:4500 -> IP_R1:4500) 620 HDR, SK { IDi, CERT, AUTH, 621 CP(CFG_REQUEST), 622 SAi2, TSi, TSr, 623 N(CLONE_IKE_SA_SUPPORTED), 624 N(MOBIKE_SUPPORTED), 625 N(ADDITIONAL_IP*_ADDRESS)+, 626 N(CLONE_IKE_SA), 627 SA, Ni, KEi} --> 629 <-- (IP_R1:4500 -> IP_I1:4500) 630 HDR, SK { IDr, CERT, AUTH, 631 CP(CFG_REPLY), 632 SAr2, TSi, TSr, 633 N(CLONE_IKE_SA_SUPPORTED), 634 N(MOBIKE_SUPPORTED), 635 N(ADDITIONAL_IP*_ADDRESS)+}, 636 N(CLONE_IKE_SA), 637 SA, Nr, KEr} 638 <-- (IP_R1:4500 -> IP_I2:4500) 639 HDR(new), SK(new) 640 { [CP(REQUEST)], 641 SAi2, TSi, TSr, 642 N(UPDATE_SA_ADDRESSES)} 643 (IP_I2:4500 -> IP_R1:4500) --> 644 HDR(new), SK(new) { [CP(CFG_REPLY)], 645 SAr2, TSi, TSr} 647 Author's Address 648 Daniel Migault 649 Orange 650 38 rue du General Leclerc 651 92794 Issy-les-Moulineaux Cedex 9 652 France 654 Phone: +33 1 45 29 60 52 655 Email: daniel.migault@orange.com