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