idnits 2.17.1 draft-dunbar-sr-sdwan-over-hybrid-networks-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 222: '... End.IPsecV4 SID MUST be encoded prece...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2021) is 1067 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SDWAN-Edge-Discovery' is mentioned on line 266, but not defined == Missing Reference: 'RFC3948' is mentioned on line 342, but not defined == Missing Reference: 'RFC8986' is mentioned on line 312, but not defined == Unused Reference: 'RFC2890' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'RFC6071' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC4664' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'SR-SDWAN' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'SRv6-SRH' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'MPLS-SR' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC7510' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC8086' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'BGP-SDWAN-Usage' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'SDWAN-Net2Cloud' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'MEF-Cloud' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'SDWAN-BGP-USAGE' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'BGP-IPSEC-Discover' is defined on line 480, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 2890 == Outdated reference: A later version (-01) exists of draft-dukes-sr-for-sdwan-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-13 == Outdated reference: A later version (-08) exists of draft-dunbar-bess-bgp-sdwan-usage-01 == Outdated reference: A later version (-39) exists of draft-ietf-rtgwg-net2cloud-problem-statement-04 -- Duplicate reference: draft-dunbar-bess-bgp-sdwan-usage, mentioned in 'SDWAN-BGP-USAGE', was also mentioned in 'BGP-SDWAN-Usage'. == Outdated reference: A later version (-04) exists of draft-dunbar-idr-sdwan-edge-discovery-00 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-19 Summary: 2 errors (**), 0 flaws (~~), 26 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTG Working Group L. Dunbar 2 Internet Draft Futurewei 3 Intended status: Standard Mehmet Toy 4 Expires: October 18, 2021 Verizon 5 May 18, 2021 7 SRv6 across SDWAN paths 8 draft-dunbar-sr-sdwan-over-hybrid-networks-07 10 Abstract 12 This document describes the mechanism of steering packets across 13 SDWAN segments based on the metadata carried by the SRv6 packets. 15 Some of the SDWAN segments are untrusted networks, and some are 16 private networks. The goal is to achieve the optimal E2E quality. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on April 23, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Conventions used in this document..............................3 60 3.1. SDWAN as Last Mile for Accessing Cloud Services...........4 61 3.2. SRv6 Domain separated by SDWAN............................4 62 4.2. End.SDWANv4...............................................5 63 4.3. End.IPsecV4...............................................6 64 4.4. End.IPsecV6...............................................8 65 7. IANA Considerations...........................................10 66 8. Security Considerations.......................................10 67 9. Contributors..................................................11 68 10. References...................................................11 69 10.1. Normative References....................................11 70 10.2. Informative References..................................11 71 11. Acknowledgments..............................................12 72 Authors' Addresses...............................................14 74 1. Introduction 76 SRv6 has many advantages. This document defines using the metadata 77 encoded in the SRH for SRv6 packets to cross an SDWAN network. 79 SDWAN is about pooling WAN bandwidth from multiple service providers 80 to get better WAN bandwidth management, visibility & control. There 81 could be multiple underlay paths between a pair of edge nodes, 82 potentially managed by different service providers, such as MPLS 83 paths and paths over the public internet. 85 This document describes the SRv6 SRH metadata encoding for the SRv6 86 packets to cross SDWAN for the scenarios described by the [BGP- 87 SDWAN-Usage]: 89 1) Homogeneous WAN, with edge nodes encrypting all traffic over 90 the WAN to other edge nodes, regardless of whether the underlay is 91 private or public. 93 2) Hybrid WAN Underlay, in which traffic over IP VPN is forwarded 94 natively without IPsec protection and carried by IPsec tunnels 95 when forwarded over the public Internet. 97 3) Private VPN PE-based SDWAN, which is about existing VPN (e.g., 98 EVPN or IPVPN) being expanded by the additional ports facing the 99 untrusted Internet for PEs to offload low-priority traffic when 100 the VPN paths are congested. 102 2. Conventions used in this document 104 BSID - Binding SID 106 DC - Data Center 108 DN - Data Network (5G) 110 SD-WAN - Software-Defined Wide Area Network 112 SID - Segment Identifier 114 SR - Segment Routing 116 3. Use Cases 117 3.1. SDWAN as Last Mile for Accessing Cloud Services 119 Digital Transformation is propelling more and more enterprises to 120 utilize the rich Cloud services, such as virtual machines, remote 121 databases, analytic tools, machine learning APIs, etc. Cloud 122 services enable enterprises to run their workloads/Apps at locations 123 geographically close to their end-users and provide advanced 124 analytic tools and APIs for the applications and data hosted in the 125 Clouds. 127 The wide availability at any location, which is one of the 128 advantages of Cloud Services, can impose challenges to connect 129 enterprises' on-premises applications with their Cloud services 130 securely. The SRv6 domain that interconnect the enterprises' 131 locations may not reach the Cloud DCs where the Cloud services are 132 hosted. SDWAN is positioned as a flexible choice as the last mile to 133 bridge the enterprise's SR domain to its desired Cloud services. 135 +--------+ +----+ +----- 136 / SRv6 \ / \ /Cloud DC 137 a--> PE1 domain SE1 SDWAN SE2-cGW--> b 138 \ / \ / \ 139 +--------+ +----+ +----- 140 Figure 1: SDWAN as last mile 142 3.2. SRv6 Domain separated by SDWAN 144 SRv6 deployment is incremental. Some services do need to cross 145 segments that do not support SRv6, as shown in the Figure below. 147 +--------+ +----+ +-------+ 148 / SRv6 \ / \ / SRv6 \ 149 a--> PE1 domain 1 SE1 SDWAN SE2 domain 2 PE4 --> b 150 \ / \ / \ / 151 +--------+ +----+ +-------+ 152 Figure 2: SDWAN connecting two SRv6 domains 154 4. SDWAN Path Programming in SRv6 156 An SDWAN path between two edge nodes can be an IPsec tunnel, an MPLS 157 path, an IPv4, or an IPv6 path over a private IP network. For an 158 SRv6 packet to cross an SDWAN domain, the edge node, such as SE1 & 159 SE2 in Figure 1 & Figure 2, can make the local decision in choosing 160 an SDWAN path between the two edge nodes. Alternatively, the 161 controller can instruct the SR domain head node, like the PE1 in 162 Figure 2, to encode the metadata in the SRH that can indicate the 163 SDWAN path for the SDWAN ingress node SE1. 165 4.2. End.SDWANv4 167 End.SDWANv4 is an End function for the receiving node to locally 168 select an SDWAN path destined towards the IPv4 destination address 169 encoded in the SRH. 171 The SDWAN tunnel information are encoded in another 128-bit value 172 following the SID or SRH TLVs. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | IPv4 SDWAN Tunnel Information | 178 ~ ~ 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | SRv6 End.SDWANv4 SID | 181 ~ ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 3. IPv4 SDWAN Sub-Path Encoding in SRH 185 The SDWAN Tunnel Information encoding follows the format from 186 [SDWAN-Edge-Discovery]: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type | Reserved | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | IPv4 SDWAN tunnel Src Address | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | IPv4 SDWAN tunnel Dest address | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 ~ Inner encapsulation Sub-TLV | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 4. SDWAN Tunnel Encoding 201 Type = SDWAN-Hybrid: for the end node to locally select an SDWAN 202 path with inner encapsulation type to carry the packet. 204 The inner encapsulation Sub-TLV can be GRE Sub-TLV or VxLAN Sub-TLV 205 as specified in the [Tunnel-Encap]. 207 For SRH to indicate exact SDWAN MPLS path to forward the packet, the 208 SRH encoding should follow the encoding described in the [SRv6- 209 traverse-MPLS]. 211 This document's Section 4.2 and 4.3 describes the encoding for SR 212 head node to indicate the IPsec IPv4 or IPv6 tunnels in SRH, 213 respectively. 215 4.3. End.IPsecV4 217 End.IPsecV4 is an End function with IPv4 IPsec tunnel instantiation, 218 i.e., instructing the receiving node to encapsulate the packet with 219 an IPsec tunnel and forward to the IPv4 destination. The IPsec 220 tunnel information can be encoded following the SID or SRH TLVs. 222 An End.IPsecV4 SID MUST be encoded preceding the IPsec tunnel 223 information encapsulation. 225 The SRv6 path of crossing IPv4 IPsec tunnel is called IPv4 IPsec 226 sub-path. The IPsec tunnel attributes are encoded by an END.IPsecV4 227 SID and the following IPv4 IPsec tunnel information encapsulation as 228 shown in the following figure. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | IPv4 IPsec Tunnel Information | 234 ~ ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | SRv6 End.IPsecV4 SID | 237 ~ ~ 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 5. IPv4 IPsec Sub-Path Encoding in SRH 241 The IPv4 IPsec tunnel should be ESP Tunnel mode. For ESP Tunnel 242 mode, there can be additional inner encapsulation. SDWAN edge nodes 243 can also encapsulate the ESP IPsec packet inside UDP for NAT 244 traversal and better ECMP [RFC3948]. 246 Here is the IPsec tunnel information encoding: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Reserved | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | IPv4 SDWAN tunnel Src Address | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | IPv4 SDWAN tunnel Dest Address | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | IPsec SA Sub-TLV | 258 ~ ~ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ~ Inner encapsulation Sub-TLV | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 6. IPv4 IPsec Tunnel Encoding 264 Type = IPv4 IPsec 266 The IPsec SA sub-TLV, specified by [SDWAN-Edge-Discovery], lists the 267 identifiers of the pre-established IPsec tunnels between the SDWAN 268 Src Address and the Dest Address. One or multiple identifiers are 269 listed in the IPsec-SA-ID Sub-TLV for the IPsec tunnels between the 270 Source and the Destination addresses. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | subTLV-Type = IPsec-SA-ID | Length = | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | IPsec SA Identifier = 1 | 278 +---------------------------------------------------------------+ 279 | IPsec SA Identifier = 2 | 280 ~ ~ 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 7. IPsec SA Sub-TLV 284 The inner encapsulation Sub-TLV can be GRE Sub-TLV or VxLAN Sub-TLV 285 as specified in the [Tunnel-Encap]. 287 When node N receives a packet whose IPv4 DA is S and S is a local 288 End.IPsecV4 SID, the line S15 - S16 from the End processing 289 [RFC8986] is replaced by the following: 291 S15. Encapsulates the SRv6 packet with a new IPsec tunnel 292 encapsulation bound to the End.IPsecV4 SID S. 294 S16. Submit the IPsec encapsulated packet to the egress IPv4 FIB 295 lookup for transmission to the IPsec end point IPv4 296 destination. 298 S17. } 300 4.4. End.IPsecV6 302 End.IPsecV6 is an End function with IPv6 IPsec tunnel instantiation, 303 i.e., instructing the receiving node to encapsulate the packet with 304 IPsec tunnel and forwarded to the IPv6 destination. 306 End.IPsecV6 behavior is very much like End.IPsecV4 except the 307 destination and source address of the IPsec tunnel are IPv6 308 addresses. 310 When node N receives a packet whose IPv6 DA is S and S is a local 311 End.IPsecV6 SID, the line S15 - S16 from the End processing 312 [RFC8986] is replaced by the following: 314 S15. Encapsulates the SRv6 packet with a new IPsec tunnel 315 encapsulation bound to the End.IPsecV6 SID S. 317 S16. Submit the IPsec encapsulated packet to the egress IPv6 FIB 318 lookup for transmission to the IPsec end point IPv6 319 destination. 321 S17. } 323 The SRv6 path of crossing IPv6 IPsec tunnel is called IPv6 IPsec 324 sub-path. The IPsec tunnel attributes are encoded by an END.IPsecV6 325 SID and the following IPv6 IPsec tunnel information encapsulation as 326 shown in the following figure. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | IPv6 IPsec Tunnel Information | 332 ~ ~ 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | SRv6 End.IPsecV6 SID | 335 ~ ~ 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 8. IPv6 IPsec Sub-Path Encoding in SRH 339 The IPv6 IPsec tunnel can be ESP Transport mode or Tunnel mode. For 340 ESP Tunnel mode, there can be additional inner encapsulation. SDWAN 341 edge nodes can also encapsulate the ESP IPsec packet inside UDP for 342 NAT traversal and better ECMP [RFC3948]. 344 Here is the IPv6 IPsec tunnel information encoding: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Reserved | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | IPv6 SDWAN tunnel Src Address | 352 ~ ~ 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | IPv6 SDWAN tunnel Dest Address | 355 ~ ~ 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | IPsec SA Sub-TLV | 358 ~ ~ 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 ~ Inner encapsulation Sub-TLV | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 9. IPv6 IPsec Tunnel Encoding 364 Type = IPv6 IPsec 366 5. Packets from SDWAN to SRv6 Domain 368 For the SDWAN as Last Mile use case illustrated in Figure 1, packets 369 from "b" -> "a" traverse from SDWAN domain to SRv6 domain. A Binding 370 SID needs to be inserted by the SDWAN Edge node SE2 so that the SR 371 domain ingress can replace the Binding SID with a list of SIDs 372 across the SRv6 domain. 374 For an SDWAN path over an IPsec Tunnel, the Binding SID is encoded 375 in the GRE key field for the GRE inner encapsulation or encoded in 376 the VNID field for the VxLAN inner encapsulation. 378 For an SDWAN path over an MPLS underlay, the last MPLS label is used 379 as the Binding SID for the SRv6 edge node to convert to a list of 380 SRv6 SIDs across the SRv6 domain. 382 Controller---+ 383 | |Binding SID Z 384 | | 385 +--------+ | +----+ | +----- 386 / SRv6 \ v/ \ v /Cloud DC 387 a<-- PE1 domain SE1 SDWAN SE2-cGW<-- b 388 \ / \ / \ 389 +--------+ +----+ +----- 390 {Z} 391 | 392 v 393 {M, N, O} {Z} 395 Figure 10: Binding SID inserted by SDWAN Edge 397 For the SRv6 domain separated by SDWAN use case illustrated in 398 Figure 2, the End.SDWANv4/v6 or End.IPsecv4/v6 SID should not be the 399 last SID in the SRH. After the SDWAN egress node decapsulates the 400 SDWAN header (IPsec header or MPLS header), the remaining SIDs in 401 the packet's SRH can forward the packet across the remaining SRv6 402 domain. 404 6. Illustration 406 To Be Added 408 7. IANA Considerations 410 TBD. 412 8. Security Considerations 414 Allowing traffic from untrusted network brings the following 415 security risks: 416 1) Potential DDoS attack to the PEs with ports facing the untrusted 417 network. I.e. the PE resource being attacked by unwanted traffic. 418 2) Potential risk of provider VPN network bandwidth being stolen by 419 the entities who spoofed the addresses of SDWAN end nodes. 421 To mitigate security risk of 1) above, it is necessary for ports facing 422 internet to enable Anti-DDoS feature to prevent major DDoS attack to 423 those PEs. 424 To mitigate the security risk of 2) above, RFC7510 defines the use of 425 DTLS to authenticate and encrypt the RFC7510 encapsulation. 427 9. Contributors 429 10. References 431 10.1. Normative References 433 [RFC2890] G. Dommety "Key and Sequence Number Extensions to GRE". 434 Sep. 2000. 436 10.2. Informative References 438 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 439 storage, distribution and enforcement of policies for 440 network security", Nov 2007. 442 [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and 443 Internet Key Exchange (IKE) Document Roadmap", Feb 2011. 445 [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 446 Networks (VPNs)", Feb 2006 448 [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual 449 Private Networks (L2VPNs)", Sept 2006. 451 [SR-SDWAN] D. Dukes, et al, "SR for SDWAN: VPN with Underlay SLA", 452 draft-dukes-sr-for-sdwan-00, in progress, Oct 2017 454 [SRv6-SRH] S. Previdi, et al, "IPv6 Segment Routing Header (SRH)", 455 draft-ietf-6man-segment-routing-header-13, in progress, 456 April 2018. 458 [MPLS-SR] A. Bashandy, et al, "Segment Routing with MPLS data 459 plane", draft-ietf-spring-segment-routing-mpls-13, in 460 progress, April 2018. 462 [RFC7510] X. Xu, et al, "Encapsulating MPLS in UDP", April 2015. 464 [RFC8086] L. Yong, et al, "GRE-in-UDP Encapsulation", March 2017. 466 [BGP-SDWAN-Usage] L. Dunbar, et al, "BGP Usage for SDWAN Overlay 467 Networks, draft-dunbar-bess-bgp-sdwan-usage-01, in 468 progress, July 2019. 470 [SDWAN-Net2Cloud] L. Dunbar, et al, "Dynamic Networks to Hybrid 471 Cloud DCs Problem Statement", draft-ietf-rtgwg-net2cloud- 472 problem-statement-04, in progress, July 2019. 474 [MEF-Cloud] "Cloud Services Architecture Technical Specification", 475 Work in progress, April 2018 477 [SDWAN-BGP-USAGE] L. Dunber, et al, "BGP Usage for SDWAN Overlay 478 Networks", draft-dunbar-bess-bgp-sdwan-usage-08, January 2021 480 [BGP-IPSEC-Discover] L. Dunber, et al, "BGP UPDATE for SDWAN Edge 481 Discovery", draft-dunbar-idr-sdwan-edge-discovery-00, January 2021 483 [Tunnel-Encap] E. Rosen, et al "The BGP Tunnel Encapsulation 484 Attribute", draft-ietf-idr-tunnel-encaps-19, March 2021. 486 11. Acknowledgments 488 TBD. 490 This document was prepared using 2-Word-v2.0.template.dot. 492 Authors' Addresses 494 Linda Dunbar 495 Futurewei 496 2330 Central Expressway 497 Santa Clara, CA 95050 498 Email: linda.dunbar@futurewei.com 500 Mehmet Toy 501 Verizon 502 One Verizon Way 503 Basking Ridge, NJ 07920 504 Email: mehmet.toy@verizon.com