idnits 2.17.1 draft-mglt-ipsecme-clone-ike-sa-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (December 3, 2015) is 3066 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 Network Working Group D. Migault (Ed) 3 Internet-Draft Ericsson 4 Intended status: Standards Track V. Smyslov 5 Expires: June 5, 2016 ELVIS-PLUS 6 December 3, 2015 8 Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2) 9 draft-mglt-ipsecme-clone-ike-sa-07.txt 11 Abstract 13 This document considers a VPN End User establishing an IPsec SA with 14 a Security Gateway using the Internet Key Exchange Protocol Version 2 15 (IKEv2), where at least one of the peers has multiple interfaces or 16 where Security Gateway is a cluster with each node having its own IP 17 address. 19 The protocol described allows a peer to clone an IKEv2 SA, where an 20 additional SA is derived from an existing one. The newly created IKE 21 SA is set without the IKEv2 authentication exchange. This IKE SA can 22 later be assigned to another interface or moved to another cluster 23 mode. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 5, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Support Negotiation . . . . . . . . . . . . . . . . . . . 6 65 5.2. Cloning the IKE SA . . . . . . . . . . . . . . . . . . . . 7 66 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 10.2. Informational References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Setting a VPN on Multiple Interfaces . . . . . . . . 11 75 A.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 11 76 A.2. Creating an additional IKE SA . . . . . . . . . . . . . . 13 77 A.3. Creating the Child SA for VPN_1 . . . . . . . . . . . . . 13 78 A.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Requirements notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 The main scenario that motivated this document is a VPN End User 90 establishing VPN with a Security Gateway when at least one of the 91 peers has multiple interfaces. Figure 1 represents the case when the 92 VPN End User has multiple interfaces, Figure 2 represents the case 93 when the Security Gateway has multiple interfaces, and Figure 3 94 represents the case when both the VPN End User and the Security 95 Gateway have multiple interfaces. With Figure 1 and Figure 2, one of 96 the peers has n = 2 interfaces and the other has a single interface. 97 This results in creating of up to n = 2 VPNs. With Figure 3, the VPN 98 End User has n = 2 interfaces and the Security Gateway has m = 2 99 interfaces. This may lead to up to m x n VPNs. 101 +------------+ +------------+ 102 | | Interface_0 : VPN_0 | | 103 | ================= | | 104 | VPN | v | Security | 105 | End User | ================== Gateway | 106 | ================^ | | 107 | | Interface_1 : VPN_1 | | 108 +------------+ +------------+ 110 Figure 1: VPN End User with Multiple Interfaces 112 +------------+ +------------+ 113 | | Interface_0 : VPN_0 | | 114 | | ================== | 115 | VPN | v | Security | 116 | End User ================= | Gateway | 117 | | ^================= | 118 | | Interface_1 : VPN_1 | | 119 +------------+ +------------+ 121 Figure 2: Security Gateway with Multiple Interfaces 123 +------------+ +------------+ 124 | | Interface_0 Interface_0' | | 125 | ================================== | 126 | VPN | \\ // | Security | 127 | End User | // \\ | Gateway | 128 | ================================== | 129 | | Interface_1 Interface_1' | | 130 +------------+ +------------+ 132 Figure 3: VPN End User and Security Gateway with Multiple Interfaces 134 With the current IKEv2 protocol [RFC7296], each VPN requires an IKE 135 SA, and setting an IKE SA requires an authentication. Authentication 136 might require multiple round trips and an activity from the End User 137 (like EAP-SIM [RFC4186] or EAP-TLS [RFC5216]) as well as crypto 138 operations that would introduce an additional delay. 140 Another scenario is a load-balancing solution. Load-sharing clusters 141 often are built so, that they are transparent for VPN End Users. In 142 case of IPsec this means that IKE and IPsec SA states are duplicated 143 on every cluster node where load balancer can redirect packets. The 144 drawback of such an approach is that anti-replay related data (in 145 particular Sequence Number) must be reliably synchronized between 146 participating nodes per every outgoing AH or ESP packet, which makes 147 building high-speed systems problematic. Another approach for 148 building load-balancing systems is to make VPN End Users aware of 149 them, which allows to have two or more Security Gateways sharing the 150 same ID, but each having its own IP address. In this case the VPN 151 End User first establishes an IKE SA with one of these gateways. 152 Then, at some point of time the gateway takes a decision to move 153 client to a different cluster node. This can be done with Redirect 154 Mechanism for IKEv2 [RFC5685]. The drawback of such an approach is 155 that it requires new IKE SA to be established from scratch, including 156 full authentication. In some cases this could be avoided by using 157 IKEv2 Session Resumption [RFC5723] with a new gateway. However this 158 requires VPN End User to know beforehand which new gateway to connect 159 to. So it is desirable to be able to clone existing IKE SA, to move 160 it to a different Security Gateway, and then to indicate VPN End User 161 to use this new SA. This would allow participating Security Gateways 162 to share the load between them. 164 This document introduces the possibility to clone the IKE SA in the 165 Internet Key Exchange Protocol Version 2 (IKEv2). The main idea is 166 that the peer with multiple interfaces sets the first IKE SA as 167 usual. Then it takes advantage of the fact that this SA is completed 168 and derives as many new parallel IKE SAs from it as the desired 169 number of VPNs. On each IKE SA a VPN is negotiated by creating one 170 or more IPsec SAs. This results in coexisting parallel VPNs. Then 171 the VPN End User moves each IPsec SA to its proper location using 172 MOBIKE (IKEv2 Mobility and Multihoming Protocol) [RFC4555]. 173 Alternatively, the VPN End User may first move the IKE SAs and then 174 create the IPsec SAs. 176 Note that it is up to host's local policy which additional VPNs to 177 create and when to do it. The process of selecting address pairs for 178 migration is a local matter. Furthermore, in the case of multiple 179 interfaces on both ends care should be taken to avoid the VPNs to be 180 duplicated by both ends or moved to the both interfaces. 182 In addition multiple MOBIKE operation may be involved from the 183 Security Gateway or the VPN End User. Suppose, as depicted in Figure 184 3 for example that the cloned VPN is between Interface _0 and 185 Interface_0', and the VPN End User and the Security Gateway want to 186 move it to Interface_1 and Interface_1'. The VPN End User may 187 initiate a MOBIKE exchange in order to move it to Interface_1, in 188 which case the cloned VPN is now between Interface_1 and 189 Interface_0'. Then the Security Gateway may also initiate a MOBIKE 190 exchange in order to move the VPN to Interface_1' in which case the 191 VPN has reached its final destination. 193 The combination of the IKE SA cloning with MOBIKE protocol provides 194 IPsec communications with multiple interfaces the following 195 advantages. First, cloning the IKE SA requires very few 196 modifications to already existing IKEv2 implementations. Then, it 197 takes advantage of already existing and widely deployed MOBIKE 198 protocol. Finally, it keeps a dedicated IKE SA for each VPN which 199 simplifies reachability tests and VPN maintenance. 201 Note also that the cloning of the IKE SA is independent from MOBIKE 202 and can also address other future scenarios not described in the 203 current document. 205 3. Terminology 207 This section defines terms and acronyms used in this document. 209 - VPN: Virtual Private Network - one or more Child (IPsec) SAs 210 created in tunnel mode between two peers. 212 - VPN End User: designates the end user that initiates the VPN with 213 a Security Gateway. This end user may be mobile and moves its 214 VPN from one Security Gateway to another. 216 - Security Gateway: designates a point of attachment for the VPN 217 service. In this document, the VPN service is provided by 218 multiple Security Gateways. Each Security Gateway may be 219 considered as a specific hardware. 221 - IKE SA: The IKE SA (IKE Security Association) is defined in 222 [RFC7296]. 224 4. Protocol Overview 226 This document specifies how to create a clone of existing IKE SA 227 without performing new authentication. In order to achieve this 228 goal, the document proposes that the two peers agree upon their 229 ability of cloning the IKE SA. This is done during the IKE_AUTH 230 exchange by exchanging the CLONE_IKE_SA_SUPPORTED notifications. To 231 create a new parallel IKE SA, one of the peers initiates a 232 CREATE_CHILD_SA exchange as if it would rekey the existing IKE SA. 233 In order to indicate the current IKE SA must not be deleted, the 234 initiator includes the CLONE_IKE_SA notification in the 235 CREATE_CHILD_SA exchange. This results in two parallel IKE SAs. 237 Note, that without the CLONE_IKE_SA notification the old IKE SA would 238 be deleted after the rekey is successfully completed (as specified in 239 Section 2.8 of [RFC7296]. 241 5. Protocol Details 243 5.1. Support Negotiation 245 The initiator and the responder indicate their support for cloning 246 IKE SA by exchanging the CLONE_IKE SA_SUPPORTED notifications. This 247 notification MUST be sent in the IKE_AUTH exchange (in case of 248 multiple IKE_AUTH exchanges - in the first IKE_AUTH message from 249 initiator and in the last IKE_AUTH message from responder). If both 250 initiator and responder send this notification during the IKE_AUTH 251 exchange, peers may clone this IKE SA. In the other case the IKE SA 252 MUST NOT be cloned. 254 Initiator Responder 255 ------------------------------------------------------------------- 256 HDR, SA, KEi, Ni --> 257 <-- HDR, SA, KEr, Nr 258 HDR, SK {IDi, AUTH, 259 SA, TSi, TSr, 260 N(CLONE_IKE_SA_SUPPORTED)} --> 261 <-- HDR, SK {IDr, AUTH, 262 SA, TSi, TSr, 263 N(CLONE_IKE_SA_SUPPORTED)} 265 5.2. Cloning the IKE SA 267 The initiator of the rekey exchange includes the CLONE_IKE_SA 268 notification in a CREATE_CHILD_SA request for rekeying the IKE SA. 269 The CLONE_IKE_SA notification indicates that the current IKE SA will 270 not be immediately deleted once the new IKE SA is created. Instead 271 two parallel IKE SAs are expected to coexist. The current IKE SA 272 becomes the old IKE SA and the newly negotiated IKE SA becomes the 273 new IKE SA. The CLONE_IKE_SA notification MUST appear only in 274 request message of the CREATE_CHILD_SA exchange concerning the IKE SA 275 rekey. If the CLONE_IKE_SA notification appears in any other 276 message, it MUST be ignored. 278 Initiator Responder 279 ------------------------------------------------------------------- 280 HDR, SK {N(CLONE_IKE_SA), SA, Ni, KEi} --> 282 If the CREATE_CHILD_SA request is concerned with an IKE SA rekey and 283 contains the CLONE_IKE_SA notification, the responder proceeds to the 284 IKE SA rekey, creates the new IKE SA, and keeps the old IKE SA. No 285 additional Notify Payloads are included in the CREATE_CHILD_SA 286 response as represented below: 288 <-- HDR, SK {SA, Nr, KEr} 290 When the IKE SA is cloned, peers MUST NOT transfer existing Child 291 SAs, that were created by the old IKE SA, to the newly created IKE 292 SA. So, all signalling messages, concerning those Child SAs would 293 continue to be sent over the old IKE SA. This is different from the 294 regular IKE SA rekey in IKEv2. 296 5.3. Error Handling 298 There may be conditions when responder for some reason is unable or 299 unwilling to clone the IKE SA. This inability may be temporary or 300 permanent. 302 Temporary inability occurs when responder doesn't have enough 303 resources at the moment to clone an IKE SA or when the IKE SA is 304 being deleted by responder. In this case the responder SHOULD reject 305 the request to clone the IKE SA with the TEMPORARY_FAILURE 306 notification. 308 <-- HDR, SK {N(TEMPORARY_FAILURE)} 310 After receiving this notification the initiator MAY retry its request 311 after waiting some period of time. See Section 2.25 of [RFC7296] for 312 details. 314 In some cases, responder may have restrictions on the number of co- 315 existing IKE SAs with one peer. These restrictions may be either 316 implicit (some devices may have enough resources to handle only a few 317 IKE SAs) or explicit (provided by some configuration parameter). If 318 the initiator wants to clone more IKE SAs, than responder is able or 319 is configured to handle, the responder SHOULD reject the request with 320 the NO_ADDITIONAL_SAS notification. 322 <-- HDR, SK {N(NO_ADDITIONAL_SAS)} 324 This condition is considered permanent and the initiator SHOULD NOT 325 retry to clone an IKE SA until some of existing SAs with the 326 responder are deleted. 328 6. Payload Description 330 Figure 4 illustrates the Notify Payload packet format as described in 331 section 3. 10 of [RFC7296]. This format is used for both the 332 CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED notifications. 334 The CLONE_IKE_SA_SUPPORTED notification is used in an IKEv2 exchange 335 of type IKE_AUTH and the CLONE_IKE_SA is used in an IKEv2 exchange of 336 type CREATE_CHILD_SA. 338 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Next Payload |C| RESERVED | Payload Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Protocol ID | SPI Size | Notify Message Type | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 4: Notify Payload 348 The fields Next Payload, Critical Bit, RESERVED and Payload Length 349 are defined in [RFC7296]. Specific fields defined in this document 350 are: 352 - Protocol ID (1 octet): set to zero. 354 - SPI Size (1 octet): set to zero. 356 - Notify Message Type (2 octets): Specifies the type of notification 357 message. It is set to for the CLONE_IKE_SA 358 notification or to for the CLONE_IKE_SA_SUPPORTED 359 Notification. 361 7. IANA Considerations 363 IANA is requested to allocate two values in the "IKEv2 Notify Message 364 Types - Status Types registry": 366 IKEv2 Notify Message Types - Status Types 367 ----------------------------------------- 368 CLONE_IKE_SA_SUPPORTED 369 CLONE_IKE_SA 371 8. Security Considerations 373 The protocol defined in this document does not modify IKEv2. 374 Security considerations for cloning an IKE SA are mostly the same as 375 those for base IKEv2 protocol described in [RFC7296]. 377 Cloning an IKE SA provides the ability for an initiator to duplicate 378 existing SAs. As a result it may influence any accounting or control 379 mechanisms based on a single IKE SA per authentication. 381 Suppose a system has a limit on the number of IKE SAs it can handle. 382 In this case, the cloning an IKE SA may provide a way for resource 383 exhaustion, as a single end user may populate multiple IKE SAs. 385 Suppose a system shares the IPsec resources by limiting the number of 386 Child SAs per IKE SA. With a single IKE SA per end user, this 387 provides an equal resource sharing. In this case, cloning the IKE SA 388 provides means for an end user to overpass this limit. Such system 389 should evaluate the number of Child SAs over the number of all IKE 390 SAs associated to an end user. 392 Note, that these issues are not unique to the ability of cloning the 393 IKE SA, as multiple IKE SAs between two peers may be created without 394 involving a cloning method. Note also, that implementation can 395 always limit the number of cloned IKE SAs. 397 Suppose VPN or any other IPsec based service monitoring is based on 398 the liveliness of the first IKE SA. Such system considers a service 399 is accessed or used from the time IKE performs an authentication to 400 the time the IKE SA is deleted. Such accounting methods were fine as 401 any IKE SA required an authentication exchange. As cloning the IKE 402 SA skips the authentication phase, it may make possible to delete the 403 initial IKE SA while the service is being used on the cloned IKE SA. 404 Such accountings method should considers the service is being used 405 from the first IKE SA establishment to until the last IKE SA is being 406 removed. 408 When cloning IKE SA is used to build load-balancing systems, there is 409 a need to transfer IKE SA states between nodes of load-sharing 410 cluster. Since IKE SA state contains sensitive information, such as 411 session keys, implementations must take all due precautions when 412 doing that, that might include using technical and/or administrative 413 means to protect IKE SA state data. The details of what is 414 transferred and how it is protected are out of scope of this 415 document. 417 9. Acknowledgments 419 The ideas of this draft came from various inputs from the ipsecme WG 420 and from discussions with Tero Kivinen and Michael Richardson. Yaron 421 Sheffer, Tero Kivinen provided significant inputs to set the current 422 design of the protocol as well as its designation. 424 10. References 426 10.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 430 RFC2119, March 1997, 431 . 433 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 434 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 435 . 437 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 438 Kivinen, "Internet Key Exchange Protocol Version 2 439 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, 440 October 2014, . 442 10.2. Informational References 444 [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible 445 Authentication Protocol Method for Global System for 446 Mobile Communications (GSM) Subscriber Identity Modules 447 (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, 448 . 450 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 451 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 452 March 2008, . 454 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 455 the Internet Key Exchange Protocol Version 2 (IKEv2)", 456 RFC 5685, DOI 10.17487/RFC5685, November 2009, 457 . 459 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 460 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 461 DOI 10.17487/RFC5723, January 2010, 462 . 464 Appendix A. Setting a VPN on Multiple Interfaces 466 This section is informational and exposes how a VPN End User as 467 illustrated in Figure 1 can build two VPNs on its two interfaces 468 without multiple authentications. Other cases represented in 469 Figure 2 and Figure 3 are similar and can be easily derived from this 470 case. The mechanism is based on cloning the IKE SA and the MOBIKE 471 extension [RFC4555]. 473 A.1. Setting VPN_0 475 First, the VPN End User negotiates a VPN using one interface. This 476 involves regular IKEv2 exchanges. In addition, the VPN End User and 477 the Security Gateway advertise their support for MOBIKE. At the end 478 of the IKE_AUTH exchange, VPN_0 is set as represented in Figure 5. 480 +------------+ +------------+ 481 | | Interface_0 : VPN_0 | | 482 | ================= | | 483 | VPN | v | Security | 484 | End User | ================== Gateway | 485 | = | | 486 | | Interface_1 | | 487 +------------+ +------------+ 489 Figure 5: VPN End User Establishing VPN_0 491 The exchanges are completely described in [RFC7296] and [RFC4555]. 492 First, peers negotiate IKE SA parameters and exchange nonces and 493 public keys in IKE_SA_INIT exchange. In the figure below they also 494 proceed to NAT detection because of the use of MOBIKE. 496 Initiator Responder 497 ------------------------------------------------------------------- 498 (IP_I0:500 -> IP_R:500) 499 HDR, SA, KEi, Ni, 500 N(NAT_DETECTION_SOURCE_IP), 501 N(NAT_DETECTION_DESTINATION_IP) --> 503 <-- (IP_R:500 -> IP_I0:500) 504 HDR, SA, KEr, Nr, 505 N(NAT_DETECTION_SOURCE_IP), 506 N(NAT_DETECTION_DESTINATION_IP) 508 Then the initiator and the responder proceed to the IKE_AUTH 509 exchange, advertise their support for MOBIKE and their ability to 510 clone the IKE SA - with the MOBIKE_SUPPORTED and the 511 CLONE_IKE_SA_SUPPORTED notifications - and negotiate the Child SA for 512 VPN_0. Optionally, the initiator and the responder can advertise 513 their multiple interfaces using the ADDITIONAL_IP4_ADDRESS and/or 514 ADDITIONAL_IP6_ADDRESS notifications. 516 (IP_I0:4500 -> IP_R:4500) 517 HDR, SK {IDi, AUTH, 518 SA, TSi, TSr, 519 N(MOBIKE_SUPPORTED), 520 [N(ADDITIONAL_IP*_ADDRESS)+,] 521 N(CLONE_IKE_SA_SUPPORTED)} --> 523 <-- (IP_R:4500 -> IP_I0:4500) 524 HDR, SK {IDr, AUTH, 525 SA, TSi, TSr, 526 N(MOBIKE_SUPPORTED), 527 [N(ADDITIONAL_IP*_ADDRESS)+,] 528 N(CLONE_IKE_SA_SUPPORTED)} 530 A.2. Creating an additional IKE SA 532 In our case the VPN End User wants to establish an additional VPN 533 with its Interface_1. The VPN End User will first establish a 534 parallel IKE SA using a CREATE_CHILD_SA that concerns an IKE SA rekey 535 associated with a CLONE_IKE_SA notification. This results in two 536 separate IKE SAs between the VPN End User and the Security Gateway. 537 Currently both IKE SAs are set using Interface_0 of the VPN End User. 539 Initiator Responder 540 ------------------------------------------------------------------- 541 (IP_I0:4500 -> IP_R:4500) 542 HDR, SK {N(CLONE_IKE_SA), 543 SA, Ni, KEi} --> 544 <-- (IP_R:4500 -> IP_I0:4500) 545 HDR, SK {SA, Nr, KEr} 547 A.3. Creating the Child SA for VPN_1 549 Once the new IKE SA has been created, the VPN End User can initiate a 550 CREATE_CHILD_SA exchange that concerns the creation of a Child SA for 551 VPN_1. The newly created VPN_1 will use Interface_0 of the VPN End 552 User. 554 It is out of scope of the document to define how the VPN End User 555 handles traffic with multiple interfaces. The VPN End User can use 556 the same inner IP address on its multiple interfaces. In this case, 557 the same Traffic Selectors (that is the IP address used for VPN_0 and 558 VPN_1) can match for both VPNs VPN_0 and VPN_1. The VPN End User 559 must be aware of such match and be able to manage it. It can for 560 example use distinct Traffic Selectors on both VPNs using different 561 ports, manage the order of its SPD or have SPD defined per 562 interfaces. Defining these mechanisms are out of scope of this 563 document. Alternatively, the VPN End User can use a different inner 564 IP address for each interface. 566 The creation of VPN_1 is performed via the newly created IKE SA as 567 follows: 569 Initiator Responder 570 ------------------------------------------------------------------- 571 (IP_I0:4500 -> IP_R:4500) 572 HDR(new), SK(new) {SA, TSi, TSr} --> 574 <-- (IP_R:4500 -> IP_I0:4500) 575 HDR(new), SK(new) {SA, TSi, TSr} 577 The resulting configuration is depicted in Figure 6. VPN_0 and VPN_1 578 have been created, but both are using the same Interface: 579 Interface_0. 581 +------------+ +------------+ 582 | | Interface_0 : VPN_0, VPN_1 | | 583 | ==================== | | 584 | VPN ================= v | Security | 585 | End User | v =============== Gateway | 586 | | ================== | 587 | | Interface_1 | | 588 +------------+ +------------+ 590 Figure 6: VPN End User Establishing VPN_0 and VPN_1 592 A.4. Moving VPN_1 on Interface_1 594 In this section, MOBIKE is used to move VPN_1 on interface_1. The 595 exchange is described in [RFC4555]. 597 (IP_I1:4500 -> IP_R:4500) 598 HDR(new), SK(new) {N(UPDATE_SA_ADDRESSES), 599 N(NAT_DETECTION_SOURCE_IP), 600 N(NAT_DETECTION_DESTINATION_IP), 601 N(COOKIE2)} --> 603 <-- (IP_R:4500 -> IP_I1:4500) 604 HDR(new), SK(new) { 605 N(NAT_DETECTION_SOURCE_IP), 606 N(NAT_DETECTION_DESTINATION_IP), 607 N(COOKIE2)} 609 This results in the situation as described in Figure 7. 611 +------------+ +------------+ 612 | | Interface_0 : VPN_0 | | 613 | ================== | | 614 | VPN | v | Security | 615 | End User | ================= Gateway | 616 | =================^ | | 617 | | Interface_1 : VPN_1 | | 618 +------------+ +------------+ 620 Figure 7: VPN End User with Multiple Interfaces 622 Authors' Addresses 624 Daniel Migault 625 Ericsson 626 8400 boulevard Decarie 627 Montreal, QC H4P 2N2 628 Canada 630 Email: daniel.migault@ericsson.com 632 Valery Smyslov 633 ELVIS-PLUS 634 PO Box 81 635 Moscow (Zelenograd) 124460 636 Russian Federation 638 Phone: +7 495 276 0211 639 Email: svan@elvis.ru