One document matched: draft-mglt-ipsecme-clone-ike-sa-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc1876 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1876.xml">
<!ENTITY rfc4555 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4555.xml">
<!ENTITY rfc4186 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml">
<!ENTITY rfc5216 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY I-D.kivinen-ipsecme-ikev2-rfc5996bis PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-kivinen-ipsecme-ikev2-rfc5996bis-04.xml">
]>
<rfc category="std"
docName="draft-mglt-ipsecme-clone-ike-sa-02.txt"
ipr="trust200902">
<front>
<title abbrev="Clone IKE SA"> Clone IKE SA Extension</title>
<author fullname="Daniel Migault" initials="D." surname="Migault (Ed)">
<organization>Orange</organization>
<address>
<postal>
<street>38 rue du General Leclerc</street>
<city>92794 Issy-les-Moulineaux Cedex 9</city>
<country>France</country>
</postal>
<phone>+33 1 45 29 60 52</phone>
<email>daniel.migault@orange.com</email>
</address>
</author>
<author fullname='Valery Smyslov' initials='V.' surname="Smyslov">
<organization>ELVIS-PLUS</organization>
<address>
<postal>
<street>PO Box 81</street>
<city>Moscow (Zelenograd)</city>
<code>124460</code>
<country>Russian Federation</country>
</postal>
<phone>+7 495 276 0211</phone>
<email>svan@elvis.ru</email>
</address>
</author>
<date/>
<area>SECURITY</area>
<workgroup>IPSECME</workgroup>
<abstract>
<t>This document considers a VPN End User setting a VPN with a security gateway where at least one of the peers has multiple interfaces.</t>
<t>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 path 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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Introduction">
<t>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. <xref target="Figure1"/> represents the case when the VPN End User has multiple interfaces, <xref target="Figure2"/> represents the case when the Security Gateway has multiple interfaces, and <xref target="Figure3"/> represents the case when both the VPN End User and the Security Gateway have multiple interfaces. With <xref target="Figure1"/> and <xref target="Figure2"/>, 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 <xref target="Figure3"/>, 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.</t>
<figure title="VPN End User with Multiple Interfaces" anchor="Figure1" >
<artwork>
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| =================== | Security |
| VPN | v | Gateway |
| End User | ============== |
| ========================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
</artwork>
</figure>
<figure title="Security Gateway with Multiple Interfaces" anchor="Figure2">
<artwork>
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| | ============= Security |
| VPN | v | Gateway |
| End User =================== | |
| | ^ ============ |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
</artwork>
</figure>
<figure title="VPN End User and Security Gateway with Multiple Interfaces" anchor="Figure3">
<artwork>
+------------+ +------------+
| | Interface_0 Interface_0' | |
| ================================= Security |
| VPN | \\ // | Gateway |
| End User | // \\ | |
| ================================= |
| | Interface_1 Interface_1' | |
+------------+ +------------+
</artwork>
</figure>
<t>With the current IKEv2 protocol <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/>, 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 <xref target="RFC4186"/> or EAP-TLS <xref target="RFC5216"/>) as well as crypto operations that would introduce an additional delay.</t>
<t>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 parallel VPNs. Then the VPN End User moves each VPN to its proper location using MOBIKE <xref target="RFC4555"/>. Alternatively, the VPN End User may first move the IKEv2 SAs and then negotiate the VPNs.</t>
<t>Combining the Clone IKE SA extension with MOBIKE <xref target="RFC4555"/> for IPsec communications with multiple interfaces provides the following advantages. First, the Clone IKE SA extension requires very few modifications to already existing IKEv2 implementations. Then, it takes advantage of already existing and widely deployed MOBIKE protocol. Finally, it keeps a dedicated IKEv2 SA for each VPN which simplifies reachability tests and VPN maintenance.</t>
<t>Note also that the Clone IKE SA extension is independent from MOBIKE and MAY also address other future scenarios.</t>
</section>
<section title="Terminology">
<t>This section defines terms and acronyms used in this document.
<list hangIndent="6" style="hanging">
<t hangText="- 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.</t>
<t hangText="- 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. </t>
<t hangText="- IKE SA: ">The IKEv2 SA (IKEv2 Security Association) is defined in <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/>.</t>
</list>
</t>
</section>
<section title="Protocol Overview">
<t>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.</t>
<t>Note, that without the CLONE_IKE_SA Notification the old IKE SA would be deleted after the rekey is successfully completed (as specified in Section 2.8 of <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/>.</t>
</section>
<section title="Protocol Details">
<section title="Support Negotiation">
<t>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.</t>
<figure>
<artwork><![CDATA[
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) }
]]></artwork>
</figure>
</section>
<section title="Cloning the IKE SA">
<t>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.</t>
<figure>
<artwork><![CDATA[
Initiator Responder
-------------------------------------------------------------------
HDR, SK { N(CLONE_IKE_SA), SA, Ni, KEi } -->
]]></artwork>
</figure>
<t>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:</t>
<figure>
<artwork><![CDATA[
<-- HDR, SK { SA, Nr, KEr }
]]></artwork>
</figure>
<t>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.</t>
</section>
<section title="Error Handling">
<t>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.</t>
<t>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.</t>
<figure>
<artwork><![CDATA[
<-- HDR, SK { N(TEMPORARY_FAILURE) }
]]></artwork>
</figure>
<t>After receiving this notification the initiator MAY retry its request after waiting some period of time. See Section 2.25 of <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/> for details.</t>
<t>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.</t>
<figure>
<artwork><![CDATA[
<-- HDR, SK { N(NO_ADDITIONAL_SAS) }
]]></artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Payload Description">
<t><xref target="Figure6"/> illustrates the Notify Payload packet format as described in section 3. 10 of <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/>. This format is used for both the CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED notifications.</t>
<t>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.</t>
<figure title="Notify Payload" anchor="Figure6">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields Next Payload, Critical Bit, RESERVED and Payload Length are defined in <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/>. Specific fields defined in this document are:
<list style="hanging" hangIndent="6">
<!-- Do we need to respecify the fields that are already specified in RFC5996?
<t hangText="- Next Payload (1 octet):">Indicates the type of payload that follows this payload.</t>
<t hangText="- Critical Bit (1 bit):"> Indicates how the responder handles the Notify Payload. As notify payload is mandatory to support in IKEv2, the Critical Bit is not set.
</t>
<t hangText="- RESERVED (7 bits):"> MUST be set to zero; MUST be ignored on receipt.</t>
<t hangText="- Payload Length (2 octets):"> Length in octets of the current payload, including the generic payload header.</t> -->
<t hangText="- Protocol ID (1 octet):"> set to zero.</t>
<t hangText="- SPI Size (1 octet):"> set to zero.</t>
<t hangText="- 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.</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to allocate two values in the IKEv2 Notify Message Types - Status Types registry:</t>
<figure>
<artwork>
IKEv2 Notify Message Types - Status Types
-----------------------------------------
CLONE_IKE_SA_SUPPORTED - TBA
CLONE_IKE_SA - TBA
</artwork>
</figure>
</section>
<section title="Security Considerations">
<t>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 <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/>.</t>
<t>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.</t>
<t>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.</t>
<t>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 an 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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Acknowledgments">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4555;
</references>
<references title="Informational References">
&rfc4186;
&rfc5216;
&I-D.kivinen-ipsecme-ikev2-rfc5996bis;
</references>
<section title="Document Change Log">
<t>[RFC Editor: This section is to be removed before publication]</t>
<t> -02: Clarification, editing. </t>
<t>-01: Valery Smyslov is now a co-author.</t>
<t>1. Exchange of CLONE_IKE_SA_SUPPORTED notifications made limited to IKE_AUTH exchange only.</t>
<t>2. Some clarifications about processing CLONE_IKE_SA notification are added.</t>
<t>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.</t>
<t>4. Reduced exchanges (combined IKE_AUTH with cloning IKE SA and CREATE_CHILD_SA with transferring to different IPs) are removed.</t>
<t>5. Error handling while clonoing IKE SA is described.</t>
<t>-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.</t>
<t>-00: First version published. draft-mglt-ipsecme-keep-old-ike-sa-00</t>
</section>
<section title="Setting a VPN on Multiple Interfaces">
<t>This section is informational and exposes how a VPN End User as illustrated in <xref target="Figure1"/> can build two VPNs on its two interfaces without multiple authentications. Other cases represented in <xref target="Figure2"/> and <xref target="Figure3"/> are similar and can be easily derived from this case. The mechanism is based on the Clone IKE SA extension and the MOBIKE extension <xref target="RFC4555"/>.</t>
<section title="Setting VPN_0">
<t>First, the VPN End User negotiates a VPN using one interface. This involves 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 <xref target="Figure7"/>.</t>
<figure title="VPN End User Establishing VPN_0" anchor="Figure7">
<artwork>
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| =================== | Security |
| VPN | v | Gateway |
| End User | ============== |
| = | |
| | Interface_1 | |
+------------+ +------------+
</artwork>
</figure>
<t>The exchanges are completely described in <xref target="I-D.kivinen-ipsecme-ikev2-rfc5996bis"/> and <xref target="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.</t>
<figure>
<artwork><![CDATA[
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)
]]></artwork>
</figure>
<t>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.</t>
<figure>
<artwork><![CDATA[
(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)+}
]]></artwork>
</figure>
</section>
<section title="Creating an additional IKEv2 Channel">
<t>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.</t>
<figure>
<artwork><![CDATA[
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}
]]></artwork>
</figure>
</section>
<section title="Creation of the Child SA for VPN_1">
<t>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.</t>
<t>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 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.
</t>
<t> The creation of VPN_1 is performed via the newly created IKE SA as follows:</t>
<figure>
<artwork><![CDATA[
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}
]]></artwork>
</figure>
<t>The resulting configuration is depicted in <xref target="Figure8"/>. VPN_0 and VPN_1 have been created, but both are using the same Interface: Interface_0.</t>
<figure title="VPN End User Establishing VPN_0 and VPN_1" anchor="Figure8">
<artwork>
+------------+ +------------+
| | Interface_0 : VPN_0, VPN_1 | |
| =================== | Security |
| VPN ================= v | Gateway |
| End User | v ============== |
| = ================== |
| | Interface_1 | |
+------------+ +------------+
</artwork>
</figure>
</section>
<section title="Moving VPN_1 on Interface_1">
<t>In this section, MOBIKE is used to move VPN_1 on interface_1. The exchange is described in <xref target="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:</t>
<figure>
<artwork><![CDATA[
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) }
]]></artwork>
</figure>
<t>After that initiator requests the peer to switch to new addresses.</t>
<figure>
<artwork><![CDATA[
(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) }
]]></artwork>
</figure>
<t>This results in the situation as described in <xref target="Figure9"/>.</t>
<figure title="VPN End User with Multiple Interfaces" anchor="Figure9">
<artwork>
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| =================== | Security |
| VPN | v | Gateway |
| End User | ============== |
| ========================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
</artwork>
</figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:25 |