Shared Use of IPsec Tunnel in a Multi-VPN Environment

Introduction IPsec 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 . The reason for doing this is that the current IKEv2 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.

Separate IPsec Tunnels for Different VPNs Between Two Devices | 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 .

Separate IPsec Tunnels for the Same VPN Between Different Devices | +--+------------------+->| +--+--> | | 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.

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

Full-Meshed IPsec Tunnels Among 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 . 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.

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.

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 when, and only when, they appear in all capitals, as shown here.

VPN-Based Traffic Selection in IKEv2

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: <-- HDR, SAr1, KEr, Nr, [CERTREQ,] N(VPN_BASED_TS_SUPPORTED) ]]>

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.

Payload Formats

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.

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.

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.

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

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

Carrying VPN ID in the ESP Data Packet

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 .

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.

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 .

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 .

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.

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 .

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.

IANA Considerations TBD

Security Considerations TBD

Acknowledgments TBD