Internet-Draft Shared IPsec Tunnel by VPNs July 2024
He, et al. Expires 8 January 2025 [Page]
Workgroup:
IPSECME Working Group
Internet-Draft:
draft-he-ipsecme-vpn-shared-ipsecsa-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
Q. He
Huawei
W. Pan
Huawei
X. Chen
Huawei
B. Ding
Huawei

Shared Use of IPsec Tunnel in a Multi-VPN Environment

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/.

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.

Table of Contents

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.

   +------------------+                  +------------------+
   |     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.

   +------------------+                  +------------------+
   |     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.

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, 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.

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.

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.

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, 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.

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.

  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.

 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.

  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.

  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.

  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, , <https://datatracker.ietf.org/doc/html/draft-klassert-ipsecme-wespv2-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4302]
Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, , <https://www.rfc-editor.org/rfc/rfc4302>.
[RFC4303]
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, , <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, , <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, , <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 , , <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, , <https://www.rfc-editor.org/rfc/rfc4301>.

Authors' Addresses

Qi He
Huawei Technologies
Wei Pan
Huawei Technologies
Xiaolan Chen
Huawei Technologies
Beijing Ding
Huawei Technologies