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