Segment routing for SD-WAN paths over hybrid networks
draft-dunbar-sr-sdwan-over-hybrid-networks-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Linda Dunbar , Mehmet Toy | ||
Last updated | 2018-06-19 (Latest revision 2018-06-01) | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-dunbar-sr-sdwan-over-hybrid-networks-01
' head- end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each Dunbar, et al. Expires June 18, 2018 [Page 8] Internet-Draft SD-WAN over multiple domains June 2018 network segment to have the intelligence (or maintaining states) of selecting next hop or next domain. There may be two approaches here: 1) Controller installs the entire SID stack at E1. 2) Controller delivers to E1 a "Key" that the SR ingress PE can use to map to the SID stack for the packets arriving at the SR Ingress PE. Section 4.2 & 4.3 will describe how the "Key" is carried by the packets. The Approach 1) requires less processing at the SR Ingress PE nodes, but only works if the remote CPEs are in the same Administrative domain as the SR domain. SR domain usually is not willing to expose its internal binding SIDs to devices in different administration domains. This approach also requires more changes to SD-WAN end nodes and need more header bytes added to the packets when rd traversing through 3 party internet. Some SD-WAN nodes might not be capable of supporting encapsulating packets with the SID stack. The Approach 2) above requires SR Ingress PE nodes to map the "Key" to the SID Stack and prepend the SID stack to the packets (Same processing for other traffic except the mapping is from the received "Key" carried in the payload). 4.1. Controller Delivers SID Stack to SD-WAN Head-end This approach is straightforward. E1 -------------------------- > SD-WAN controller request for a SD-WAN path E1<->E2 with a specific SLA E1 <-------------------------- SD-WAN controller Reply with the Ingress PE Node ID or address & the Binding SID. Here is the packet header for SD-WAN Source Node to prepend to the payload: Dunbar, et al. Expires June 18, 2018 [Page 9] Internet-Draft SD-WAN over multiple domains June 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 IPv4 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Prot.=17(UDP) | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SD-WAN Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SR Ingress PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = | Dest. Port = 4754/4755 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To traverse SRv6 domain, SRv6 Header is appended after the GRE header [SRv6-SRH]: Dunbar, et al. Expires June 18, 2018 [Page 10] Internet-Draft SD-WAN over multiple domains June 2018 To traverse MPLS-SR domain, a stack of MPLS labels is appended after GRE Header [MPLS-SR]. 4.2. Using GRE Key to Differentiate Flows This section describes a method of SD-WAN head-end node using GRE Key to indicate the desired property for different flows between SD- WAN end-points (E1<->E2 in the figure above): such as different desired routes through the SR Domain, different egress PEs based on cost, performance or other factors. It might be difficult or impossible to DiffServ bits carried by the packets to describe those flow properties. The SR Domain ingress can map the GRE key to different SID through the SR Domain. We assume that the SD-WAN Controller can determine which ingress PE can lead to the optimal path between E1<->E2. It is beyond the scope of this document on how SD-WAN controller computes the paths and how & what SD-WAN controller communicates with the SR Domain controller. Here is the sequence of the flow: E1 -------------------------- > SD-WAN controller request for a SD-WAN path E1<->E2 with a specific SLA E1 <-------------------------- SD-WAN controller Reply with the Ingress PE Node ID or address & the GRE Key. Note: the GRE key from the SD-WAN controller is for the ingress PE to correlate desired Path with the list of SIDs to prepend the packet across the SR domain. When SD-WAN Controller get the E1<->E2 path request, it will communicate with the VPN Controller to get the optimal Ingress PE Dunbar, et al. Expires June 18, 2018 [Page 11] Internet-Draft SD-WAN over multiple domains June 2018 Node ID (or IP address) and the GRE key to encapsulate the original packets between E1 <-> E2 (assuming IPsec Tunnel mode is used). Upon receiving the GRE encapsulated packets, the provider ingress Edge C1/C3 decapsulates the outer GRE tunnel header, use the GRE key to map to the pre-defined (by the network controller) Binding SIDs, prepend the Binding SIDs to the packets, and forward its desired paths across the provider VPN. Depending on how the SD-WAN path destination can be reached by the egress PE, the egress PE has different processing procedure: - If the destination of the SD-WAN path is directly attached to the egress VPN PE node, the egress VPN PE decapsulates SR header and forward the packets to SD-WAN path destination node, such as the E2 in the figure above. - If the destination of the SD-WAN path is IP reachable via IPv4 network from the egress VPN PE node, the egress VPN PE node decapsulates SR header and forward the packets to SD-WAN path destination node via its internet facing port to the SD-WAN path destination (i.e. the E2 node in the figure above). - If the SD-WAN path is traversing multiple domains owned by different network operators, the egress PE processing is described in the next session. 4.3. Using UDP Source Port Number to Differentiate Flows [RFC8086] describes how to use GRE-in-UDP source port number as entropy for better ECMP performance. When the remotely attached CPEs is within very close proximity to the PEs, e.g. only one or two hopes away like in LTE access, there is less issue if ECMP put all flows with same traffic classifier into one path. Then, those UDP numbers can also be used as a key to SR PE nodes to map to the appropriate SID to the packets. Same as RFC8086, UDP source port values used as a key for SR PEs to map to appropriate SIDs SHOULD be chosen from the ephemeral port range (49152-65535) [RFC8085]. The GRE-in-UDP encapsulation format contains a UDP header [RFC768] and a GRE header [RFC2890]. The format is shown as follow (presented in bit order): Dunbar, et al. Expires June 18, 2018 [Page 12] Internet-Draft SD-WAN over multiple domains June 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 IPv4 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Prot.=17(UDP) | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SD-WAN Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SR Ingress PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = SIDs key Value | Dest. Port = 4754/4755 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: UDP + GRE Headers in IPv4 Dunbar, et al. Expires June 18, 2018 [Page 13] Internet-Draft SD-WAN over multiple domains June 2018 Here is the GRE Header for IPv6 network, i.e. the SD-WAN Source SD- WAN Destination, and SR PEs are all in IPv6 domain: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 IPv6 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NxtHdr=17(UDP)| Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + SD-WAN Source IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + SR Domain Ingress PE IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = SIDs key value | Dest. Port = 4754/4755 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dunbar, et al. Expires June 18, 2018 [Page 14] Internet-Draft SD-WAN over multiple domains June 2018 | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: GRE+UDP for IPv6 4.4. GRE Header Extension A new protocol type can be added to the GRE header [RFC2890] to make it easier for the SR PE to do the proper actions: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed GRE header will have the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ New protocol type (value to be assigned by IANA): UDP-Key: Using UDP source port value as a Key for SR Ingress PE to map to the appropriate SIDs. GRE-KEY: Using GRE Key value as a key for SR ingress PE to map to the appropriate SIDs Dunbar, et al. Expires June 18, 2018 [Page 15] Internet-Draft SD-WAN over multiple domains June 2018 5. SD-WAN path over multiple SP managed domains The following figure shows a SD-WAN Path E1<->E2 over two SP domains which are interconnected by public internet. Dunbar, et al. Expires June 18, 2018 [Page 16] Internet-Draft SD-WAN over multiple domains June 2018 +------------+ | SDWAN | /-----------/ | Control | / [SDWAN-C]... +---+--------+ / / : | /-----------/ : | SD-WAN Overlay : | /-------------------------------------------/ : | / / : | / [A]-----[E1]***********[E2]--------[Z] / : +---+ / * : / : | | / ******* : / : | | /-----------------------*--------:----------/ : | | /----------/ * .. .. .. .. .. :. : | +-+--------+ / / * : : | | SP-1 | / [SR-C] / * : : | |Control | / : / * : : | +----------+ /------:---/ ***** : : | +----------+ : /---*---*-----------------------/ : : | | SP-1 | : / * * / : : | |Underlay | : / [C1]-[C3]------[C4]-[C6] / : : | +----------+ :/ \ /* / / : : | : \ /--/-*--/ / : : | +----------+ /: \ / * / : : +-+ SP-2 | / :...........[C2] * / : : |Control | /-------------**-----*----------/ : : +----------+ * * * .. .. .. .. ..: : * * : : +------------+ /---*---*---------:-------------/ : | SP-2 | / * * : / : | Underlay | / [D1]-[D4]------[D2]-[D5] / : +------------+ / \ / / / : / \ /--/----/ / : / \ / / : / [D3]..........................: / / /-------------------------------/ Figure 5: SD-WAN path over two different SP domains Dunbar, et al. Expires June 18, 2018 [Page 17] Internet-Draft SD-WAN over multiple domains June 2018 Let's assume that the SP-1 domain's egress node for the SD-WAN path E1<->E2 is C2, which can reach D1 or D4 of SP-2 via public IP network (say IPv4 network). Let's also assume that the optimal route for some flows over SD-WAN path E1<->E2 are C1->C2->D1 and other flows are over C1->C2->D4 (out of the scope of this document on how the path is calculated). If SP-1 is SR enabled, the mechanism described in Section 4 is applicable to the SD-WAN path source node E1 and the SP-1's ingress PE (e.g. C1 or C3 in the figure). However, the processing at egress node might be different depending on how the SP-1's egress edges are connected to the SP-2's ingress edge nodes. 5.1. When Both SP domains support SR There may be three approaches here: 1) Controller installs the entire SID stack at E1, and the SID list contains SID entries belong to both domains. 2) Controller delivers to E1 the SID stack that only for the first domain, but delivers to C6 (egress node of first domain) the binding SID of the second domain. 3) Controller delivers a "Key" to E1, which can be encoded as GRE KEY or represented by the Source UDP port of the GRE encapsulation, for Ingress PE of the first SR Domain to map to its own SID stack as described in Section 4. The first SR Domain will reserve the "Key" through its domain and pass the "Key" to the second SR domain. The second SR Domain Ingress node will use the same method to map the "Key" to its SID stack. 5.2. When SP-2 does not support SR Under this circumstance (which can be caused by SP-2 not supporting SR or not willing to share Binding SIDs to SP-1), if the packets arriving at SP-1 egress node C6 do not have any metadata indicating the types of encrypted payload, C6 does not really have much choice Dunbar, et al. Expires June 18, 2018 [Page 18] Internet-Draft SD-WAN over multiple domains June 2018 other than simply forwarding the packets to E2 via public IP network. This way, the packets may or may not traverse through the SP-2 domain. If the distance between C6 and E2 is far, the quality of service can be unpredictable. 5.3. When SP-1 and SP-2 don't want to share network information If SP-1's ingress node C1 can include the GRE KEY it receives from E1 in the data packets' SR header, the SP-1's egress node can map the Key to the SP-2's Ingress node and encapsulate the data packet in a new GRE header destined towards the SP-2's Ingress node. Then the SP-2's Ingress node can follow the procedure described in the Section 4 to forward the data packets across its domain. If the first SR Domain does not support adding metadata to carry the "key" through its domain, the controller can deliver the "key" to SP-1's egress node the same time as it delivers the key to E1, knowing the SD-WAN path will need to traverse two domains with the second one does support SR but the two SPs don't want to exchange network information. 5.4. TLV to pass Metadata through SRv6 Domain If SP-1 is SRv6 based, the ingress node C1 can append a TLV to the end of the SR Header [SRv6-SRH] to carry the KEY it receives from E1[Dc1]. The SP-1 egress node C6 can get the mapping between the KEYs and the Node-IDs (or Addresses) of the next domain's ingress edge node (i.e. D1 or D4 in the figure 3 above) from its network controller ahead of time. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID (4 octets) from the GRE tunnel remote ingress node | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional // | Node ID or address for the ingress node Next domain // | Variable length (0~32 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dunbar, et al. Expires June 18, 2018 [Page 19] Internet-Draft SD-WAN over multiple domains June 2018 TYPE: (to be assigned by IANA) is to indicate the TLV is for carrying the flow identifier of the packet encoded by the SD-WAN source node. Upon receiving the packet, the egress node (C6) can - find the Node-ID (or the address) for the next domain's ingress node, - construct a GRE header with the Key received from the TLV above and the destination address from the mapping given by the controller, - encapsulate the GRE header to the data packet (which has decapsulated SR header), - and forward the packet to the public internet. 6. Security Considerations Remotely attached CPEs might brought the following security risks: 1) Potential DDoS attack to the PEs with ports facing internet. I.e. the PE resourced being attacked by unwanted traffic. 2) Potential risk of provider VPN network bandwidth being stolen by the entities who spoofed the addresses of SD-WAN end nodes. To mitigate security risk of 1) above, it is absolutely necessary for PEs which accept remotely attached CPEs or simply have ports facing internet to enable Anti-DDoS feature to prevent major DDoS attack to those PEs. To mitigate the security risk of 2) above, RFC7510 defines the use of DTLS to authenticate and encrypt the RFC7510 encapsulation. Dunbar, et al. Expires June 18, 2018 [Page 20] Internet-Draft SD-WAN over multiple domains June 2018 However, for the scenario of SD-WAN source node being remotely attached to PEs, using the method recommended by RFC7510 means the source node has to perform DTLS on top of the IPSec encryption between SD-WAN end points E1<->E2. This can be too processing heavy for the SD-WAN end nodes. In addition, if there are many SD-WAN flows to traverse through the ingress PE (e.g. C1, C2, C4 in the figure 1 above), heavy processing is required on the ingress PEs. Since the payload between E2<->E2 is already encrypted, the confidentiality of the payload is already ensured. The network operators need to balance between how much they can tolerant some percentage of bandwidth being stolen and how much extra cost they are willing to pay for completely prevent any unpaid traffic traversing through its VPN networks. For operators who opt for lower cost ingress PEs and CPEs, but can tolerant some percentage of bandwidth being used by unpaid subscribers, a simple approach can be considered: - Embed a key in the packets, which can be changed periodically, like the digital signature used by a certificate authority or certification authority (CA). - The key can be encoded in the GRE Key field between SD-WAN end node and Ingress PE. Since GRE has 24 bits, some fixed bits can be used to represent the signature of paid subscribers. 7. IANA Considerations This document requires new protocol type: Protocol type to be added to GRE header: SR_Route 8. References 8.1. Normative References [RFC2890] G. Dommety "Key and Sequence Number Extensions to GRE". Sep. 2000. Dunbar, et al. Expires June 18, 2018 [Page 21] Internet-Draft SD-WAN over multiple domains June 2018 8.2. Informative References [RFC2735] B. Fox, et al "NHRP Support for Virtual Private networks". Dec. 1999. [RFC8192] S. Hares, et al "Interface to Network Security Functions (I2NSF) Problem Statement and Use Cases", July 2017 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, storage, distribution and enforcement of policies for network security", Nov 2007. [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Feb 2011. [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", Feb 2006 [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", Sept 2006. [SR-SD-WAN] D. Dukes, et al, "SR for SDWAN: VPN with Underlay SLA", draft-dukes-sr-for-sdwan-00, in progress, Oct 2017 [SRv6-SRH] S. Previdi, et al, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-13, in progress, April 2018. [MPLS-SR] A. Bashandy, et al, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-13, in progress, April 2018. [RFC7510] X. Xu, et al, "Encapsulating MPLS in UDP", April 2015. [RFC8086] L. Yong, et al, "GRE-in-UDP Encapsulation", March 2017. [MEF-Cloud] "Cloud Services Architecture Technical Specification", Work in progress, April 2018 Dunbar, et al. Expires June 18, 2018 [Page 22] Internet-Draft SD-WAN over multiple domains June 2018 9. Acknowledgments Many thanks to Dean Cheng and Jim Guichard for the discussion and contributions. Dunbar, et al. Expires June 18, 2018 [Page 23] Internet-Draft SD-WAN over multiple domains June 2018 Authors' Addresses Linda Dunbar Huawei Email: Linda.Dunbar@huawei.com Mehmet Toy Verizon One Verizon Way Basking Ridge, NJ 07920 Email: mehmet.toy@verizon.com Dunbar, et al. Expires June 18, 2018 [Page 24]