RFC 7791

Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)

📅 published March 2016, from ietf

RFC 7791: Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2) 🎀

  • Authors: D. Migault, Ed. (Ericsson) and V. Smyslov (ELVIS-PLUS) 💖
  • Category: Standards Track 🦋
  • ISSN: 2070-1721 🌸
  • Date: March 2016 📅
  • Obsoletes / Updates: This header doesn't list any RFCs that it obsoletes or updates. 🧚

Abstract

okay so this doc is about a VPN end user setting up an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2) 🔐. It's giving "multiple interfaces" energy, because the setup is for cases where at least one of the peers has more than one interface, or where the Security Gateway is a cluster and every node has its own IP address 🌈.

The protocol here lets a peer clone an IKEv2 SA, meaning a new SA gets derived from an existing one ✨. The new IKE SA gets set up without the IKEv2 authentication exchange, which is so iconic 💅. Later on, this IKE SA can be assigned to another interface or moved to another cluster node 🦋.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741 📚.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7791 🌸.

Copyright (c) 2016 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   5
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
5.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   6
  5.1.  Support Negotiation . . . . . . . . . . . . . . . . . . .   6
  5.2.  Cloning the IKE SA  . . . . . . . . . . . . . . . . . . .   7
  5.3.  Error Handling  . . . . . . . . . . . . . . . . . . . . .   7
6.  Payload Description . . . . . . . . . . . . . . . . . . . . .   8
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
Appendix A.  Setting a VPN on Multiple Interfaces . . . . . . . .  11
  A.1.  Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . .  11
  A.2.  Creating an Additional IKE SA . . . . . . . . . . . . . .  12
  A.3.  Creating the Child SA for VPN_1 . . . . . . . . . . . . .  12
  A.4.  Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . .  13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction ✨

The main scenario behind this doc is a VPN end user setting up a VPN with a Security Gateway when at least one of the peers has multiple interfaces 🎀. Figure 1 shows the case where the VPN end user has multiple interfaces, Figure 2 shows the case where the Security Gateway has multiple interfaces, and Figure 3 shows the case where both the VPN end user and the Security Gateway have multiple interfaces 💅. For Figure 1 and Figure 2, one peer has n = 2 interfaces and the other has a single interface. That leads to up to n = 2 VPNs 🌸. For Figure 3, the VPN end user has n = 2 interfaces and the Security Gateway has m = 2 interfaces. That can lead to up to m x n VPNs 🔥.

   +------------+                                +------------+
   |            | Interface_0 : VPN_0            |            |
   |            =================                |            |
   |    VPN     |               v                |  Security  |
   |  End User  |               ==================  Gateway   |
   |            ================^                |            |
   |            | Interface_1 : VPN_1            |            |
   +------------+                                +------------+

Figure 1: VPN End User with Multiple Interfaces

   +------------+                                +------------+
   |            |            Interface_0 : VPN_0 |            |
   |            |               ==================            |
   |    VPN     |               v                |  Security  |
   |  End User  =================                |  Gateway   |
   |            |               ^=================            |
   |            |            Interface_1 : VPN_1 |            |
   +------------+                                +------------+

Figure 2: Security Gateway with Multiple Interfaces

   +------------+                                +------------+
   |            | Interface_0       Interface_0' |            |
   |            ==================================            |
   |    VPN     |             \\ //              |  Security  |
   |  End User  |             // \\              |  Gateway   |
   |            ==================================            |
   |            | Interface_1       Interface_1' |            |
   +------------+                                +------------+

Figure 3: VPN End User and Security Gateway with Multiple Interfaces

With the current IKEv2 protocol [RFC7296], each VPN needs its own IKE SA, and setting up an IKE SA needs authentication 🔐. That authentication can take multiple round trips and some action from the end user (like EAP-SIM [RFC4186] or EAP-TLS [RFC5216]), plus crypto operations that add extra delay 🥺.

Another scenario is a load-balancing solution. Load-sharing clusters are often built to be transparent for VPN end users 🌈. With IPsec, that means the IKE and IPsec SA states get duplicated on every cluster node that the load balancer can redirect packets to 👯. The downside is that anti-replay related data (in particular, the Sequence Number) has to be reliably synchronized between the participating nodes for every outgoing Authentication Header (AH) or Encapsulating Security Payload (ESP) packet. That makes building high-speed systems kind of problematic 😭.

Another way to build load-balancing systems is to make VPN end users aware of them. That lets two or more Security Gateways share the same ID while each one has its own IP address 🧚. In this setup, the VPN end user first establishes an IKE SA with one of these gateways. Then, at some point, the gateway decides to move the client to a different cluster node 🦋. This can be done with the Redirect Mechanism for IKEv2 [RFC5685]. The downside is that a brand new IKE SA has to be set up from scratch, including full authentication 💀. In some cases, that can be avoided by using IKEv2 Session Resumption [RFC5723] with a new gateway. But that requires the VPN end user to know beforehand which new gateway to connect to 🙈. So it's desirable to be able to clone the existing IKE SA, move it to a different Security Gateway, and then tell the VPN end user to use this new SA. That way, the participating Security Gateways can share the load between them 💜.

This document introduces the possibility of cloning the IKE SA in IKEv2 🎀. The main idea is that the peer with multiple interfaces sets up the first IKE SA as usual. Then it takes advantage of the fact that this SA is completed, and derives as many new parallel IKE SAs from it as the number of VPNs it wants 🌸. On each IKE SA, a VPN gets negotiated by creating one or more IPsec SAs. The result is coexisting parallel VPNs ✨. Then the VPN end user moves each IPsec SA to its proper location using the IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555]. Alternatively, the VPN end user can move the IKE SAs first and create the IPsec SAs afterwards 🦋.

It's up to the host's local policy to decide which additional VPNs to create and when to create them 🧠. Picking the address pairs for migration is a local matter too 🍓.

In the case of multiple interfaces on both ends, take care to avoid the VPNs being duplicated by both ends, or moved to both interfaces 👑.

Multiple MOBIKE operations can also be involved, coming from the Security Gateway or the VPN end user 🔁. Say, as depicted in Figure 3, the cloned VPN is between Interface _0 and Interface_0', and the VPN end user and the Security Gateway want to move it to Interface_1 and Interface_1'. The VPN end user can start a MOBIKE exchange to move it to Interface_1. Then the cloned VPN is between Interface_1 and Interface_0' 🌈. After that, the Security Gateway can start its own MOBIKE exchange to move the VPN to Interface_1'. At that point, the VPN has reached its final destination 🎉.

Combining IKE SA cloning with the MOBIKE protocol gives IPsec communications with multiple interfaces some real perks 💖. First, cloning the IKE SA needs very few changes to existing IKEv2 implementations 🫶. Then, it takes advantage of the already existing and widely deployed MOBIKE protocol 🔥. Finally, it keeps a dedicated IKE SA for each VPN, which makes reachability tests and VPN maintenance way simpler 🥹.

Also, cloning the IKE SA is independent from MOBIKE. It can address other future scenarios that aren't described in this document 🔮.

2. 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] 📏.

3. Terminology 📖

This section defines the terms and acronyms used in this document 🌷.

  • VPN: Virtual Private Network -- one or more Child (IPsec) SAs created in tunnel mode between two peers. 🔐
  • VPN End User: designates the end user that initiates the VPN with a Security Gateway. This end user may be mobile and move 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: IKE Security Association as defined in [RFC7296]. 💜

4. Protocol Overview ✨

okay so this doc is all about cloning existing IKE SAs without doing new authentication 🫶 like, why redo the whole login when you already did the work??

here's the plan. both peers agree they're allowed to clone during IKE_AUTH by swapping the CLONE_IKE_SA_SUPPORTED notifications. then, to make a new parallel IKE SA, one peer starts a CREATE_CHILD_SA exchange like it's rekeying the existing IKE SA 💅. the twist is the initiator adds the CLONE_IKE_SA notification, which basically says "hey, keep the current IKE SA, don't delete it!" 🙈 and boom, you get two parallel IKE SAs. iconic.

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 [RFC7296]). so that notification is doing the heavy lifting 💜

5. Protocol Details ✨

5.1. Support Negotiation

okay so both the initiator and the responder say "yes, we can clone" by sending the CLONE_IKE_SA_SUPPORTED notifications 🦋 this notification MUST be sent in the IKE_AUTH exchange. if there are multiple IKE_AUTH exchanges, it goes in the first IKE_AUTH message from the initiator and in the last IKE_AUTH message from the responder (main character energy for the final message, lol) 👑

if both the initiator and the responder send this notification during the IKE_AUTH exchange, peers may clone this IKE SA. otherwise? the IKE SA MUST NOT be cloned. no exceptions, bestie 🚫

Initiator                         Responder
-------------------------------------------------------------------
HDR, SA, KEi, Ni -->
                            <-- HDR, SA, KEr, Nr
HDR, SK {IDi, AUTH,
     SA, TSi, TSr,
     N(CLONE_IKE_SA_SUPPORTED)} -->
                            <-- HDR, SK {IDr, AUTH,
                                     SA, TSi, TSr,
                                     N(CLONE_IKE_SA_SUPPORTED)}

5.2. Cloning the IKE SA

so the initiator of the rekey exchange drops the CLONE_IKE_SA notification into a CREATE_CHILD_SA request that's rekeying the IKE SA ✨ that notification says the current IKE SA won't get deleted right away once the new one exists. instead, two parallel IKE SAs are expected to coexist, which is so fun to think about 🎀 the current IKE SA becomes the old IKE SA, and the newly negotiated one becomes the new IKE SA.

real talk though, the CLONE_IKE_SA notification MUST appear only in the request message of the CREATE_CHILD_SA exchange concerning the IKE SA rekey. if it shows up in any other message, it MUST be ignored. so no sneaking it in anywhere else 🙅‍♀️

Initiator                         Responder
-------------------------------------------------------------------
HDR, SK {N(CLONE_IKE_SA), SA, Ni, KEi} -->

if the CREATE_CHILD_SA request is about an IKE SA rekey and contains the CLONE_IKE_SA notification, the responder goes ahead with the IKE SA rekey, creates the new IKE SA, and keeps the old IKE SA 🌸 the CREATE_CHILD_SA response doesn't include any extra Notify Payloads, so it looks like this:

                            <--  HDR, SK {SA, Nr, KEr}

now the tea ☕ when the IKE SA is cloned, peers MUST NOT transfer existing Child SAs that were created by the old IKE SA over to the newly created IKE SA. so all the signaling messages about those Child SAs keep going over the old IKE SA. this is different from a regular IKE SA rekey in IKEv2, so don't get it twisted 🙈

5.3. Error Handling

sometimes the responder just can't or won't clone the IKE SA 😭 that inability might be temporary or it might be permanent, so let's break both down.

temporary inability happens when the responder doesn't have enough resources at the moment to clone an IKE SA, or when the responder is in the middle of deleting that IKE SA. in this case, the responder SHOULD reject the request to clone the IKE SA with the TEMPORARY_FAILURE notification 🧚

                            <--  HDR, SK {N(TEMPORARY_FAILURE)}

once the initiator gets that notification, it MAY retry its request after waiting some period of time. for the details, check Section 2.25 of [RFC7296] 💖

now for the permanent vibes. the responder might have restrictions on how many coexisting IKE SAs it can have with one peer. those restrictions can be implicit (some devices only have enough resources for a few IKE SAs) or explicit (set by some configuration parameter) 💀 if the initiator wants to clone more IKE SAs than the responder can handle 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 counts as permanent, so the initiator SHOULD NOT retry cloning an IKE SA until some of the existing SAs with the responder have been deleted. that's a hard pass for now 🫠

6. Payload Description

okay so Figure 4 shows the Notify Payload packet format, the same one described in Section 3.10 of [RFC7296] ✨ this format gets used for both the CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED notifications, so it's giving consistency 💜

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. easy peasy 🍓

                        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

the fields Next Payload, Critical Bit, RESERVED, and Payload Length are all defined in [RFC7296], so we're not reinventing them 🙌 the specific fields defined in this document are:

  • Protocol ID (1 octet): Set to zero.
  • Security Parameter Index (SPI) Size (1 octet): Set to zero.
  • Notify Message Type (2 octets): Specifies the type of notification message. It is set to 16432 for the CLONE_IKE_SA_SUPPORTED notification or 16433 for the CLONE_IKE_SA notification. the number is the vibe check 🔢✨

7. IANA Considerations

IANA has allocated two values in the "IKEv2 Notify Message Types - Status Types" registry. the IANA crew really did this for us 🥰

  Value    Notify Messages - Status Types
-----------------------------------------
  16432    CLONE_IKE_SA_SUPPORTED
  16433    CLONE_IKE_SA

8. Security Considerations

okay this section is serious, so I'm going to be serious 🔥 the protocol defined in this document does not modify IKEv2. the security considerations for cloning an IKE SA are mostly the same as the ones for the base IKEv2 protocol described in [RFC7296].

that said, cloning an IKE SA lets an initiator duplicate existing SAs. because of that, it may influence any accounting or control mechanisms that are based on a single IKE SA per authentication 👀

suppose a system has a limit on how many IKE SAs it can handle. in that case, cloning an IKE SA may open a door for resource exhaustion, since a single end user could populate multiple IKE SAs 🚨

suppose a system shares IPsec resources by limiting the number of Child SAs per IKE SA. with a single IKE SA per end user, that gives an equal resource share. but if you clone the IKE SA, the end user can overpass this limit. such a system should evaluate the number of Child SAs over the number of all IKE SAs associated with an end user 💅

these issues aren't unique to cloning, though, since multiple IKE SAs between two peers can be created without any cloning method at all. also, implementations can always limit the number of cloned IKE SAs, which is a nice safety valve 🛟

suppose the VPN or any other IPsec-based service monitoring is based on the liveliness of the first IKE SA. such a system considers a service to be accessed or used from the time IKE performs an authentication until the time the IKE SA is deleted. those accounting methods were fine, since any IKE SA required an authentication exchange. but cloning skips the authentication phase, so it may make it possible to delete the initial IKE SA while the service is still being used on the cloned IKE SA 😬 such accounting methods should consider that the service is being used from the first IKE SA establishment until the last IKE SA is removed.

when this solution is used to build load-balancing systems, there's a need to transfer IKE SA states between nodes of a load-sharing cluster. IKE SA state contains sensitive information, such as session keys, so implementations must take all due precautions 🔐 those precautions might include technical and/or administrative means to protect IKE SA state data. the details of what gets transferred and how it's protected are out of scope for this document.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Setting a VPN on Multiple Interfaces 🎀

this section is informational 💖 it shows how a VPN end user, as illustrated in Figure 1, can build two VPNs on its two interfaces without multiple authentications. the cases in Figure 2 and Figure 3 are similar and can be easily derived from this one 🧚 the mechanism is based on cloning the IKE SA and the MOBIKE extension [RFC4555]. two VPNs, one login, zero drama ✨

A.1. Setting VPN_0

okay so bestie, first the VPN end user negotiates a VPN over one interface 🫶 This is all regular IKEv2 stuff. On top of that, the VPN end user and the Security Gateway both announce that they support MOBIKE 📱 By the end of the IKE_AUTH exchange, VPN_0 is set up like in Figure 5 ✨

   +------------+                                +------------+
   |            | Interface_0 : VPN_0            |            |
   |            =================                |            |
   |    VPN     |               v                |  Security  |
   |  End User  |               ==================  Gateway   |
   |            =                                |            |
   |            | Interface_1                    |            |
   +------------+                                +------------+

                 Figure 5: VPN End User Establishing VPN_0

The full details live in [RFC7296] and [RFC4555] 💅 First the peers agree on IKE SA parameters and swap nonces and public keys during the IKE_SA_INIT exchange. In the diagram below, they also go through NAT detection because of MOBIKE 🌸

   Initiator                         Responder
   -------------------------------------------------------------------
   (IP_I0:500 -> IP_R:500)
   HDR, SA, KEi, Ni,
        N(NAT_DETECTION_SOURCE_IP),
        N(NAT_DETECTION_DESTINATION_IP)  -->

                         <--  (IP_R:500 -> IP_I0:500)
                              HDR, SA, KEr, Nr,
                                   N(NAT_DETECTION_SOURCE_IP),
                                   N(NAT_DETECTION_DESTINATION_IP)

Then the initiator and the responder move on to the IKE_AUTH exchange 🦋 They both show they support MOBIKE and that they can clone the IKE SA, using the MOBIKE_SUPPORTED and CLONE_IKE_SA_SUPPORTED notifications. They also negotiate the Child SA for VPN_0 💖 If they want, the initiator and the responder can also share their multiple interfaces with the ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications. That part is totally optional, babe 🙈

   (IP_I0:4500 -> IP_R:4500)
   HDR, SK {IDi, AUTH,
        SA, TSi, TSr,
        N(MOBIKE_SUPPORTED),
        [N(ADDITIONAL_IP*_ADDRESS)+,]
        N(CLONE_IKE_SA_SUPPORTED)}  -->

                         <--  (IP_R:4500 -> IP_I0:4500)
                              HDR, SK {IDr, AUTH,
                                   SA, TSi, TSr,
                                   N(MOBIKE_SUPPORTED),
                                   [N(ADDITIONAL_IP*_ADDRESS)+,]
                                   N(CLONE_IKE_SA_SUPPORTED)}

A.2. Creating an Additional IKE SA

So in this case 💜 the VPN end user wants a second VPN over its Interface_1. First it sets up a parallel IKE SA using a CREATE_CHILD_SA exchange, which is an IKE SA rekey tied to a CLONE_IKE_SA notification. Now there are two separate IKE SAs between the VPN end user and the Security Gateway. Both of them are still running over the end user's Interface_0 for now 🧚

   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 {SA, Nr, KEr}

A.3. Creating the Child SA for VPN_1

Once the new IKE SA exists, the VPN end user can start a CREATE_CHILD_SA exchange to make a Child SA for VPN_1 ✨ VPN_1 will run over Interface_0 of the VPN end user, at least for now.

Okay, this next bit is out of scope for this doc 🫠 The document doesn't define how the VPN end user handles traffic across multiple interfaces. The end user can use the same inner IP address on all of its interfaces. If it does, the same Traffic Selectors (the IP address used for VPN_0 and VPN_1) can match for both VPN_0 and VPN_1. The end user must be aware of that match and be able to manage it. For example, it can use distinct Traffic Selectors on both VPNs with different ports, manage the order of its Security Policy Database (SPD), or define the SPD per interface. Defining those mechanisms is also out of scope here 💀 The other option is to give each interface its own inner IP address.

Here's how VPN_1 gets created over the new IKE SA 🎀

   Initiator                         Responder
   -------------------------------------------------------------------
   (IP_I0:4500 -> IP_R:4500)
   HDR(new), SK(new) {SA, TSi, TSr}  -->

                         <--  (IP_R:4500 -> IP_I0:4500)
                              HDR(new), SK(new) {SA, TSi, TSr}

The result looks like Figure 6 🌈 VPN_0 and VPN_1 both exist now, but they're both still sitting on the same Interface: Interface_0.

   +------------+                                +------------+
   |            | Interface_0 : VPN_0, VPN_1     |            |
   |            ====================             |            |
   |    VPN     =================  v             |  Security  |
   |  End User  |               v  ===============  Gateway   |
   |            |               ==================            |
   |            | Interface_1                    |            |
   +------------+                                +------------+

            Figure 6: VPN End User Establishing VPN_0 and VPN_1

A.4. Moving VPN_1 on Interface_1

Now for the glow-up ✨ In this section, MOBIKE moves VPN_1 over to Interface_1. The exchange is described in [RFC4555].

   (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)}

And that gets us to the situation in Figure 7 🦋

   +------------+                                +------------+
   |            | Interface_0 : VPN_0            |            |
   |            ==================               |            |
   |    VPN     |                v               |  Security  |
   |  End User  |                =================  Gateway   |
   |            =================^               |            |
   |            | Interface_1 : VPN_1            |            |
   +------------+                                +------------+

              Figure 7: VPN End User with Multiple Interfaces

Acknowledgments 🫶

The ideas in this document came from a bunch of input from the IP Security Maintenance and Extensions (ipsecme) Working Group, plus conversations with Tero Kivinen and Michael Richardson 💜 Yaron Sheffer and Tero Kivinen gave a lot of important input that shaped the protocol's current design, and also its name 👑

Authors' Addresses 🌸

Daniel Migault (editor) Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada

Email: daniel.migault@ericsson.com

Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation

Phone: +7 495 276 0211 Email: svan@elvis.ru

📦 where this page comes from