| Internet-Draft | ESP Protection for Services over SRv6 | March 2026 |
| Wang, et al. | Expires 2 September 2026 | [Page] |
This document describes a mechanism for protecting selected service traffic using IPsec ESP while transporting the traffic over an SRv6 Policy. The approach enables service payloads to be encrypted prior to SRv6 encapsulation, allowing the SRv6 header to remain visible for segment-based forwarding within the provider network. This mechanism supports services or applications that require additional confidentiality and integrity protection, even when carried over an operator-managed SRv6 domain. The document also outlines how the necessary parameters can be signaled using BGP.¶
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 2 September 2026.¶
Copyright (c) 2026 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.¶
Segment Routing over IPv6 (SRv6) [RFC8986] is widely deployed within service provider networks to steer traffic across an operator controlled infrastructure. In many deployments, the SRv6 domain is considered operationally secure, and service traffic is transported without additional encryption inside the provider network. However, certain services, such as enterprise VPNs, regulated workloads, or sensitive application traffic, may require an additional layer of confidentiality and integrity protection, even when traversing a trusted SRv6 domain¶
This document describes a mechanism to provide optional IPsec based protection for selected services carried over an SRv6 network. The objective is to allow a subset of services to be encrypted using ESP while preserving SRv6 forwarding semantics. In this approach, the Segment Routing Header (SRH) remains visible to intermediate nodes for path steering, while the service payload is protected by ESP.¶
Because SRv6 service delivery commonly relies on BGP based control plane signaling, this document specifies a method for using BGP to distribute the IPsec parameters required for secure service transport. The intent is to enable coordinated establishment of ESP protection for selected SRv6 services without introducing a separate key exchange protocol within the SRv6 forwarding domain.¶
This mechanism does not alter SRv6 forwarding behavior. It augments SRv6 service transport by enabling additional security for selected services, while allowing other services to continue using standard SRv6 encapsulation without encryption.¶
SRv6: Segment Routing over IPv6¶
ESP: Encapsulating Security Payload¶
IPsec: Internet Protocol Security¶
SA: Security Association¶
+--+ +--+ +--+
,|P1|---------|P3|-------|P5|
/ +/-+ +/-+ +/-+\
.` | | | `.
SecureSer1_ / | | | . SecureSer1
'+---+/ | | | \ +---+/
|PE1|\ | | | '|PE2|
.+---+ \ | | | / +---+-,Service2
Service2 \ | | | / / .
| | \ | | | / | |
| | \ +\-+ +\-+ +\-+ / | |
| | '|P2|---------|P4|-------|P6|/ | |
| | +--+ +--+ +--+ | |
| |<------------------------------------------>| |
| | SRv6 Policy | |
\<------------------------------------------------>\
services Over SRv6 Policy
SecureSer: Secure-Service
¶
As illustrated in the preceding figure, traffic between PE1 and PE2 traverses the provider backbone and is steered according to an SRv6 Policy. The SRv6 Policy determines the explicit forwarding path across the core network in order to meet service-level objectives such as performance and resiliency.¶
Secure-Service-1 has confidentiality requirements that mandate additional data-plane protection. Accordingly, its packets are protected using ESP prior to being forwarded along the SRv6 policy path. The SRv6 header remains visible to intermediate nodes for segment based forwarding, while the service payload is encrypted to provide confidentiality and integrity across the backbone.¶
In contrast, Service2 represents regular service traffic that does not require additional protection and is transported using standard SRv6 encapsulation without ESP.¶
The SRv6 header [RFC8754] is placed outside the IPsec ESP [RFC4303] encrypted payload to preserve normal SRv6 forwarding behavior within the domain. The Segment Routing Header (SRH) contains the segment list and associated routing information that must remain visible to intermediate nodes in order to enable segment-based forwarding. By keeping the SRH unencrypted, SRv6-capable devices can process the Routing Type 4 header and apply the appropriate forwarding actions. At the same time, ESP protects the inner service payload, providing confidentiality and integrity without interfering with SRv6 path steering. This layering ensures that routing functions and payload protection operate independently and consistently within the SRv6 domain.¶
The following figure shows the encapsulated packet format:¶
+-----------------------+ +-----------------------+
| Link MAC Header | | Link MAC Header |
+-----------------------+ +-----------------------+
| Eth Type = IPv6 | | Eth Type = IPv6 |
+-----------------------+ +-----------------------+
| IPv6 Header | | IPv6 Header |
| Next Header = 43 (RH) | | Next Header = 43 (RH) |
+-----------------------+ +-----------------------+
| Segment Routing Header| | Segment Routing Header|
| (SRH, Routing Type=4) | | (SRH, Routing Type=4) |
| Next Header = | | Next Header = 50 (ESP)|
| IPv4 / IPv6 / L4 | +-----------------------+
+-----------------------+ | ESP Header |
| Inner IPv4/IPv6 | +-----------------------+
| packet or payload | | Encrypted Inner |
+-----------------------+ | IPv4/IPv6 packet |
Standard SRv6 Packet +-----------------------+
| ESP Trailer + ICV |
+-----------------------+
ESP over SRv6 (SRH visible)
¶
The BGP Tunnel Encapsulation Attribute defined in [RFC9012] allows service routes to carry information about the tunnels that can be used to transport them. However, [RFC9012] does not define how IPsec ESP can be integrated with SRv6 service delivery, particularly when SRv6 policies are used for path steering. Specifically, it does not describe a mechanism for advertising both SRv6 SID information and the IPsec parameters required to protect selected services. As a result, additional specification is required to enable coordinated signaling of SRv6 and ESP-related attributes for a given service route.¶
The [I-D.ietf-bess-secure-evpn] document defines a method for distributing IPsec-related information for EVPN services using BGP. It introduces a new Tunnel Type, ESP-Transport, within the framework of [RFC9012]. In that approach, VXLAN remains the outer transport encapsulation, and ESP is applied to protect the VXLAN-encapsulated payload. While this model is appropriate for VXLAN-based deployments, it does not directly address SRv6-based service transport. In an SRv6 domain, the Segment Routing Header (SRH) must remain visible to intermediate nodes to enable segment-based forwarding. Encrypting an outer encapsulation in a manner that obscures SRv6 routing information would prevent proper SRv6 policy processing.¶
n addition, [I-D.ietf-idr-sdwan-edge-discovery] defines sub-TLVs for advertising IPsec-related attributes within the BGP Tunnel Encapsulation Attribute framework. These sub-TLVs provide a mechanism for distributing IPsec parameters associated with specific tunnel types and may be applicable to secure service transport beyond SD-WAN environments. However, the SD-WAN draft primarily associates those IPsec sub-TLVs with SD-WAN tunnel types and hybrid underlay constructs. It does not define a tunnel type or signaling semantics for the case where ESP protection is applied in conjunction with SRv6 encapsulation. In particular, it does not specify how IPsec parameters and SRv6 SID information are to be jointly interpreted when the SRv6 header remains outside the encrypted payload. As a result, while the existing IPsec sub-TLVs could be reused, a clear tunnel type definition and associated processing rules are required to support ESP-protected services transported over an SRv6 policy.¶
Therefore, a Tunnel Type is required to explicitly indicate that a service route is to be transported over an SRv6 policy while being protected by ESP. Such a definition would clarify the processing semantics when SRv6 encapsulation and IPsec parameters are jointly signaled using the BGP Tunnel Encapsulation Attribute. In particular, it would specify that the SRv6 header remains outside the encrypted payload for forwarding purposes, while the inner service payload is protected by ESP. This preserves SRv6 path steering behavior and ensures consistent interpretation of IPsec-related sub-TLVs when applied to SRv6-based service transport.¶
This document defines a new Tunnel Type, ESP-Protected-Payload, within the BGP Tunnel Encapsulation Attribute framework specified in [RFC9012]. The ESP-Protected-Payload Tunnel Type indicates that the service payload is to be protected using IPsec ESP, while being transported over an outer encapsulation such as SRv6. The SRv6 header remains outside the encrypted payload to preserve normal segment-based forwarding behavior within the SRv6 domain.¶
The IPsec-related sub-TLVs defined in [I-D.ietf-idr-sdwan-edge-discovery], including the IPsec SA Nonce, IPsec Public Key, and IPsec SA Proposal sub-TLVs, MAY be carried under the ESP-Protected-Payload Tunnel Type. These sub-TLVs provide the necessary parameters for establishing ESP protection for the service. This document reuses those sub-TLV definitions without modification, and defines their interpretation when applied to SRv6-based service transport.¶
When a service route carries additional attributes, such as a color and SRv6 SID information, route resolution is performed according to the local tunnel policy. The service route is resolved to the appropriate SRv6 Provider Edge (PE) or SRv6 Policy based on the color value or as explicitly indicated by the Tunnel Encapsulation Extended Community. The ESP-Protected-Payload Tunnel Type applies to the selected SRv6 transport, indicating that the inner service payload MUST be protected by ESP prior to transmission over the resolved SRv6 policy.¶
Let's take the scenario described in section 3 as an example. The following steps illustration the procedure:¶
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-Protected-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-Protected-Payload 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-Protected-Payload needs to be allocated by IANA.¶
In this solution, selected service traffic is protected using IPsec ESP prior to transmission over the SRv6 domain. As a result, the inner service payload is encrypted and integrity-protected while traversing the provider backbone. Intermediate nodes that process the SRv6 header for forwarding purposes do not have visibility into the encrypted payload. This mechanism provides confidentiality and data integrity protection for services requiring enhanced security, such as those carrying sensitive or regulated traffic.¶
Yulin Shi Huawei Email: shiyulin@huawei.com Xiangfeng Ding Huawei Email: dingxiangfeng@huawei.com Shunwan Zhuang Huawei Email: zhuangshunwan@huawei.com¶