IPSec for BGP Enabled Services over SRv6

Data security is of paramount importance to many users, particularly those in the financial industry. As a result, many large-scale financial users have constructed their own backbone networks, some of which traverse third-party backbone networks. In order to enable flexible orchestration and control of services, emerging technologies such as SRv6 have been introduced. Normally, SRv6 domain is considered trusted domain and secure(, , ). However, despite the benefits of these technologies, customers still require encryption of services to prevent data leakage during orchestration and scheduling on the backbone network. This is particularly important given the sensitive nature of financial data and the potential consequences of data breaches. As such, there is a need for robust and effective encryption mechanisms to ensure the security of data in transit. In order to provide this type of service, it is necessary to encrypt user data and then orchestrate it based on the SRv6 Policy path. This approach ensures that data is protected from unauthorized access or interception during transit, while also 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. The BGP Tunnel Encapsulation Attribute is defined in . This attribute can be advertised with service routes to indicate the creation of tunnels and encapsulation of tunnel information. However, it is worth noting that this approach may not be entirely consistent with the business requirements described above. As such, further analysis is required to determine the optimal approach to meet these requirements while also leveraging the benefits of the BGP Tunnel Encapsulation Attribute. This may involve the development of new mechanisms or the modification of existing ones to ensure that they align with the specific needs of the business and provide a robust and effective solution. The specification outlines a method for conveying IPSec information in a service route to indicate how to encrypt a service. This approach enables service routes to continue using VXLAN tunnels and encapsulate VXLAN-encapsulated service packets in ESP. However, it is important to note that this mode is not applicable to SRv6. In SRv6 encapsulation, the SID list is used to guide how data packets are forwarded along different paths on the network, based on the SRv6-Policy. As a result, the SID list shouldn't be encapsulated in ESP. This presents a challenge for service providers who wish to leverage the benefits of SRv6 while also ensuring the security and integrity of user data.

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

| | | | SRv6 Policy | | \<------------------------------------------------>\ VPN Over SRv6 Policy ]]> As shown in the preceding figure, the service from PE1 to PE2 traverses the backbone network. To achieve the optimal service SLA, SRv6 Policy needs to be used to orchestrate the service path. VPN1 requires higher confidentiality requirements because of its service nature. Therefore, all data needs to be encrypted to prevent leakage at intermediate nodes. Therefore, packets of VPN1 need to be encrypted before being forwarded along the path orchestrated by the SRv6 policy.

The BGP Tunnel Encapsulation Attribute is defined in , and is utilized by BGP services to convey information regarding the need for encryption of service routes. Specifically, the tunnel type is set to ESP-Transport, as defined in the . However, this encapsulation mode is not suitable for SRv6. Therefore, a new encapsulation mode needs to be introduced to instruct services to be encrypted before outer tunnel encapsulation. When an EVPN Prefix Route is utilized to advertise a service route and carries the Tunnel Encapsulation Attribute with Tunnel-type set to ESP-Transport-Only-Payload, it indicates that data packets accessing the address must be encrypted using ESP. To facilitate this encryption, the document has defined the IPsec SA Nonce, IPsec Public Key, and IPsec SA Proposal, which are essential for ensuring the secure transmission of user data. This document directly inherits the definitions of these critical pieces of information, which are necessary for the proper implementation of secure service encryption. The IPsec SA Nonce, IPsec Public Key, and IPsec SA Proposal required for service encryption have been defined in . This document directly inherits the definitions of this information. When a service route carries additional information, such as the color and SRv6 SID, it is necessary to iterate the route to an SRv6 BE or SRv6 Policy. The specific route to be utilized is determined by the local tunnel policy or specified by the Tunnel-Encap Extend Community. The following figure shows the encapsulated packet format:

Let's take the scenario described in section 3 as an example.: 1. PE1 obtains IPSec information from BGP, including IPSec SA Nounce. 2. PE1 obtains VPN routes, such as EVPN Type 5 Prefix Routes, and adds a Tunnel-Encapsulation Attribute to the routes based on local policies. The Tunnel-Type parameter is ESP-Transport-Only-Payload. 3. PE1 obtains the VPN route and carries tunnel information, such as the VPN SID and Color Extended Community, based on the local policy. 4. PE1 advertises the route to PE2 through RRs. 5. 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. 6. 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. 7. PE2 receives the CE-side traffic that matches the route advertised by PE1. PE2 performs IPSec encryption based on the indicated IPSec encryption information, encapsulates the traffic into an SRv6 tunnel based on the indicated tunnel information, and sends the traffic to PE1 along the tunnel information. 8. 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 information because the packets carry ESP information. Searches the VRF table and forwards traffic to the CE based on the user packet information.

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.