| Internet-Draft | IPSec for BGP Enabled Services over SRv6 | July 2023 |
| Wang, et al. | Expires 11 January 2024 | [Page] |
For certain users, security is of paramount importance. Even when building their own backbone networks, these users require end-to-end service encryption to ensure the confidentiality and integrity of their data. In such scenarios, IPsec can be used to provide flexible and robust encryption capabilities, while SRv6 can be used to guide the forwarding of data packets along different paths on the network. By combining these technologies, users can create a highly secure and efficient network environment that meets their specific needs and requirements.¶
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 11 January 2024.¶
Copyright (c) 2023 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.¶
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([RFC8754], [RFC8402], [RFC8986]). 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 [RFC9012]. 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 [I-D.ietf-bess-secure-evpn] 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¶
+--+ +--+ +--+
,|P1|---------|P3|-------|P5|
/ +/-+ +/-+ +/-+\
.` | | | `.
VPN1_ / | | | . ,VPN1
'+---+/ | | | \ +---+/
|PE1|\ | | | '|PE2|
.+---+ \ | | | / +---+-,VPN2
VPN2`. / \ | | | / / .
| | \ | | | / | |
| | \ +\-+ +\-+ +\-+ / | |
| | '|P2|---------|P4|-------|P6|/ | |
| | +--+ +--+ +--+ | |
| |<------------------------------------------>| |
| | 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 [RFC9012], 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 [I-D.ietf-bess-secure-evpn]. 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 [I-D.ietf-idr-sdwan-edge-discovery] 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 [I-D.ietf-idr-sdwan-edge-discovery]. 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:¶
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| 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¶
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 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.¶
Yulin Shi Huawei Email: shiyulin@huawei.com Xiangfeng Ding Huawei Email: dingxiangfeng@huawei.com Shunwan Zhuang Huawei Email: zhuangshunwan@huawei.com¶