idnits 2.17.1 draft-ietf-rtgwg-net2cloud-gap-analysis-07.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 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2020) is 1369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MEF-Cloud' is mentioned on line 134, but not defined == Missing Reference: 'RFC3489' is mentioned on line 266, but not defined ** Obsolete undefined reference: RFC 3489 (Obsoleted by RFC 5389) == Missing Reference: 'RFC6325' is mentioned on line 321, but not defined == Missing Reference: 'RFC2332' is mentioned on line 346, but not defined == Missing Reference: 'Secure-EVPN' is mentioned on line 496, but not defined == Missing Reference: 'BGP-Edge-DISCOVERY' is mentioned on line 492, but not defined == Missing Reference: 'BGP-Edge-Discovery' is mentioned on line 499, but not defined == Missing Reference: 'RFC4364' is mentioned on line 506, but not defined == Unused Reference: 'RFC2119' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC8192' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC5521' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'BGP-EDGE-DISCOVERY' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 659, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-dunbar-idr-sdwan-edge-discovery-00 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-17 == Outdated reference: A later version (-06) exists of draft-sajassi-bess-secure-evpn-01 == 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 (~~), 19 warnings (==), 1 comment (--). 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: January 26, 2021 Malis Consulting 5 C. Jacquenet 6 Orange 7 July 26, 2020 9 Networks Connecting to Hybrid Cloud DCs: Gap Analysis 10 draft-ietf-rtgwg-net2cloud-gap-analysis-07 12 Abstract 14 This document analyzes the IETF routing area technical gaps that may 15 affect the dynamic connection to workloads and applications hosted 16 in hybrid Cloud Data Centers from enterprise premises. 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 January 26, 2009. 41 Copyright Notice 43 Copyright (c) 2020 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...................................................3 59 2. Conventions used in this document..............................3 60 3. Gap Analysis for Accessing Cloud Resources.....................4 61 3.1. Multiple PEs connecting to virtual CPEs in Cloud DCs......6 62 3.2. Access Control for workloads in the Cloud DCs.............6 63 3.3. NAT Traversal.............................................7 64 3.4. BGP between PEs and remote CPEs via Internet..............7 65 3.5. Multicast traffic from/to the remote edges................8 66 4. Gap Analysis of Traffic over Multiple Underlay Networks........9 67 5. Aggregating VPN paths and Internet paths......................10 68 5.1. Control Plane for Cloud Access via Heterogeneous Networks11 69 5.2. Using BGP UPDATE Messages................................12 70 5.2.1. Lack ways to differentiate traffic in Cloud DCs.....12 71 5.2.2. Miss attributes in Tunnel-Encap.....................12 72 5.3. SECURE-EVPN/BGP-EDGE-DISCOVERY...........................12 73 5.4. SECURE-L3VPN.............................................13 74 5.5. Preventing attacks from Internet-facing ports............14 75 6. Gap Summary...................................................14 76 7. Manageability Considerations..................................15 77 8. Security Considerations.......................................16 78 9. IANA Considerations...........................................16 79 10. References...................................................16 80 10.1. Normative References....................................16 81 10.2. Informative References..................................16 82 11. Acknowledgments..............................................17 84 1. Introduction 86 [Net2Cloud-Problem] describes the problems enterprises face today 87 when interconnecting their branch offices with dynamic workloads 88 hosted in third party data centers (a.k.a. Cloud DCs). In 89 particular, this document analyzes the available routing protocols 90 to identify whether there are any gaps that may impede such 91 interconnection which may for example justify additional 92 specification effort to define proper protocol extensions. 94 For the sake of readability, an edge, C-PE, or CPE are used 95 interchangeably throughout this document. More precisely: 97 . Edge: may include multiple devices (virtual or physical); 98 . C-PE: provider-owned edge, e.g. for SECURE-EVPN's PE-based 99 BGP/MPLS VPN, where PE is the edge node; 100 . CPE: device located in enterprise premises. 102 2. Conventions used in this document 104 Cloud DC: Third party Data Centers that usually host applications 105 and workload owned by different organizations or 106 tenants. 108 Controller: Used interchangeably with Overlay controller to manage 109 overlay path creation/deletion and monitor the path 110 conditions between sites. 112 CPE-Based VPN: Virtual Private Network designed and deployed from 113 CPEs. This is to differentiate from most commonly used 114 PE-based VPNs a la RFC 4364. 116 OnPrem: On Premises data centers and branch offices 118 3. Gap Analysis for Accessing Cloud Resources 120 Because of the ephemeral property of the selected Cloud DCs for 121 specific workloads/Apps, an enterprise or its network service 122 provider may not have direct physical connections to the Cloud DCs 123 that are optimal for hosting the enterprise's specific 124 workloads/Apps. Under those circumstances, an overlay network design 125 can be an option to interconnect the enterprise's on-premises data 126 centers & branch offices to its desired Cloud DCs. 128 However, overlay paths established over the public Internet can have 129 unpredictable performance, especially over long distances. 130 Therefore, it is highly desirable to minimize the distance or the 131 number of segments that traffic had to be forwarded over the public 132 Internet. 134 The Metro Ethernet Forum's Cloud Service Architecture [MEF-Cloud] 135 also describes a use case of network operators using Overlay paths 136 over an LTE network or the public Internet for the last mile access 137 where the VPN service providers cannot always provide the required 138 physical infrastructure. 140 In some scenarios, some overlay edge nodes may not be directly 141 attached to the PEs that participate to the delivery and the 142 operation of the enterprise's VPN. 144 When using an overlay network to connect the enterprise's sites to 145 the workloads hosted in Cloud DCs, the existing C-PEs at 146 enterprise's sites have to be upgraded to connect to the said 147 overlay network. If the workloads hosted in Cloud DCs need to be 148 connected to many sites, the upgrade process can be very expensive. 150 [Net2Cloud-Problem] describes a hybrid network approach that extends 151 the existing MPLS-based VPNs to the Cloud DC Workloads over the 152 access paths that are not under the VPN provider's control. To make 153 it work properly, a small number of the PEs of the BGP/MPLS VPN can 154 be designated to connect to the remote workloads via secure IPsec 155 tunnels. Those designated PEs are shown as fPE (floating PE or 156 smart PE) in Figure 3. Once the secure IPsec tunnels are 157 established, the workloads hosted in Cloud DCs can be reached by the 158 enterprise's VPN without upgrading all of the enterprise's CPEs. The 159 only CPE that needs to connect to the overlay network would be a 160 virtualized CPE instantiated within the cloud DC. 162 +--------+ +--------+ 163 | Host-a +--+ +----| Host-b | 164 | | | (') | | 165 +--------+ | +-----------+ ( ) +--------+ 166 | +-+--+ ++-+ ++-+ +--+-+ (_) 167 | | CPE|--|PE| |PE+--+ CPE| | 168 +--| | | | | | | |---+ 169 +-+--+ ++-+ ++-+ +----+ 170 / | | 171 / | MPLS +-+---+ +--+-++--------+ 172 +------+-+ | Network |fPE-1| |CPE || Host | 173 | Host | | | |- --| || d | 174 | c | +-----+ +-+---+ +--+-++--------+ 175 +--------+ |fPE-2|-----+ 176 +---+-+ (|) 177 (|) (|) Overlay 178 (|) (|) over any access 179 +=\======+=========+ 180 // \ | Cloud DC \\ 181 // \ ++-----+ \\ 182 + | 183 | vCPE | 184 +-+----+ 185 ----+-------+-------+----- 186 | | 187 +---+----+ +---+----+ 188 | Remote | | Remote | 189 | App-1 | | App-2 | 190 +--------+ +--------+ 192 Figure 1: VPN Extension to Cloud DC 194 In Figure 1, the optimal Cloud DC to host the workloads (as a 195 function of the proximity, capacity, pricing, or any other criteria 196 chosen by the enterprises) does not have a direct connection to the 197 PEs of the NGP/MPLS VPN that interconnects the enterprise's sites. 199 3.1. Multiple PEs connecting to virtual CPEs in Cloud DCs 201 To extend BGP/MPLS VPNs to virtual CPEs in Cloud DCs, it is 202 necessary to establish secure tunnels (such as IPsec tunnels) 203 between the PEs and the vCPEs. 205 Even though a set of PEs can be manually selected for a specific 206 cloud data center, there are no standard protocols for those PEs to 207 interact with the vCPEs instantiated in the third party cloud data 208 centers over unsecure networks. The interaction includes exchanging 209 performance, route information, etc.. 211 When there is more than one PE available for use (as there should be 212 for resiliency purposes or because of the need to support multiple 213 cloud DCs geographically scattered), it is not straightforward to 214 designate an egress PE to remote vCPEs based on applications. It 215 might not be possible for PEs to recognize all applications because 216 too much traffic traversing the PEs. 218 When there are multiple floating PEs that have established IPsec 219 tunnels with a remote CPE, the remove CPE can forward outbound 220 traffic to the optimal PE, which in turn forwards traffic to egress 221 PEs to reach the final destinations. However, it is not 222 straightforward for the ingress PE to select which egress PEs to 223 send traffic. For example, in Figure 1: 225 - fPE-1 is the optimal PE for communication between App-1 <-> 226 Host-a due to latency, pricing or other criteria. 228 - fPE-2 is the optimal PE for communication between App-1 <-> 229 Host-b. 231 3.2. Access Control for workloads in the Cloud DCs 233 There is widespread diffusion of access policy for Cloud Resource, 234 some of which is not easy for verification and validation. Because 235 there are multiple parties involved in accessing Cloud Resources, 236 policy enforcement points are not easily visible for policy 237 refinement, monitoring, and testing. 239 The current state of the art for specifying access policies for 240 Cloud Resources could be improved by having automated and reliable 241 tools to map the user-friendly (natural language) rules into machine 242 readable policies and to provide interfaces for enterprises to self- 243 manage policy enforcement points for their own workloads. 245 3.3. NAT Traversal 247 Cloud DCs that only assign private IPv4 addresses to the 248 instantiated workloads assume that traffic to/from the workload 249 usually needs to traverse NATs. 251 There is no automatic way for an enterprise's network controller to 252 be informed of the NAT properties for its workloads in Cloud DCs 254 One potential solution could be utilizing the messages sent during 255 initialization of an IKE VPN when NAT Traversal option is enabled. 256 There are some inherent problems while sending IPSec packets through 257 NAT devices. One way to overcome these problems is to encapsulate 258 IPSec packets in UDP. To do this effectively, there is a discovery 259 phase in IKE (Phase1) that tries to determine if either of the IPSec 260 gateways is behind a NAT device. If a NAT device is found, IPSec- 261 over-UDP is proposed during IPSec (Phase 2) negotiation. If there is 262 no NAT device detected, IPSec is used 264 Another potential solution could be allowing the virtual CPE in 265 Cloud DCs to solicit a STUN (Session Traversal of UDP Through 266 Network Address Translation, [RFC3489]) Server to get the 267 information about the NAT property, the public IP addresses and port 268 numbers so that such information can be communicated to the relevant 269 peers. 271 3.4. BGP between PEs and remote CPEs via Internet 273 Even though an EBGP (external BGP) Multi-Hop design can be used to 274 connect peers that are not directly connected to each other, there 275 are still some issues about extending BGP from MPLS VPN PEs to 276 remote CPEs in cloud DCs via any access path (e.g., Internet). 278 The path between the remote CPEs and VPN PEs that maintain VPN 279 routes can traverse untrusted segments. 281 EBGP Multi-hop design requires configuration on both peers, either 282 manually or via NETCONF from a controller. To use EBGP between a PE 283 and remote CPEs, the PE has to be manually configured with the 284 "next-hop" set to the IP address of the CPEs. When remote CPEs, 285 especially remote virtualized CPEs are dynamically instantiated or 286 removed, the configuration of Multi-Hop EBGP on the PE has to be 287 changed accordingly. 289 Egress peering engineering (EPE) is not sufficient. Running BGP on 290 virtualized CPEs in Cloud DCs requires GRE tunnels to be 291 established first, which requires the remote CPEs to support 292 address and key management capabilities. RFC 7024 (Virtual Hub & 293 Spoke) and Hierarchical VPN do not support the required 294 properties. 296 Also, there is a need for a mechanism to automatically trigger 297 configuration changes on PEs when remote CPEs' are instantiated or 298 moved (leading to an IP address change) or deleted. 300 EBGP Multi-hop design does not include a security mechanism by 301 default. The PE and remote CPEs need secure communication channels 302 when connecting via the public Internet. 304 Remote CPEs, if instantiated in Cloud DCs might have to traverse 305 NATs to reach PEs. It is not clear how BGP can be used between 306 devices located beyond the NAT and the devices located behind the 307 NAT. It is not clear how to configure the Next Hop on the PEs to 308 reach private IPv4 addresses. 310 3.5. Multicast traffic from/to the remote edges 312 Among the multiple floating PEs that are reachable from a remote CPE 313 in a Cloud DC, multicast traffic sent by the remote CPE towards the 314 MPLS VPN can be forwarded back to the remote CPE due to the PE 315 receiving the multicast packets forwarding the multicast/broadcast 316 frame to other PEs that in turn send to all attached CPEs. This 317 process may cause traffic loops. 319 This problem can be solved by selecting one floating PE as the CPE's 320 Designated Forwarder, similar to TRILL's Appointed Forwarders 321 [RFC6325]. 323 BGP/MPLS VPNs do not have features like TRILL's Appointed 324 Forwarders. 326 4. Gap Analysis of Traffic over Multiple Underlay Networks 328 Very often the Hybrid Cloud DCs are interconnected by multiple types 329 of underlay networks, such as VPN, public Internet, wireless and 330 wired infrastructures, etc. Sometimes the enterprises' VPN providers 331 do not have direct access to the Cloud DCs that host some specific 332 applications or workloads operated by the enterprise. 334 When reached by an untrusted network, all sensitive data to/from 335 this virtual CPE have to be encrypted, usually by means of IPsec 336 tunnels. When reached by a trusted direct connect paths, sensitive 337 data can be forwarded without encryption for better performance. 339 If a virtual CPE in Cloud DC can be reached by both trusted and 340 untrusted paths, better performance can be achieved to have a mixed 341 encrypted and unencrypted traffic depending which paths the traffic 342 is forwarded. However, there is no appropriate control plane 343 protocol to achieve this automatically. 345 Some networks achieve the IPsec tunnel automation by using the 346 modified NHRP protocol [RFC2332] to register network facing ports of 347 the edge nodes with their Controller (or NHRP server), which then 348 maps a private VPN address to a public IP address of the destination 349 node/port. DSVPN [DSVPN] or DMVPN [DMVPN] are used to establish 350 tunnels between WAN ports of SDWAN edge nodes. 352 NHRP was originally intended for ATM address resolution, and as a 353 result, it misses many attributes that are necessary for dynamic 354 virtual C-PE registration to the controller, such as: 356 - Interworking with the MPLS VPN control plane. An overlay edge can 357 have some ports facing the MPLS VPN network over which packets can 358 be forwarded without any encryption and some ports facing the 359 public Internet over which sensitive traffic needs to be 360 encrypted. 361 - Scalability: NHRP/DSVPN/DMVPN work fine with small numbers of edge 362 nodes. When a network has more than 100 nodes, these protocols do 363 not scale well. 364 - NHRP does not have the IPsec attributes, which are needed for 365 peers to build Security Associations over the public Internet. 366 - NHRP messages do not have any field to encode the C-PE supported 367 encapsulation types, such as IPsec-GRE or IPsec-VxLAN. 368 - NHRP messages do not have any field to encode C-PE Location 369 identifiers, such as Site Identifier, System ID, and/or Port ID. 370 - NHRP messages do not have any field to describe the gateway(s) to 371 which the C-PE is attached. When a C-PE is instantiated in a Cloud 372 DC, it is desirable for the C-PE's owner to be informed about how 373 and where the C-PE is attached. 374 - NHRP messages do not have any field to describe C-PE's NAT 375 properties if the C-PE is using private IPv4 addresses, such as 376 the NAT type, Private address, Public address, Private port, 377 Public port, etc. 379 5. Aggregating VPN paths and Internet paths 381 Most likely, enterprises (especially the largest ones) already have 382 their C-PEs interconnected by VPNs, based upon VPN techniques like 383 EVPN, L2VPN, or L3VPN. Their VPN providers might have direct 384 paths/links to the Cloud DCs that host their workloads and 385 applications. 387 When there is short term high traffic volume that can't justify 388 increasing the VPNs capacity, enterprises can utilize public 389 internet to reach their Cloud vCPEs. Then it is necessary for the 390 vCPEs to communicate with the controller on how traffic is 391 distributed among multiple heterogeneous underlay networks and to 392 manage secure tunnels over untrusted networks. 394 +---+ 395 +--------------|RR |----------+ 396 / Untrusted +-+-+ \ 397 / +---------------------- 398 / | \ Cloud DC 399 +----+ +---------+ packets encrypted over | +------+ +----+ 400 | TN3|--| A1-----+ Untrusted +-------+ |--| TN1| 401 +----+ | C-PE A2-\ | | vCPE | +----+ 402 +----+ | A A3--+--+ +---+ | | B | +----+ 403 | TN2|--| | |PE+--------------+PE |---+ |--| TN3| 404 +----+ +---------+ +--+ trusted +---+ | +------+ +----+ 405 | WAN | | 406 +----+ +---------+ +--+ packets +---+ | +------+ +----+ 407 | TN1|--| C1--|PE| go natively |PE |---+ |--| TN1| 408 +----+ | C-PE C2--+--+ without encry+---+ | | vCPE | +----+ 409 | C | +--------------+ | | D | 410 | | | | | 411 +----+ | C3--| without encrypt over | | | +----+ 412 | TN2|--| C4--+---- Untrusted --+------+ |--| TN2| 413 +----+ +---------+ | +------+ +----+ 414 | 415 +------------------------ 416 Figure 2: vCPEs reached by Hybrid Paths 418 5.1. Control Plane for Cloud Access via Heterogeneous Networks 420 The Control Plane for managing applications and workloads in cloud 421 DCs reachable by heterogeneous networks need to include the 422 following properties: 424 - vCPE in a cloud DCs needs to communicate with its controller of 425 the properties of the directly connected underlay networks. 427 - Need Controller-facilitated IPsec SA attributes and NAT 428 information distribution 429 o The controller facilitates and manages the peer 430 authentication for all IPsec tunnels terminated at the 431 vCPEs. 433 - Establishing and Managing the topology and reachability for 434 services attached to the vCPEs in Cloud DCs. 435 o This is for the overlay layer's route distribution, so 436 that a vCPE can populate its overlay routing table with 437 entries that identify the next hop for reaching a specific 438 route/service attached to the vCPEs. 440 5.2. Using BGP UPDATE Messages 442 5.2.1. Lack ways to differentiate traffic in Cloud DCs 444 One enterprise can have different types of applications in one Cloud 445 DC. Some can be production applications, some can be testing 446 applications, and some can belong to one specific departments. The 447 traffic to/from different applications might need to traverse 448 different network paths or need to be differentiated by Control 449 plane and data plane. 451 BGP already has built-in mechanisms, like Route Target, to 452 differentiate different VPNs. But Route Target (RT) is for MPLS 453 based VPNs, therefore RT is not appropriate to directly apply to 454 virtual paths laid over mixed VPNs, IPsec or public underlay 455 networks. 457 5.2.2. Miss attributes in Tunnel-Encap 459 [Tunnel-Encap] describes the BGP UPDATE Tunnel Path Attribute that 460 advertises endpoints' tunnel encapsulation capabilities for the 461 respective attached client routes encoded in the MP-NLRI Path 462 Attribute. The receivers of the BGP UPDATE can use any of the 463 supported encapsulations encoded in the Tunnel Path Attribute for 464 the routes encoded in the MP-NLRI Path Attribute. 466 Here are some of the issues raised by using [Tunnel-Encap] to 467 distribute the property of client routes be carried by mixed of 468 hybrid networks: 470 - [Tunnel-Encap] doesn't have encoding methods to advertise that a 471 route can be carried by mixed of IPsec tunnels and other already 472 supported tunnels. 473 - The mechanism defined in [Tunnel-Encap] does not facilitate the 474 exchange of IPsec SA-specific attributes. 476 5.3. SECURE-EVPN/BGP-EDGE-DISCOVERY 478 [SECURE-EVPN] describes a solution that utilize BGP as control plane 479 for the Scenario #1 described in [BGP-SDWAN-Usage]. It relies upon a 480 BGP cluster design to facilitate the key and policy exchange among 481 PE devices to create private pair-wise IPsec Security Associations. 482 [Secure-EVPN] attaches all the IPsec SA information to the actual 483 client routes. 485 [BGP-Edge-DISCOVERY] proposes BGP UPDATEs from client routers only 486 include the IPsec SA identifiers (ID) to reference the IPsec SA 487 attributes being advertised by separate Underlay Property BGP UPDATE 488 messages. If a client route can be encrypted by multiple IPsec SAs, 489 then multiple IPsec SA IDs are included in the Tunnel-Encap Path 490 attribute for the client route. 492 [BGP-Edge-DISCOVERY] proposes detailed IPsec SA attributes are 493 advertised in a separate BGP UPDATE for the underlay networks. 495 [Secure-EVPN] and [BGP-Edge-Discovery] differs in the information 496 included in the client routes. [Secure-EVPN] attaches all the IPsec 497 SA information to the actual client routes, whereas the [BGP-Edge- 498 Discovery] only includes the IPsec SA IDs for the client routes. The 499 IPsec SA IDs used by [BGP-Edge-Discovery] is pointing to the SA- 500 Information which are advertised separately, with all the SA- 501 Information attached to routes which describe the SDWAN underlay, 502 such as WAN Ports or Node address. 504 5.4. SECURE-L3VPN 506 [SECURE-L3VPN] describes a method to enrich BGP/MPLS VPN [RFC4364] 507 capabilities to allow some PEs to connect to other PEs via public 508 networks. [SECURE-L3VPN] introduces the concept of Red Interface & 509 Black Interface used by PEs, where the RED interfaces are used to 510 forward traffic into the VPN, and the Black Interfaces are used 511 between WAN ports through which only IPsec-formatted packets are 512 forwarded to the Internet or to any other backbone network, thereby 513 eliminating the need for MPLS transport in the backbone. 515 [SECURE-L3VPN] assumes PEs use MPLS over IPsec when sending traffic 516 through the Black Interfaces. 518 [SECURE-L3VPN] is useful, but it misses the aspects of aggregating 519 VPN and Internet underlays. In addition: 521 - The [SECURE-L3VPN] assumes that a CPE "registers" with the RR. 522 However, it does not say how. It assumes that the remote CPEs are 523 pre-configured with the IPsec SA manually. For overlay networks to 524 connect Hybrid Cloud DCs, Zero Touch Provisioning is expected. 525 Manual configuration is not an option. 527 - The [SECURE-L3VPN] assumes that C-PEs and RRs are connected via an 528 IPsec tunnel. For management channel, TLS/DTLS is more economical 529 than IPsec. The following assumption made by [SECURE-L3VPN] can be 530 difficult to meet in the environment where zero touch provisioning 531 is expected: 532 A CPE must also be provisioned with whatever additional 533 information is needed in order to set up an IPsec SA with 534 each of the red RRs 536 - IPsec requires periodic refreshment of the keys. The [SECURE- 537 L3VPN] does not provide any information about how to synchronize 538 the refreshment among multiple nodes. 539 - IPsec usually sends configuration parameters to two endpoints only 540 and lets these endpoints negotiate the key. The [SECURE-L3VPN] 541 assumes that the RR is responsible for creating/managing the key 542 for all endpoints. When one endpoint is compromised, all other 543 connections may be impacted. 545 5.5. Preventing attacks from Internet-facing ports 547 When C-PEs have Internet-facing ports, additional security risks are 548 raised. 550 To mitigate security risks, in addition to requiring Anti-DDoS 551 features on C-PEs, it is necessary for C-PEs to support means to 552 determine whether traffic sent by remote peers is legitimate to 553 prevent spoofing attacks, in particular. 555 6. Gap Summary 557 Here is the summary of the technical gaps discussed in this 558 document: 560 - For Accessing Cloud Resources 562 a) Traffic Path Management: when a remote vCPE can be reached by 563 multiple PEs of one provider VPN network, it is not 564 straightforward to designate which egress PE to the remote 565 vCPE based on applications or performance. 566 b) NAT Traversal: There is no automatic way for an enterprise's 567 network controller to be informed of the NAT properties for 568 its workloads in Cloud DCs. 569 c) There is no loop prevention for the multicast traffic to/from 570 remote vCPE in Cloud DCs. 572 Needs a feature like Appointed Forwarder specified by TRILL to 573 prevent multicast data frames from looping around. 575 d) BGP between PEs and remote CPEs via untrusted networks. 577 - Missing control plane to manage the propagation of the property of 578 networks connected to the virtual nodes in Cloud DCs. 580 BGP UPDATE propagate client's routes information, but don't 581 distinguish underlay networks. 583 - Issues of aggregating traffic over private paths and Internet 584 paths 586 a) Control plane messages for different overlay segmentations 587 needs to be differentiated. User traffic belonging to 588 different segmentations need to be differentiated. 589 b) BGP Tunnel Encap doesn't have ways to indicate a route or 590 prefix that can be carried by both IPsec tunnels and VPN 591 tunnels 592 c) Missing clear methods in preventing attacks from Internet- 593 facing ports 595 7. Manageability Considerations 597 Zero touch provisioning of overlay networks to interconnect Hybrid 598 Clouds is highly desired. It is necessary for a newly powered up 599 edge node to establish a secure connection (by means of TLS, DTLS, 600 etc.) with its controller. 602 8. Security Considerations 604 Cloud Services are built upon shared infrastructures, therefore 605 not secure by nature. 607 Secure user identity management, authentication, and access 608 control mechanisms are important. Developing appropriate security 609 measurements can enhance the confidence needed by enterprises to 610 fully take advantage of Cloud Services. 612 9. IANA Considerations 614 This document requires no IANA actions. RFC Editor: Please remove 615 this section before publication. 617 10. References 619 10.1. Normative References 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 10.2. Informative References 626 [RFC8192] S. Hares, et al, "Interface to Network Security Functions 627 (I2NSF) Problem Statement and Use Cases", July 2017 629 [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent 630 Address Family Identifier (SAFI) and the BGP Tunnel 631 Encapsulation Attribute", April 2009. 633 [BGP-EDGE-DISCOVERY] L. Dunbar, et al, "BGP UPDATE for SDWAN Edge 634 Discovery ", draft-dunbar-idr-sdwan-edge-discovery-00, 635 Work-in-progress, July 2020. 637 [BGP-SDWAN-Usage] L. Dunbar, et al, "BGP Usage for SDWAN Overlay 638 Networks ", draft-dunbar-bess-bgp-sdwan-usage-08, work-in- 639 progress, July 2020. 641 [Tunnel-Encap] K. Patel, et al, "The BGP Tunnel Encapsulation 642 Attribute", draft-ietf-idr-tunnel-encaps-17, July 2020. 644 [SECURE-EVPN] A. Sajassi, et al, draft-sajassi-bess-secure-evpn-01, 645 work in progress, March 2019. 647 [SECURE-L3VPN] E. Rosen, "Provide Secure Layer L3VPNs over Public 648 Infrastructure", draft-rosen-bess-secure-l3vpn-00, work- 649 in-progress, July 2018 651 [DMVPN] Dynamic Multi-point VPN: 652 https://www.cisco.com/c/en/us/products/security/dynamic- 653 multipoint-vpn-dmvpn/index.html 655 [DSVPN] Dynamic Smart VPN: 656 http://forum.huawei.com/enterprise/en/thread-390771-1- 657 1.html 659 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 660 storage, distribution and enforcement of policies for 661 network security", Nov 2007. 663 [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect 664 Underlay to Cloud Overlay Problem Statement", draft-dm- 665 net2cloud-problem-statement-02, June 2018 667 11. Acknowledgments 669 Acknowledgements to John Drake for his review and contributions. 670 Many thanks to John Scudder for stimulating the clarification 671 discussion on the Tunnel-Encap draft so that our gap analysis can be 672 more accurate. 674 This document was prepared using 2-Word-v2.0.template.dot. 676 Authors' Addresses 678 Linda Dunbar 679 Futurewei 680 Email: ldunbar@futurewei.com 682 Andrew G. Malis 683 Malis Consulting 684 Email: agmalis@gmail.com 686 Christian Jacquenet 687 Orange 688 Rennes, 35000 689 France 690 Email: Christian.jacquenet@orange.com