idnits 2.17.1 draft-dm-net2cloud-gap-analysis-03.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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([Net2Cloud-problem]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 27, 2019) is 1913 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Net2Cloud-problem' is mentioned on line 565, but not defined == Missing Reference: 'RFC2332' is mentioned on line 141, but not defined == Missing Reference: 'BGP-SDWAN-EXT' is mentioned on line 173, but not defined == Missing Reference: 'SECURE-EVPN' is mentioned on line 271, but not defined == Missing Reference: 'Tunnel-Encap' is mentioned on line 313, but not defined == Missing Reference: 'MEF-Cloud' is mentioned on line 391, but not defined == Missing Reference: 'RFC6325' is mentioned on line 534, but not defined == Unused Reference: 'RFC2119' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 616, 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: 2 errors (**), 0 flaws (~~), 14 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 Huawei 4 Expires: July 27, 2019 C. Jacquenet 5 Orange 6 January 27, 2019 8 Gap Analysis of Interconnecting Underlay with Cloud Overlay 9 draft-dm-net2cloud-gap-analysis-03 11 Abstract 13 This document analyzes the technological gaps when using SD-WAN to 14 interconnect workloads & apps hosted in various locations, 15 especially cloud data centers when the network service providers do 16 not have or have limited physical infrastructure to reach the 17 locations [Net2Cloud-problem]. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, except to publish it 27 as an RFC and to translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on April 27, 2009. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Conventions used in this document..............................3 65 3. Gap Analysis of C-PEs Registration Protocol....................4 66 4. Gap Analysis in aggregating VPN paths and Internet paths.......5 67 4.1. Gap analysis of Using BGP to cover SD-WAN paths...........7 68 4.2. Gaps in preventing attacks from Internet facing ports....10 69 5. Gap analysis of CPEs not directly connected to VPN PEs........10 70 5.1. Gap Analysis of Floating PEs to connect to Remote CPEs...12 71 5.2. NAT Traversal............................................13 72 5.3. Complication of using BGP between PEs and remote CPEs via 73 Internet......................................................13 74 5.4. Designated Forwarder to the remote edges.................14 75 5.5. Traffic Path Management..................................14 76 6. Manageability Considerations..................................15 77 7. Security Considerations.......................................15 78 8. IANA Considerations...........................................15 79 9. References....................................................15 80 9.1. Normative References.....................................16 81 9.2. Informative References...................................16 82 10. Acknowledgments..............................................17 84 1. Introduction 86 [Net2Cloud-Problem] describes the problems that enterprises face 87 today in transitioning their IT infrastructure to support digital 88 economy, such as connecting enterprises' branch offices to dynamic 89 workloads in different Cloud DCs. 91 This document analyzes the technological gaps to interconnect 92 dynamic workloads & apps hosted in various locations and in Cloud 93 DCs that the enterprise existing VPN service provider might not have 94 or have limited the physical infrastructure to reach. When 95 enterprise' VPN service providers do not have or have insufficient 96 bandwidth to reach a location, SD-WAN is emerged as way to aggregate 97 bandwidth of multiple networks, such as MPLS VPN, Public Internet, 98 etc. This document primarily focuses on the technological gaps of 99 SD-WAN. 101 For ease of description, SD-WAN edge, SD-WAN end points, C-PE, or 102 CPE are used interchangeably throughout this document. 104 2. Conventions used in this document 106 Cloud DC: Third party Data Centers that usually host applications 107 and workload owned by different organizations or 108 tenants. 110 Controller: Used interchangeably with SD-WAN controller to manage 111 SD-WAN overlay path creation/deletion and monitor the 112 path conditions between sites. 114 CPE-Based VPN: Virtual Private Secure network formed among CPEs. 115 This is to differentiate from most commonly used PE- 116 based VPNs a la RFC 4364. 118 OnPrem: On Premises data centers and branch offices 120 SD-WAN: Software Defined Wide Area Network. In this document, 121 "SD-WAN" refers to the solutions specified by ONUG (Open 122 Network User Group), https://www.onug.net/software- 123 defined-wide-area-network-sd-wan/, which is about 124 pooling WAN bandwidth from multiple underlay networks to 125 get better WAN bandwidth management, visibility & 126 control. When the underlay networks are private 127 networks, traffic can traverse without additional 128 encryption; when the underlay networks are public, such 129 as Internet, some traffic needs to be encrypted when 130 traversing through (depending on user provided 131 policies). 133 3. Gap Analysis of C-PEs Registration Protocol 135 SD-WAN, conceived in ONUG (Open Network User Group) a few years ago 136 as a means to aggregate multiple connections between any two points, 137 has emerged as an on-demand technology to securely interconnect the 138 OnPrem branches with the workloads instantiated in Cloud DCs that do 139 not connect to BGP/MPLS VPN PEs or have very limited bandwidth. 141 Some SD-WAN networks use the NHRP protocol [RFC2332] to register SD- 142 WAN edges with a "Controller" (or NHRP server), which then has the 143 ability to map a private VPN address to a public IP address of the 144 destination node. DSVPN [DSVPN] or DMVPN [DMVPN] are used to 145 establish tunnels among SD-WAN edge nodes. 147 NHRP was originally intended for ATM address resolution, and as a 148 result, it misses many attributes that are necessary for dynamic 149 endpoint C-PE registration to controller, such as: 151 - Interworking with MPLS VPN control plane. A SD-WAN edge can have 152 some ports facing MPLS VPN network and some ports facing public 153 Internet that requires encryption for some sensitive data to 154 traverse. 155 - Scalability. NHRP/DSVPN/DMVPN works fine with small number of edge 156 nodes. When a network has more than 100 nodes, the protocol does 157 not work well. 158 - NHRP does not have the IPsec attributes, which are needed for peers to 159 build Security Associations over public internet. 160 - NHRP does not have field to indicate C-PE supported encapsulation types, 161 such as IPsec-GRE, IPsec-VxLAN, or others. 163 - NHRP does not have field to indicate C-PE Location identifier, such as 164 Site Identifier, System ID, and/or Port ID. 165 - NHRP does not have field to describe the gateway to which the C-PE 166 is attached. When a C-PE is instantiated in a Cloud DC, to 167 establish connection to the C-PE, it is necessary to know the 168 Cloud DC operator's Gateway to which the CPE is attached. 169 - NHRP does not have field to describe C-PE's NAT properties if the 170 C-PE is using private addresses, such as the NAT type, Private 171 address, Public address, Private port, Public port, etc. 173 [BGP-SDWAN-EXT] describes how to use BGP for SD-WAN edge nodes to 174 register its properties to SD-WAN controller, which then 175 disseminates the information to other SD-WAN edge nodes that are 176 authenticated to communicate. 178 4. Gap Analysis in aggregating VPN paths and Internet paths 180 Most likely, enterprises especially large ones already have their 181 CPEs interconnected by providers' VPNs, such as EVPN, L2VPN, or 182 L3VPN. The VPN can be PE based or CPE based as shown in the 183 following diagram. The commonly used CPE-based VPNs have CPE 184 directly attached to PEs, therefore the communication is considered 185 as secure. BGP are used to distribute routes among CPEs, even though 186 sometimes routes among CPEs are statically configured. 188 +---+ EVPN MAC/IP BGP updates 189 +======+RR +===========+ 190 // +---+ \\ 191 // \\ 192 // <-----EVPN-VxLAN------> \\ 193 +-+--+ ++-+ ++-+ +--+-+ 194 | CPE|--|PE| |PE+----+ CPE| 195 | 1 | |1 | |x | | x | 196 +-+--+ ++-+ ++-+ +----+ 197 | | 198 | VPN +-+---+ +----+ 199 | Network | PE3 | |CPE | 200 | | |- --| 3 | 201 +--------+ +--+--+ +-+---+ +----+ 202 | CPE +----+ PE4 |--------+ 203 | 4 | +---+-+ 204 +--------+ 206 === or \\ indicates control plane communications 208 Figure 1: L2 or L3 VPNs over IP WAN 210 To use SD-WAN to aggregate Internet routes with the VPN routes, the 211 C-PEs need to have some ports connected to PEs and other ports 212 connected to the Internet. It is necessary to have a registration 213 protocol for C-PEs to register with their SD-WAN Controllers to 214 establish secure tunnels among relevant C-PEs. 216 If using NHRP for registration, C-PEs need to participate in two 217 separate control planes: EVPN&BGP for CPE-based VPNs via links 218 directly attached to PEs and NHRP & DSVPN/DMVPN for ports connected 219 to internet. Two separate control planes not only add complexity to 220 C-PEs, but also increase operational cost. 222 +---------Internet paths--------------+ 223 | | 224 | +---+ | 225 | |RR | | 226 | +======+---+===========+ | 227 | // \\ | 228 | // <-----EVPN-VxLAN----> \\ | 229 | +-+--+ ++-+ ++-+ +--+-+ (|) 230 | | CPE|--|PE| |PE+--+ CPE| (|) 231 +--| 1 | |1 | |x | | c |---+ 232 +-+--+ ++-+ ++-+ +----+ 233 | | 234 | VPN +-+---+ +----+ 235 +--------+ | Network | PE3 | |CPE | 236 | CPE | | | |- --| 3 | 237 | c | +-----+ +-+---+ +----+ 238 +------+-+-------+ PE4 |-----+ 239 +---+-+ 240 Figure 2: CPEs interconnected by VPN paths and Internet Paths 242 4.1. Gap analysis of Using BGP to cover SD-WAN paths 244 Since C-PE already supports BGP, it is desirable to consider using 245 BGP to control the SD-WAN instead of two separate control planes. 246 This section analyzes the gaps of using BGP to control SD-WAN. 248 As described [BGP-SDWAN-Usage], SD-WAN Overlay Control Plane has 249 three distinct functional tiers: 251 - SD-WAN node's private address and WAN Ports/Addresses 252 registration to the SD-WAN Controller. 253 o It is for informing the SD-WAN controller and potential 254 peers of the underlay networks to which the C-PE is 255 connected. 257 - Controller Facilitated IPsec SA management and NAT information 258 distribution 259 o It is for SD-WAN controller to facilitate or manage the 260 IPsec configurations and peer authentications for all 261 IPsec tunnels terminated at the SDWAN nodes. For some 262 scenarios where the WAN ports are private addresses, this 263 step is for informing the type of NAT translating the 264 private addresses to public ones. 266 - Establishing and Managing the topology and reachability for 267 services attached to the client ports of SD-WAN nodes. 268 o This is for the overlay layer's routes distribution, so 269 that a C-PE can establish the overlay routing table that 270 identifies the next hop for reaching a specific 271 route/service attached to remote nodes. [SECURE-EVPN] 272 describes EVPN and other options. 274 RFC5512 and [Tunnel-Encap] describe methods for endpoints to 275 advertise tunnel information and to trigger tunnel establishment. 276 RFC5512 & [Tunnel-Encap] have the Endpoint Address to indicate IPv4 277 or IPv6 address format, the Tunnel Encapsulation attribute to 278 indicate different encapsulation formats, such as L2TPv3, GRE, 279 VxLAN, IP-in-IP, etc. There are sub-TLVs to describe the detailed 280 tunnel information for each of the encapsulations. 282 [Tunnel-Encap] removed SAFI =7 (which was specified by RFC5512) for 283 distributing encapsulation tunnel information. [Tunnel-Encap] 284 require Tunnels being associated with routes. 286 There is also the Color sub-TLV to describe customer-specified 287 information about the tunnels (which can be creatively used for SD- 288 WAN) 290 Here are some of the gaps using [Tunnel-Encap] to control SD-WAN: 292 - Lacking C-PE Registration functionality 293 - Lacking IPsec Tunnel type 294 - [Tunnel-Encap] has Remote Address SubTLV, but does not have any 295 field to indicate the Tunnel originating interface, which was in 296 RFC5512. 297 - The mechanisms described by [Tunnel-Encap] cannot be effectively 298 used for SD-WAN overlay network because a SD-WAN Tunnel can be 299 between Internet facing WAN ports of two C-PEs and needs to be 300 established before data arrival because the tunnel establishment 301 can fail, e.g. two end points supporting different encryption 302 algorithms. 303 - Client traffic (e.g. an EVPN route) can have option of going 304 through MPLS network natively without encryption, or going through 305 the IPsec tunnels between the internet facing WAN ports of two C- 306 PEs. 308 - There is no routes to be associated with the SD-WAN Tunnel between 309 two C-PE's internet facing WAN ports, unless consider using the 310 interface facing WAN Port addresses assigned by ISP (Internet 311 Service Providers) as the route for the Tunnel. 312 There is a suggestion on using a "Fake Route" for a SD-WAN node to 313 use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points 314 properties. However, using "Fake Route" can create deployment 315 complexity for large SD-WAN networks with many tunnels. For 316 example, for a SD-WAN network with hundreds of nodes, with each 317 node having many ports & many end-points to establish SD-WAN 318 tunnels to their corresponding peers, the node would need many 319 "fake addresses". For large SD-WAN networks (such as has more than 320 10000 nodes), each node might need 10's thousands of "fake 321 addresses", which is very difficult to manage and needs lots of 322 configuration to get the nodes provisioned. 323 - Does not have fields to carry detailed information of the remote 324 C-PE: such as Site-ID, System-ID, Port-ID 325 - Does not have the proper field to express IPsec attributes among 326 the SD-WAN edge nodes to establish proper IPsec Security 327 Associations. 328 - Does not have proper way for two peer CPEs to negotiate IPSec 329 keys, based on the configuration sent by the Controller. 330 - Does not have field to indicate the UDP NAT private address <-> 331 public address mapping 332 - C-PEs tend to communicate with a few other CPEs, not all the C-PEs 333 need to form mesh connections. Without any BGP extension, many 334 nodes can get dumped with too much information of other nodes that 335 they never need to communicate with. 337 [VPN-over-Internet] describes a way to securely interconnect C-PEs 338 via IPsec using BGP. This method is useful, however, it still misses 339 some aspects to aggregate CPE-based VPN routes with internet routes 340 that interconnect the CPEs. In addition: 342 - The draft does not have options of C-PE having both MPLS ports and 343 Internet ports. 344 - The draft assumes that CPE "registers" with the RR. However, it does not 345 say how. It assumes that the remote CPEs are pre-configured with the 346 IPsec SA manually. In SD-WAN, Zero Touch Provisioning is expected. It is 347 not acceptable to require manual configuration. 349 - For RR communication with CPE, this draft only mentioned IPSec. Missing 350 TLS/DTLS. 351 - The draft assumes that CPEs and RR are connected with an IPsec tunnel. 352 With zero touch provisioning, we need an automatic way to synchronize 353 the IPsec SA between CPE and RR. The draft assumes: 354 A CPE must also be provisioned with whatever additional information 355 is needed in order to set up an IPsec SA with each of the red RRs 357 - IPsec requires periodic refreshment of the keys. The draft hasn't 358 addressed how to synchronize the refreshment among multiple nodes. 359 - IPsec usually only sends configuration parameters to two endpoints 360 and let the two endpoints negotiate the KEY. Now we assume that RR 361 is responsible for creating the KEY for all endpoints. When one 362 endpoint is compromised, all other connections are impacted. 364 4.2. Gaps in preventing attacks from Internet facing ports 366 When C-PEs have ports facing Internet, it brings in the security 367 risks of potential DDoS attacks to the C-PEs from the ports facing 368 internet. 370 To mitigate security risks, in addition to requring Anti-DDoS 371 features on C-PEs to prevent major DDoS attacks, it is necessary to 372 have ways for C-PEs to validate traffic from remote peers to prevent 373 spoofed traffic. 375 5. Gap analysis of CPEs not directly connected to VPN PEs 377 Because of the ephemeral property of the selected Cloud DCs, an 378 enterprise or its network service provider may not have the direct 379 links to the Cloud DCs that are optimal for hosting the enterprise's 380 specific workloads/Apps. Under those circumstances, SD-WAN is a very 381 flexible choice to interconnect the enterprise on-premises data 382 centers & branch offices to its desired Cloud DCs. 384 However, SD-WAN paths over public Internet can have unpredictable 385 performance, especially over long distances and across domains. 386 Therefore, it is highly desirable to place as much as possible the 387 portion of SD-WAN paths over service provider VPN (e.g., 388 enterprise's existing VPN) that have guaranteed SLA to minimize the 389 distance/segments over public Internet. 391 MEF Cloud Service Architecture [MEF-Cloud] also describes a use case 392 of network operators needing to use SD-WAN over LTE or public 393 Internet for last mile accesses where they are not present. 395 Under those scenarios, one or both of the SD-WAN endpoints may not 396 directly be attached to the PEs of a VPN Domain. 398 Using SD-WAN to connect the enterprise existing sites with the 399 workloads in Cloud DC, the enterprise existing sites' CPEs have to 400 be upgraded to support SD-WAN. If the workloads in Cloud DC need to 401 be connected to many sites, the upgrade process can be very 402 expensive. 404 [Net2Cloud-Problem] describes a hybrid network approach that 405 integrates SD-WAN with traditional MPLS-based VPNs, to extend the 406 existing MPLS-based VPNs to the Cloud DC Workloads over the access 407 paths that are not under the VPN provider control. To make it work 408 properly, a small number of the PEs of the MPLS VPN can be 409 designated to connect to the remote workloads via SD-WAN secure 410 IPsec tunnels. Those designated PEs are shown as fPE (floating PE 411 or smart PE) in Figure 3. Once the secure IPsec tunnels are 412 established, the workloads in Cloud DC can be reached by the 413 enterprise's VPN without upgrading all of the enterprise's existing 414 CPEs. The only CPE that needs to support SD-WAN would be a 415 virtualized CPE instantiated within the cloud DC. 417 +--------+ +--------+ 418 | Host-a +--+ +----| Host-b | 419 | | | (') | | 420 +--------+ | +-----------+ ( ) +--------+ 421 | +-+--+ ++-+ ++-+ +--+-+ (_) 422 | | CPE|--|PE| |PE+--+ CPE| | 423 +--| | | | | | | |---+ 424 +-+--+ ++-+ ++-+ +----+ 425 / | | 426 / | MPLS +-+---+ +--+-++--------+ 427 +------+-+ | Network |fPE-1| |CPE || Host | 428 | Host | | | |- --| || d | 429 | c | +-----+ +-+---+ +--+-++--------+ 430 +--------+ |fPE-2|-----+ 431 +---+-+ (|) 432 (|) (|) SD-WAN 433 (|) (|) over any access 434 +=\======+=========+ 435 // \ | Cloud DC \\ 436 // \ ++-----+ \\ 437 +Remote| 438 | CPE | 439 +-+----+ 440 ----+-------+-------+----- 441 | | 442 +---+----+ +---+----+ 443 | Remote | | Remote | 444 | App-1 | | App-2 | 445 +--------+ +--------+ 447 Figure 3: VPN Extension to Cloud DC 449 In Figure 3, the optimal Cloud DC to host the workloads (due to 450 proximity, capacity, pricing, or other criteria chosen by the 451 enterprises) does not happen to have a direct connection to the PEs 452 of the MPLS VPN that interconnects the enterprise's existing sites. 454 5.1. Gap Analysis of Floating PEs to connect to Remote CPEs 456 To extend MPLS VPNs to remote CPEs, it is necessary to establish 457 secure tunnels (such as IPsec tunnels) between the Floating PEs and 458 the remote CPEs. 460 Gap: 462 Even though a set of PEs can be manually selected to act as the 463 floating PEs for a specific cloud data center, there are no standard 464 protocols for those PEs to interact with the remote CPEs (most 465 likely virtualized) instantiated in the third party cloud data 466 centers (such as exchanging performance or route information). 468 When there is more than one fPE available for use (as there should 469 be for resiliency or the ability to support multiple cloud DCs 470 scattered geographically), it is not straightforward to designate an 471 egress fPE to remote CPEs based on applications. There is too much 472 applications' traffic traversing PEs, and it is not feasible for PEs 473 to recognize applications from the payload of packets. 475 5.2. NAT Traversal 477 Most cloud DCs only assign private addresses to the workloads 478 instantiated. Therefore, traffic to/from the workload usually need 479 to traverse NAT. 480 A SD-WAN edge node can inquire STUN (Session Traversal of UDP 481 Through Network Address Translation RFC 3489) Server to get the NAT 482 property, the public IP address and the Public Port number to pass 483 to peers. 485 5.3. Complication of using BGP between PEs and remote CPEs via Internet 487 Even though an EBGP (external BGP) Multi-hop design can be used to 488 connect peers that are not directly connected to each other, there 489 are still some complications/gaps in extending BGP from MPLS VPN PEs 490 to remote CPEs via any access paths (e.g., Internet). 492 The path between the remote CPEs and VPN PE can traverse untrusted 493 nodes. 495 EBGP Multi-hop scheme requires static configuration on both peers. 496 To use EBGP between a PE and remote CPEs, the PE has to be manually 497 configured with the "next-hop" set to the IP addresses of the CPEs. 498 When remote CPEs, especially remote virtualized CPEs are dynamically 499 instantiated or removed, the configuration on the PE Multi-Hop EBGP 500 has to be changed accordingly. 502 Gap: 504 Egress peering engineering (EPE) is not enough. Running BGP on 505 virtualized CPEs in Cloud DC requires GRE tunnels being 506 established first, which in turn requires address and key 507 management for the remote CPEs. RFC 7024 (Virtual Hub & Spoke) and 508 Hierarchical VPN is not enough. 510 Also there is a need for a method to automatically trigger 511 configuration changes on PE when remote CPEs' are instantiated or 512 moved (leading to an IP address change) or deleted. 514 EBGP Multi-hop scheme does not have an embedded security 515 mechanism. The PE and remote CPEs need secure communication 516 channels when connecting via the public Internet. 518 Remote CPEs, if instantiated in Cloud DC, might have to traverse NAT 519 to reach PE. It is not clear how BGP can be used between devices 520 outside the NAT and the entities behind the NAT. It is not clear how 521 to configure the Next Hop on the PEs to reach private IPv4 522 addresses. 524 5.4. Designated Forwarder to the remote edges 526 Among multiple floating PEs available for a remote CPE, multicast 527 traffic from the remote CPE towards the MPLS VPN can be forwarded 528 back to the remote CPE due to the PE receiving the multicast data 529 frame forwarding the multicast/broadcast frame to other PEs that in 530 turn send to all attached CPEs. This process may cause traffic loop. 532 Therefore, it is necessary to designate one floating PE as the CPE's 533 Designated Forwarder, similar to TRILL's Appointed Forwarders 534 [RFC6325]. 536 Gap: the MPLS VPN does not have features like TRILL's Appointed 537 Forwarders. 539 5.5. Traffic Path Management 541 When there are multiple floating PEs that have established IPsec 542 tunnels to the remote CPE, the remote CPE can forward the outbound 543 traffic to the Designated Forwarder PE, which in turn forwards the 544 traffic to egress PEs to the destinations. However, it is not 545 straightforward for the egress PE to send back the return traffic to 546 the Designated Forwarder PE. 548 Example of Return Path management using Figure 3 above. 550 - fPE-1 is DF for communication between App-1 <-> Host-a due to 551 latency, pricing or other criteria. 552 - fPE-2 is DF for communication between App-1 <-> Host-b. 554 6. Manageability Considerations 556 Zero touch provisioning of SD-WAN edge nodes is expected in SD- 557 WAN deployment. It is necessary for a newly powered up SD-WAN 558 edges to establish a secure connection (such as TLS, DTLS, etc.) 559 to its controller. 561 7. Security Considerations 563 The intention of this draft is to identify the gaps in current and 564 proposed SD-WAN approaches that can address requirements 565 identified in [Net2Cloud-problem]. 567 Several of these approaches have gaps in meeting enterprise 568 security requirements when tunneling their traffic over the 569 Internet, as is the general intention of SD-WAN. See the 570 individual sections above for further discussion of these security 571 gaps. 573 8. IANA Considerations 575 This document requires no IANA actions. RFC Editor: Please remove 576 this section before publication. 578 9. References 579 9.1. Normative References 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 9.2. Informative References 586 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 587 (I2NSF) Problem Statement and Use Cases", July 2017 589 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 590 Address Family Identifier (SAFI) and the BGP Tunnel 591 Encapsulation Attribute", April 2009. 593 [BGP-SDWAN-EXT]L. Dunbar, "BGP Extension for SDWAN Overlay 594 Networks", draft-dunbar-idr-bgp-sdwan-overlay-ext-00, Oct 595 2018. 597 [BGP-SDWAN-Usage] L. Dunbar, et al, "Framework of Using BGP for 598 SDWAN Overlay Networks", draft-dunbar-idr-sdwan-framework- 599 00, work-in-progress, Feb 2019. 601 [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation 602 Attribute", draft-ietf-idr-tunnel-encaps-10, July 2018. 604 [VPN-over-Internet] E. Rosen, "Provide Secure Layer L3VPNs over 605 Public Infrastructure", draft-rosen-bess-secure-l3vpn-00, 606 work-in-progress, July 2018 608 [DMVPN] Dynamic Multi-point VPN: 609 https://www.cisco.com/c/en/us/products/security/dynamic- 610 multipoint-vpn-dmvpn/index.html 612 [DSVPN] Dynamic Smart VPN: 613 http://forum.huawei.com/enterprise/en/thread-390771-1- 614 1.html 616 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 617 storage, distribution and enforcement of policies for 618 network security", Nov 2007. 620 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 621 Underlay to Cloud Overlay Problem Statement", draft-dm- 622 net2cloud-problem-statement-02, June 2018 624 10. Acknowledgments 626 Acknowledgements to xxx for his review and contributions. 628 This document was prepared using 2-Word-v2.0.template.dot. 630 Authors' Addresses 632 Linda Dunbar 633 Huawei 634 Email: Linda.Dunbar@huawei.com 636 Andrew G. Malis 637 Huawei 638 Email: agmalis@gmail.com 640 Christian Jacquenet 641 Orange 642 Rennes, 35000 643 France 644 Email: Christian.jacquenet@orange.com