Skip to main content

Shared Use of IPsec Tunnel in a Multi-VPN Environment
draft-he-ipsecme-vpn-shared-ipsecsa-01

Document Type Active Internet-Draft (individual)
Authors Qi He , Wei Pan , Xiaolan Chen , Beijing Ding
Last updated 2024-07-08
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-he-ipsecme-vpn-shared-ipsecsa-01
IPSECME Working Group                                              Q. He
Internet-Draft                                                    W. Pan
Intended status: Standards Track                                 X. Chen
Expires: 8 January 2025                                          B. Ding
                                                                  Huawei
                                                             7 July 2024

         Shared Use of IPsec Tunnel in a Multi-VPN Environment
                 draft-he-ipsecme-vpn-shared-ipsecsa-01

Abstract

   In a multi-VPN environment, currently, different IPsec tunnels (i.e.,
   different IKE SAs and Child SAs) have to be created to differentiate
   and protect the traffic of each VPN between the device and its peer.
   When the number of neighbors of a device and the number of VPNs
   increases, the number of IPsec tunnels also increases considerably.
   This results in the need for a large number of SAs, which exceeds the
   device's capacity.

   This document proposes a method for different VPNs to share the use
   of a single IPsec tunnel, which can greatly reduce the number of SAs
   required in a multi-VPN scenario.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-he-ipsecme-vpn-shared-
   ipsecsa/.

   Discussion of this document takes place on the ipsec Working Group
   mailing list (mailto:ipsec@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ipsec/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/ipsec/.

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 https://datatracker.ietf.org/drafts/current/.

He, et al.               Expires 8 January 2025                 [Page 1]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   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 8 January 2025.

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Possible Solutions  . . . . . . . . . . . . . . . . . . .   7
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   7
   4.  VPN-Based Traffic Selection in IKEv2  . . . . . . . . . . . .   8
     4.1.  Negotiation of Support for VPN-Based Traffic Selection  .   8
     4.2.  VPN-Based Traffic Selector Negotiation  . . . . . . . . .   8
     4.3.  Payload Formats . . . . . . . . . . . . . . . . . . . . .   9
       4.3.1.  VPN_BASED_TS_SUPPORTED Notify . . . . . . . . . . . .   9
       4.3.2.  TS_IPV4_ADDR_RANGE_VPN and TS_IPV6_ADDR_RANGE_VPN
               Traffic Selectors . . . . . . . . . . . . . . . . . .  10
   5.  IPsec Data Packet Processing  . . . . . . . . . . . . . . . .  12
     5.1.  Carrying VPN ID in the ESP Data Packet  . . . . . . . . .  12
       5.1.1.  Carrying VPN ID in ESP Header . . . . . . . . . . . .  12
       5.1.2.  Carrying VPN ID in WESP Header  . . . . . . . . . . .  13
       5.1.3.  Carrying VPN ID in ESP Trailer  . . . . . . . . . . .  14
     5.2.  Carrying VPN ID in the AH Data Packet . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

He, et al.               Expires 8 January 2025                 [Page 2]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

1.  Introduction

   IPsec [RFC4301] is widely used to provide security for IP
   communications.  VPNs are also a widely used feature in IP networks
   to create logically isolated networks.  Administrators can create
   multiple VPNs on a device and assign them to different services so
   that these services are isolated from each other.  These VPNs can use
   the same address space or different address spaces.  Regardless of
   the address spaces these VPNs use, the traffic between different VPNs
   is not accessible to each other.

   When an administrator has planned multiple VPNs on two devices for
   use by different services and needs to utilize IPsec to provide
   security for the traffic, the existing practice is to create separate
   IPsec tunnels (separate IKE SAs and Child SAs) for different VPNs, as
   shown in Figure 1.  The reason for doing this is that the current
   IKEv2 [RFC7296] does not carry any VPN information when creating a
   Child SA.  The initiator can know which VPN the Child SA is
   associated with when requesting the creation of this SA.  However,
   the responder can't get any VPN-related information from the request
   and associate it with the correct VPN.  Therefore, different VPNs
   need to be separated from the IKE SAs, since different IKE SAs
   require different interfaces (even logical interfaces) and these
   interfaces can be respectively associated with the corresponding
   VPNs.

He, et al.               Expires 8 January 2025                 [Page 3]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

        +------------------+                  +------------------+
        |     Device A     |                  |     Device B     |
        |                  |                  |                  |
        |  +------------+  |                  |  +------------+  |
        |  |            |  |  IPsec Tunnel 1  |  |            |  |
     ---+->|    VPN 1   +--+------------------+->|    VPN 1   +--+-->
        |  |            |  |                  |  |            |  |
        |  +------------+  |                  |  +------------+  |
        |                  |                  |                  |
        |  +------------+  |                  |  +------------+  |
        |  |            |  |  IPsec Tunnel 2  |  |            |  |
     ---+->|    VPN 2   +--+------------------+->|    VPN 2   +--+-->
        |  |            |  |                  |  |            |  |
        |  +------------+  |                  |  +------------+  |
        |                  |                  |                  |
        |      ......      |                  |      ......      |
        |                  |                  |                  |
        |  +------------+  |                  |  +------------+  |
        |  |            |  |  IPsec Tunnel N  |  |            |  |
     ---+->|    VPN N   +--+------------------+->|    VPN N   +--+-->
        |  |            |  |                  |  |            |  |
        |  +------------+  |                  |  +------------+  |
        |                  |                  |                  |
        +------------------+                  +------------------+

      Figure 1: Separate IPsec Tunnels for Different VPNs Between Two
                                  Devices

   Although it is possible to plan the use of private addresses for VPNs
   within a device, since the network between two devices is a public
   network, it is necessary to plan public addresses for both ends of
   the IPsec tunnel.  If the number of tunnels increases, the amount of
   work involved in planning tunnel addresses rises, bringing network
   planning and management complexity to the operator.

   Meanwhile, for the same VPN, if the device has different neighbors,
   it needs to create IPsec tunnels with these neighbors separately, as
   shown in Figure 2.

He, et al.               Expires 8 January 2025                 [Page 4]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

        +------------------+                  +------------------+
        |     Device A     |                  |     Device B     |
        |                  |                  |                  |
        |  +------------+  |  IPsec Tunnel 1  |  +------------+  |
     ---+->|            +--+------------------+->|            +--+-->
        |  |    VPN 1   |  |                  |  |    VPN 1   |  |
     ---+->|            +--+-------+          |  |            |  |
        |  +------------+  |       |          |  +------------+  |
        |                  |       |          |                  |
        |      ......      |       |          |      ......      |
        |                  |       |          |                  |
        |  +------------+  |       |          |  +------------+  |
        |  |            |  |       |          |  |            |  |
        |  |    VPN N   |  |       |          |  |    VPN N   |  |
        |  |            |  |       |          |  |            |  |
        |  +------------+  |       |          |  +------------+  |
        |                  |       |          |                  |
        +------------------+       |          +------------------+
                              IPsec|Tunnel 4
                                   |          +------------------+
                                   |          |     Device C     |
                                   |          |                  |
                                   |          |  +------------+  |
                                   |          |  |            |  |
                                   +----------+->|    VPN 1   +--+-->
                                              |  |            |  |
                                              |  +------------+  |
                                              |                  |
                                              |      ......      |
                                              |                  |
                                              |  +------------+  |
                                              |  |            |  |
                                              |  |    VPN N   |  |
                                              |  |            |  |
                                              |  +------------+  |
                                              |                  |
                                              +------------------+

         Figure 2: Separate IPsec Tunnels for the Same VPN Between
                             Different Devices

   When more peer devices exist and more VPNs are used, more IPsec
   tunnels need to be established.  The complexity of network operation
   and maintenance is increased, and the number of SAs brought about is
   also a serious challenge for the devices, since the number of SAs
   supported by the devices is limited.

He, et al.               Expires 8 January 2025                 [Page 5]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   This document proposes a method for multiple VPNs to share the use of
   IPsec tunnels, which can reduce the number of SAs in the multi-VPN
   environment, and indirectly reduce the difficulty of network
   planning, operation, and maintenance.

2.  Problem Statement

   In 3GPP networks, the backhaul network between the base station and
   the security gateway is also protected by IPsec.  For traffic
   traveling from one base station to another, it adds unnecessary
   overhead if the traffic is detoured from the security gateway.  To
   avoid traffic detouring, the typical practice is to transmit traffic
   directly between base stations, so that each base station needs to
   establish an IPsec tunnel with neighboring base stations.  As shown
   in Figure 3, the full-meshed IPsec tunnels are established between
   base stations.  In 5G and future millimeter wave applications, base
   stations will be deployed in more diverse scenarios and at higher
   densities than before, so devices will need to establish IPsec
   tunnels with more neighboring base stations.

       +------------------+                     +------------------+
       |                  |<------------------->|                  |
       |  Base Station 1  |                     |  Base Station 2  |
       |                  |<---------+          |                  |
       +------------------+          |          +------------------+
                ^                    |             ^      ^
                |                    |             |      |
                |                    |             |      |
                |                    |             |      |
                |      +-------------+-------------+      |
                |      |             |                    |
                |      |             |                    |
                |      |             |                    |
                v      v             |                    |
       +------------------+          |          +---------+--------+
       |                  |          +--------->|                  |
       |  Base Station 3  |                     |  Base Station 4  |
       |                  |<------------------->|                  |
       +------------------+                     +------------------+

          Figure 3: Full-Meshed IPsec Tunnels Among Base Stations

   Due to the considerable infrastructure construction cost, the
   operator that owns base stations partially compensates for their
   investment by sharing their equipment with other operators through
   Radio Access Network (RAN) Sharing technology [RANSharing].  When
   multiple operators share the RAN, different operators will be
   assigned to different VPNs.  Because of the isolation of these VPNs,

He, et al.               Expires 8 January 2025                 [Page 6]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   the traffic of different operators does not cross or affect each
   other, even though the address spaces they use may overlap.  However,
   for these different VPNs, separate IPsec tunnels are needed.

   The number of IPsec tunnels is seriously boosted as the number of
   base stations and operators sharing the RAN increases.  For a
   scenario where the number of neighbors is N, and the number of
   sharing operators is M, it is necessary to establish a number of IKE
   SAs of N * M and a minimum number of Child SAs of N * M.  The limited
   number of SAs supported by the device restricts the development and
   evolution of services in this scenario.

2.1.  Possible Solutions

   Since the device needs to establish an IPsec tunnel with each of its
   neighbors, and the number of neighbors of the device cannot be
   optimized, what can be considered is to share the same IPsec tunnel
   for different VPNs between every two devices.  Currently, each VPN's
   IPsec tunnel uses a separate IKE SA and Child SA, while the shared
   IPsec tunnel allows different VPNs to use the same IKE SA and Child
   SA, greatly reducing the number of IKE SAs and Child SAs.

   Currently, when IKEv2 negotiates the creation of a Child SA, it only
   negotiates the range of traffic to be protected based on the IP five-
   tuple information without VPN information.  That is, the current
   Child SA does not associate VPN attributes, therefore, different IKE
   SAs are created to distinguish the traffic of different VPNs.  To
   realize the sharing of the same IPsec tunnel by different VPNs,
   firstly, it is necessary to add the VPN attribute for each traffic
   selector when negotiating the traffic to be protected in Child SAs,
   so that the traffic of different VPNs can be unambiguously placed
   into the same Child SA.  Secondly, because the relationship between
   Child SAs and VPNs is not one-to-one, it is not possible to determine
   the VPN based on the SPI field in the IPsec data packet, so it is
   also necessary to carry the VPN information in the IPsec data packet
   to distinguish to which VPN the inner packet belongs.

3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

He, et al.               Expires 8 January 2025                 [Page 7]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

4.  VPN-Based Traffic Selection in IKEv2

4.1.  Negotiation of Support for VPN-Based Traffic Selection

   To indicate support for combining VPN information with the Traffic
   Selector when creating or rekeying the Child SA, the initiator
   includes the VPN_BASED_TS_SUPPORTED notify payload in the IKE_SA_INIT
   exchange request.

   A responder that does not support the VPN-based traffic selection
   processes the request as normal, and does not include the new Notify
   in the response.  As per regular IKEv2 processing, a responder that
   does not recognize this new Notify, MUST ignore the notify.  The
   absence of the Notify in the response indicates to the initiator that
   the responder doesn't support or want the use of VPN-based traffic
   selection.  The initiator can continue the IKEv2 negotiation normally
   or terminate the negotiation based on its local choices.

   A responder that supports the VPN-based traffic selection includes
   the VPN_BASED_TS_SUPPORTED notify payload in the response, to
   indicate that it's willing to use the VPN-based Traffic Selectors
   when creating or rekeying the Child SAs.  If both peers have
   exchanged VPN_BASED_TRAFFIC_SELECTOR_SUPPORTED notifies, peers MUST
   use the new traffic selectors defined in this document during the
   CREATE_CHILD_SA exchange, and MUST NOT use the traditional traffic
   selectors.

   The IKE_SA_INIT message exchange in this case is shown below:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni,
       N(VPN_BASED_TS_SUPPORTED)  -->
                                <--  HDR, SAr1, KEr, Nr, [CERTREQ,]
                                         N(VPN_BASED_TS_SUPPORTED)

4.2.  VPN-Based Traffic Selector Negotiation

   Two new Traffic Selector types are introduced to combine the VPN
   information with the IP address range information.
   TS_IPV4_ADDR_RANGE_VPN is for the IPv4 VPN addresses, and
   TS_IPV6_ADDR_RANGE_VPN is for IPv6.  Compared to TS_IPV4_ADDR_RANGE
   and TS_IPV6_ADDR_RANGE, the two new Traffic Selectors contain an
   additional field called "VPN ID".  This new field indicates which VPN
   the Traffic Selector is associated with.

He, et al.               Expires 8 January 2025                 [Page 8]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   When multiple Traffic Selectors with different VPN IDs are included
   in the TSi and TSr payloads, only the ones with the same VPN ID can
   be paired.  For example, the Traffic Selectors with VPN 1 in the TSi
   payload should be paired with the Traffic Selectors with VPN 1 in the
   TSr payload.

   If a Traffic Selector in the TSi or TSr payload can't be paired with
   a corresponding one with the same VPN ID, then this Traffic Selector
   MUST be ignored.  For example, if a Traffic Selector with VPN 2 is in
   the TSi payload and no Traffic Selector with VPN 2 is in the TSr
   payload, then this one in the TSi payload must be ignored.

   If the VPN ID in the paired Traffic Selectors is not recognized, or
   if all Traffic Selectors in the TSi payload can't be paired with any
   Traffic Selector in the TSr payload, then the responder SHOULD reply
   with the TS_UNACCEPTABLE notification to the initiator.

   The initiator and responder MUST share the same understanding of VPN
   IDs; otherwise, the traffic negotiation result may divert from the
   operator's expectation.  How to do this is out of the scope of this
   document, and one possible way is that the operator configures the
   same VPNs and VPN IDs for all devices.

   Other processes for the two new Traffic Selectors are the same as the
   ones for the traditional Traffic Selectors.

4.3.  Payload Formats

4.3.1.  VPN_BASED_TS_SUPPORTED Notify

   The VPN_BASED_TS_SUPPORTED Notify Message type notification is used
   by the initiator and responder to indicate their support for
   combining VPN information with the Traffic Selector when creating or
   rekeying the 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(=0)| SPI Size (=0) |      Notify Message Type      |
   +---------------+---------------+-------------------------------+

   *  Protocol ID (1 octet) - MUST be 0.

   *  SPI Size (1 octet) - MUST be 0, meaning no SPI is present.

   *  Notify Message Type (2 octets) - MUST be set to the value TBD1.

He, et al.               Expires 8 January 2025                 [Page 9]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   This Notify Message type contains no data.

   The Critical bit MUST be 0.  A non-zero value MUST be ignored.

4.3.2.  TS_IPV4_ADDR_RANGE_VPN and TS_IPV6_ADDR_RANGE_VPN Traffic
        Selectors

   The TS_IPV4_ADDR_RANGE_VPN and TS_IPV6_ADDR_RANGE_VPN Traffic
   Selectors are used to identify packet flows, based on IP address
   ranges and VPN information, for processing by IPsec security
   services.

                        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
   +---------------+---------------+-------------------------------+
   |   TS Type     |IP Protocol ID*|       Selector Length         |
   +---------------+---------------+-------------------------------+
   |           Start Port*         |           End Port*           |
   +---------------+---------------+-------------------------------+
   |                                                               |
   ~                         Starting Address*                     ~
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   ~                         Ending Address*                       ~
   |                                                               |
   +---------------------------------------------------------------+
   |                             VPN ID                            |
   +---------------------------------------------------------------+

   *  TS Type (one octet) - Specifies the type of Traffic Selector.

   *  IP protocol ID (1 octet) - Value specifying an associated IP
      protocol ID (such as UDP, TCP, and ICMP).  A value of zero means
      that the protocol ID is not relevant to this Traffic Selector --
      the SA can carry all protocols.

   *  Selector Length (2 octets, unsigned integer) - Specifies the
      length of this Traffic Selector substructure including the header.

   *  Start Port (2 octets, unsigned integer) - Value specifying the
      smallest port number allowed by this Traffic Selector.  For
      protocols for which port is undefined (including protocol 0), or
      if all ports are allowed, this field MUST be zero.  ICMP and
      ICMPv6 Type and Code values, as well as Mobile IP version 6
      (MIPv6) mobility header (MH) Type values, are represented in this
      field as specified in Section 4.4.1.1 of [RFC4301].  ICMP Type and
      Code values are treated as a single 16-bit integer port number,

He, et al.               Expires 8 January 2025                [Page 10]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

      with Type in the most significant eight bits and Code in the least
      significant eight bits.  MIPv6 MH Type values are treated as a
      single 16-bit integer port number, with Type in the most
      significant eight bits and the least significant eight bits set to
      zero.

   *  End Port (2 octets, unsigned integer) - Value specifying the
      largest port number allowed by this Traffic Selector.  For
      protocols for which port is undefined (including protocol 0), or
      if all ports are allowed, this field MUST be 65535.  ICMP and
      ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
      represented in this field as specified in Section 4.4.1.1 of
      [RFC4301].  ICMP Type and Code values are treated as a single
      16-bit integer port number, with Type in the most significant
      eight bits and Code in the least significant eight bits.  MIPv6 MH
      Type values are treated as a single 16-bit integer port number,
      with Type in the most significant eight bits and the least
      significant eight bits set to zero.

   *  Starting Address - The smallest address included in this Traffic
      Selector (length determined by TS Type).

   *  Ending Address - The largest address included in this Traffic
      Selector (length determined by TS Type).

   *  VPN ID - Specifies the ID of the VPN that this Traffic Selector is
      associated with.

   The following table lists values for the Traffic Selector Type field
   and the corresponding Address Selector Data.

He, et al.               Expires 8 January 2025                [Page 11]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   TS Type                            Value
   -------------------------------------------------------------------
   TS_IPV4_ADDR_RANGE_VPN              TBD2

       A range of IPv4 VPN addresses, represented by three four-
       octet values.  The first value is the beginning IPv4 address
       (inclusive), the second value is the ending IPv4 address
       (inclusive), and the third value is the VPN ID associated with
       these IPv4 addresses.  All addresses with the same VPN ID
       falling between the two specified addresses are considered to
       be within the list.

   TS_IPV6_ADDR_RANGE_VPN              TBD3

       A range of IPv6 VPN addresses, represented by two sixteen-
       octet values and one four-octet value.  The first sixteen-
       octet value is the beginning IPv6 address (inclusive), the
       second sixteen-octet value is the ending IPv6 address
       (inclusive), and the four-octet value is the VPN ID
       associated with these IPv6 addresses.  All addresses with the
       same VPN ID falling between the two specified addresses are
       considered to be within the list.

5.  IPsec Data Packet Processing

   When traffic belonging to different VPNs share the same IPsec tunnel
   (i.e., the same Child SA), the outer IP header and the ESP [RFC4303]
   / AH [RFC4302] header (the SPI field) are the same for all IPsec
   traffic.  Hence, these headers aren't able to differentiate which VPN
   the inner traffic belongs to.  In order to differentiate between the
   inner packets' VPNs, it is required that the VPN ID information
   should be added into the IPsec data packet.

   The possible way is to add VPN ID information in the AH header, and
   in the ESP header or trailer.

5.1.  Carrying VPN ID in the ESP Data Packet

5.1.1.  Carrying VPN ID in ESP Header

   When using IPsec ESP, the first possible option is that the sender
   inserts the four-octet VPN ID into the ESP header after the Sequence
   Number field.  The extended ESP format is shown as Figure 4.

He, et al.               Expires 8 January 2025                [Page 12]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

     0                   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
   +---------------------------------------------------------------+
   |               Security Parameters Index (SPI)                 |
   +---------------------------------------------------------------+
   |                      Sequence Number                          |
   +---------------------------------------------------------------+
   |                            VPN ID                             |
   +---------------------------------------------------------------+---
   |                        IV (optional)                          | ^ p
   +---------------------------------------------------------------+ | a
   |                                                               | | y
   ~               Rest of Payload Data  (variable)                ~ | l
   |                                                               | | o
   +               +-----------------------------------------------+ | a
   |               |         TFC Padding * (optional, variable)    | v d
   +---------------+         +-------------------------------------+---
   |                         |        Padding (0-255 bytes)        |
   +-------------------------+     +---------------+---------------+
   |                               |  Pad Length   | Next Header   |
   +-------------------------------+---------------+---------------+
   |                                                               |
   ~              Integrity Check Value-ICV (variable)             ~
   |                                                               |
   +---------------------------------------------------------------+

                      Figure 4: Extended ESP Format 1

   *  VPN ID - Specifies the ID of the VPN that this ESP packet belongs
      to.

   The receiver distinguishes the VPN from the VPN ID in the ESP header.
   Then, all these packets will be processed by the corresponding VPN
   after the decryption and integrity check.

5.1.2.  Carrying VPN ID in WESP Header

   The second possible option is that using the Flow Identifier option
   defined in WESP format [I-D.klassert-ipsecme-wespv2].  The sender
   inserts the four-octet VPN ID into the Flow Identifier option.  The
   format is shown as Figure 5.

He, et al.               Expires 8 January 2025                [Page 13]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

      0                   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 Header  |    HdrLen     |CryptOffset| R | V |  OptLen   |
     +---------------+---------------+-----------+---+---+-----------+
     |  Flow Id Opt  |  Opt Data Len |             VPN ID            |
     +---------------+---------------+-------------------------------+
     |        VPN ID (Cont.)         |         Padding Option        |
     +-------------------------------+-------------------------------+
     |                  Existing ESP Encapsulation                   ~
     |                                                               |
     +---------------------------------------------------------------+

                           Figure 5: WESP Format

   *  VPN ID - Specifies the ID of the VPN that the inner ESP packet
      belongs to.

   The receiver distinguishes the VPN from the VPN ID in the WESP
   header.  Then, all these packets will be processed by the
   corresponding VPN after the decryption and integrity check.

5.1.3.  Carrying VPN ID in ESP Trailer

   When using IPsec ESP, the third possible option is that the sender
   inserts the four-octet VPN ID into the ESP trailer before the Padding
   field.  The extended ESP format is shown as Figure 6.

He, et al.               Expires 8 January 2025                [Page 14]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

     0                   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
   +---------------------------------------------------------------+
   |               Security Parameters Index (SPI)                 |
   +---------------------------------------------------------------+
   |                      Sequence Number                          |
   +---------------------------------------------------------------+---
   |                        IV (optional)                          | ^ p
   +---------------------------------------------------------------+ | a
   |                                                               | | y
   ~               Rest of Payload Data  (variable)                ~ | l
   |                                                               | | o
   +               +-----------------------------------------------+ | a
   |               |         TFC Padding * (optional, variable)    | v d
   +---------------+         +-------------------------------------+---
   |                         |                VPN ID               |
   +-------------------------+-------------------------------------+
   |      VPN ID (Cont.)     |        Padding (0-255 bytes)        |
   +-------------------------+     +---------------+---------------+
   |                               |  Pad Length   | Next Header   |
   +-------------------------------+---------------+---------------+
   |                                                               |
   ~              Integrity Check Value-ICV (variable)             ~
   |                                                               |
   +---------------------------------------------------------------+

                      Figure 6: Extended ESP Format 2

   *  VPN ID - Specifies the ID of the VPN that this ESP packet belongs
      to.

   The fourth possible option is that the sender inserts the four-octet
   VPN ID into the ESP trailer before the Next Header field.  The
   extended ESP format is shown as Figure 7.

He, et al.               Expires 8 January 2025                [Page 15]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

     0                   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
   +---------------------------------------------------------------+
   |               Security Parameters Index (SPI)                 |
   +---------------------------------------------------------------+
   |                      Sequence Number                          |
   +---------------------------------------------------------------+---
   |                        IV (optional)                          | ^ p
   +---------------------------------------------------------------+ | a
   |                                                               | | y
   ~               Rest of Payload Data  (variable)                ~ | l
   |                                                               | | o
   +               +-----------------------------------------------+ | a
   |               |         TFC Padding * (optional, variable)    | v d
   +---------------+         +-------------------------------------+---
   |                         |        Padding (0-255 bytes)        |
   +-------------------------+     +---------------+---------------+
   |                               |  Pad Length   |    VPN ID     |
   +-------------------------------+---------------+---------------+
   |                  VPN ID (Cont.)               |  Next Header  |
   +-----------------------------------------------+---------------+
   |                                                               |
   ~              Integrity Check Value-ICV (variable)             ~
   |                                                               |
   +---------------------------------------------------------------+

                      Figure 7: Extended ESP Format 3

   *  VPN ID - Specifies the ID of the VPN that this ESP packet belongs
      to.

   The receiver decrypts the ESP packet and distinguishes the VPN from
   the VPN ID in the ESP trailer.  Then, all these packets will be
   processed by the corresponding VPN after the decryption and integrity
   check.

5.2.  Carrying VPN ID in the AH Data Packet

   When using IPsec AH, the sender inserts the four-octet VPN ID into
   the AH header after the Sequence Number field.  The extended AH
   header format is shown as Figure 8.

He, et al.               Expires 8 January 2025                [Page 16]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

       0                   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 Header   |  Payload Len  |          RESERVED             |
     +---------------+---------------+-------------------------------+
     |                 Security Parameters Index (SPI)               |
     +---------------------------------------------------------------+
     |                       Sequence Number                         |
     +---------------------------------------------------------------+
     |                            VPN ID                             |
     +---------------------------------------------------------------+
     |                                                               |
     ~              Integrity Check Value-ICV (variable)             ~
     |                                                               |
     +---------------------------------------------------------------+

                    Figure 8: Extended AH Header Format

   *  VPN ID - Specifies the ID of the VPN that this AH packet belongs
      to.

   The receiver distinguishes the VPN from the VPN ID in the AH header.
   Then, all these packets will be processed by the corresponding VPN
   after the integrity check.

6.  IANA Considerations

   TBD

7.  Security Considerations

   TBD

8.  Acknowledgments

   TBD

9.  References

9.1.  Normative References

   [I-D.klassert-ipsecme-wespv2]
              Klassert, S. and A. Antony, "Wrapped ESP Version 2", Work
              in Progress, Internet-Draft, draft-klassert-ipsecme-
              wespv2-01, 28 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-klassert-
              ipsecme-wespv2-01>.

He, et al.               Expires 8 January 2025                [Page 17]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4303>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/rfc/rfc7296>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

9.2.  Informative References

   [RANSharing]
              3GPP, "Telecommunication management; Network sharing;
              Concepts and requirements", 3GPP TS 32.130 v18.0.0 ,
              September 2023, <https://www.3gpp.org/ftp/Specs/
              archive/32_series/32.130/32130-i00.zip>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.

Authors' Addresses

   Qi He
   Huawei Technologies
   Email: archibald.heqi@huawei.com

   Wei Pan
   Huawei Technologies
   Email: william.panwei@huawei.com

   Xiaolan Chen
   Huawei Technologies

He, et al.               Expires 8 January 2025                [Page 18]
Internet-Draft         Shared IPsec Tunnel by VPNs             July 2024

   Email: chenxiaolan4@huawei.com

   Beijing Ding
   Huawei Technologies
   Email: dingbeijing@huawei.com

He, et al.               Expires 8 January 2025                [Page 19]