| Internet-Draft | IPSec for BGP Enabled Services over SRv6 | January 2024 |
| Wang, et al. | Expires 29 July 2024 | [Page] |
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. The method is needed for some users or applications that demand an elevated level of security, necessitating the encryption of their data flows even within networks like SRv6, which are built and managed by Network Service Providers (NSP) and generally considered secure. Employing encryption for selective flows 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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 29 July 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.¶
A Network Service Provider (NSP) managed SRv6 domain, designed to be restricted to authorized users, is often considered a trusted and secure domain ([RFC8754], [RFC8402], [RFC8986]). 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¶
+--+ +--+ +--+
,|P1|---------|P3|-------|P5|
/ +/-+ +/-+ +/-+\
.` | | | `.
VPN1_ / | | | . ,VPN1
'+---+/ | | | \ +---+/
|PE1|\ | | | '|PE2|
.+---+ \ | | | / +---+-,VPN2
VPN2`. / \ | | | / / .
| | \ | | | / | |
| | \ +\-+ +\-+ +\-+ / | |
| | '|P2|---------|P4|-------|P6|/ | |
| | +--+ +--+ +--+ | |
| |<------------------------------------------>| |
| | 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:¶
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| Link MAC Header | | Link MAC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| Eth Type = IPv6 | | Eth Type = IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Header | | IPv6 Header |
| NextHeader=RH | | NextHeader=RH |
+-----------------------+ +-----------------------+
| IPv6 EH | | IPv6 EH(SRH) |
|NextHeader = IPv4/IPv6 | | NextHeader = ESP |
+-----------------------+ +-----------------------+
| User IPv4/6 Payload | | ESP Header |
+-----------------------+ +-----------------------+
Standard SRv6 Packet | User IPv4/6 Payload |
+-----------------------+
| ESP Trailer |
+-----------------------+
ESP in SRv6 Packet¶
The BGP Tunnel Encapsulation Attribute defined in [RFC9012] 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 [I-D.ietf-bess-secure-evpn] defines a methodology for advertising IPSec information for a service route to other PEs via BGP. The [I-D.ietf-bess-secure-evpn] introduces a new Tunnel Type, ESP-Transport, into the existing framework outlined in [RFC9012]. 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.¶
Yulin Shi Huawei Email: shiyulin@huawei.com Xiangfeng Ding Huawei Email: dingxiangfeng@huawei.com Shunwan Zhuang Huawei Email: zhuangshunwan@huawei.com¶