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