IPSec for BGP Enabled Services over SRv6

A Network Service Provider (NSP) managed SRv6 domain, designed to be restricted to authorized users, is often considered a trusted and secure domain (, , ). However, in certain cases, users or applications demand an elevated level of security, necessitating the encryption of their data flows even within NSP managed networks like SRv6. The need for such robust security measures arises from the sensitivity and confidentiality of the information being transmitted. By encrypting data flows within those networks, organizations can fortify their defenses against potential threats, ensuring that unauthorized access or tampering is thwarted. This heightened security posture becomes particularly crucial for entities handling sensitive data, such as financial institutions, government agencies, or organizations dealing with proprietary and classified information. Employing encryption over NSP managed networks, including technologies like SRv6, adds an extra layer of protection, safeguarding valuable data from potential breaches and enhancing overall network security. This document describes an approach to encrypting selective user data flows using IPsec and then orchestrating the encrypted flows based on the SRv6 Policy path. This approach ensures that data is protected from unauthorized access or interception during transit while enabling flexible and efficient service orchestration. By leveraging the capabilities of SRv6, it is possible to create a highly dynamic and adaptable network environment that can meet the evolving needs of users and applications.

SRv6: Segment Routing over IPv6 ESP: Encapsulating Security Payload IPSec: Internet Protocol Security SA: Security Association

| | | | SRv6 Policy | | \<------------------------------------------------>\ VPN Over SRv6 Policy ]]> As illustrated in the preceding figure, the service route from PE1 to PE2 spans the backbone network. To attain the optimal service SLA, the utilization of SRv6 Policy becomes essential to orchestrate the service path. VPN1, due to its specific service requirements, demands heightened confidentiality. Consequently, VPN1 packets must undergo encryption before traversing the path orchestrated by SRv6. This precautionary measure ensures the prevention of any potential leakage at intermediate nodes along the route. In contrast, VPN2 entails regular traffic without the necessity for additional encryption.

The placement of the SRv6 header [RFC8754] outside the IPsec ESP (Encapsulating Security Payload) [RFC4303] encrypted payload is crucial for the seamless traversal of packets through an SRv6 domain. Placing the SRv6 header outside the encrypted payload allows the SRv6 domain to process and manipulate routing information without compromising the integrity and confidentiality provided by IPsec ESP. As the SRv6 header contains routing instructions and segments that guide the packet through the network, its visibility to the SRv6 domain is essential for proper routing decisions. By keeping the SRv6 header unencrypted, the SRv6-enabled devices within the domain can interpret and apply segment routing policies accurately, ensuring efficient packet forwarding while maintaining the necessary security measures provided by IPsec ESP for the payload. This separation of concerns enables a harmonious integration of SRv6 and IPsec, optimizing both routing flexibility and security within the network. The following figure shows the encapsulated packet format:

The BGP Tunnel Encapsulation Attribute defined in can be advertised with service routes to indicate the properties of the tunnels that can carry the service routes. However, it is worth noting that [RFC9012] does not sufficiently address the integration of IPsec ESP with SRv6, especially regarding segment routing policies. Further analysis is required to determine the optimal approach to leverage the BGP Tunnel Encapsulation Attribute to advertise IPsec ESP-related parameters and the SRv6 SIDS information for the service routes. The defines a methodology for advertising IPSec information for a service route to other PEs via BGP. The introduces a new Tunnel Type, ESP-Transport, into the existing framework outlined in . The Tunnel Type ESP-Transport indicates that the service routes should be encapsulated by VXLAN, with the associated IPsec parameters dictating the encryption of the VXLAN encapsulated payload. While this approach facilitates the continued use of VXLAN tunnels and ensures that IPsec ESP encrypts the entire VXLAN encapsulated payload, it is not be ideal for traversing the SRv6 domain. Encrypting the VXLAN encapsulated payload exclusively with IPsec ESP poses a challenge for service providers seeking to leverage SRv6 benefits while maintaining robust security measures. The SRv6 header contains routing instructions and segments that guide the packet through the SRv6 domain; its visibility to the SRv6 domain is essential for proper routing decisions. There is a need for a new Tunnel Type to signify that services must be encrypted prior to the outer SRv6 encapsulation. This enhancement ensures compatibility with SRv6, safeguarding both the advantages of SRv6 and the security of user data.

This document introduces a new Tunnel Type referred to as ESP-Encrypted-Payload, within the framework of the Tunnel Encapsulation Attribute specified by [RFC9012]. The ESP-Encrypted-Payload Tunnel Type serves the purpose of explicitly specifying that data packets must undergo encryption using ESP Transport. Notably, it provides the flexibility for the Outer header to be integrated into an underlay network, such as SRv6. Pertinent Sub-TLVs associated with IPsec, as detailed in [I-D.ietf-idr-sdwan-edge-discovery], including IPsec SA Nonce, IPsec Public Key, and IPsec SA Proposal, can be appended under the ESP-Encrypted-Payload Tunnel Type. This document seamlessly inherits the IPsec sub-TLVs, ensuring the effective implementation of secure service encryption. When a service route includes extra information, such as the color and SRv6 SID (Segment Identifier), a process of iteration is required to direct the route towards an SRv6 Provider Edge (PE) or an SRv6 Policy. The selection of the specific route for this iteration is determined either by the local tunnel policy or explicitly specified by the Tunnel-Encap Extend Community

Let's take the scenario described in section 3 as an example.: 1. PE1 obtains IPSec related parameters by configuration, from its management system, or via negotiation, including IPSec SA encryption algorithms, keying material, nonce, and security policies, etc.. 2. PE1 detects its attached VPN routes, such as EVPN Type 5 Prefix Routes or others. 3. PE1 adds a Tunnel-Encapsulation Attribute to the routes based on local policies. The Tunnel-Type parameter is ESP-Encrypted-Payload. 4. PE1 obtains the VPN route and carries tunnel information, such as the VPN SID and Color Extended Community, based on the local policy. 5. PE1 advertises the route to PE2 through RRs. 6. After receiving the route advertised by PE1, PE2 performs IPSec key negotiation based on the ESP-Transport Tunnel-Encapsulation Attribute carried in the route and indicates that the route needs to be encrypted using IPSec. 7. After PE2 receives the route advertised by PE1 and carries information such as the VPN ID and color, PE2 associates the route with the SRv6 tunnel. 8. When PE2 receives the CE-side traffic that matches the route advertised by PE1. PE2 performs IPSec encryption based on the indicated IPSec sub-TLVs advertised by PE1, encapsulates the traffic into an SRv6 tunnel based on the indicated tunnel information, and sends the traffic to PE1 along the tunnel information. 9. After receiving the traffic from PE2, PE1 finds the corresponding VRF based on the SRv6 tunnel information and decrypts the packets to obtain the original user packet payload. Searches the VRF table and forwards traffic to the CE based on the user packet header.

Tunnel-Type ESP-Transport-Only-Payload needs to be allocated by IANA.

In this solution, the specified data packet is encrypted after being sent from the PE. This process ensures that even if an intermediate node obtains the related data packet, it is difficult to obtain the real content information. By implementing this encryption process, the security of the entire solution is significantly improved, providing better protection for high-security services such as finance.