idnits 2.17.1 draft-dm-vpn-ext-to-cloud-dc-problem-statement-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 338 has weird spacing: '...olution shoul...' -- The document date (October 30, 2017) is 2369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'ITU-T-X1036' is defined on line 377, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 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 A. Malis 3 Intended status: Informational Huawei 4 Expires: January 2018 C. Jacquenet 5 Orange 6 October 30, 2017 8 VPN Extension to Dynamic Cloud DC Problem Statement 9 draft-dm-vpn-ext-to-cloud-dc-problem-statement-01 11 Abstract 13 This document describes the problems associated with extending 14 existing VPN that interconnects Enterprise customers' multiple sites 15 to dynamic workloads instantiated in cloud data centers. This 16 document further describes a set of requirements that a solution 17 would need to fulfill to address the problems discussed herein. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, except to publish it 27 as an RFC and to translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on April 30, 2009. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Definition of terms............................................4 65 3. Problems associated with current SD-WAN solutions..............4 66 3.1. Complexity of multi-point any-to-any interconnection......5 67 3.2. Poor performance over long distance.......................6 68 3.3. Scaling Issues with IPsec Tunnels.........................7 69 3.4. End-to-End Security Concern for data flows................7 70 4. Problems associated with MPLS-based VPNs for dynamic applications 71 in the cloud......................................................7 72 5. Requirements for Dynamic Cloud Data Center VPNs................9 73 6. Security Considerations.......................................10 74 7. IANA Considerations...........................................10 75 8. References....................................................10 76 8.1. Normative References.....................................10 77 8.2. Informative References...................................10 78 9. Acknowledgments...............................................11 80 1. Introduction 82 Cloud-based applications and services continue to change how 83 businesses of all sizes work and share information. "Cloud based 84 applications & workloads" are those that are instantiated in third 85 party Data Centers which also host services for other customers. The 86 benefits of these cloud-based applications and services are 87 numerous, including fueling mobility and access to applications 88 anytime, anywhere, and on any device, making collaboration more 89 efficient and easier to manage. 91 With the advent of widely available third party cloud data centers 92 in diverse geographic locations and the advancement of tools for 93 monitoring and predicting application behaviors, it is technically 94 feasible for enterprises to instantiate applications and workloads 95 geographically closest to their end users. This property aids in 96 improving end-to-end latency and overall user experience. 97 Conversely, an enterprise may wish to shutdown applications and 98 workloads that are too far from their end users (therefore removing 99 the networking connection to those deleted applications and 100 workloads). In addition, an Enterprise may wish to take advantage of 101 more and more business applications offered by third party private 102 cloud data centers, such as SAP HANA, Oracle Cloud, Salesforce 103 Cloud, etc. 105 However, given the nature of how most Enterprise VPN networks are 106 built, whether SD-WAN, MPLS-based, or a combination of both, it is 107 difficult (or impossible) for many Enterprises to utilize these 108 cloud-based resources in a flexible and scalable manner with reasons 109 to be elaborated in subsequent sections of this documents. 111 This document describes a number of issues with existing VPN 112 technologies, either SD-WAN or MPLS-based, related to connectivity 113 of Enterprise sites to dynamic workloads instantiated in a cloud 114 data center. The Enterprise Sites include HQ, spokes, on premise 115 data centers, and branch offices as their corresponding VPN features 116 can be different. 118 2. Definition of terms 120 Cloud DC: Off-Premise Data Centers that usually host applications 121 and workload owned by different organizations or 122 tenants. 124 Controller: Used interchangeably with SD-WAN controller to manage 125 SD-WAN overlay path creation/deletion and monitoring the 126 path conditions between two sites. 128 SD-WAN: Software Defined Wide Area Network, which can mean many 129 different things. In this document, "SD-WAN" refers to 130 the solutions specified by ONUG (Open Network User 131 Group), which build point-to-point IPsec overlay paths 132 between two end-points (or branch offices) that need to 133 intercommunicate. 135 3. Problems associated with current SD-WAN solutions 137 A software-defined wide area network (SD-WAN) VPN is an overlay 138 network that decouples the network management function from the 139 physical hardware, using a centralized controller to set policies, 140 prioritize network traffic, establish IPsec [RFC6071] tunnels 141 between enterprise locations to carry the VPN traffic, and to map 142 between internal addresses on the VPN and external addresses on the 143 public Internet. Many enterprises use SD-WAN VPNs as an alternative, 144 or in addition to, more traditional VPNs (such as MPLS-based VPNs 145 [RFC4364] or [RFC4664]). 147 SD-WAN is typically used to control traffic distribution among 148 multiple paths between two end-points, e.g. some paths being MPLS 149 path, others being via public internet. SD-WAN depends on logically 150 centralized network control to utilize real-time traffic management 151 over multiple paths between the two end-points. The virtual overlay, 152 possibly secured by IPsec tunnels, is transported over the public 153 Internet using fiber, cable, or DSL-based Internet access, but can 154 use other types of WAN connections as well, including private or 155 public WAN connections like MPLS, or wireless technologies such as 156 Wi-Fi or 4G/Long Term Evolution (LTE). 158 SD-WAN lets enterprises augment their current network with cost- 159 effective, readily available Broadband Internet connectivity. When 160 used in conjunction with MPLS VPNs, some traffic can be offloaded to 161 SD-WAN overlay paths based on traffic forwarding policy 162 (application-based or otherwise), or when the MPLS VPN connection 163 between the two locations is congested, or otherwise undesirable. 165 3.1. Complexity of multi-point any-to-any interconnection 167 The dynamic workload instantiated in cloud DC needs to communicate 168 with multiple branch offices and on premise data centers. Most 169 enterprises need multi-point interconnection among multiple 170 locations, as done by MPLS L2/L3 VPNs. 172 Using SD-WAN overlay paths to achieve any-to-any mesh 173 interconnection among all branches not only requires all branches 174 CPEs to support SD-WAN, but also require CPEs to manage routing 175 among other CPEs located at other locations, which can increase the 176 complexity of the CPEs when compared to MPLS-based VPN solutions. 178 Today's industry so called "SD-WAN" solutions build point-to-point 179 IPsec overlay paths between two end-points (or branch offices) that 180 need to intercommunicate. This overlay path can serve as a backup to 181 an MPLS path in a hybrid solution, or as the primary path in a 182 stand-alone solution. 184 Whereas, MPLS-based VPNs have their PEs directly connected to the 185 CEs. Therefore, CEs only need to forward all traffic with 186 destinations attached to remote CEs to the directly attached PEs, 187 leaving all the routing to remote destinations to the PEs, thereby 188 reducing the complexity of CPEs. Even for multi-home CPEs, the CPEs 189 only need to route traffic among the PEs that the CPEs are directly 190 attached to. But the SD-WAN's CPE needs to route the traffic among 191 all other CPEs. 193 For an enterprise with multiple sites, using SD-WAN overlay paths 194 among sites requires each CPE to manage all the addresses that local 195 hosts have the potential to reach, i.e. map internal VPN addresses 196 to appropriate SD-WAN paths. This is similar to the complexity of 197 Frame Relay-based VPNs, where each CPE needed to maintain mesh 198 routing for all destinations if they were to avoid an extra hop 199 through a hub router. That is one of the primary reasons most 200 enterprise networks transitioned to MPLS-based VPNs from Frame 201 Relay. Even though SD-WAN CPEs can get assistance from a central 202 controller (instead of performing their own routing protocol) to 203 resolve the mapping between destinations and SD-WAN paths, SD-WAN 204 CPEs are still responsible for routing table maintenance as remote 205 destinations change their attachments, e.g. the dynamic workload in 206 other DCs are de-commissioned or added. 208 3.2. Poor performance over long distance 210 When CPEs are far apart from each other or across particular 211 boundaries, whether political (e.g. country boundary) or related to 212 Internet topology, performance over the public Internet can be 213 problematic and unpredictable. Even though there are many monitoring 214 tools available to measure delay and various performance 215 characteristics of the network, the measurement for paths over the 216 Internet is passive and past measurements may not represent future 217 performance. 219 To compensate for delay over the Internet, most content today is 220 hosted by data centers closest to end users. E2E services usually do 221 not traverse long distances, but rather between end users and local 222 data centers. Content distribution to the edges has transformed user 223 experience of accessing content over the Internet. 225 However, SD-WAN is about connecting two geographically different 226 locations, which is very different from today's experience of 227 accessing various websites over the Internet. 229 3.3. Scaling Issues with IPsec Tunnels 230 IPsec is used by SD-WAN to achieve secure overlay connections 231 between two locations over any underlay network. 232 For a simple SD-WAN overlay between a small number of fixed branch 233 offices, each CPE only needs to terminate a very small number of 234 IPsec tunnels, which will be for the most part static in nature. 235 However, for multiple branches to reach workloads hosted in cloud 236 DCs, the SD-WAN solution requires a Cloud DC gateway to maintain 237 individual IPsec tunnels between the Cloud DC gateway and each 238 individual branch office. For a company with hundreds or thousands 239 of locations, there could be hundreds (or even thousands) of IPsec 240 tunnels terminating at the Cloud DC gateway, which can be very 241 processing intensive for the gateway. Many routers today have 242 limited capacity to support a large number of IPsec tunnels. 244 3.4. End-to-End Security Concern for data flows 245 When IPsec tunnels from enterprise on-premise CPEs are terminated 246 at the Cloud DC gateway where the workloads or applications are 247 hosted, some enterprises have concerns regarding traffic to/from 248 their workload being exposed to others behind the data center 249 gateway (e.g., exposed to other organizations that have workloads 250 in the same data center). 251 To ensure that traffic to/from workloads is not exposed to 252 unwanted entities, it's necessary to have the IPsec tunnels go all 253 the way to the workload (say servers, or VMs) within the DC. 255 4. Problems associated with MPLS-based VPNs for dynamic applications in 256 the cloud 258 Traditional VPNs (e.g., MPLS based L2/L3 VPNs) that most businesses 259 use to connect their branch offices are isolated, secure and 260 reliable, but they cannot keep up in the cloud-based world. One of 261 the key roadblocks for achieving this dynamic workload instantiation 262 is the lack of flexible & secure network connectivity to workloads 263 in third party cloud data centers. Another roadblock is the lack of 264 a standard way to express and enforce consistent security policies 265 to their workload [RFC8192]. The traditional VPN path and bandwidth 266 are not flexible enough in supporting the need for enterprises to 267 connect to dynamically instantiated (or removed) workloads and 268 applications at any place (i.e., third party cloud data centers). 270 The current business environment is characterized by dramatic and 271 constant changes, especially around the IT space. Those changes 272 include: 274 - The movement on the part of most businesses to adopt digital 275 business initiatives, such as variety of data & behavior 276 analytic tools for end customers, employees, and products. 277 Those tools need to be running close to their targets to 278 achieve optimal results. 279 - Broad adoption of public cloud computing services. 280 - Deployment of WAN solutions based on new architectural 281 approaches. 282 - The dramatic increase in the number and sophistication of 283 security attacks. 285 Traditional MPLS-based VPNs have been widely deployed as an 286 effective way to support business and organizations that require 287 network performance and reliability. MPLS shifted the burden of 288 managing a VPN service from enterprises to service providers. The 289 CPEs for MPLS VPN are also simpler and less expensive, since they do 290 not need to manage how to send packets to remote sites, they simply 291 pass all outbound traffic to the MPLS VPN PEs to which the CPEs are 292 attached. MPLS has addressed the problems of scale, availability, 293 and fast recovery from network faults, and incorporates traffic 294 engineering to ensure guaranteed bandwidth for high priority 295 traffic. 297 However, traditional MPLS-based VPNs are not optimized for 298 connecting to dynamic applications in cloud data centers because: 300 - It's not easy to add/remove VPN's PEs at dynamic locations. It 301 takes a relatively long time to deploy provider edge routers at 302 new locations. When enterprise's workloads are changed from one 303 cloud DC to another (i.e., removed from one DC and re- 304 instantiated to another location when demand changes), the 305 enterprise branch offices need to be connected to the new cloud 306 DC. 308 The big drive for moving workloads into the cloud comes from 309 widely available cloud DCs at geographically diverse locations 310 that apps can be instantiated so that they can be close to 311 their users. When the user base changes, the applications can 312 be quickly moved to a new cloud DC location closest to the new 313 user base. 315 - The third party cloud data center where an enterprise chooses 316 to host workloads for easy access to its clients may not be 317 connected to the Provider Edge (PE) nodes of the enterprise's 318 VPN. 319 - Many cloud data centers do not expose its internal network for 320 provider MPLS based VPNs to reach the workload natively & 321 securely. 322 - Many data centers use some forms of encapsulation, i.e. VxLAN, 323 STT, NSH, etc. There has not been any standard to address the 324 interworking to those encapsulations. 325 - 327 5. Requirements for Dynamic Cloud Data Center VPNs 329 In order to address the aforementioned issues, any solution for 330 enterprise VPNs that includes connectivity to dynamic workloads or 331 applications in cloud data centers should satisfy a set of 332 requirements: 334 - The solution should allow enterprises to take advantage of the 335 current state of the art in VPN technology, both in traditional 336 MPLS-based VPNs and IPsec-based VPNs (or any combination 337 thereof) that run over the top of the public Internet. 338 - The solution shouldn't require enterprise to upgrade all their 339 existing CPEs. . 340 - The solution shouldn't require either CPEs or routers to 341 support more than xx IPsec tunnels simultaneously. 342 - The solution needs to support easy and fast VPN connections to 343 dynamic workloads and applications in third party data centers, 344 and easily allow these workloads to migrate both within a data 345 center and between data centers. 347 - Allow VPNs to provide bandwidth and other performance 348 guarantees. 349 - Be a cost-effective solution for enterprises to incorporate 350 dynamic cloud-based applications and workloads into their 351 existing VPN environment. 353 6. Security Considerations 355 For the most part, we introduce no new security concerns beyond 356 those of existing MPLS=based VPNs, which are extremely widely 357 deployed. The one addition to MPLS VPNs is selective use of SD-WAN, 358 which uses IPsec tunnels. 360 7. IANA Considerations 362 This document requires no IANA actions. RFC Editor: Please remove 363 this section before publication. 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 8.2. Informative References 374 [RFC8192] S. Hares, et al "Interface to Network Security Functions 375 (I2NSF) Problem Statement and Use Cases", July 2017 377 [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, 378 storage, distribution and enforcement of policies for 379 network security", Nov 2007. 381 [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and 382 Internet Key Exchange (IKE) Document Roadmap", Feb 2011. 384 [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 385 Networks (VPNs)", Feb 2006 387 [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual 388 Private Networks (L2VPNs)", Sept 2006. 390 9. Acknowledgments 392 Acknowledgements to Jim Guichard for his review and contributions. 394 This document was prepared using 2-Word-v2.0.template.dot. 396 Authors' Addresses 398 Linda Dunbar 399 Huawei 400 Email: Linda.Dunbar@huawei.com 402 Andrew G. Malis 403 Huawei 404 Email: agmalis@gmail.com 406 Christian Jacquenet 407 France Telecom 408 Rennes, 35000 409 France 410 Email: Christian.jacquenet@orange.com