idnits 2.17.1 draft-ietf-rtgwg-net2cloud-gap-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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 == Line 390 has weird spacing: '...rs that use S...' -- The document date (March 25, 2019) is 1852 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 137, but not defined == Missing Reference: 'BGP-SDWAN-PORT' is mentioned on line 170, but not defined == Missing Reference: 'SDWAN-Port' is mentioned on line 233, but not defined == Missing Reference: 'SECURE-EVPN' is mentioned on line 333, but not defined == Missing Reference: 'Tunnel-Encap' is mentioned on line 291, but not defined == Missing Reference: 'MEF-Cloud' is mentioned on line 389, 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: 1 error (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft A. Malis 3 Intended status: Informational Huawei 4 Expires: September 25, 2019 C. 5 Jacquenet 6 Orange 7 March 25, 2019 9 Gap Analysis of Interconnecting Underlay with Cloud Overlay 10 draft-ietf-rtgwg-net2cloud-gap-analysis-01 12 Abstract 14 This document analyzes the technological gaps when using SD-WAN to 15 interconnect workloads & apps hosted in various locations, 16 especially cloud data centers when the network service providers do 17 not have or have limited physical infrastructure to reach the 18 locations [Net2Cloud-problem]. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on September 25, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction...................................................2 61 2. Conventions used in this document..............................3 62 3. Gap Analysis of C-PEs WAN Ports Registration...................4 63 4. Gap Analysis in aggregating VPN paths and Internet paths.......5 64 4.1. Gap analysis of Using BGP for SD-WAN......................6 65 4.2. Gaps in preventing attacks from Internet-facing ports.....9 66 5. Gap analysis of CPEs not directly connected to VPN PEs........10 67 5.1. Gap Analysis of Floating PEs to connect to Remote CPEs...12 68 5.2. NAT Traversal............................................12 69 5.3. Complication of using BGP between PEs and remote CPEs via 70 Internet......................................................12 71 5.4. Designated Forwarder to the remote edges.................13 72 5.5. Traffic Path Management..................................14 73 6. Manageability Considerations..................................14 74 7. Security Considerations.......................................14 75 8. IANA Considerations...........................................15 76 9. References....................................................15 77 9.1. Normative References.....................................15 78 9.2. Informative References...................................15 79 10. Acknowledgments..............................................16 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 various locations and in Cloud 90 DCs that the enterprise's VPN service provider may not own/operate 91 or may be unable to provide the required connectivity to access 92 these locations. When enterprise' VPN service providers have 93 insufficient bandwidth to reach a location, SD-WAN techniques can be 94 used to aggregate bandwidth of multiple networks, such as MPLS VPNs, 95 the Public Internet, to achieve better performance and visibility. 96 This document primarily focuses on the technological gaps of SD-WAN. 98 For ease of description, a SD-WAN edge, a SD-WAN end-point, C-PE, or 99 CPE are used interchangeably throughout this document. 101 2. Conventions used in this document 103 Cloud DC: Third party Data Centers that usually host applications 104 and workload owned by different organizations or 105 tenants. 107 Controller: Used interchangeably with SD-WAN controller to manage 108 SD-WAN overlay path creation/deletion and monitor the 109 path conditions between sites. 111 CPE-Based VPN: Virtual Private Network designed and deployed from 112 CPEs. This is to differentiate from most commonly used 113 PE-based VPNs a la RFC 4364. 115 OnPrem: On Premises data centers and branch offices 117 SD-WAN: Software Defined Wide Area Network, "SDWAN" refers to 118 the solutions of pooling WAN bandwidth from multiple 119 underlay networks to get better WAN bandwidth 120 management, visibility & control. When the underlay is 121 private network, traffic can traverse without additional 122 encryption; when the underlay networks are public, such 123 as the Internet, some traffic needs to be encrypted when 124 traversing through (depending on user-provided 125 policies). 127 3. Gap Analysis of C-PEs WAN Ports Registration 129 The SD-WAN WG stemmed out from ONUG (Open Network User Group) in 130 2014 and was the placeholder to define SD-WAN as a means to 131 aggregate multiple underlay networks between any two points. SD-WAN 132 technology has emerged as an on-demand technology to securely 133 interconnect the OnPrem branches with the workloads instantiated in 134 Cloud DCs that do not connect to BGP/MPLS VPN PEs or have very 135 limited bandwidth. 137 Some SD-WAN networks use the NHRP protocol [RFC2332] to register WAN 138 ports of SD-WAN edges with a "Controller" (or NHRP server), which 139 then has the ability to map a private VPN address to a public IP 140 address of the destination node. DSVPN [DSVPN] or DMVPN [DMVPN] are 141 used to establish tunnels between WAN ports of 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 over which packets can be sent 149 natively without encryption and some ports facing the public 150 Internet over which sensitive traffic needs to be encrypted before 151 being sent. 152 - Scalability. NHRP/DSVPN/DMVPN works fine with small numbers of 153 edge nodes. When a network has more than 100 nodes, the protocol 154 does not work well. 155 - NHRP does not have the IPsec attributes, which are needed for 156 peers to build Security Associations over public internet. 157 - NHRP messages do not have any field to encode the C-PE supported 158 encapsulation types, such as IPsec-GRE or IPsec-VxLAN,. 159 - NHRP messages do not have any field to encode C-PE Location 160 identifiers, such as Site Identifier, System ID, and/or Port ID. 161 - NHRP messages do not have any field to describe the gateway(s) to 162 which the C-PE is attached. When a C-PE is instantiated in a Cloud 163 DC, to establish connection to the C-PE, it is necessary to know 164 the Cloud DC operator's Gateway to which the CPE is attached. 165 - NHRP messages do not have any field to describe C-PE's NAT 166 properties if the C-PE is using private addresses, such as the NAT 167 type, Private address, Public address, Private port, Public port, 168 etc. 170 [BGP-SDWAN-PORT] describes how to use BGP for SD-WAN edge nodes to 171 register their WAN ports properties to the SD-WAN controller, which 172 then disseminates the information to other SD-WAN edge nodes that 173 are authenticated before the SD-WAN controller and the other SD-WAN 174 edge nodes can communicate with them. 176 4. Gap Analysis in aggregating VPN paths and Internet paths 178 Most likely, enterprises (especially the largest ones) already have 179 their CPEs interconnected by providers' VPNs, based upon VPN 180 techniques such as EVPN, L2VPN, or L3VPN. The VPN can be PE-based or 181 CPE-based. The commonly used PE-based VPNs have CPE directly 182 attached to PEs, therefore the communication between CPEs & PEs is 183 considered as secure. MP-BGP is used to learn & distribute routes 184 among CPEs, even though sometimes routes among CPEs are statically 185 configured. 187 To aggregate paths over the Internet and paths over the VPN, the C- 188 PEs need to have some WAN ports connected to the PEs of the VPNs and 189 other WAN ports connected to the Internet. It is necessary for the 190 CPEs to use a protocol so that they can register the WAN port 191 properties with their SD-WAN Controller(s): this information 192 conditions the establishment and the maintenance of IPsec SA 193 associations among relevant C-PEs. 195 If using NHRP for registration purposes, C-PEs need to participate 196 in two separate control planes: EVPN&BGP for CPE-based VPNs and NHRP 197 & DSVPN/DMVPN for ports connected to the Internet. Two separate 198 control planes not only add complexity to C-PEs, but also increase 199 operational cost. 201 +---+ 202 +--------------|RR |----------+ 203 / Untrusted +-+-+ \ 204 / \ 205 / \ 206 +----+ +---------+ packets encrypted over +------+ +----+ 207 | TN3|--| A1-----+ Untrusted +------ B1 |--| TN1| 208 +----+ | C-PE A2-\ | C-PE | +----+ 209 +----+ | A A3--+--+ +---+---B2 B | +----+ 210 | TN2|--| | |PE+--------------+PE |---B3 |--| TN3| 211 +----+ +---------+ +--+ trusted +---+ +------+ +----+ 212 | WAN | 213 +----+ +---------+ +--+ packets +---+ +------+ +----+ 214 | TN1|--| C1--|PE| go natively |PE |-- D1 |--| TN1| 215 +----+ | C-PE C2--+--+ without encry+---+ | C-PE | +----+ 216 | C | +--------------+ | D | 217 | | | | 218 +----+ | C3--| without encrypt over | | +----+ 219 | TN2|--| C4--+---- Untrusted --+------D2 |--| TN2| 220 +----+ +---------+ +------+ +----+ 221 Figure 1: CPEs interconnected by VPN paths and Internet Paths 223 4.1. Gap analysis of Using BGP for SD-WAN 225 This section analyzes the gaps of using BGP to control SD-WAN. 227 As described in [BGP-SDWAN-Usage], SD-WAN Overlay Control Plane has 228 three distinct aspects: 230 - SD-WAN node's WAN Ports Property registration to the SD-WAN 231 Controller. 232 o It is to inform the SD-WAN controller and potential peers 233 of the WAN ports property of the C-PE [SDWAN-Port]. When 234 the WAN ports are using private addresses, this step can 235 register the type of NAT that translate private addresses 236 into public ones. 238 - Controller Facilitated IPsec SA management and NAT information 239 distribution 240 o It is for SD-WAN controller to facilitate or manage the 241 IPsec configuration and peer authentication for all IPsec 242 tunnels terminated at the SDWAN nodes. 244 - Establishing and Managing the topology and reachability for 245 services attached to the client ports of SD-WAN nodes. 246 o This is for the overlay layer's route distribution, so 247 that a C-PE can populate its overlay routing table with 248 entries that identify the next hop for reaching a specific 249 route/service attached to remote nodes. [SECURE-EVPN] 250 describes EVPN and other options. 252 RFC5512 and [Tunnel-Encap] describe methods for endpoints to 253 advertise tunnel information and trigger tunnel establishment. 254 RFC5512 & [Tunnel-Encap] use the Endpoint Address that indicates an 255 IPv4 or an IPv6 address, and the Tunnel Encapsulation attribute to 256 indicate different encapsulation formats, such as L2TPv3, GRE, 257 VxLAN, IP-in-IP, etc. There are sub-TLVs to describe the detailed 258 tunnel information for each of the encapsulation types. 260 [Tunnel-Encap] removed SAFI =7 (which was specified by RFC5512) for 261 distributing encapsulation tunnel information. [Tunnel-Encap] 262 requires that tunnels need to be associated with routes. 264 There is also the Color sub-TLV to describe customer-specified 265 information about the tunnels (which can be creatively used for SD- 266 WAN). 268 Here are some of the gaps using [Tunnel-Encap] to control SD-WAN: 270 - Lacking C-PE WAN Port Property Registration functionality 271 - Lacking IPsec Tunnel type 272 - [Tunnel-Encap] has Remote Address SubTLV, but does not have any 273 field to indicate the Tunnel originating interface, as defined in 274 RFC5512. 275 - The mechanisms described by [Tunnel-Encap] cannot be effectively 276 used for SD-WAN overlay network because a SD-WAN Tunnel can be 277 established between Internet-facing WAN ports of two C-Pes. This 278 tunnel needs to be established before data arrival because the 279 tunnel establishment can fail, e.g., in case the two end-points 280 support different encryption algorithms. 281 - Client traffic can either be forwarded through the MPLS network 282 natively without any encryption for better performance, or through 283 the Internet-facing ports with IPsec encryption. 284 - There can be many client routes associated with the SD-WAN IPsec 285 tunnel between two C-PE's Internet-facing WAN ports, but the 286 corresponding destination prefixes (as announced by the 287 aforementioned routes) can also be reached over the VPN underlay 288 natively without encryption. A more realistic approach to separate 289 IPsec SA management from client routes association with IPsec. 290 There is a suggestion on using a "Fake Route" for a SD-WAN node to 291 use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points 292 properties. However, using "Fake Route" can raise some design 293 complexity for large SD-WAN networks with many tunnels. For 294 example, for a SD-WAN network with hundreds of nodes, with each 295 node having many ports & many end-points to establish SD-WAN 296 tunnels with their corresponding peers, the node would need as 297 many "fake addresses". For large SD-WAN networks (such as those 298 comprised of more than 10000 nodes), each node might need 10's 299 thousands of "fake addresses", which is very difficult to manage 300 and needs lots of configuration to get the nodes provisioned. 301 - Does not have any field to carry detailed information about the 302 remote C-PE, such as Site-ID, System-ID, Port-ID 303 - Does not have any field to express IPsec attributes for the SD-WAN 304 edge nodes to establish IPsec Security Associations with others. 305 - Does not have any proper way for two peer CPEs to negotiate IPsec 306 keys, based on the configuration sent by the Controller. 307 - Does not have any field to indicate the UDP NAT private address 308 <-> public address mapping 309 - C-PEs tend to communicate with a subset of the other C-PEs, not 310 all the C-PEs need to form mesh connections. Without any BGP 311 extension, many nodes can get dumped with too much information 312 coming from other nodes that they never need to communicate with. 314 [SECURE-L3VPN] describes how to extend the RFC4364 VPN to allow some 315 PEs to connect to other PEs via public networks. [SECURE-L3VPN] 316 introduces the concept of Red Interface & Black Interface on those 317 PEs, where the RED interfaces are used to forward traffic into the 318 VPN, and the Black Interfaces are used between WAN ports over which 319 only IPsec-protected packets to the Internet or other backbone 320 network are sent thereby eliminating the need for MPLS transport in 321 the backbone. 323 [SECURE-L3VPN] assumes PEs terminate MPLS packets, and use MPLS over 324 IPsec when sending traffic through the Black Interfaces. 326 [SECURE-EVPN] describes a solution where point-to-multipoint BGP 327 signaling is used in the control plane for SDWAN Scenario #1. It 328 relies upon a BGP cluster design to facilitate the key and policy 329 exchange among PE devices to create private pair-wise IPsec Security 330 Associations without IKEv2 point-to-point signaling or any other 331 direct peer-to-peer session establishment messages. 333 Both [SECURE-L3VPN] and [SECURE-EVPN] are useful, however, they both 334 miss the aspects of aggregating VPN and Internet underlays. In 335 summary: 337 - These documents do not address the scenario of C-PE having some 338 ports facing VPN PEs and other ports facing the Internet. 339 - 340 - The [SECURE-L3VPN] assumes that CPE "registers" with the RR. 341 However, it does not say how. It assumes that the remote CPEs are 342 pre-configured with the IPsec SA manually. In SD-WAN, Zero Touch 343 Provisioning is expected. Manual configuration is not an option, 344 given the dimensioning figures but also the purpose of SD-WAN to 345 automate configuration tasks. 346 - For RR communication with CPEs, this draft only mentions IPsec. 347 Missing TLS/DTLS. 348 - The draft assumes that CPEs and RR are connected with an IPsec 349 tunnel. With zero touch provisioning, we need an automatic way to 350 synchronize the IPsec SAs between CPE and RR. The draft assumes: 351 A CPE must also be provisioned with whatever additional 352 information is needed in order to set up an IPsec SA with 353 each of the red RRs 355 - IPsec requires periodic refreshment of the keys. The draft does 356 not provide any information about how to synchronize the 357 refreshment among multiple nodes. 358 - IPsec usually sends configuration parameters to two endpoints only 359 and lets these endpoints negotiate the key. Let us assume that the 360 RR is responsible for creating the key for all endpoints: When one 361 endpoint is compromised, all other connections will be impacted. 363 4.2. Gaps in preventing attacks from Internet-facing ports 365 When C-PEs have Internet-facing ports, additional security risks are 366 raised. 368 To mitigate security risks, in addition to requiring Anti-DDoS 369 features on C-PEs, it is necessary for CPEs to support means to 370 determine whether traffic sent by remote peers is legitimate to 371 prevent spoofing attacks. 373 5. Gap analysis of CPEs not directly connected to VPN PEs 375 Because of the ephemeral property of the selected Cloud DCs, an 376 enterprise or its network service provider may not have direct 377 connections to the Cloud DCs that are used for hosting the 378 enterprise's specific workloads/Apps. Under those circumstances, SD- 379 WAN is a very flexible choice to interconnect the enterprise on- 380 premises data centers & branch offices to its desired Cloud DCs. 382 However, SD-WAN paths over public Internet can have unpredictable 383 performance, especially over long distances and across domains. 384 Therefore, it is highly desirable to place as much as possible the 385 portion of SD-WAN paths over service provider VPN (e.g., 386 enterprise's existing VPN) that have guaranteed SLA to minimize the 387 distance/segments over public Internet. 389 MEF Cloud Service Architecture [MEF-Cloud] also describes a use case 390 of network operators that use SD-WAN over LTE or the public 391 Internet for last mile access where the VPN providers cannot 392 necessarily provide the required physical infrastructure. 394 Under those scenarios, one or two of the SD-WAN endpoints may not be 395 directly attached to the PEs of a VPN Domain. 397 When using SD-WAN to connect the enterprise's existing sites with 398 the workloads in Cloud DC, the corresponding CPEs have to be 399 upgraded to support SD-WAN. If the workloads in Cloud DCs need to 400 be connected to many sites, the upgrade process can be very 401 expensive. 403 [Net2Cloud-Problem] describes a hybrid network approach that 404 integrates SD-WAN with traditional MPLS-based VPNs, to extend the 405 existing MPLS-based VPNs to the Cloud DC Workloads over the access 406 paths that are not under the VPN provider's control. To make it work 407 properly, a small number of the PEs of the MPLS VPN can be 408 designated to connect to the remote workloads via SD-WAN secure 409 IPsec tunnels. Those designated PEs are shown as fPE (floating PE 410 or smart PE) in Figure 3. Once the secure IPsec tunnels are 411 established, the workloads in Cloud DC can be reached by the 412 enterprise's VPN without upgrading all of the enterprise's existing 413 CPEs. The only CPE that needs to support SD-WAN would be a 414 virtualized CPE instantiated within the cloud DC. 416 +--------+ +--------+ 417 | Host-a +--+ +----| Host-b | 418 | | | (') | | 419 +--------+ | +-----------+ ( ) +--------+ 420 | +-+--+ ++-+ ++-+ +--+-+ (_) 421 | | CPE|--|PE| |PE+--+ CPE| | 422 +--| | | | | | | |---+ 423 +-+--+ ++-+ ++-+ +----+ 424 / | | 425 / | MPLS +-+---+ +--+-++--------+ 426 +------+-+ | Network |fPE-1| |CPE || Host | 427 | Host | | | |- --| || d | 428 | c | +-----+ +-+---+ +--+-++--------+ 429 +--------+ |fPE-2|-----+ 430 +---+-+ (|) 431 (|) (|) SD-WAN 432 (|) (|) over any access 433 +=\======+=========+ 434 // \ | Cloud DC \\ 435 // \ ++-----+ \\ 436 +Remote| 437 | CPE | 438 +-+----+ 439 ----+-------+-------+----- 440 | | 441 +---+----+ +---+----+ 442 | Remote | | Remote | 443 | App-1 | | App-2 | 444 +--------+ +--------+ 446 Figure 3: VPN Extension to Cloud DC 448 In Figure 3, the optimal Cloud DC to host the workloads (due to 449 proximity, capacity, pricing, or other criteria chosen by the 450 enterprises) does not have a direct connection to the PEs of the 451 MPLS VPN that interconnects the enterprise's existing sites. 453 5.1. Gap Analysis of Floating PEs to connect to Remote CPEs 455 To extend MPLS VPNs to remote CPEs, it is necessary to establish 456 secure tunnels (such as IPsec tunnels) between the Floating PEs and 457 the remote CPEs. 459 Gap: 461 Even though a set of PEs can be manually selected to act as the 462 floating PEs for a specific cloud data center, there are no standard 463 protocols for those PEs to interact with the remote CPEs (most 464 likely virtualized) instantiated in the third party cloud data 465 centers (such as exchanging performance or route information). 467 When there is more than one fPE available for use (as there should 468 be for resiliency or the ability to support multiple cloud DCs 469 geographically scattered), it is not straightforward to designate an 470 egress fPE to remote CPEs based on applications. There is too much 471 applications' traffic traversing PEs, and it is not feasible for PEs 472 to recognize applications from the payload of packets. 474 5.2. NAT Traversal 476 Most cloud DCs only assign private addresses to the instantiated 477 workloads. Therefore, traffic to/from the workload usually needs to 478 traverse NATs. 479 A SD-WAN edge node can solicit a STUN (Session Traversal of UDP 480 Through Network Address Translation RFC 3489) Server to get the NAT 481 property, the public IP address and the Public Port number to pass 482 to peers. 484 5.3. Complication of using BGP between PEs and remote CPEs via Internet 486 Even though an EBGP (external BGP) Multi-hop design can be used to 487 connect peers that are not directly connected to each other, there 488 are still some complications/gaps in extending BGP from MPLS VPN PEs 489 to remote CPEs via any access paths (e.g., Internet). 491 The path between the remote CPEs and VPN PE can traverse untrusted 492 nodes. 494 EBGP Multi-hop design requires static configuration on both peers. 495 To use EBGP between a PE and remote CPEs, the PE has to be manually 496 configured with the "next-hop" set to the IP address of the CPEs. 497 When remote CPEs, especially remote virtualized CPEs are dynamically 498 instantiated or removed, the configuration of Multi-Hop EBGP on the 499 PE has to be changed accordingly. 501 Gap: 503 Egress peering engineering (EPE) is not enough. Running BGP on 504 virtualized CPEs in Cloud DC requires GRE tunnels being 505 established first, which in turn requires address and key 506 management for the remote CPEs. RFC 7024 (Virtual Hub & Spoke) and 507 Hierarchical VPN is not enough. 509 Also there is a need for a mechanism to automatically trigger 510 configuration changes on PEs when remote CPEs' are instantiated or 511 moved (leading to an IP address change) or deleted. 513 EBGP Multi-hop design does not include a security mechanism by 514 default. The PE and remote CPEs need secure communication channels 515 when connecting via the public Internet. 517 Remote CPEs, if instantiated in Cloud DCs, might have to traverse 518 NATs to reach PE. It is not clear how BGP can be used between 519 devices outside the NAT and the entities behind the NAT. It is not 520 clear how to configure the Next Hop on the PEs to reach private IPv4 521 addresses. 523 5.4. Designated Forwarder to the remote edges 525 Among the multiple floating PEs that are available for a remote CPE, 526 multicast traffic sent by the remote CPE towards the MPLS VPN can be 527 forwarded back to the remote CPE due to the PE receiving the 528 multicast data frame forwarding the multicast/broadcast frame to 529 other PEs that in turn send to all attached CPEs. This process may 530 cause traffic loops. 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 with the remote CPE, the remote CPE can forward outbound 543 traffic to the Designated Forwarder PE, which in turn forwards 544 traffic to egress PEs and then to the final destinations. However, 545 it is not straightforward for the egress PE to send back the return 546 traffic to 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-WAN 557 deployment. It is necessary for a newly powered up SD-WAN edge 558 node to establish a secure connection (by means of TLS, DTLS, 559 etc.) with 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, since this is the purpose of SD-WAN. See the individual 570 sections above for further discussion of these security gaps. 572 8. IANA Considerations 574 This document requires no IANA actions. RFC Editor: Please remove 575 this section before publication. 577 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-PORT]L. Dunbar, et al, "Subsequent Address Family 594 Indicator for SDWAN Ports", draft-dunbar-idr-sdwan-port- 595 safi-00, Work-in-progress, March 2019. 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 [SECURE-L3VPN] E. Rosen, "Provide Secure Layer L3VPNs over Public 605 Infrastructure", draft-rosen-bess-secure-l3vpn-00, work- 606 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