idnits 2.17.1 draft-mglt-ipsecme-keep-old-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 (July 05, 2013) is 3946 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 Francetelecom - Orange 4 Intended status: Standards Track July 05, 2013 5 Expires: January 06, 2014 7 KEEP_OLD_IKE_SA Extension 8 draft-mglt-ipsecme-keep-old-ike-sa-00.txt 10 Abstract 12 This document considers a VPN Client 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 interface requires to set an IKEv2 channel on each 18 interface, and then on each paths if both the VPN Client and the 19 security gateway have multiple interfaces. Setting multiple IKEv2 20 channel involves multiple authentications which MAY each require 21 multiple round trips and delay the VPN establishment. In addition 22 multiple authentications unnecessarily load the VPN client and the 23 authentication infrastructure. 25 This document presents the KEEP_OLD_IKE_SA extension, where an 26 additional IKEv2 channel from an already authenticated IKEv2 channel. 27 The newly created IKEv2 channel is set without the IKEv2 28 authentication exchange. The newly created IKEv2 channel can then be 29 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 January 06, 2014. 48 Copyright Notice 50 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Payload Description . . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 9.2. Informational References . . . . . . . . . . . . . . . . 8 76 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 8 77 Appendix B. Setting a VPN on Multiple Interfaces . . . . . . . . 8 78 B.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 8 79 B.2. Creating an additional IKEv2 Channel . . . . . . . . . . 10 80 B.3. Creation of the Child SA for VPN_1 . . . . . . . . . . . 11 81 B.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 12 82 B.5. Reduced Exchange . . . . . . . . . . . . . . . . . . . . 13 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Introduction 93 This document considers a VPN End User setting its VPN with a 94 Security Gateway, and at least one of the peers has multiple 95 interfaces. Figure 1 represents the case where the VPN has multiple 96 interfaces, figure 2 represents the case where the Security Gateway 97 has multiple interfaces, and figure 3 represents the case where both 98 the VPN End User and the Security Gateway has multiple interfaces. 99 With figure 1 and figure 2, one of the peer has n = 2 interfaces and 100 the other has a single interface. This results in the creating of up 101 to n = 2 VPNs. With figure 3, the VPN End User has n = 2 interfaces 102 and the Security Gateway has m =2 interfaces. This can lead to up to 103 m x n VPNs. 105 +------------+ +------------+ 106 | | Interface_0 : VPN_0 | | 107 | =================== | Security | 108 | VPN | v | Gateway | 109 | End User | ============== | 110 | ========================^ | | 111 | | Interface_1 : VPN_1 | | 112 +------------+ +------------+ 114 Figure 1: VPN End User with Multiple Interfaces 116 +------------+ +------------+ 117 | | Interface_0 : VPN_0 | | 118 | | ============= Security | 119 | VPN | v | Gateway | 120 | End User =================== | | 121 | | ^ ============ | 122 | | Interface_1 : VPN_1 | | 123 +------------+ +------------+ 125 Figure 2: Security Gateway with Multiple Interfaces 127 +------------+ +------------+ 128 | | Interface_0 Interface_0' | | 129 | ================================= Security | 130 | VPN | \\ // | Gateway | 131 | End User | // \\ | | 132 | ================================= | 133 | | Interface_1 Interface_1' | | 134 +------------+ +------------+ 136 Figure3: VPN End User and Security Gateway 137 with Multiple Interfaces 139 With the current IKEv2 [RFC5996], each VPN requires an IKEv2 channel, 140 and setting an IKEv2 channel requires an authentication. 141 Authentication can involve multiple round trips like EAP-SIM 142 [RFC4186] as well as crypto operations that MAY delay the 143 connectivity. 145 This document presents the KEEP_OLD_IKE_SA extension. The main idea 146 is that the peer with multiple interfaces sets an first authenticated 147 IKEv2 channel. Then it takes advantage of this authentication and 148 derives as many parallel IKEv2 channels as VPNs. On each IKEv2 149 channel a VPN is negotiated. This results in parallel VPNS. Then 150 the VPN End User moves the VPNs to their proper places using MOBIKE. 151 Alternatively, the VPN End User can also move the IKEv2 channels and 152 then negotiate the VPNs. 154 [I-D.mglt-mif-security-requirements] provides a problem statement for 155 IPsec and multiple interfaces. 156 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] and 157 [I-D.mglt-ipsecme-alternate-outer-address] have been proposed so 158 tunnel outer IP address can differ from those of the IKEv2 channel. 159 The advantage of the KEEP_OLD_IKE_SA extension is that is requires 160 very few modification to already existing IKEv2 implementation. 161 Then, it is reusing already existing and widely deployed protocol 162 such as MOBIKE [RFC4555]. Finally by keeping a dedicated IKEv2 163 channel for each VPN, it eases reachability tests. 165 3. Terminology 167 This section defines terms and acronyms used in this document. 169 - VPN End User: designates the End User that initiates the VPN with 170 a Security Gateway. This End User may be mobile and moves its 171 VPN from on Security Gateway to the other. 173 - Security Gateway: designates a point of attachment for the VPN 174 service. In this document, the VPN service is provided by 175 multiple Security Gateways. Each Security Gateway may be 176 considered as a specific hardware. 178 - Security Association (SA): The Security Association is defined in 179 [RFC4301]. 181 4. Protocol Overview 182 The goal of the document is to specify how to create a new IKEv2 183 channel. IKEv2 [RFC5996] specifies the CREATE_CHILD_SA that makes 184 possible to rekey an IKE_SA, create or rekey a new Child SA. 186 The difference between rekeying an IKE_SA and creating a new IKE_SA 187 is that the old IKE_SA MUST NOT be deleted, either by starting a 188 Delete exchange or removing the IKE_SA without the Delete exchange. 190 Note that IKEv2 [RFC5996] Section 1.3.2 or Section 2.18 does not 191 explicitly mentions that the old IKE_SA MUST be deleted. However, 192 there are currently no signaling advertising the IKE_SA has not been 193 deleted. The purpose of this document is to avoid this uncertainty 194 when rekeying the IKE_SA. In other words, the document avoids that 195 one peer expects a additional IKE_SA to be created whereas the other 196 simply proceed to a replacement of the old IKE_SA. 198 Currently, one MAY check whether or not the old IKE_SA has been 199 deleted or not by waiting a for a given time and then initiate and 200 empty INFORMATIONAL exchange using the old IKE_SA. The absence of 201 response MAY indicate the old IKE_SA has been removed. 203 This document introduces KEEP_OLD_IKE_SA Notify Payload. The 204 initiator sends the KEEP_OLD_IKE_SA Notify Payload in a 205 CREATE_CHILD_SA request for rekeying the IKE_SA. The KEEP_OLD_IKE_SA 206 Notify Payload is placed before the concerned SA and indicates what 207 is expected for the old IKE_SA. Motivation of this draft is to 208 indicate the old IKE_SA MUST NOT be deleted once the new IKE_SA is 209 rekeyed. Alternatively, the initiator MAY use the KEEP_OLD_IKE_SA 210 Notify Payload to indicate the old IKE_SA is not expected to be re- 211 used. 213 Initiator Responder 214 ------------------------------------------------------------------- 215 HDR, SK {N(KEEP_OLD_IKE_SA) SA, Ni, KEi} --> 217 The responder finds a KEEP_OLD_IKE_SA, if it does not understand the 218 extension it ignores the payload as defined in [RFC5996] 219 Section 3.10.1. Similarly, the KEEP_OLD_IKE_SA Notify Payload MUST 220 be ignored if the CREATE_CHILD_SA request does not concern a IKE_SA 221 rekey. If the initiator wants to check whether the IKE_SA has been 222 deleted or not, it SHOULD proceed to additional empty INFORMATIONAL 223 exchange as described in [RFC5996] Section 2.4. In this case, the 224 responder's response will be: 226 <-- HDR, SK {SA, Nr, KEr} 228 In any other case, the responder understands the KEEP_OLD_IKE_SA 229 Notify Payload and the CREATE_CHILD_SA request concerns a IKE_SA 230 rekey. The responder MUST proceed to the IKE_SA rekey. If the 231 KEEP_OLD_IKE_SA indicates the old IKE_SA MUST be kept, the responder 232 MUST keep the old IKE_SA active. Alternatively, if it indicates the 233 old IKE_SA is not supposed to be used, the responder MAY delete the 234 old IKE_SA after a given time out. The responder MUST respond and 235 indicate if the old IKE_SA has been kept or not. The exchange will 236 be: 238 <-- HDR, SK { N(KEEP_OLD_IKE_SA) 239 SA, Nr, KEr} 241 5. Payload Description 243 Figure 7 illustrates the KEEP_OLD_IKE_SA Notify Payload packet 244 format. 246 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Next Payload |C| RESERVED | Payload Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Protocol ID | SPI Size | Notify Message Type | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |Q| RESERVED | Code Values | RESERVED | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 7: KEEP_OLD_IKE_SA Notify Payload 258 - Next Payload (1 octet): Indicates the type of payload that follows 259 after the header. 261 - Critical Bit (1 bit): Indicates how the responder handles the 262 Notify Payload. In this document the Critical Bit is not set. 264 - RESERVED (7 bits): MUST be set as zero; MUST be ignored on 265 receipt. 267 - Payload Length (2 octet): Length in octets of the current payload, 268 including the generic payload header. 270 - Protocol ID (1 octet): set to zero. 272 - SPI Size (1 octet): set to zero. 274 - Notify Message Type (2 octets): Specifies the type of notification 275 message. It is set to KEEP_OLD_IKE_SA in this document. 277 - Question Bit (1 bit): set to one by the initiator and set to zero 278 by the responder. 280 - RESERVED (7 bits): set to zero. 282 - Code Values: Code that indicates what action is expected to be 283 done with the newly negotiated IKE_SA. 285 Code Values 286 ----------------------- 287 Keep Old IKE_SA 0 288 Unused Old IKE_SA 1 289 Unassigned 2-255 291 6. IANA Considerations 293 The new fields and number are the following: 295 IKEv2 Notify Message Types - Status Types 296 ----------------------------------------- 297 KEEP_OLD_IKE_SA - TBD 299 7. Security Considerations 301 The protocol defined in this document does not modifies IKEv2. It 302 signalizes what has been implementation dependent on how to manage an 303 old IKE_SA after a rekey. 305 8. Acknowledgment 307 The ideas of this draft came from various inputs from the ipsecme and 308 discussions with Tero Kivinen and Michael Richardson. 310 9. References 312 9.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 318 Internet Protocol", RFC 4301, December 2005. 320 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 321 (MOBIKE)", RFC 4555, June 2006. 323 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 324 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 325 5996, September 2010. 327 9.2. Informational References 329 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] 330 Arora, J. and P. Kumar, "Alternate Tunnel Addresses for 331 IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00 332 (work in progress), April 2010. 334 [I-D.mglt-ipsecme-alternate-outer-address] 335 Migault, D., "IKEv2 Alternate Outer IP Address Extension", 336 draft-mglt-ipsecme-alternate-outer-address-00 (work in 337 progress), February 2013. 339 [I-D.mglt-mif-security-requirements] 340 Migault, D. and C. Williams, "IPsec Multiple Interfaces 341 Problem Statement", draft-mglt-mif-security- 342 requirements-03 (work in progress), November 2012. 344 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 345 Protocol Method for Global System for Mobile 346 Communications (GSM) Subscriber Identity Modules (EAP- 347 SIM)", RFC 4186, January 2006. 349 Appendix A. Document Change Log 351 [RFC Editor: This section is to be removed before publication] 353 -00: First version published. 355 Appendix B. Setting a VPN on Multiple Interfaces 357 This section is informational and exposes how a VPN End User as 358 illustrated in Figure 1 can builds two VPNs on its two interfaces 359 without multiple authentications. Other cases represented in figure 360 2 and 3 are similar and can be easily derived from the case. The 361 mechanism is based on the KEEP_OLD_IKE_SA extension and the MOBIKE 362 extension [RFC4555]. 364 B.1. Setting VPN_0 366 First, the VPN End User negotiates a VPN using one interface. This 367 involves a regular IKEv2 setting. In addition, the VPN End User and 368 the Security Gateway advertise they support MOBIKE. At the end of 369 the exchange, VPN_0 is set as represented in figure 4. 371 +------------+ +------------+ 372 | | Interface_0 : VPN_0 | | 373 | =================== | Security | 374 | VPN | v | Gateway | 375 | End User | ============== | 376 | = | | 377 | | Interface_1 | | 378 +------------+ +------------+ 380 Figure 4: VPN End User Establishing VPN_0 382 The exchange is completely described in [RFC4555]. First the 383 negotiates the IKE_SA. In the figure below peers also proceed to NAT 384 detection because of the use of MOBIKE. 386 Initiator Responder 387 ------------------------------------------------------------------- 388 (IP_I1:500 -> IP_R1:500) 389 HDR, SAi1, KEi, Ni, 390 N(NAT_DETECTION_SOURCE_IP), 391 N(NAT_DETECTION_DESTINATION_IP) --> 393 <-- (IP_R1:500 -> IP_I1:500) 394 HDR, SAr1, KEr, Nr, 395 N(NAT_DETECTION_SOURCE_IP), 396 N(NAT_DETECTION_DESTINATION_IP) 398 The initiators and the responder proceed to the authentication 399 exchange, advertise they support MOBIKE and negotiate the SA for 400 VPN_0. Optionally, the initiator and the Security Gateway MAY 401 advertise their multiple interfaces using the ADDITIONAL_IP4_ADDRESS 402 and/or ADDITIONAL_IP6_ADDRESS Notify Payload 404 (IP_I1:4500 -> IP_R1:4500) 405 HDR, SK { IDi, CERT, AUTH, 406 CP(CFG_REQUEST), 407 SAi2, TSi, TSr, 408 N(MOBIKE_SUPPORTED), 409 N(ADDITIONAL_IP*_ADDRESS)+ } --> 411 <-- (IP_R1:4500 -> IP_I1:4500) 412 HDR, SK { IDr, CERT, AUTH, 413 CP(CFG_REPLY), 414 SAr2, TSi, TSr, 415 N(MOBIKE_SUPPORTED), 416 N(ADDITIONAL_IP*_ADDRESS)+} 418 B.2. Creating an additional IKEv2 Channel 420 In our case the the initiator wants to set establish a VPN with its 421 Interface_1 between the VPN End User and the Security Gateway. The 422 VPN End User will first establish a parallel IKE_SA using a 423 CREATE_CHILD_SA that concerns an IKE_SA rekey associated to a 424 KEEP_OLD_IKE_SA Notify Payload. This results in two different IKE_SA 425 between the VPN End User and the Security Gateway. Currently both 426 IKE_SA are set using Interface 0 of the VPN End User. 428 In this section we consider the creation of the additional IKE_SA as 429 a separate exchange. However, they are several situations where this 430 extra round trips MAY be avoided. First if the VPN End User knows 431 multiple interfaces MAY be involved, it can combine this exchange 432 with the previous one (IKE_AUTH, CREATE_CHILD_SA concerning the 433 creation of the SA). Secondly, the Security Gateway MAY also start 434 the CREATE_CHILD_SA exchange to create an additional IKE_SA. This 435 reduces the delay to half a round trip. 437 The CREATE_CHILD_SA exchange to create an additional IKE_SA MAY be 438 combined with the IKE_AUTH exchange exchange if the VPN End User 439 estimates with a high probability that multiple interfaces MAY be 440 involved in the communication. This MAY be the case if the VPN End 441 User has multiple interfaces, or if the VPN End User guesses that the 442 Security Gateway has multiple interfaces. In the case the 443 KEEP_OLD_IKE_SA Notify Payload is not supported by the Security 444 Gateway or that the Security Gateway has only one interface, this 445 will result in rekeying the IKE_SA, and thus does not compromise the 446 communication. 448 Similarly, the CREATE_CHILD_SA exchange to create an additional 449 IKE_SA MAY be initiated by the responder and combined with the 450 IKE_AUTH exchange if the Security Gateway wants to reduce the number 451 of round trips, and supposes the VPN End User will use its multiple 452 interfaces. Note that the Security Gateway knows if multiple 453 interfaces are involved in the communication. What remains uncertain 454 is whether the VPN End User has the ability to use these multiple 455 interfaces simultaneously. 457 Initiator Responder 458 ------------------------------------------------------------------- 459 (IP_I1:4500 -> IP_R1:4500) 460 HDR, SK { N(KEEP_OLD_IKE_SA), 461 SA, Ni, KEi} --> 462 <-- (IP_R1:4500 -> IP_I1:4500) 463 HDR, SK { N(KEEP_OLD_IKE_SA), 464 SA, Nr, KEr} 466 B.3. Creation of the Child SA for VPN_1 468 Once the new IKEv2 channel has been created, the VPN End User MAY 469 initiate a CREATE_CHILD_SA exchange that concerns the creation of a 470 Child SA for VPN_1. The newly created VPN_1 will use Interface_0 of 471 the VPN End User. 473 It is out of scope of the document to define how the VPN End User MAY 474 handle traffic with its multiple interfaces. The VPN End User MAY 475 use the same IP inner address on its multiple interfaces. In this 476 case, the same Traffic Selectors (that is the IP address used for 477 VPN_0 and VPN_1) MAY match for both VPNs VPN_0 and VPN_1. The End 478 User VPN SHOULD be aware of such match and be able to manage it. It 479 MAY for example use distinct Traffic Selectors on both VPNs using 480 different ports, manage the order of its SPD or have SPD defined per 481 interfaces. Defining these mechanisms are out of scope of this 482 document. Alternatively, the VPN End User MAY uses a different IP 483 address for each interface. In the latter case, if the inner IP 484 address is assigned by the Security Gateway, the Configuration 485 Payload (CP) MUST be placed before the SA Payload as specified in 486 [RFC5996] Section 2.19. 488 The creation of VPN_1 is performed via the newly created IKE_SA as 489 follows: 491 Initiator Responder 492 ------------------------------------------------------------------- 493 (IP_I1:4500 -> IP_R1:4500) 494 HDR(new), SK(new) { [CP(CFG_REQUEST)], 495 SAi2, TSi, TSr } --> 497 <-- (IP_R1:4500 -> IP_I1:4500) 498 HDR(new), SK(new) { [CP(CFG_REPLY)], 499 SAr2, TSi, TSr} 501 The resulting configuration is depicted in figure 5. VPN_0 and VPN_1 502 have been created, but both are using the same Interface: 503 Interface_0. 505 +------------+ +------------+ 506 | | Interface_0 : VPN_0, VPN_1 | | 507 | =================== | Security | 508 | VPN ================= v | Gateway | 509 | End User | v ============== | 510 | = ================== | 511 | | Interface_1 | | 512 +------------+ +------------+ 514 Figure 5: VPN End User Establishing VPN_0 and VPN_1 516 B.4. Moving VPN_1 on Interface_1 518 In this section, MOBIKE is used to move VPN_1 on interface_1. The 519 exchange is described in [RFC4555]. All exchanges are using the new 520 IKE_SA. Eventually, the VPN End User MAY check if the Security 521 Gateway is reachable via Interface_1. The exchanges are described 522 below: 524 Initiator Responder 525 ------------------------------------------------------------------- 526 (IP_I2:4500 -> IP_R1:4500) 527 HDR(new), SK(new) { N(NAT_DETECTION_SOURCE_IP), 528 N(NAT_DETECTION_DESTINATION_IP) } 530 <-- (IP_R2:4500 -> IP_I1:4500) 531 HDR(new), SK(new) { 532 N(NAT_DETECTION_SOURCE_IP), 533 N(NAT_DETECTION_DESTINATION_IP) } 535 (This worked, and the initiator requests the peer to switch to new 536 addresses.) 538 (IP_I2:4500 -> IP_R1:4500) 539 HDR(new), SK(new) { N(UPDATE_SA_ADDRESSES), 540 N(NAT_DETECTION_SOURCE_IP), 541 N(NAT_DETECTION_DESTINATION_IP), 542 N(COOKIE2) } --> 544 <-- (IP_R1:4500 -> IP_I2:4500) 545 HDR(new), SK(new) { 546 N(NAT_DETECTION_SOURCE_IP), 547 N(NAT_DETECTION_DESTINATION_IP), 548 N(COOKIE2) } 550 This results in the situation as described in figure 6. 552 +------------+ +------------+ 553 | | Interface_0 : VPN_0 | | 554 | =================== | Security | 555 | VPN | v | Gateway | 556 | End User | ============== | 557 | ========================^ | | 558 | | Interface_1 : VPN_1 | | 559 +------------+ +------------+ 561 Figure 6: VPN End User with Multiple Interfaces 563 B.5. Reduced Exchange 565 The previous sections detail the various exchanges between the VPN 566 End User and the Security Gateway. This section shows an example 567 where the number of exchanges are limited, thus limiting the delay to 568 set up a multiple interface VPN communication. 570 Initiator Responder 571 ------------------------------------------------------------------- 573 (IP_I1:500 -> IP_R1:500) 574 HDR, SAi1, KEi, Ni, 575 N(NAT_DETECTION_SOURCE_IP), 576 N(NAT_DETECTION_DESTINATION_IP) --> 578 <-- (IP_R1:500 -> IP_I1:500) 579 HDR, SAr1, KEr, Nr, 580 N(NAT_DETECTION_SOURCE_IP), 581 N(NAT_DETECTION_DESTINATION_IP) 582 (IP_I1:4500 -> IP_R1:4500) 583 HDR, SK { IDi, CERT, AUTH, 584 CP(CFG_REQUEST), 585 SAi2, TSi, TSr, 586 N(MOBIKE_SUPPORTED), 587 N(ADDITIONAL_IP*_ADDRESS)+, 588 N(KEEP_OLD_IKE_SA), 589 SA, Ni, KEi} --> 591 <-- (IP_R1:4500 -> IP_I1:4500) 592 HDR, SK { IDr, CERT, AUTH, 593 CP(CFG_REPLY), 594 SAr2, TSi, TSr, 595 N(MOBIKE_SUPPORTED), 596 N(ADDITIONAL_IP*_ADDRESS)+}, 597 N(KEEP_OLD_IKE_SA), 598 SA, Nr, KEr} 600 <-- (IP_R1:4500 -> IP_I2:4500) 601 HDR(new), SK(new) 602 { [CP(REQUEST)], 603 SAi2, TSi, TSr, 604 N(UPDATE_SA_ADDRESSES)} 605 (IP_I2:4500 -> IP_R1:4500) --> 606 HDR(new), SK(new) { [CP(CFG_REPLY)], 607 SAr2, TSi, TSr} 609 Author's Address 611 Daniel Migault 612 Francetelecom - Orange 613 38 rue du General Leclerc 614 92794 Issy-les-Moulineaux Cedex 9 615 France 617 Phone: +33 1 45 29 60 52 618 Email: mglt.ietf@gmail.com