]> Huawei

Beiqing Road Beijing shengcheng@huawei.com

Huawei

Beiqing Road Beijing China shihang9@huawei.com

Routing idr Multi-segment SD-WAN IPSec The document describes the control plane enhancement for multi-segment SD-WAN to implement Edge-to-edge encryption, GW information exchange, include/exclude transit list exchange.

Introduction To interconnect geographically faraway branches or SASE resources, multi-segment SD-WAN is often deployed via cloud backbone. This document focuses on the scenario where the edge connects to the Cloud GW through unsafe public network such as internet, as shown in . IPSec encryption is used to provide the authentication, integrity and confidentiality of the data from edge to edge.

Multi-segment SD-WAN | +--+--+ +--+--+ |CPE 1| |CPE 2| +-----+ +-----+ ]]>

To reduce the computing overhead of the Cloud GW, it is preferred to establish IPSec tunnel from edge to edge rather than from edge to Cloud GW. The overlay routing information is carried outside of the encrypted payload. When GW receives packet from CPE, it only needs to look at the unencrypted overlay routing header to do the forwarding. This document describes the control plane enhancement on top of to exchange the IPSec SA and corresponding GW information between edges to enable edge-to-edge IPSec encryption. This document also defines an extension to exchange the include/exclude transit list information from egress edge to ingress edge.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Exchange IPSec SA for edge-to-edge encryption All CPEs are under the control of one BGP instance. defines the mechanism for SD-WAN edges to discover each other's properties. The IPSec Key exchange between the CPE is via BGP update through RR. However, the granularity of IPSec SA in is limited to per site, per node or per port and it does not specify if the IPSec is between edge to edge or edge to Cloud GW. To that end, this document defines a new route type to exchange the IPSec SA for edge-to-edge IPSec encryption. The format is shown in .

Edge-to-edge IPSec encryption NLRI

where:

• NLRI Route Type = TBD: For advertising edge-to-edge IPSec encryption where the IPSec SA can be uniquely identified by a tuple: <Route-Distinguisher, SD-WAN-Color, SD-WAN-Node-ID>
• Route-Distinguisher: an 8-octet value used to distinguish routes from different VPN (see ).
• SD-WAN-Color: represent the SD-WAN site ID.
• SD-WAN-Node-ID: The node's IPv4 or IPv6 address.

The IPSec SA related sub-TLVs remain the same as defined in and is carried in the SD-WAN-Hybrid Tunnel Encapsulation attribute.

Exchange corresponding GW information between edges To help the ingress Cloud GW(GW1) route and forward to the egress Cloud GW, the source CPE need to carry the egress GW information in the data plane. To that end, the CPE need to discover the corresponding GW and advertise the corresponding GW information to other CPEs. Note that there may exist multiple path between the CPE and the corresponding GW. The source CPE may need to choose a specific path. This document defines a new NLRI route-type to carry the corresponding GW information. The format is shown in .

Corresponding GW information NLRI

where: the SD-WAN-Color and SD-WAN-Node-ID is the same as in . Depending on the deployment of the cloud backbone, there are two options for corresponding GW information discovery and advertisement.

Option 1: Link SID Assume that SRv6 or SR-MPLS is running on the cloud backbone. SD-WAN tunnels will be established between the CPE and the corresponding GW. For each tunnel, a link SID will be allocated by the GW. Then the link SID will be notified from the GW to the CPE through a dedicated hello protocol or manual configuration. A new Sub-TLV in the SD-WAN-Hybrid Tunnel Encapsulation attribute is defined as follows:

Option 2: Gateway ID + tunnel IP address The GW site ID and the destination tunnel IP address can be used as the corresponding GW information. A new Sub-TLV in the SD-WAN-Hybrid Tunnel Encapsulation attribute is defined as follows:

Exchange include/exclude transit list from destination edge to source edge When a user tries to access certain service, the traffic may need to go through certain Cloud Availability Regions or Zones to get better security. Or the traffic can not go through certain Cloud Availability Regions or Zones due to the regulation. As described in , the traffic enforcement rule is indicated using the including/excluding transit list in the data plane which is encapsulated at the source edge. The destination edge knows the traffic enforcement rules for each service behind it and need to pass the include/exclude transit list to the source edge. This document proposes to carry the list in the client route using Metadata Path Attribute defined in . Two new Sub-TLVs are defined to carry the include/exclude transit list.

Security Considerations This document does not introduce any new security considerations.

IANA Considerations TBD.

References Normative References Futurewei Hickory Hill Consulting Arrcus Microsoft Verizon Arista 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] Futurewei Microsoft Huawei Verizon China Mobile This draft describes a new Metadata Path Attribute and some sub-TLVs for egress routers to advertise the Edge Service Metadata of the directly attached edge services (ES). The Edge Service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like specific User Equipment (UE). Informative References Microsoft Futurewei Arista Microsoft The document describes the methods to optimize the stitching of multiple SD-WAN segments on transit nodes across Cloud DCs.

Acknowledgements The authors would like to thank Haibo Wang for his contribution to the document.