Internet DRAFT - draft-he-ipsecme-vpn-shared-ipsecsa
draft-he-ipsecme-vpn-shared-ipsecsa
IPSECME Working Group Q. He
Internet-Draft W. Pan
Intended status: Standards Track X. Chen
Expires: 4 September 2024 B. Ding
Huawei
3 March 2024
Shared Use of IPsec Tunnel in a Multi-VPN Environment
draft-he-ipsecme-vpn-shared-ipsecsa-00
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 4 September 2024 [Page 1]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024.
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 ESP Trailer . . . . . . . . . . . 13
5.2. Carrying VPN ID in the AH Data Packet . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
He, et al. Expires 4 September 2024 [Page 2]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 3]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 4]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 5]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 6]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 7]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 8]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 9]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 10]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 4 September 2024 [Page 11]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 second 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 4 September 2024 [Page 12]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 ESP Trailer
When using IPsec ESP, the second 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 5.
He, et al. Expires 4 September 2024 [Page 13]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 5: Extended ESP Format 2
* VPN ID - Specifies the ID of the VPN that this ESP packet belongs
to.
The third 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 6.
He, et al. Expires 4 September 2024 [Page 14]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 6: 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 7.
He, et al. Expires 4 September 2024 [Page 15]
Internet-Draft Shared IPsec Tunnel by VPNs March 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 7: 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
[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>.
He, et al. Expires 4 September 2024 [Page 16]
Internet-Draft Shared IPsec Tunnel by VPNs March 2024
[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
Email: chenxiaolan4@huawei.com
Beijing Ding
Huawei Technologies
He, et al. Expires 4 September 2024 [Page 17]
Internet-Draft Shared IPsec Tunnel by VPNs March 2024
Email: dingbeijing@huawei.com
He, et al. Expires 4 September 2024 [Page 18]
