Clone IKE SA Extension
draft-mglt-ipsecme-clone-ike-sa-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7791.
|
|
|---|---|---|---|
| Authors | Daniel Migault , Valery Smyslov | ||
| Last updated | 2015-01-19 | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-05)
by Joel Halpern
Almost ready
|
||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 7791 (Proposed Standard) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mglt-ipsecme-clone-ike-sa-03
IPSECME D. Migault (Ed)
Internet-Draft Orange
Intended status: Standards Track V. Smyslov
Expires: July 23, 2015 ELVIS-PLUS
January 19, 2015
Clone IKE SA Extension
draft-mglt-ipsecme-clone-ike-sa-03.txt
Abstract
This document considers a VPN End User setting a VPN with a security
gateway where at least one of the peers has multiple interfaces.
With the current IKEv2 protocol, the outer IP addresses of the VPN
are determined by those used by IKEv2 SA. As a result using multiple
interfaces requires to set up an IKEv2 SA on each interface, or on
each paths if both the VPN Client and the security gateway have
multiple interfaces. Setting each IKEv2 SA involves authentications
which might require multiple round trips as well as activity from the
VPN User and thus would delay the VPN establishment. In addition
multiple authentications unnecessarily increase the load on the VPN
client and the authentication infrastructure.
This document presents the Clone IKE SA extension, where an
additional IKEv2 SA is derived from an existing IKEv2 SA. The newly
created IKEv2 SA is set without the IKEv2 authentication exchange.
The newly created IKEv2 SA can later be assigned to another interface
using MOBIKE protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2015.
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 1]
Internet-Draft Clone IKE SA January 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Support Negotiation . . . . . . . . . . . . . . . . . . . 5
5.2. Cloning the IKE SA . . . . . . . . . . . . . . . . . . . . 6
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . . 6
6. Payload Description . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informational References . . . . . . . . . . . . . . . . . 9
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 10
Appendix B. Setting a VPN on Multiple Interfaces . . . . . . . . 10
B.1. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . 11
B.2. Creating an additional IKEv2 Channel . . . . . . . . . . . 12
B.3. Creation of the Child SA for VPN_1 . . . . . . . . . . . . 12
B.4. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 2]
Internet-Draft Clone IKE SA January 2015
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
The main scenario that motivated this document is a VPN End User
establishing VPN with a Security Gateway when at least one of the
peers has multiple interfaces. Figure 1 represents the case when the
VPN End User has multiple interfaces, Figure 2 represents the case
when the Security Gateway has multiple interfaces, and Figure 3
represents the case when both the VPN End User and the Security
Gateway have multiple interfaces. With Figure 1 and Figure 2, one of
the peers has n = 2 interfaces and the other has a single interface.
This results in creating of up to n = 2 VPNs. With Figure 3, the VPN
End User has n = 2 interfaces and the Security Gateway has m = 2
interfaces. This may lead to up to m x n VPNs.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| =================== | Security |
| VPN | v | Gateway |
| End User | ============== |
| ========================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 1: VPN End User with Multiple Interfaces
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| | ============= Security |
| VPN | v | Gateway |
| End User =================== | |
| | ^ ============ |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 2: Security Gateway with Multiple Interfaces
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 3]
Internet-Draft Clone IKE SA January 2015
+------------+ +------------+
| | Interface_0 Interface_0' | |
| ================================= Security |
| VPN | \\ // | Gateway |
| End User | // \\ | |
| ================================= |
| | Interface_1 Interface_1' | |
+------------+ +------------+
Figure 3: VPN End User and Security Gateway with Multiple Interfaces
With the current IKEv2 protocol [RFC5996], each VPN requires an IKEv2
SA, and setting an IKEv2 SA requires an authentication.
Authentication might require multiple round trips and an activity
from the End User (like EAP-SIM [RFC4186] or EAP-TLS [RFC5216]) as
well as crypto operations that would introduce an additional delay.
This document presents the Clone IKE SA extension. The main idea is
that the peer with multiple interfaces sets the first IKEv2 SA as
usual. Then it takes advantage of the fact that this IKE SA is
completed and derives as many new parallel IKEv2 SAs from it as the
desired number of VPNs. On each IKEv2 SA a VPN is negotiated. This
results in coexisting of parallel VPNs. Then the VPN End User moves
each VPN to its proper location using MOBIKE [RFC4555].
Alternatively, the VPN End User may first move the IKEv2 SAs and then
negotiate the VPNs.
Several documents have addressed the issue of IPsec and multiple
interfaces. [I-D.mglt-mif-security-requirements] provides a problem
statement for IPsec and multiple interfaces.
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] and
[I-D.mglt-ipsecme-alternate-outer-address] have been proposed to
allow tunnel outer IP addresses to be different from those of the
IKEv2 SA.
The advantage of the Clone IKE SA extension is that is requires very
few modifications to already existing IKEv2 implementations. Then,
it reuses already existing and widely deployed MOBIKE protocol
[RFC4555]. Finally keeping a dedicated IKEv2 SA for each VPN
simplifies reachability tests and VPN maintenance.
Note also that the Clone IKE SA extension is independent from MOBIKE
and MAY also address other future scenarios.
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 4]
Internet-Draft Clone IKE SA January 2015
3. Terminology
This section defines terms and acronyms used in this document.
- VPN End User: designates the end user that initiates the VPN with
a Security Gateway. This end user may be mobile and moves its
VPN from one Security Gateway to another.
- Security Gateway: designates a point of attachment for the VPN
service. In this document, the VPN service is provided by
multiple Security Gateways. Each Security Gateway may be
considered as a specific hardware.
- IKE SA: The IKEv2 SA (IKEv2 Security Association) is defined in
[RFC5996].
4. Protocol Overview
The goal of the document is to specify how to create a new IKEv2 SA
without performing an authentication. In order to achieve this goal,
the document proposes that the two peers agree they support the Clone
IKE SA extension. This is done during the IKE_AUTH exchange by
exchanging the CLONE_IKE_SA_SUPPORTED Notifications. To create a new
parallel IKE SA, one of the peers initiates a CREATE_CHILD_SA
exchange as if it would rekey the IKE SA. In order to indicate the
current IKE SA must not be deleted, the initiator includes the
CLONE_IKE_SA Notification in the CREATE_CHILD_SA exchange. This
results in two parallel IKE SAs.
5. Protocol Details
5.1. Support Negotiation
The initiator and the responder indicate their support for the Clone
IKE SA extension by exchanging the CLONE_IKE SA_SUPPORTED
Notifications. This notification MUST be sent in the IKE_AUTH
exchange (in case of multiple IKE_AUTH exchanges, in the message
containing the SA payload). If both initiator and responder send
this notification during the IKE_AUTH exchange, peers MAY use the
Clone IKE SA extension. In the other case the Clone IKE SA extension
MUST NOT be used.
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 5]
Internet-Draft Clone IKE SA January 2015
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED) }
<-- HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY), SAr2, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED) }
5.2. Cloning the IKE SA
The initiator of the rekey exchange includes the CLONE_IKE_SA
Notification in a CREATE_CHILD_SA request for rekeying the IKE SA.
The CLONE_IKE_SA Notification indicates that the current IKE SA MUST
NOT be deleted. Instead two parallel IKEv2 SAs are expected to
coexist. The current IKE SA becomes the old IKE SA and the newly
negotiated IKE SA becomes the new IKE SA. The CLONE_IKE_SA
Notification MUST appear only in request message of the
CREATE_CHILD_SA exchange concerning the IKE SA rekey. If the
CLONE_IKE_SA Notification appears in any other message, it MUST be
ignored.
Initiator Responder
-------------------------------------------------------------------
HDR, SK { N(CLONE_IKE_SA), SA, Ni, KEi } -->
If the CREATE_CHILD_SA request concerns an IKE SA rekey and contains
the CLONE_IKE_SA Notification, the Responder proceeds to the IKE SA
rekey, creates the new IKE SA, and keeps the old IKE SA. No
additional Notify Payload is included in the CREATE_CHILD_SA response
as represented below:
<-- HDR, SK { SA, Nr, KEr }
When using Clone IKE SA Extension peers MUST NOT transfer existing
Child SAs, that were created by the old IKE SA, to the newly created
IKE SA. So, all signalling messages, concerning those Child SAs MUST
continue to be send over the old IKE SA. This is different from the
regular IKE SA rekey.
5.3. Error Handling
There may be conditions when responder for some reason is unable or
unwilling to perform IKE SA cloning. This inability may be temporary
or permanent.
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 6]
Internet-Draft Clone IKE SA January 2015
Temporary inability occurs when responder doesn't have enough
resources at the moment to clone IKE SA or when IKE SA is being
deleted by responder. In this case the responder SHOULD reject
request to clone IKE SA with the TEMPORARY_FAILURE notification.
<-- HDR, SK { N(TEMPORARY_FAILURE) }
After receiving this notification the initiator MAY retry its request
after waiting some period of time. See Section 2.25 of [RFC5996] for
details.
In some cases responder may have restrictions on the number of co-
existing IKE SAs with one peer. These restrictions may be either
implicit (some devices may have enough resources to handle only a few
IKE SAs) or explicit (provided by some configuration parameter). If
the initiator wants to clone more IKE SAs, than responder is able or
is configured to handle, the responder SHOULD reject the request with
the NO_ADDITIONAL_SAS notification.
<-- HDR, SK { N(NO_ADDITIONAL_SAS) }
This condition is considered permanent and the initiator SHOULD NOT
retry to clone IKE SA until some of existing IKE SAs with the
responder are deleted.
6. Payload Description
Figure 4 illustrates the Notify Payload packet format as described in
section 3. 10 of [RFC5996]. This format is used for both the
CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED notifications.
The CLONE_IKE_SA_SUPPORTED Notification is used in an IKEv2 exchange
of type IKE_AUTH and the CLONE_IKE_SA is used in an IKEv2 exchange of
type CREATE_CHILD_SA.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Notify Payload
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 7]
Internet-Draft Clone IKE SA January 2015
- Protocol ID (1 octet): set to zero.
- SPI Size (1 octet): set to zero.
- Notify Message Type (2 octets): Specifies the type of notification
message. It is set to <TBA by IANA> for the CLONE_IKE_SA
notification or to <TBA by IANA> for the CLONE_IKE_SA_SUPPORTED
Notification.
7. IANA Considerations
IANA is requested to allocate two values in the IKEv2 Notify Message
Types - Status Types registry:
IKEv2 Notify Message Types - Status Types
-----------------------------------------
CLONE_IKE_SA_SUPPORTED - TBA
CLONE_IKE_SA - TBA
8. Security Considerations
The protocol defined in this document does not modify IKEv2.
Security considerations for Clone IKE SA extension are mostly the
same as those for base IKEv2 protocol described in [RFC5996].
This extension provides the ability for an initiator to clone
existing IKE SAs. As a result it may influence any accounting or
control mechanisms based on a single IKE SA per authentication.
Suppose a system has a limit on the number of IKE SAs it can handle.
In this case, the Clone IKE SA extension may provide a way for
resource exhaustion, as a single end user may populate multiple IKE
SAs.
Suppose a system shares the IPsec resources by limiting the number of
Child SAs per IKE SA. With a single IKE SA per end user, this
provides an equal resource sharing. The Clone IKE SA provides means
for a end user to overpass this limit. Such system should evaluate
the number of Child SAs over the number of all IKE SAs associated to
an end user.
Note, that these issues are not unique for Clone IKE SA extensions,
as multiple IKE SAs between two peers may be created without this
extension. Note also, that implementation can always limit the
number of cloned IKE SAs.
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 8]
Internet-Draft Clone IKE SA January 2015
Suppose VPN or any other IPsec based service monitoring is based on
the liveliness of the first IKE SA. Such system considers a service
is accessed or used from the time IKE performs an authentication to
the time the IKE SA is deleted. Such accounting methods were fine as
any IKE SA required an authentication exchange. As the Clone IKE SA
skips the authentication phase, Clone IKE SA may make possible to
delete the initial IKE SA while the service is being used on the
cloned IKE SA. Such accountings method should considers the service
is being used from the first IKE SA establishment to until the last
IKE SA is being removed.
9. Acknowledgments
The ideas of this draft came from various inputs from the ipsecme WG
and from discussions with Tero Kivinen and Michael Richardson. Yaron
Sheffer, Tero Kivinen provided significant inputs to set the current
design of the protocol as well as its designation.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
10.2. Informational References
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses]
Arora, J. and P. Kumar, "Alternate Tunnel Addresses for
IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00
(work in progress), April 2010.
[I-D.mglt-ipsecme-alternate-outer-address]
Migault, D., "IKEv2 Alternate Outer IP Address Extension",
draft-mglt-ipsecme-alternate-outer-address-00 (work in
progress), February 2013.
[I-D.mglt-mif-security-requirements]
Migault, D. and C. Williams, "IPsec Multiple Interfaces
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 9]
Internet-Draft Clone IKE SA January 2015
Problem Statement",
draft-mglt-mif-security-requirements-03 (work in
progress), November 2012.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for Global System for Mobile
Communications (GSM) Subscriber Identity Modules (EAP-
SIM)", RFC 4186, January 2006.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-01: Valery Smyslov is now a co-author.
1. Exchange of CLONE_IKE_SA_SUPPORTED notifications made limited to
IKE_AUTH exchange only.
2. Some clarifications about processing CLONE_IKE_SA notification
are added.
3. Some words that with Clone IKE SA existing Child SAs must not be
transferred to newly created IKE SA (unlike regular rekey) are added.
4. Reduced exchanges (combined IKE_AUTH with cloning IKE SA and
CREATE_CHILD_SA with transferring to different IPs) are removed.
5. Error handling while clonoing IKE SA is described.
-00: Comments from Valery Smyslov, Tero Kivinen and Yaron Sheffer.
SUPPORTED Notify Payload can be placed in a INFORMATIONAL or IKE_AUTH
exchange. CLONE_IKE_SA is sent in a CREATE_CHILD_SA exchange and is
provided both in the query and in the response.
-00: First version published. draft-mglt-ipsecme-keep-old-ike-sa-00
Appendix B. Setting a VPN on Multiple Interfaces
This section is informational and exposes how a VPN End User as
illustrated in Figure 1 can build two VPNs on its two interfaces
without multiple authentications. Other cases represented in
Figure 2 and Figure 3 are similar and can be easily derived from this
case. The mechanism is based on the Clone IKE SA extension and the
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 10]
Internet-Draft Clone IKE SA January 2015
MOBIKE extension [RFC4555].
B.1. Setting VPN_0
First, the VPN End User negotiates a VPN using one interface. This
involves a regular IKEv2 exchanges. In addition, the VPN End User
and the Security Gateway advertise their support for MOBIKE. At the
end of the IKE_AUTH exchange, VPN_0 is set as represented in
Figure 5.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| =================== | Security |
| VPN | v | Gateway |
| End User | ============== |
| = | |
| | Interface_1 | |
+------------+ +------------+
Figure 5: VPN End User Establishing VPN_0
The exchanges are completely described in [RFC5996] and [RFC4555].
First, peers negotiate IKE SA parameters and exchange nonces and
public keys in IKE_SA_INIT exchange. In the figure below they also
proceed to NAT detection because of the use of MOBIKE.
Initiator Responder
-------------------------------------------------------------------
(IP_I0:500 -> IP_R:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R:500 -> IP_I0:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
Then the initiator and the responder proceed to the IKE_AUTH
exchange, advertise their support for MOBIKE and for the Clone IKE SA
extension - with the MOBIKE_SUPPORTED and the CLONE_IKE_SA_SUPPORTED
Notifications - and negotiate the Child SA for VPN_0. Optionally,
the initiator and the Security Gateway MAY advertise their multiple
interfaces using the ADDITIONAL_IP4_ADDRESS and/or
ADDITIONAL_IP6_ADDRESS Notify Payload.
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 11]
Internet-Draft Clone IKE SA January 2015
(IP_I0:4500 -> IP_R:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP*_ADDRESS)+ } -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP*_ADDRESS)+}
B.2. Creating an additional IKEv2 Channel
In our case the the initiator wants to establish a VPN with its
Interface_1 between the VPN End User and the Security Gateway. The
VPN End User will first establish a parallel IKE SA using a
CREATE_CHILD_SA that concerns an IKE SA rekey associated to a
CLONE_IKE_SA Notify Payload. This results in two different IKE SAs
between the VPN End User and the Security Gateway. Currently both
IKE SAs are set using Interface 0 of the VPN End User.
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR, SK { N(CLONE_IKE_SA),
SA, Ni, KEi} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK { N(CLONE_IKE_SA),
SA, Nr, KEr}
B.3. Creation of the Child SA for VPN_1
Once the new IKEv2 SA has been created, the VPN End User MAY initiate
a CREATE_CHILD_SA exchange that concerns the creation of a Child SA
for VPN_1. The newly created VPN_1 will use Interface_0 of the VPN
End User.
It is out of scope of the document to define how the VPN End User
handles traffic with multiple interfaces. The VPN End User MAY use
the same IP inner address on its multiple interfaces. In this case,
the same Traffic Selectors (that is the IP address used for VPN_0 and
VPN_1) MAY match for both VPNs VPN_0 and VPN_1. The end user VPN
SHOULD be aware of such match and be able to manage it. It MAY for
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 12]
Internet-Draft Clone IKE SA January 2015
example use distinct Traffic Selectors on both VPNs using different
ports, manage the order of its SPD or have SPD defined per
interfaces. Defining these mechanisms are out of scope of this
document. Alternatively, the VPN End User MAY use a different IP
address for each interface. In the latter case, if the inner IP
address is assigned by the Security Gateway, the Configuration
Payload (CP) MUST be placed before the SA Payload as specified in
[RFC5996] Section 2.19.
The creation of VPN_1 is performed via the newly created IKE SA as
follows:
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR(new), SK(new) { [CP(CFG_REQUEST)],
SAi2, TSi, TSr } -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR(new), SK(new) { [CP(CFG_REPLY)],
SAr2, TSi, TSr}
The resulting configuration is depicted in Figure 6. VPN_0 and VPN_1
have been created, but both are using the same Interface:
Interface_0.
+------------+ +------------+
| | Interface_0 : VPN_0, VPN_1 | |
| =================== | Security |
| VPN ================= v | Gateway |
| End User | v ============== |
| = ================== |
| | Interface_1 | |
+------------+ +------------+
Figure 6: VPN End User Establishing VPN_0 and VPN_1
B.4. Moving VPN_1 on Interface_1
In this section, MOBIKE is used to move VPN_1 on interface_1. The
exchange is described in [RFC4555]. All exchanges use the new IKE
SA. Eventually, the VPN End User MAY check if the Security Gateway
is reachable via Interface_1. The exchanges are described below:
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 13]
Internet-Draft Clone IKE SA January 2015
Initiator Responder
-------------------------------------------------------------------
(IP_I1:4500 -> IP_R:4500)
HDR(new), SK(new) { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R:4500 -> IP_I1:4500)
HDR(new), SK(new) {
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
After that initiator requests the peer to switch to new addresses.
(IP_I1:4500 -> IP_R:4500)
HDR(new), SK(new) { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } -->
<-- (IP_R:4500 -> IP_I1:4500)
HDR(new), SK(new) {
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) }
This results in the situation as described in Figure 7.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| =================== | Security |
| VPN | v | Gateway |
| End User | ============== |
| ========================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 7: VPN End User with Multiple Interfaces
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 14]
Internet-Draft Clone IKE SA January 2015
Authors' Addresses
Daniel Migault
Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Phone: +33 1 45 29 60 52
Email: daniel.migault@orange.com
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd) 124460
Russian Federation
Phone: +7 495 276 0211
Email: svan@elvis.ru
Migault (Ed) & Smyslov Expires July 23, 2015 [Page 15]