idnits 2.17.00 (12 Aug 2021) /tmp/idnits16691/draft-ietf-rtgwg-net2cloud-gap-analysis-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2019) is 1067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2332' is mentioned on line 145, but not defined == Missing Reference: 'BGP-SDWAN-PORT' is mentioned on line 179, but not defined == Missing Reference: 'SDWAN-Port' is mentioned on line 238, but not defined == Missing Reference: 'SECURE-EVPN' is mentioned on line 351, but not defined == Missing Reference: 'Tunnel-Encap' is mentioned on line 322, but not defined == Missing Reference: 'RFC4364' is mentioned on line 332, but not defined == Missing Reference: 'MEF-Cloud' is mentioned on line 409, but not defined == Missing Reference: 'RFC6325' is mentioned on line 553, but not defined == Missing Reference: 'Net2Cloud-problem' is mentioned on line 583, but not defined == Unused Reference: 'RFC2119' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 637, but no explicit reference was found in the text -- No information found for draft-dunbar-idr-sdwan-framework - is the name correct? == Outdated reference: A later version (-01) exists of draft-rosen-bess-secure-l3vpn-00 == Outdated reference: A later version (-07) exists of draft-dm-net2cloud-problem-statement-02 Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft A. Malis 3 Intended status: Informational Futurewei 4 Expires: December 19, 2019 C. Jacquenet 5 Orange 6 June 19, 2019 8 Gap Analysis of Dynamic Networks to Hybrid Cloud DCs 9 draft-ietf-rtgwg-net2cloud-gap-analysis-02 11 Abstract 13 This document analyzes the technological gaps when using SD-WAN to 14 dynamically interconnect workloads and applications hosted in 15 rd various 3 party cloud data centers. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on December 19, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Conventions used in this document..............................3 59 3. Gap Analysis of C-PEs WAN Port Registration....................4 60 4. Aggregating VPN paths and Internet paths.......................5 61 4.1. Key Control Plane Components of SD-WAN....................6 62 4.2. Using BGP Tunnel-Encap....................................7 63 4.3. SECURE-L3VPN/EVPN.........................................9 64 4.4. Preventing attacks from Internet-facing ports............10 65 5. CPEs not directly connected to VPN PEs........................10 66 5.1. Floating PEs to connect to Remote CPEs...................13 67 5.2. NAT Traversal............................................13 68 5.3. Complexity of using BGP between PEs and remote CPEs via 69 Internet......................................................13 70 5.4. Designated Forwarder to the remote edges.................14 71 5.5. Traffic Path Management..................................15 72 6. Manageability Considerations..................................15 73 7. Security Considerations.......................................15 74 8. IANA Considerations...........................................16 75 9. References....................................................16 76 9.1. Normative References.....................................16 77 9.2. Informative References...................................16 78 10. Acknowledgments..............................................17 80 1. Introduction 82 [Net2Cloud-Problem] describes the problems that enterprises face 83 today in transitioning their IT infrastructure to support digital 84 economy, such as connecting enterprises' branch offices to dynamic 85 workloads in different Cloud DCs. 87 This document analyzes the technological gaps to interconnect 88 dynamic workloads & apps hosted in cloud data centers that the 89 enterprise's VPN service provider may not own/operate or may be 90 unable to provide the enterprise with the required connectivity to 91 access such locations. When VPN service providers have insufficient 92 bandwidth to reach a location, SD-WAN techniques can be used to 93 aggregate bandwidth of multiple networks, such as MPLS VPNs or the 94 Public Internet to achieve better performance. This document 95 primarily focuses on the technological gaps raised by using SD-WAN 96 techniques to connect enterprise premises to cloud data centers 97 operated by third parties. 99 For the sake of readability, a SD-WAN edge, a SD-WAN endpoint, C-PE, 100 or CPE are used interchangeably throughout this document. However, 101 each term has some minor emphasis, especially when used in other 102 related documents: 104 . SD-WAN Edge: could include multiple devices (virtual or 105 physical); 106 . SD-WAN endpoint: to refer to a WAN port of SD-WAN devices or a 107 single SD-WAN device; 108 . C-PE: more for provider owned SD-WAN edge, e.g. for SECURE- 109 EVPN's PE based VPN, when PE is the edge node of SD-WAN; 110 . CPE: more for enterprise owned SD-WAN edge. 112 2. Conventions used in this document 114 Cloud DC: Third party Data Centers that usually host applications 115 and workload owned by different organizations or 116 tenants. 118 Controller: Used interchangeably with SD-WAN controller to manage 119 SD-WAN overlay path creation/deletion and monitor the 120 path conditions between sites. 122 CPE-Based VPN: Virtual Private Network designed and deployed from 123 CPEs. This is to differentiate from most commonly used 124 PE-based VPNs a la RFC 4364. 126 OnPrem: On Premises data centers and branch offices 128 SD-WAN: Software Defined Wide Area Network, "SD-WAN" refers to 129 the solutions of pooling WAN bandwidth from multiple 130 underlay networks to get better WAN bandwidth 131 management, visibility & control. When the underlay is a 132 private network, traffic may be forwarded without any 133 additional encryption; when the underlay networks are 134 public, such as the Internet, some traffic needs to be 135 encrypted when passing through (depending on user- 136 provided policies). 138 3. Gap Analysis of C-PEs WAN Port Registration 140 SD-WAN technology has emerged as means to dynamically and securely 141 interconnect the OnPrem branches with the workloads instantiated in 142 Cloud DCs that do not have direct connectivity to BGP/MPLS VPN PEs 143 or have very limited bandwidth. 145 Some SD-WAN networks use the NHRP protocol [RFC2332] to register WAN 146 ports of SD-WAN edges with a "Controller" (or NHRP server), which 147 then has the ability to map a private VPN address to a public IP 148 address of the destination node. DSVPN [DSVPN] or DMVPN [DMVPN] are 149 used to establish tunnels between WAN ports of SD-WAN edge nodes. 151 NHRP was originally intended for ATM address resolution, and as a 152 result, it misses many attributes that are necessary for dynamic 153 endpoint C-PE registration to the controller, such as: 155 - Interworking with the MPLS VPN control plane. A SD-WAN edge can 156 have some ports facing the MPLS VPN network over which packets can 157 be forwarded without any encryption and some ports facing the 158 public Internet over which sensitive traffic needs to be encrypted 159 before being sent. 161 - Scalability: NHRP/DSVPN/DMVPN works fine with small numbers of 162 edge nodes. When a network has more than 100 nodes, these 163 protocols do not scale well. 164 - NHRP does not have the IPsec attributes, which are needed for 165 peers to build Security Associations over the public internet. 166 - NHRP messages do not have any field to encode the C-PE supported 167 encapsulation types, such as IPsec-GRE or IPsec-VxLAN. 168 - NHRP messages do not have any field to encode C-PE Location 169 identifiers, such as Site Identifier, System ID, and/or Port ID. 170 - NHRP messages do not have any field to describe the gateway(s) to 171 which the C-PE is attached. When a C-PE is instantiated in a Cloud 172 DC, it is desirable for C-PE's owner to be informed of how/where 173 the C-PE is attached. 174 - NHRP messages do not have any field to describe C-PE's NAT 175 properties if the C-PE is using private addresses, such as the NAT 176 type, Private address, Public address, Private port, Public port, 177 etc. 179 [BGP-SDWAN-PORT] describes how SD-WAN edge nodes use BGP to register 180 their WAN ports properties to the SD-WAN controller, which then 181 propagates the information to other SD-WAN edge nodes that are 182 authenticated and authorized to communicate with them. 184 4. Aggregating VPN paths and Internet paths 186 Most likely, enterprises (especially the largest ones) already have 187 their CPEs interconnected by providers' VPNs, based upon VPN 188 techniques such as EVPN, L2VPN, or L3VPN. The VPN can be PE-based or 189 CPE-based. The commonly used PE-based VPNs have CPE directly 190 attached to PEs, therefore the communication between CPEs and PEs is 191 considered as secure. MP-BGP is used to learn & distribute routes 192 among CPEs, even though sometimes routes among CPEs are statically 193 configured on the CPEs. 195 To aggregate paths over the Internet and paths over the VPN, the C- 196 PEs need to have some WAN ports connected to the PEs of the VPNs and 197 other WAN ports connected to the Internet. It is necessary for the 198 CPEs to use a protocol so that they can register the WAN port 199 properties with their SD-WAN Controller(s): this information 200 conditions the establishment and the maintenance of IPsec SA 201 associations among relevant C-PEs. 203 When using NHRP for registration purposes, C-PEs need to run two 204 separate control planes: EVPN&BGP for CPE-based VPNs, and NHRP & 205 DSVPN/DMVPN for ports connected to the Internet. Two separate 206 control planes not only add complexity to C-PEs, but also increase 207 operational cost. 208 +---+ 209 +--------------|RR |----------+ 210 / Untrusted +-+-+ \ 211 / \ 212 / \ 213 +----+ +---------+ packets encrypted over +------+ +----+ 214 | TN3|--| A1-----+ Untrusted +------ B1 |--| TN1| 215 +----+ | C-PE A2-\ | C-PE | +----+ 216 +----+ | A A3--+--+ +---+---B2 B | +----+ 217 | TN2|--| | |PE+--------------+PE |---B3 |--| TN3| 218 +----+ +---------+ +--+ trusted +---+ +------+ +----+ 219 | WAN | 220 +----+ +---------+ +--+ packets +---+ +------+ +----+ 221 | TN1|--| C1--|PE| go natively |PE |-- D1 |--| TN1| 222 +----+ | C-PE C2--+--+ without encry+---+ | C-PE | +----+ 223 | C | +--------------+ | D | 224 | | | | 225 +----+ | C3--| without encrypt over | | +----+ 226 | TN2|--| C4--+---- Untrusted --+------D2 |--| TN2| 227 +----+ +---------+ +------+ +----+ 228 Figure 1: CPEs interconnected by VPN paths and Internet Paths 230 4.1. Key Control Plane Components of SD-WAN 232 As described in [BGP-SDWAN-Usage], the SD-WAN Overlay Control Plane 233 has three distinct properties: 235 - SD-WAN node's WAN Port Property registration to the SD-WAN 236 Controller. 237 o To inform the SD-WAN controller and authorized peers of 238 the WAN port properties of the C-PE [SDWAN-Port]. When the 239 WAN ports are assigned private addresses, this step can 240 register the type of NAT that translates private addresses 241 into public ones. 243 - Controller facilitated IPsec SA management and NAT information 244 distribution 245 o It is for SD-WAN controller to facilitate or manage the 246 IPsec configuration and peer authentication for all IPsec 247 tunnels terminated at the SD-WAN nodes. 249 - Establishing and Managing the topology and reachability for 250 services attached to the client ports of SD-WAN nodes. 251 o This is for the overlay layer's route distribution, so 252 that a C-PE can populate its overlay routing table with 253 entries that identify the next hop for reaching a specific 254 route/service attached to remote nodes. [SECURE-EVPN] 255 describes EVPN and other options. 257 4.2. Using BGP Tunnel-Encap 259 RFC5512 and [Tunnel-Encap] describe methods to construct BGP UPDATE 260 messages that advertise endpoints' tunnel encapsulation capability 261 and the respective attached client routes, so that the peers that 262 receive of the BGP UPDATE can establish appropriate tunnels with the 263 endpoints for the aforementioined routes. RFC5512 uses the Endpoint 264 Address subTLV, whereas [Tunnel-Encap] uses Remote Endpoint Address 265 subTLV to indicates address of the tunnel endpoint which can be an 266 IPv4 or an IPv6 address. There are Tunnel Encapsulation attribute 267 subTLVs to indicate the supported encapsulation types, such as 268 L2TPv3, GRE, VxLAN, IP-in-IP, etc. 270 [Tunnel-Encap] removed SAFI =7 (which was specified by RFC5512) for 271 distributing encapsulation tunnel information. [Tunnel-Encap] 272 requires that tunnels need to be associated with routes. 274 There is also the Color sub-TLV to describe customer-specified 275 information about the tunnels (which can be creatively used for SD- 276 WAN). 278 Here are some of the gaps using [Tunnel-Encap] to control SD-WAN 279 Tunnels: 281 - [Tunnel-Encap] doesn't have the functionality that would help the 282 C-PE to register its WAN Port properties. 283 - A SD-WAN tunnel, e.g. IPsec-based, requires a negotiation between 284 the tunnel's end points for supported encryption algorithms and 285 tunnel types before it can be properly established, whereas 286 [Tunnel-Encap] only allow the announcement of one endpoint's 287 supported encapsulation capabilities for specific attached routes 288 and no negotiation between tunnel end points is needed. The 289 establishment of a SD-WAN tunnel can fail, e.g., in case the two 290 endpoints support different encryption algorithms. That is why a 291 SD-WAN tunnel needs to be established and maintained independently 292 from advertising client routes attached to the edge node. 293 - [Tunnel-Encap] requires all tunnels updates are associated with 294 routes. There can be many client routes associated with the SD-WAN 295 IPsec tunnel between two C-PEs' WAN ports; the corresponding 296 destination prefixes (as announced by the aforementioned routes) 297 may also be reached through the VPN underlay without any 298 encryption. A more realistic approach to separate SD-WAN tunnel 299 management from client routes association with the SD-WAN tunnels. 300 - When SD-WAN tunnel and clients routes are separate, the SD-WAN 301 Tunnel establishment may not have routes associated. 302 There is a suggestion on using a "Fake Route" for a SD-WAN node to 303 use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points 304 properties. However, using "Fake Route" can raise some design 305 complexity for large SD-WAN networks with many tunnels. For 306 example, for a SD-WAN network with hundreds of nodes, with each 307 node having many ports & many endpoints to establish SD-WAN 308 tunnels with their corresponding peers, the node would need as 309 many "fake addresses". For large SD-WAN networks (such as those 310 comprised of more than 10000 nodes), each node might need 10's 311 thousands of "fake addresses", which is very difficult to manage 312 and requires lots of configuration tasks to get the nodes properly 313 set up. 314 - [Tunnel-Encap] does not have any field to carry detailed 315 information about the remote C-PE, such as Site-ID, System-ID, 316 Port-ID 317 - [Tunnel-Encap] Does not have any field to carry IPsec attributes 318 for the SD-WAN edge nodes to establish IPsec Security Associations 319 with others. It does not have any proper way for two peer CPEs to 320 negotiate IPsec keys either, based on the configuration sent by 321 the Controller. 322 - [Tunnel-Encap] does not have any field to indicate the UDP NAT 323 private address <-> public address mapping 324 - C-PEs tend to communicate with a subset of the other C-PEs, not 325 all the C-PEs need to be connected through a mesh topology. 326 Without any BGP extension, many nodes can get dumped with too much 327 information coming from other nodes that they never need to 328 communicate with. 330 4.3. SECURE-L3VPN/EVPN 332 [SECURE-L3VPN] describes how to extend the BGP/MPLS VPN [RFC4364] 333 capabilities to allow some PEs to connect to other PEs via public 334 networks. [SECURE-L3VPN] introduces the concept of Red Interface & 335 Black Interface used by PEs, where the RED interfaces are used to 336 forward traffic into the VPN, and the Black Interfaces are used 337 between WAN ports through which only IPsec-protected packets are 338 forwarded to the Internet or to other backbone network thereby 339 eliminating the need for MPLS transport in the backbone. 341 [SECURE-L3VPN] assumes PEs using MPLS over IPsec when sending 342 traffic through the Black Interfaces. 344 [SECURE-EVPN] describes a solution where point-to-multipoint BGP 345 signaling is used in the control plane for SDWAN Scenario #1. It 346 relies upon a BGP cluster design to facilitate the key and policy 347 exchange among PE devices to create private pair-wise IPsec Security 348 Associations without IKEv2 point-to-point signaling or any other 349 direct peer-to-peer session establishment messages. 351 Both [SECURE-L3VPN] and [SECURE-EVPN] are useful, however, they both 352 miss the aspects of aggregating VPN and Internet underlays. In 353 summary: 355 - These documents do not address the scenario of C-PE having some 356 ports facing VPN PEs and other ports facing the Internet. 358 - The [SECURE-L3VPN] assumes that a CPE "registers" with the RR. 359 However, it does not say how. It assumes that the remote CPEs are 360 pre-configured with the IPsec SA manually. In SD-WAN, Zero Touch 361 Provisioning is expected. Manual configuration is not an option, 362 as it contradicts the objectives of SD-WAN to automate 363 configuration tasks. 364 - For RR communication with C-PEs, this draft only mentions IPsec. 365 Missing TLS/DTLS. 366 - The draft assumes that C-PEs and RR are connected with an IPsec 367 tunnel. With zero touch provisioning, we need an automatic way to 368 synchronize the IPsec SAs between C-PEs and RR. The draft assumes: 370 A CPE must also be provisioned with whatever additional 371 information is needed in order to set up an IPsec SA with 372 each of the red RRs 374 - IPsec requires periodic refreshment of the keys. The draft does 375 not provide any information about how to synchronize the 376 refreshment among multiple nodes. 377 - IPsec usually sends configuration parameters to two endpoints only 378 and lets these endpoints negotiate the key. Let us assume that the 379 RR is responsible for creating the key for all endpoints: When one 380 endpoint is compromised, all other connections will be impacted. 382 4.4. Preventing attacks from Internet-facing ports 384 When C-PEs have Internet-facing ports, additional security risks are 385 raised. 387 To mitigate security risks, in addition to requiring Anti-DDoS 388 features on C-PEs, it is necessary for CPEs to support means to 389 determine whether traffic sent by remote peers is legitimate to 390 prevent spoofing attacks. 392 5. CPEs not directly connected to VPN PEs 394 Because of the ephemeral property of the selected Cloud DCs, an 395 enterprise or its network service provider may not have direct 396 connections to the Cloud DCs that are used for hosting the 397 enterprise's specific workloads/Apps. Under those circumstances, SD- 398 WAN is a very flexible choice to interconnect the enterprise on- 399 premises data centers & branch offices to its desired Cloud DCs. 401 However, SD-WAN paths established over the public Internet can have 402 unpredictable performance, especially over long distances and across 403 operators' domains. Therefore, it is highly desirable to steer as 404 much as possible the portion of SD-WAN paths over service provider 405 VPN (e.g., enterprise's existing VPN) that have guaranteed SLA to 406 minimize the distance or the number of segments over the public 407 Internet. 409 MEF Cloud Service Architecture [MEF-Cloud] also describes a use case 410 of network operators that uses SD-WAN over LTE or the public 411 Internet for last mile access where the VPN service providers cannot 412 necessarily provide the required physical infrastructure. 414 Under those scenarios, one or two of the SD-WAN endpoints may not be 415 directly attached to the PEs of a VPN Domain. 417 When using SD-WAN to connect the enterprise's existing sites with 418 the workloads hosted in Cloud DCs, the corresponding CPEs have to be 419 upgraded to support SD-WAN. If the workloads hosted in Cloud DCs 420 need to be connected to many sites, the upgrade process can be very 421 expensive. 423 [Net2Cloud-Problem] describes a hybrid network approach that 424 integrates SD-WAN with traditional MPLS-based VPNs, to extend the 425 existing MPLS-based VPNs to the Cloud DC Workloads over the access 426 paths that are not under the VPN provider's control. To make it work 427 properly, a small number of the PEs of the MPLS VPN can be 428 designated to connect to the remote workloads via SD-WAN secure 429 IPsec tunnels. Those designated PEs are shown as fPE (floating PE 430 or smart PE) in Figure 3. Once the secure IPsec tunnels are 431 established, the workloads hosted in Cloud DCs can be reached by the 432 enterprise's VPN without upgrading all of the enterprise's existing 433 CPEs. The only CPE that needs to support SD-WAN would be a 434 virtualized CPE instantiated within the cloud DC. 436 +--------+ +--------+ 437 | Host-a +--+ +----| Host-b | 438 | | | (') | | 439 +--------+ | +-----------+ ( ) +--------+ 440 | +-+--+ ++-+ ++-+ +--+-+ (_) 441 | | CPE|--|PE| |PE+--+ CPE| | 442 +--| | | | | | | |---+ 443 +-+--+ ++-+ ++-+ +----+ 444 / | | 445 / | MPLS +-+---+ +--+-++--------+ 446 +------+-+ | Network |fPE-1| |CPE || Host | 447 | Host | | | |- --| || d | 448 | c | +-----+ +-+---+ +--+-++--------+ 449 +--------+ |fPE-2|-----+ 450 +---+-+ (|) 451 (|) (|) SD-WAN 452 (|) (|) over any access 453 +=\======+=========+ 454 // \ | Cloud DC \\ 455 // \ ++-----+ \\ 456 +Remote| 457 | CPE | 458 +-+----+ 459 ----+-------+-------+----- 460 | | 461 +---+----+ +---+----+ 462 | Remote | | Remote | 463 | App-1 | | App-2 | 464 +--------+ +--------+ 466 Figure 3: VPN Extension to Cloud DC 468 In Figure 3, the optimal Cloud DC to host the workloads (as a 469 function of the proximity, capacity, pricing, or other criteria 470 chosen by the enterprises) does not have a direct connection to the 471 PEs of the MPLS VPN that interconnects the enterprise's existing 472 sites. 474 5.1. Floating PEs to connect to Remote CPEs 476 To extend MPLS VPNs to remote CPEs, it is necessary to establish 477 secure tunnels (such as IPsec tunnels) between the Floating PEs and 478 the remote CPEs. 480 Even though a set of PEs can be manually selected to act as the 481 floating PEs for a specific cloud data center, there are no standard 482 protocols for those PEs to interact with the remote CPEs (most 483 likely virtualized) instantiated in the third party cloud data 484 centers (such as exchanging performance or route information). 486 When there is more than one fPE available for use (as there should 487 be for resiliency purposes or the ability to support multiple cloud 488 DCs geographically scattered), it is not straightforward to 489 designate an egress fPE to remote CPEs based on applications. There 490 is too much applications' traffic traversing PEs, and it is not 491 feasible for PEs to recognize applications from the payload of 492 packets. 494 5.2. NAT Traversal 496 Cloud DCs that only assign private IPv4 addresses to the 497 instantiated workloads assume that traffic to/from the workload 498 usually needs to traverse NATs. 499 A SD-WAN edge node can solicit a STUN (Session Traversal of UDP 500 Through Network Address Translation RFC 3489) Server to get the NAT 501 property, the public IP address and the Public Port number so that 502 such information can be communicated to the relevant peers. 504 5.3. Complexity of using BGP between PEs and remote CPEs via Internet 506 Even though an EBGP (external BGP) Multi-hop design can be used to 507 connect peers that are not directly connected to each other, there 508 are still some complications in extending BGP from MPLS VPN PEs to 509 remote CPEs via any access path (e.g., Internet). 511 The path between the remote CPEs and VPN PEs that maintain VPN 512 routes may very well traverse untrusted nodes. 514 EBGP Multi-hop design requires static configuration on both peers. 515 To use EBGP between a PE and remote CPEs, the PE has to be manually 516 configured with the "next-hop" set to the IP address of the CPEs. 517 When remote CPEs, especially remote virtualized CPEs are dynamically 518 instantiated or removed, the configuration of Multi-Hop EBGP on the 519 PE has to be changed accordingly. 521 Egress peering engineering (EPE) is not sufficient. Running BGP on 522 virtualized CPEs in Cloud DCs requires GRE tunnels to be 523 established first, which requires the remote CPEs to support 524 address and key management capabilities. RFC 7024 (Virtual Hub & 525 Spoke) and Hierarchical VPN do not support the required 526 properties. 528 Also, there is a need for a mechanism to automatically trigger 529 configuration changes on PEs when remote CPEs' are instantiated or 530 moved (leading to an IP address change) or deleted. 532 EBGP Multi-hop design does not include a security mechanism by 533 default. The PE and remote CPEs need secure communication channels 534 when connecting via the public Internet. 536 Remote CPEs, if instantiated in Cloud DCs, might have to traverse 537 NATs to reach PEs. It is not clear how BGP can be used between 538 devices located beyond the NAT and the devices located behind the 539 NAT. It is not clear how to configure the Next Hop on the PEs to 540 reach private IPv4 addresses. 542 5.4. Designated Forwarder to the remote edges 544 Among the multiple floating PEs that are reachable from a remote 545 CPE, multicast traffic sent by the remote CPE towards the MPLS VPN 546 can be forwarded back to the remote CPE due to the PE receiving the 547 multicast packets forwarding the multicast/broadcast frame to other 548 PEs that in turn send to all attached CPEs. This process may cause 549 traffic loops. 551 Therefore, it is necessary to designate one floating PE as the CPE's 552 Designated Forwarder, similar to TRILL's Appointed Forwarders 553 [RFC6325]. 555 MPLS VPNs do not have features like TRILL's Appointed Forwarders. 557 5.5. Traffic Path Management 559 When there are multiple floating PEs that have established IPsec 560 tunnels with the remote CPE, the remote CPE can forward outbound 561 traffic to the Designated Forwarder PE, which in turn forwards 562 traffic to egress PEs and then to the final destinations. However, 563 it is not straightforward for the egress PE to send back the return 564 traffic to the Designated Forwarder PE. 566 Example of Return Path management using Figure 3 above. 568 - fPE-1 is DF for communication between App-1 <-> Host-a due to 569 latency, pricing or other criteria. 570 - fPE-2 is DF for communication between App-1 <-> Host-b. 572 6. Manageability Considerations 574 Zero touch provisioning of SD-WAN edge nodes should be a major 575 feature of SD-WAN deployments. It is necessary for a newly powered 576 up SD-WAN edge node to establish a secure connection (by means of 577 TLS, DTLS, etc.) with its controller. 579 7. Security Considerations 581 The intention of this draft is to identify the gaps in current and 582 proposed SD-WAN approaches that can address requirements 583 identified in [Net2Cloud-problem]. 585 Several of these approaches have gaps in meeting enterprise 586 security requirements when tunneling their traffic over the 587 Internet, since this is the purpose of SD-WAN. See the individual 588 sections above for further discussion of these security gaps. 590 8. IANA Considerations 592 This document requires no IANA actions. RFC Editor: Please remove 593 this section before publication. 595 9. References 597 9.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 9.2. Informative References 604 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 605 (I2NSF) Problem Statement and Use Cases", July 2017 607 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 608 Address Family Identifier (SAFI) and the BGP Tunnel 609 Encapsulation Attribute", April 2009. 611 [BGP-SDWAN-PORT]L. Dunbar, et al, "Subsequent Address Family 612 Indicator for SDWAN Ports", draft-dunbar-idr-sdwan-port- 613 safi-00, Work-in-progress, March 2019. 615 [BGP-SDWAN-Usage] L. Dunbar, et al, "Framework of Using BGP for 616 SDWAN Overlay Networks", draft-dunbar-idr-sdwan-framework- 617 00, work-in-progress, Feb 2019. 619 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 620 Attribute", draft-ietf-idr-tunnel-encaps-10, July 2018. 622 [SECURE-EVPN A. Sajassi, et al, draft-sajassi-bess-secure-evpn-01, 623 work in progress, March 2019. 625 [SECURE-L3VPN] E. Rosen, "Provide Secure Layer L3VPNs over Public 626 Infrastructure", draft-rosen-bess-secure-l3vpn-00, work- 627 in-progress, July 2018 629 [DMVPN] Dynamic Multi-point VPN: 630 https://www.cisco.com/c/en/us/products/security/dynamic- 631 multipoint-vpn-dmvpn/index.html 633 [DSVPN] Dynamic Smart VPN: 634 http://forum.huawei.com/enterprise/en/thread-390771-1- 635 1.html 637 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 638 storage, distribution and enforcement of policies for 639 network security", Nov 2007. 641 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 642 Underlay to Cloud Overlay Problem Statement", draft-dm- 643 net2cloud-problem-statement-02, June 2018 645 10. Acknowledgments 647 Acknowledgements to xxx for his review and contributions. 649 This document was prepared using 2-Word-v2.0.template.dot. 651 Authors' Addresses 653 Linda Dunbar 654 Futurewei 655 Email: ldunbar@futurewei.com 657 Andrew G. Malis 658 Futurewei 659 Email: agmalis@gmail.com 661 Christian Jacquenet 662 Orange 663 Rennes, 35000 664 France 665 Email: Christian.jacquenet@orange.com