| Internet-Draft | Shared IPsec Tunnel by VPNs | March 2024 |
| He, et al. | Expires 4 September 2024 | [Page] |
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.¶
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/.¶
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 4 September 2024.¶
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.¶
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 +--+--> | | | | | | | | | +------------+ | | +------------+ | | | | | +------------------+ +------------------+
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 | |
| | | |
| +------------+ |
| |
+------------------+
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.¶
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 |
| |<------------------->| |
+------------------+ +------------------+
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.¶
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.¶
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.¶
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)
¶
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.¶
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.¶
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.
¶
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.¶
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.¶
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) ~ | | +---------------------------------------------------------------+
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.¶
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.¶
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) ~ | | +---------------------------------------------------------------+
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.¶
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) ~ | | +---------------------------------------------------------------+
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.¶
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.¶
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) ~ | | +---------------------------------------------------------------+
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.¶
TBD¶