Internet-Draft | SDWAN Edge Discovery | October 2024 |
Dunbar, et al. | Expires 24 April 2025 | [Page] |
The document describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery.¶
In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 24 April 2025.¶
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.¶
BGP [RFC4271] can be used as a control plane for a SD-WAN network. SD-WAN network refers to a policy-driven network over multiple heterogeneous underlay networks to get better WAN bandwidth management, visibility, and control.¶
The document describes BGP UPDATE messages for an SD-WAN edge node to advertise its properties to its RR which then propagates that information to the authorized peers.¶
The following acronyms and terms are used in this document:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The objectives of SD-WAN edge discovery for an SD-WAN edge node are to discover its authorized BGP peers and each peer's associated properities in order to establish secure overlay tunnels [Net2Cloud]. The attributes to be propagated include:¶
the SD-WAN (client) VPNs information,¶
the attached routes under the SD-WAN VPNs, and¶
the properties of the underlay networks over which the client routes can be carried.¶
Some SD-WAN peers are connected by both trusted VPNs and untrusted public networks. Some SD-WAN peers are connected only by untrusted public networks. For the traffic over untrusted networks, IPsec Security Associations (IPsec SA) must be established and maintained. For the trusted VPNs, IPsec Security associations may not be set-up. If an edge node has network ports behind a NAT, the NAT properties need to be discovered by the authorized SD-WAN peers.¶
Like any VPN networks, the attached client routes belonging to specific SD-WAN VPNs can only be exchanged with the SD-WAN peer nodes authorized to communicate.¶
A pure IPsec VPN has IPsec tunnels connecting all edge nodes over public networks. Therefore, it requires stringent authentication and authorization (i.e., IKE Phase 1) before other properties of IPsec SA can be exchanged. The IPsec Security Association (SA) between two untrusted nodes typically requires the following configurations and message exchanges:¶
In a BGP-controlled SD-WAN network over hybrid MPLS VPN and public internet underlay networks, all edge nodes and RRs are already connected by private secure paths. The RRs have the policies to manage the authentication of all peer nodes. More importantly, when an edge node needs to establish multiple IPsec tunnels to many edge nodes, all the management information can be multiplexed into the secure management tunnel between RR and the edge node operating as a BGP peer. Therefore, the amount of authentication in a BGP-Controlled SD-WAN network can be significantly reduced.¶
Client VPNs are configured via VRFs, just like the configuration of the existing MPLS VPN. The IPsec equivalent traffic selectors for local and remote routes are achieved by importing/exporting VPN Route Targets. The binding of client routes to IPsec SA is dictated by policies. As a result, the IPsec configuration for a BGP controlled SD-WAN (with mixed MPLS VPN) can be simplified in the following manner:¶
The SD-WAN controller has the authority to authenticate edges and peers so the Remote Peer association is controlled by the SD-WAN Controller (RR).¶
The IKEv2 proposals (including the IPsec Transform set) can be sent directly to peers, or incorporated in a BGP UPDATE.¶
The BGP UPDATE announces the client route reachability through the SDWAN hybrid tunnels. A SDWAN hybrid tunnel combines several other tunnels into a single logical tunnel. The SD-WAN Hybrid tunnel implementations insure that all tunnels within are either running over secure network links or secured by IPsec.¶
Importing/exporting Route Targets under each client VPN (VRF) achieves the traffic selection (or permission) among clients' routes attached to multiple edge nodes.¶
Note: The web of SDWAN hybrid tunnels in a network is denoted in this document as an SD-WAN underlay. BGP passes information about the SDWAN hybrid tunnels between BGP peers by passing an SD-WAN Underlay NLRI paired with the tunnel encapsulation attribute (TEA) with an SDWAN tunnel type SD-WAN-Hybrid TLV.¶
Also, note that with this method there is no need to run multiple routing protocols in each IPsec tunnel.¶
There are two different sequences of BGP UPDATE messages are used for SD-WAN Edge Discovery. The first associates Client routes BGP Updates with a SD-WAN Hybrid Tunnel. The second passes information regarding the SD-WAN web of Hybrid tunnels (denoted as the SD-WAN Underlay) between Egress routers and Ingress routers to aid set-up of SD-WAN Hybrid tunnels in a network./¶
This section describes how client routes in BGP Updates are associated with the SD-WAN Hybrid Tunnel.¶
This BGP UPDATE message contains the client routes (NLRI), Next Hop, and the attributes which identify the Hybrid SD-WAN tunnel toward the Next Hop. The SD-WAN-Hybrid Tunnel BGP attributes are either passed as either:¶
Encapsulation Extended Community [Encap-EC] which identifies the SD-WAN-hybrid tunnel with a Tunnel Egress End Point as NextHop in BGP Update [per RFC9012],¶
Tunnel Encapsulation Attribute (TEA) which identifies the SD-WAN-Hybrid tunnel and uses the Tunnel Egress Endpoint SubTLV to identify the egress endpoint (see [RFC9012] section 3.1)¶
For a Hybrid SD-WAN Tunnel¶
In figure 1, four overlay paths between C-PE1 and C-PE2 are established for illustration purpose. More overlay paths are possible. One physical port on C-PE2 can terminate multiple overlay paths from different ports on C-PE1.¶
in one of two forms below:¶
Edges nodes use this BGP UPDATE to advertise the properties of directly attached underlay networks and IPsec SA attributes associated with an SD-WAN-Hybrid tunnel. The properties of underlay networks include encapsulation, NAT and underlay physical properties. The IPsec SA attributes passed include keys, nonce, and encryption algorithms, and other IP SEC attributes.¶
The security attributes are likely to change more rapidly than the physical attributes of links within the Hybrid SD-Wan Tunnel. Typically the attributes of the links are passed during initial set-up of Hybrid SD-WAN tunnels in the network.¶
Given the topology in figure 1, C-PE2 can send the SD-WAN NLRI in a BGP Update messages to advertise the properties of Internet facing ports 192.0.0.1 and 170.0.0.1, and their associated IPsec SA related parameters. One associated paramater for the SDWAN underlay is the SD-WAN Color. This SD-WAN color (see section 6.1) indicates a group of tunnels. The Client routes may signal the desire to use this group of tunnels by optionally attaching a Color Extended Community (Color-EC) or by local policy. Local network policy determines the mapping between Color-EC and the tunnel groupings identified by the SD-WAN-Color.¶
Example 1 below provides sample BGP Updates per port. This type of UPDATE packing provides poor packing of UPDATES, but it may occur. Example 2 provides a single BGP Update which passes the initial information in one update. In the update, Color-EC is Color Extended Community [RFC4360].¶
Example #1 - BGP Updates per Port¶
Example #2 - IP Sec Terminated at Node C-PE2¶
The basic scheme of SD-WAN edge node discovery using BGP consists of the following:¶
Secure connection to a SD-WAN controller (BGP RR in this context):¶
For an SD-WAN edge with both MPLS and IPsec paths, the edge node should already have a secure connection to its controller (RR in this context). For an SD-WAN edge that is only accessible via Internet, the SD-WAN edge upon power-up establishes a secure tunnel (such as TLS or SSL) with the SD-WAN central controller whose address is preconfigured on the edge node. The central controller informs the edge node of its local RR. The edge node then establishes a transport layer secure session with the RR (such as TLS or SSL).¶
The BGP Peer Edge node will advertise the properties of its Hybrid SD-WAN Tunnel to its designated RR via the secure connection.¶
The RR propagates the received information to the authorized BGP peers.¶
The authorized BGP peers can establish the secure data channels via Hybrid SD-WAN tunnel and exchange more information among each other.¶
For an SD-WAN deployment with multiple RRs, it is assumed that there are secure connections among those RRs. How secure connections are established among those RRs is out of the scope of this document. The existing BGP UPDATE propagation mechanisms control the edge properties propagation among the RRs.¶
For some environments where the communication to RR is highly secured, [RFC9016] IKE-less can be deployed to simplify IPsec SA establishment among edge nodes.¶
In SD-WAN deployment, SD-WAN Segmentation is a frequently used term which refers to partitioning a network into multiple subnetworks, just like MPLS VPNs. SD-WAN Segmentation is achieved by creating SD-WAN virtual topologies and SD-WAN VPNs. An SD-WAN virtual topology consists of a set of edge nodes and the tunnels (a.k.a. underlay paths) interconnecting those edge nodes. These tunnels forming the underlay paths can be IPsec tunnels, or MPLS VPN tunnels, or other tunnels.¶
An SD-WAN VPN is configured in the same way as the VRFs of an MPLS VPN. One SD-WAN client VPN can be mapped to multiple SD-WAN virtual topologies. SD-WAN Controller governs the policies of mapping a client VPN to SD-WAN virtual topologies.¶
Each SD-WAN edge node may need to support multiple VPNs. Route Target is used to differentiate the SD-WAN VPNs. For example, in the picture below, the Payment-Flow on C-PE2 is only mapped to the virtual topology of C-PEs to/from Payment Gateway, whereas other flows can be mapped to a multipoint-to-multipoint virtual topology.¶
BGP Route Reflectors [RFC4456] may be configured to constrain the distribution of BGP informtion to specific BGP clients.¶
The RR is configured to speak to the BGP clients (CE-PE1 and CE-PE2) over secure virtual links (IPsec), and send only certain routes. The configuration on the RR and the BGP Peers sending SD-WAN routes forms a "walled garden" for the SD-WAN information.¶
It is out of the scope of this document on how RR is configured with the policies to filter out unauthorized nodes for specific SD-WAN VPNs.¶
The Tunnel Encapsulation Attribute for the SD-WAN Hybrid Tunnel Type may be associated with BGP UPDATE messages with NLRI with AFI/SAFI IPv4 Unicast (1/1), IPv4 with MPLS labels (1/4), IPVPN-IPv4 Label Unicast (1/128), IPv6 Unicast (2/1), IPv6 with MPLS labels (2/4), VPN-IPv6 Label Unicast (2/128), and EVPN (25/70).¶
When associated with any NLRI in this set, these routes are described as "Client Routes" in this document. Based on [RFC9012], there are two forms a Tunnel Encapsulation Attribute (TEA) can take: "Barebones" using the Encapsulation Extended Community (Encaps-EC) and a normal Tunnel Encapsulation form.¶
The SD-WAN Client Route UPDATE message uses the Encapsulation Extended Community (Encap-EC) to identify the Hybrid SD-WAN tunnel and the Tunnel Egress Endpoint. Per [RFC9012], the Encapsulation Extended Community uses the NextHop Field in the BGP UPDATE as the Tunnel Egress EndPoint. The validation for the Tunnel Egress Endpoint uses the validation in section 6, 8, and 13 applied to the NextHop.¶
A Color Extended Community (Color-EC) or local policy applied to the client route directs the traffic for the client route to across appropriate interface within the Hybrid SD-WAN Tunnel to the Tunnel Egress Endpoint.¶
The Client route with the Tunnel Encapsulation Path Attribute (TEA) with the Hybrid SD-WAN route TLV must have the Tunnel Egress Endpoint (SubTLV=6) and any of the SubTLVs found in [RFC9012]. The validation for the Tunnel Egress Endpoint uses the validation in section 6, 8, and 13 from [RFC9012].¶
A single SD-WAN client route may be attached to multiple SD-WAN Hybrid tunnels. An Update with an SD-WAN client route may express these tunnels as an Encap-EC or a TEA. Each of these tunnel descriptions is treated as a unique Hybrid SD-WAN tunnel with a unique Egress Endpoint. Local Policy on the BGP Peer determines which tunnel the client data traffic will use.¶
An SD-WAN VPN ID is same as a client VPN in a BGP controlled SD-WAN network. The Route Target Extended Community should be included in a Client Route UPDATE message to differentiate the client routes from routes belonging to other VPNs. Route Target value is taken as the VPN ID (for 1/1 and 2/1). For 1/128 and 2/128, the RD from the NLRI identifies the VPN ID. For EVPN, picking up the VPN-ID from EVPN SAFI.¶
SD-WAN edge node which can be reached by either an MPLS path or an IPsec path within the hybrid SD-WAN tunnel. If client packets are sent via a secure MPLS network within the Hybrid SD-WAN tunnel, then the data packets will have MPLS headers with the MPLS Labels based on the scheme specified by [RFC8277]. It is assumed the secure MPLS network assures the security outer MPLS Label header.¶
If the packets are sent via a link with IPsec outer encryption across a public network, the payload is still encrypted with GRE or VXLAN encryption. For GRE Encapsulation within an IPsec tunnel, the GRE key field can be used to carry the SD-WAN VPN ID. For network virtual overlay (VxLAN, GENEVE, etc.) encapsulation within the IPsec tunnel, the Virtual Network Identifier (VNI) field is used to carry the SD-WAN VPN ID.¶
The hybrid SD-WAN underlay tunnel UPDATE is to advertise the detailed properties associated with the public facing WAN ports and IPsec tunnels. The Edge BGP Peer will advertise the SD-WAN properties to its designated RR via the secure connection. Each BGP Update message with a the SD-WAN Underlay NLRI MUST contain a Tunnel Encapsulation Attribute (TEA) for a Hybrid Tunnel type. The TEA can include with SubTLVs for Extended Port attribute (see section 7) or IP Sec information (see section 8). The IPsec information subTLVs include: IPsec-SA-ID, IPsec SA Nonce, IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.¶
A new NLRI SAFI (SD-WAN SAFI=74) is introduced within the MP_REACH_NLRI Path Attribute of [RFC4760] for advertising the detailed properties of the SD-WAN tunnels terminated at the edge node:¶
Where¶
This document defines the following SD-WAN Route type:¶
For advertising the detailed properties of the SD-WAN tunnels terminated at the edge, where the transport network port can be uniquely identified by a tuple of three values (Port-Local-ID, SD-WAN-Color, SD-WAN-Node-ID). The SD-WAN NLRI Route-Type =1 has the following encoding:¶
Route Type values outside of 1 are out of scope for this document.¶
A new BGP Tunnel-Type SD-WAN-Hybrid (code point 25) indicates hybrid underlay tunnels.¶
The valid SubTLVs for the Hybrid Tunnel type include subTLVs specified in [RFC9012] and the following SubTLVs specified in this document:¶
Extended Port Attributes Sub-TLV¶
IPsec SA-ID Sub-TLV¶
IPSec SA Rekey Sub-TLV¶
IPsec Public Key Sub-TLV¶
IPsec SA Proposal Sub-TLV¶
Simplified IPsec SA Sub-TLV¶
The Extended Port Attributes are described in section 7, and the IPsec related SubTLVs are described in section 8.¶
The SD-WAN Underlay NLRI is sent with a Tunnel Encapsulation Attribute with the Extended Port Attribute Sub-TLV advertises the properties associated with a public Internet-facing WAN port that might be behind NAT. An SD-WAN edge node can query a STUN Server (Session Traversal of UDP through Network address translation [RFC8489]) to get the NAT properties, including the public IP address and the Public Port number, to pass to its peers.¶
The location of a NAT device can be:¶
Only the initiator is behind a NAT device. Multiple initiators can be behind separate NAT devices. Initiators can also connect to the responder through multiple NAT devices.¶
Only the responder is behind a NAT device.¶
Both the initiator and the responder are behind a NAT device.¶
The initiator's address and/or responder's address can be dynamically assigned by an ISP or when their connection crosses a dynamic NAT device that allocates addresses from a dynamic address pool.¶
As one SD-WAN edge can connect to multiple peers, the pair-wise NAT exchange as IPsec's IKE[RFC7296] is not efficient. In the BGP Controlled SD-WAN, NAT properties for a WAN port are encoded in the Extended Port Attribute sub-TLV, which the following format:¶
Where:¶
- Flags:¶
- NAT Type: the NAT type can be one of the following values:¶
1: without NAT ;¶
2: 1-to-1 static NAT;¶
3: Full Cone;¶
4: Restricted Cone;¶
5: Port Restricted Cone;¶
6: Symmetric; or¶
7: Unknown (i.e. no response from the STUN server).¶
NAT type values outside of 1-7 are invalid for this SubTLV.¶
- Encap-Type: the supported encapsulation types for the port.¶
Notes:¶
The Encap-Type inside the Extended Port Attribute Sub-TLV is different from the RFC9012's BGP-Tunnel-Encapsulation type. The port can indicate the specific encapsulations, such as:¶
If the IPsec-SA-ID subTLV or the IPsec SA detailed subTLVs (Nonce/publicKey/Proposal) are included in the SD-WAN-Hybrid tunnel, the Encap-Type indicates the encapsulation type within the IPsec payload.¶
If the IPsec SA subTLVs are not included in the SD-WAN-Hybrid Tunnel, the Encap-Type indicates the encapsulation of the payload without IPsec encryption.¶
- RD ID: Routing Domain ID, need to be globally unique. Any value in this octet is valid.¶
One Extended Sub-Sub-TLVs is specified in this document: Underlay Network Property Sub-Sub-TLV¶
The Underlay Network Property Sub-Sub-TLV is an optional field within the Extended Port Attribute Sub-TLV to convey the WAN port connection types and bandwidth, such as LTE, DSL, Ethernet, others.¶
The format of this Sub-TLV is as follows:¶
Where:¶
are listed below as:¶
Port type define as follows:¶
The connection types of equipment and port types will continue to grow with technology change. Future specifications may specify additional connection types or port types.¶
This section describes the SubTLVs that pass data regarding IPsec parameters for the Hybrid SD-WAN tunnel. During set-up of the Hybrid SD-WAN tunnels, the IPsec parameters need to be securely passed to set-up secure association. For hybrid SD-WAN tunnels, the IPsec security association for IPsec links may change to different security associations over time.¶
The IPSec subTLVs supported by the Hybrid Tunnel type are: IPSec-SA-ID, IPsec SA Nounce, IPsec Public Key, IPsec Proposal, and Simplified IPSec SA. The IPSec-SA-ID SubTLV provides a way to indicate the IPsec SA Identifiers (section 8.1) for pre-configured security association. The other four SubTLVs provide different ways to pass details regarding IPsec security associations. The IPsec SA Nounce passes Nounce and rekey counters for a Secure Association identified by IPsec SA Identifier (see section 8.2). The IPSec Public Key SubTLV passes IPsec Public Key data with a time duration (see section 8.3). The IPsec Proposal SubTLV provides Transform attributes and Transform IDs (see section 8.4). The Simplified IP SEC SA passes the information that identifies configuration for 2 keys (see section 8.5).¶
For a quick rotation between security associations, the SDWAN NLRI (port-id, color, node) can quickly distribute a switch to a set of new security association using the BGP Update message. In this case, the BGP UPDATE message would like figure 10¶
IPsec-SA-ID Sub-TLV within the Hybrid Underlay Tunnel UPDATE indicates one or more pre-established IPsec SAs by using their identifiers, instead of listing all the detailed attributes of the IPsec SAs.¶
Using an IPsec-SA-ID Sub-TLV not only greatly reduces the size of BGP UPDATE messages, but also allows the pairwise IPsec rekeying process to be performed independently.¶
The following is the structure of the IPsec-SA-ID sub-TLV¶
where:¶
- IPSec-SA-ID Sub-Type (8 bits): Assigned the value of 64 by this document.¶
- length (8 bits): Specifies the total length in octets of the value field (excluding the Type and Length fields). For the IPSec-SA-ID Sub-Type, the length should be the 2 + 4 *(number of IPsec SA IDs) .¶
- Reserved: Reserved for future use. In this version of the document, the Reserved field MUST be set to zero and MUST be ignored upon receipt. Received values MUST be propagated without change.¶
- The value field consists of a sequence of IPsec SA Identifiers, each 4 octets long. As shown in figure above, n IPsec SAs are attached in the IPsec-SA-ID Sub-TLV:¶
The IPsec SA Rekey Counter Sub-TLV provides the rekey counter for a security association (identified by IPsec SA Identifier).¶
The IPsec SA Rekey Counter Sub-TLV Type is assigned value of 66 by this document.¶
The Value field of this Sub-TLV is as follows:¶
where:¶
- ID Length (8 bits): indicates the length in octets of SA-Identifer. This length should be 4 octets.¶
- Nonce length (16 bits): indicates the length in octets of the Nonce Data.¶
- I Flag: when set to 1, the I-flag indicates that the communication being established is new. when set to 0, it signals that the communication is a continuation of an existing session.¶
- Reserved (7 bits): Reserved for future use. In this version of the document, the Reserved field MUST be set to zero and MUST be ignored upon receipt. Received values MUST be propagated without change.¶
- Rekey Counter (64 bits): the number of key updates or rekeys that have occurred. Each time a key is rotated or replaced, the ReKey Counter is incremented.¶
- IPsec SA Identifier (IPSec-SA-ID): a specific IPsec SAs terminated at the edge.¶
- Nonce Data: a random or pseudo-random number for preventing replay attacks. Its length is a multiple of 32 bits[RFC7296].¶
Note:¶
The IPsec-SA-ID may also refer to the values carried in the same TEA in the same Tunnel TLV (type SD-WAN Hybrid) as the IPsec SA Rekey SubTLV in either the IPsec Public Key SubTLV or the IPsec SA Proposal SubTLV. The IPsec SA Rekey Counter, IPsec Public Key, and IPsec SA Proposal SubTLVs work together to create security associations.¶
The IPsec-SA-ID may refer to information in another Tunnel TLV in the same TEA associated wiht the same BGP UPDATE message as the IPsec SA Rekey Counter sub-TLV.¶
The IPsec-SA-ID can be used in the IPsec-SA-ID subTLV of a different BGP UPDATE message.¶
The IPsec Public Key Sub-TLV Type is assigned value of 67 by this document.¶
The Value field of this Sub-TLV is as follows:¶
where:¶
Diffie-Hellman Group Num (16-bits): identifies the Diffie-Hellman group used to compute the Key Exchange Data. Details on Diffie-Hellman group numbers can be found in Appendix B of IKEv2 [RFC7296] and [RFC5114].¶
The Key Exchange data: This refers to a copy of the sender's Diffie-Hellman public value. The length of the Diffie-Hellman public value is defined for MODP groups in [RFC 7296] and for ECP groups in [RFC 5903].¶
Duration (32 bits): a 4-octet value specifying the life span of the Diffie-Hellman key in seconds.¶
The IPsec SA Proposal Sub-TLV is to indicate the number of Transform Sub-TLVs.¶
The IIPsec SA Proposal Sub-TLV Type is assigned value of 68 by this document.¶
The Value field of this Sub-TLV is as follows:¶
where:¶
Transform Attr Length (16 bits): indicates the length of the Transform Attributes field.¶
Transform Type (8 bits): The Transform Type values are defined in Section 3.3.2 of [RFC7296] and [IKEV2IANA]. Only ENCR, INTEG, and ESN values are permitted.¶
Reserved (8 bits): reserved for future use. These bits are ignored upon receipt and set to zero when transmitted.¶
Transform ID (16 bits): An identifer for the transform defined by the associated transform attributes.¶
Transform Attributes: These Sub-SubTLV are defined in section 3.3.5 of [RFC7296].¶
For a simple SD-WAN network with edge nodes supporting only a few pre-defined encryption algorithms, a simple IPsec sub-TLV can be used to encode the pre-defined algorithms, as below:¶
Where:¶
All other transform values are outside the scope of this document.¶
Mode = 1 indicates that the Tunnel Mode is used.¶
Mode = 2 indicates that the Transport mode is used.¶
All mode values besides 1 and 2 are outside the scope of this document.¶
the ESP algorithms supported. Its values are specified by [IANA-ESP]. One SD-WAN edge node can support multiple ESP algorithms and send them to its peers to negotiate the strongest one. The default algorithm is AES-256.¶
The Error handling for SD-WAN VPN support has two components: error handling for Tunnel Encapsulation signaling (Encaps-EC and TEA) and the SD-WAN NLRI. An SD-WAN NLRI, a Tunnel Encapsulation attribute MUST always accompany the SD-WAN NLRI.¶
The error handling for the tunnel encapsulation signaling (Encaps-EC and TEA) adheres to the error handling and validation specified by [RFC9012].¶
The Tunnel encapsulation signaled with the client routes indicates the Egress endpoint via Next Hop in the Encaps-EC or the TEA SubTLV for Tunnel Egress Endpoints. As indicated in sections 5.1 and 5.2, the SD-WAN Hybrid tunnel follows the validation section 6, 8, and 13 from [RFC9012].¶
The SD-WAN client routes associate the same NLRIs that [RFC9012] associates with the Encaps-EC and the TEA using the validation specified in [RFC9012] in sections 6, 8, and 13. When the SD-WAN Hybrid Tunnel is associated with the SD-WAN NLRI, and all RFC9012 validation rules in section 6, 8, and 13 are extended to apply to the SD-WAN NLRI.¶
[RFC9012] contains the necessary detail to specify validation for the new SubTLVs present for the SD-WAN Tunnel type. However, to aid users of this document the following recap of validation of [RFC9012] is provided below. The validation from section 13 of [RFC9012] includes:¶
Invalid tunnel type must be treat if the TLV was not present.¶
A malformed subTLVs must be treated as an unrecognized subTLV except for Tunnel Egress Endpoint. If Tunnel Egress Endpoint is malformed, the entire TLV must be ignored.¶
Multiple incidents of Tunnel Egress Endpoint, Encapsulation, DS, UDP Destination Port, Embedded Label Handling, MPLS Label Stack, Prefixes-SID cause the first incident of these subTLVs to be utilized. Subsequent TLVs after the first one per type are ignored (per RFC9012), but propogated.¶
If a subTLV is meaningless for a tunnel type, the subTLV is ignored, but the subTLV is not considered malformed or removed from the Tunnel Attribute propagated with the NLRI.¶
For SD-WAN client routes with a TEA with a SD-WAN Hybrid Tunnel type, the Extended Port subTLV and the IPSec SubTLVs (IPsec SA-ID, IPSec nonce, IPSec Public Key, IPsec Proposal, and Simplified IPsec SA) are meaningful, but may be rarely sent.¶
For SD-WAN NLRI underlay routes, the the Extended Port subTLV and the IPSec SubTLVs (IPsec SA-ID, IPSec nonce, IPSec Public Key, IPsec Proposal, and Simplified IPsec SA) are valid and meaningful. Incorrect fields within any of these 5 TLVs or subSubTLVs within the TLVs should cause the subTLV to be treated as malformed SubTLV. Per [RFC9012], a malformed subTLV is treated as an unrecognized subTLV. Multiple copies of each SubTLV may be included in a single TLV.¶
The SD-WAN NLRI [AFI 1/SAFI = 74] utilizes a route type field to describe the format of the NLRI. This specification only allows an NLRI with a type value of 1. An NLRI with a type of field of another value is ignored and not processed. The implementation MAY log an error upon a reception of an type value outside of Route Type 1. Error handling for the SD-WAN NLRI also adheres to the BGP Update error handling specified in [RFC7606].¶
Section 6.1 specifies that Route Type 1 has a tuple of (Port-Local-ID, SD-WAN-Color, SD-WAN-Node-ID). Port-Local-ID may be zero if the NLRI applies to multiple ports. The BGP Peer receiving the NLRI must have pre-configured inbound filters to set the preference for the SD-WAN NLRI tuple.¶
Since a Port-Local-ID value of zero indicates the NLRI applies to multiple ports, it is possible to have the following NLRI within a packet (or received in multiple packets):¶
Port-Local-ID (0), SD-WAN-Color (10), SD-WAN-Node-ID (2.2.2.2),¶
Port-Local-ID (0), SD-WAN-Color (20), SD-WAN-Node-ID (2.2.2.2), and¶
Port-Local-ID (0), SD-WAN-Color (30), SD-WAN-Node-ID (2.2.2.2).¶
These NLRI may simply indicate that there are three groups of tunnels for SD-WAN-Node-ID (2.2.2.2) assigned three colors. For example, these tunnels could represent three types of gold, silver and bronze network service.¶
The local policy configuration in the BGP peer receiving this NLRI must determine the validity of the route based on policy. Local configuration and policy must be carefully constrain the SD-WAN-NLRI, tunnels, and IPsec security associations in to create a "walled garden".¶
In the future, other proposals for a SD-WAN NLRI may specify a different route type. Those proposals must specify the following:¶
The SD-WAN NLRI (AFI=1/SAFI=74) must be paired with Tunnel Encapsulation attribute with a tunnel TLV for tunnel type SD-WAN-Hybrid. If the SD-WAN NLRI exist in an BGP UPDATE without a Tunnel Encapsulation Attribute (TEA) with a tunnel TLV for tunnel type SD-WAN-Hybrid, the NLRI is considered malformed and Treat-as-withdraw approach (per RFC7606).¶
The SD-WAN NLRI should not be paired with Encapsulation Extended Community. If an SD-WAN NLRI is paried Encapsulation Extended Community rather than a Tunnel Encapsulation Attribute, the SD-WAN NLRI is considered malformed and Treat-as-withdraw approach (per [RFC7606]) should be used.¶
Unlike MPLS VPN whose PE nodes are all controlled by the network operators, SD-WAN edge nodes can be installed anywhere, in shopping malls, in 3rd party Cloud DCs, etc.¶
It is very important to ensure that client routes advertisement from an SD-WAN edge node are legitimate. The RR needs to ensure the SD-WAN Hybrid Tunnels and routes run over the appropriate Security associations.¶
It is critical that the Hybrid SD-WAN Tunnel have correctly forward traffic based on the local policy on the client routes, the tunnel egress and tunnel ingress, and the security association. The RR reflector and the BGP peer must check that the client routes, tunnel egress, tunnel ingress, and security associations align with expected values for a tunnel.¶
Each BGP peer (e.g. a C-PE) advertises a SD-WAN SAFI Underlay NLRI to the other BGP peers via a BGP Route Reflector to establish pairwise IPsec Security Associations (SA) between itself and other remote BGP Peers. During the SD-WAN SAFI NLRI advertisement, the BGP Peer originating may pass information about security asssociation in one of three forms:¶
an identifier for a pre-configured and established IPsec Security Association,¶
a simplified set of security parameters for setting up a IPsec Security association (Transform, IPsec Mode, AH and ESP Algorithms, rekey counter, 2 public keys, nonce, and duration of security association), or¶
a flexible set of security parameters where Nonce, Public Key, and SA Proposal are uniquely specified.¶
For existing IPsec Security associations, the receiving BGP peer can simply utilize one of these existing security associations to pass data. If multiple IPsec associations are pre-configured, the local policy on the SD-WAN Edge Node may may help select which security association is chosen for the SD-WAN Hybrid Tunnel.¶
If the receiving and originating BGP peer engage in a set-up for the IPsec security associations for the link within the SD-WAN Hybrid tunnel, IPsec mechansims require that there are matching IPsec transforms. Without common IPsec transforms, the IPsec set-up process cannot operate.¶
The TEA passes in the Tunnel TLV for the SD-WAN Hybrid Tunnel these three sets of information in the following subTLVs:¶
The BGP Peer's need to send the IPSec SA attributes received on the SD-WAN NLRI in the TEA between the local and remote WAN ports. If there is a match on the SA Attributes between the two ports, the IPSec Tunnel is established. If there is a mismtach on the SA Attributes, no IPsec Tunnel is established.¶
The C-PE devices do not try to negotiate the base IPSec-SA parameters between the local and the remote ports in the case of simple IPSec SA exchange or the Transform sets between local and remote ports. If there is a mismatch in the IPsec SA, then no IPsec Tunnel is created. If there is a mismatch on the Transform sets in the case of full-set of IPSec SA Sub-TLVs, no tunnel is created.¶
This section provides one example of how IPsec Security associationes are created over the SD-WAN Hybrid tunnel. Figure 1 in Section 3 shows an establish an IPsec Tunnel being created between C-PE1 and C-PE2 WAN Ports A2 and B2 (A2: 192.10.0.10 - B2:192.0.0.1).¶
To create this tunnel C-PE1 needs to advertise the following attributes for establishing the IPsec SA:¶
NextHop: 192.10.0.10¶
SD-WAN Node ID: 1.1.1.1¶
SD-WAN-Site-ID: 1500¶
Tunnel Encap Attr (Type=SD-WAN) -¶
C-PE2 needs to advertise the following attributes for establishing IPsec SA:¶
As there is no matching transform between the WAN ports A2 and B2 in C-PE1 and C-PE2, respectively, no IPsec Tunnel will be established.¶
The document describes the encoding for SD-WAN edge nodes to advertise its properties to their peers to its RR, which propagates to the intended peers via untrusted networks.¶
The secure propagation is achieved by secure channels, such as TLS, SSL, or IPsec, between the SD-WAN edge nodes and the local controller RR.¶
SD-WAN edge nodes might not have secure channels with the RR. In this case, BGP connection has be established over IPsec or TLS.¶
This document describes the encoding for SD-WAN edge nodes to advertise their properties to their peers via their respective Route Reflector (RR), which then propagates the information to the intended peers. SD-WAN edge nodes to advertise its properties to their peers via a secure connection (TLS, SSL, or IPsec) to the RR which propagates to the intended peers over a secure connection (TLS, SSL, or IPsec).¶
In a walled garden SD-WAN deployment where all SD-WAN edges and the central controller are under one administrative control and the network operates within a closed environment, the threat model is primarily on internal threats, misconfigurations, and localized physical risks. Unauthorized physical access to SD-WAN edge devices in remote locations is a concern. Such access might allow attackers to compromise the edge devices and potentially manipulate the advertised Client prefixes with VPN IDs (or Route Targets) that do not belong to them. This can lead to unauthorized data interception and traffic redirection.¶
Therefore, it is necessary to ensure physical security controls are in place at remote locations, including locks, surveillance, and access controls. Additionally, the RR needs to verify the BGP advertisements from each SD-WAN edge to ensure that their advertised VPN IDs (or Route Targets) are truly theirs. This verification helps prevent unauthorized advertisement of prefixes and ensures the integrity of the routing information within the SD-WAN environment. Ensuring secure communication between SD-WAN edge nodes and the central controller within a walled garden deployment is crucial. It is essential to utilize secure communication channels such as TLS or IPsec for all communications between edge nodes and the controller.¶
IANA has assigned SAFI = 74 as the Hybrid (SD-WAN) SAFI.¶
IANA is requested to assign a type from the BGP Tunnel Encapsulation Attribute Tunnel Types as follows [RFC8126]:¶
Value Description Reference ----- ------------ --------- 25 SD-WAN-Hybrid (this document)¶
IANA is requested to assign the following sub-Types in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry:¶
Value Type Description Reference Section ----- ----------------------- ------------- ------- 64 IPSEC-SA-ID Sub-TLV This document 8.1 65 Extended Port Property Sub-TLV This document 7.0 66 IPsec SA Rekey Counter Sub-TLV This document 8.2 67 IPsec Public Key Sub-TLV This document 8.3 68 IPsec SA Proposal Sub-TLV This document 8.4 69 Simplified IPsec SA sub-TLV This document 8.5¶
IANA is requested to assign the following Sub-Sub-Types within the Extended Port Property Sub-TLV:¶
Value Type Description Reference Section ----- ----------------------- ------------- ------- 1 Underlay Network Property Sub-Sub-TLV This document 7.1¶
Acknowledgements to Wang Haibo, Shunwan Zhuang, Hao Weiguo, and ShengCheng for implementation contribution. Many thanks to Yoav Nir, Graham Bartlett, Jim Guichard, John Scudder, and Donald Eastlake for their review and suggestions.¶
Below is a list of other contributing authors:¶