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