[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-dm-net2cloud-problem-statement

Network Working Group                                         L. Dunbar
Internet Draft                                                 A. Malis
Intended status: Informational                                   Huawei
Expires: January 2018                                      C. Jacquenet
                                                                  Orange
                                                       October 30, 2017



            VPN Extension to Dynamic Cloud DC Problem Statement
       draft-dm-vpn-ext-to-cloud-dc-problem-statement-00

Abstract

   This document describes the problems associated with extending
   existing VPN that interconnects Enterprise customers' multiple sites
   to dynamic workloads instantiated in cloud data centers. This
   document further describes a set of requirements that a solution
   would need to fulfill to address the problems discussed herein.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt




xxx, et al.             Expires April 30, 2018                 [Page 1]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 30, 2009.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents


   1. Introduction...................................................3
   2. Definition of terms............................................4
   3. Problems associated with current SD-WAN solutions..............4
      3.1. Complexity of multi-point any-to-any interconnection......5
      3.2. Poor performance over long distance.......................6
      3.3. Scaling Issues with IPsec Tunnels.........................7
      3.4. End-to-End Security Concern for data flows................7
   4. Problems associated with MPLS-based VPNs for dynamic applications
   in the cloud......................................................7
   5. Requirements for Dynamic Cloud Data Center VPNs................9
   6. Security Considerations.......................................10
   7. IANA Considerations...........................................10
   8. References....................................................10
      8.1. Normative References.....................................10
      8.2. Informative References...................................10
   9. Acknowledgments...............................................11






Dunbar, et al.          Expires June 30, 2018                  [Page 2]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


1. Introduction

   Cloud-based applications and services continue to change how
   businesses of all sizes work and share information. "Cloud based
   applications & workloads" are those that are instantiated in third
   party Data Centers which also host services for other customers. The
   benefits of these cloud-based applications and services are
   numerous, including fueling mobility and access to applications
   anytime, anywhere, and on any device, making collaboration more
   efficient and easier to manage.

   With the advent of widely available third party cloud data centers
   in diverse geographic locations and the advancement of tools for
   monitoring and predicting application behaviors, it is technically
   feasible for enterprises to instantiate applications and workloads
   geographically closest to their end users. This property aids in
   improving end-to-end latency and overall user experience.
   Conversely, an enterprise may wish to shutdown applications and
   workloads that are too far from their end users (therefore removing
   the networking connection to those deleted applications and
   workloads). In addition, an Enterprise may wish to take advantage of
   more and more business applications offered by third party private
   cloud data centers, such as SAP HANA, Oracle Cloud, Salesforce
   Cloud, etc.

   However, given the nature of how most Enterprise VPN networks are
   built, whether SD-WAN, MPLS-based, or a combination of both, it is
   difficult (or impossible) for many Enterprises to utilize these
   cloud-based resources in a flexible and scalable manner with reasons
   to be elaborated in subsequent sections of this documents.

   This document describes a number of issues with existing VPN
   technologies, either SD-WAN or MPLS-based, related to connectivity
   of Enterprise sites to dynamic workloads instantiated in a cloud
   data center. The Enterprise Sites include HQ, spokes, on premise
   data centers, and branch offices as their corresponding VPN features
   can be different.






Dunbar, et al.          Expires June 30, 2018                  [Page 3]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


2. Definition of terms



   Cloud DC:   Off-Premise Data Centers that usually host applications
               and workload owned by different organizations or
               tenants.



   Controller: Used interchangeably with SD-WAN controller to manage
               SD-WAN overlay path creation/deletion and monitoring the
               path conditions between two sites.

   SD-WAN:     Software Defined Wide Area Network, which can mean many
               different things. In this document, "SD-WAN" refers to
               the solutions specified by ONUG (Open Network User
               Group), which build point-to-point IPsec overlay paths
               between two end-points (or branch offices) that need to
               intercommunicate.


   [JNG1][LD2]

3. Problems associated with current SD-WAN solutions

   A software-defined wide area network (SD-WAN) VPN is an overlay
   network that decouples the network management function from the
   physical hardware, using a centralized controller to set policies,
   prioritize network traffic, establish IPsec [RFC6071] tunnels
   between enterprise locations to carry the VPN traffic, and to map
   between internal addresses on the VPN and external addresses on the
   public Internet. Many enterprises use SD-WAN VPNs as an alternative,
   or in addition to, more traditional VPNs (such as MPLS-based VPNs
   [RFC4364] or [RFC4664]).

   SD-WAN is typically used to control traffic distribution among
   multiple paths between two end-points, e.g. some paths being MPLS
   path, others being via public internet. SD-WAN depends on logically
   centralized network control to utilize real-time traffic management
   over multiple paths between the two end-points. The virtual overlay,


Dunbar, et al.          Expires June 30, 2018                  [Page 4]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


   possibly secured by IPsec tunnels, is transported over the public
   Internet using fiber, cable, or DSL-based Internet access, but can
   use other types of WAN connections as well, including private or
   public WAN connections like MPLS, or wireless technologies such as
   Wi-Fi or 4G/Long Term Evolution (LTE).

   SD-WAN lets enterprises augment their current network with cost-
   effective, readily available Broadband Internet connectivity. When
   used in conjunction with MPLS VPNs, some traffic can be offloaded to
   SD-WAN overlay paths based on traffic forwarding policy
   (application-based or otherwise), or when the MPLS VPN connection
   between the two locations is congested, or otherwise undesirable.

3.1. Complexity of multi-point any-to-any interconnection[JNG3][JNG4][LD5]

   The dynamic workload instantiated in cloud DC needs to communicate
   with multiple branch offices and on premise data centers. Most
   enterprises need multi-point interconnection among multiple
   locations, as done by MPLS L2/L3 VPNs.

   Using SD-WAN overlay paths to achieve any-to-any mesh
   interconnection among all branches not only requires all branches
   CPEs to support SD-WAN, but also require CPEs to manage routing
   among other CPEs located at other locations, which can increase the
   complexity of the CPEs when compared to MPLS-based VPN solutions.

   Today's industry so called "SD-WAN" solutions build point-to-point
   IPsec overlay paths between two end-points (or branch offices) that
   need to intercommunicate. This overlay path can serve as a backup to
   an MPLS path in a hybrid solution, or as the primary path in a
   stand-alone solution.

   Whereas, MPLS-based VPNs have their PEs directly connected to the
   CEs. Therefore, CEs only need to forward all traffic with
   destinations attached to remote CEs to the directly attached PEs,
   leaving all the routing to remote destinations to the PEs, thereby
   reducing the complexity of CPEs. Even for multi-home CPEs, the CPEs
   only need to route traffic among the PEs that the CPEs are directly
   attached to. But the SD-WAN's CPE needs to route the traffic among
   all other CPEs.

   For an enterprise with multiple sites, using SD-WAN overlay paths
   among sites requires each CPE to manage all the addresses that local
   hosts have the potential to reach, i.e. map internal VPN addresses


Dunbar, et al.          Expires June 30, 2018                  [Page 5]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


   to appropriate SD-WAN paths. This is similar to the complexity of
   Frame Relay-based VPNs, where each CPE needed to maintain mesh
   routing for all destinations if they were to avoid an extra hop
   through a hub router. That is one of the primary reasons most
   enterprise networks transitioned to MPLS-based VPNs from Frame
   Relay. Even though SD-WAN CPEs can get assistance from a central
   controller (instead of performing their own routing protocol) to
   resolve the mapping between destinations and SD-WAN paths, SD-WAN
   CPEs are still responsible for routing table maintenance as remote
   destinations change their attachments, e.g. the dynamic workload in
   other DCs are de-commissioned or added.



3.2. Poor performance over long distance

   When CPEs are far apart from each other or across particular
   boundaries, whether political  (e.g. country boundary) or related to
   Internet topology, performance over the public Internet can be
   problematic and unpredictable. Even though there are many monitoring
   tools available to measure delay and various performance
   characteristics of the network, the measurement for paths over the
   Internet is passive and past measurements may not represent future
   performance.

   To compensate for delay over the Internet, most content today is
   hosted by data centers closest to end users. E2E services usually do
   not traverse long distances, but rather between end users and local
   data centers. Content distribution to the edges has transformed user
   experience of accessing content over the Internet.

   However, SD-WAN is about connecting two geographically different
   locations, which is very different from today's experience of
   accessing various websites over the Internet.














Dunbar, et al.          Expires June 30, 2018                  [Page 6]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


3.3. Scaling Issues with IPsec Tunnels
     IPsec is used by SD-WAN to achieve secure overlay connections
     between two locations over any underlay network.
     For a simple SD-WAN overlay between a small number of fixed branch
     offices, each CPE only needs to terminate a very small number of
     IPsec tunnels, which will be for the most part static in nature.
     However, for multiple branches to reach workloads hosted in cloud
     DCs, the SD-WAN solution requires a Cloud DC gateway to maintain
     individual IPsec tunnels between the Cloud DC gateway and each
     individual branch office. For a company with hundreds or thousands
     of locations, there could be hundreds (or even thousands) of IPsec
     tunnels terminating at the Cloud DC gateway, which can be very
     processing intensive for the gateway. Many routers today have
     limited capacity to support a large number of IPsec tunnels.


3.4. End-to-End Security Concern for data flows
     When IPsec tunnels from enterprise on-premise CPEs are terminated
     at the Cloud DC gateway where the workloads or applications are
     hosted, some enterprises have concerns regarding traffic to/from
     their workload being exposed to others behind the data center
     gateway (e.g., exposed to other organizations that have workloads
     in the same data center).
     To ensure that traffic to/from workloads is not exposed to
     unwanted entities, it's necessary to have the IPsec tunnels go all
     the way to the workload (say servers, or VMs) within the DC.




4. Problems associated with MPLS-based VPNs for dynamic applications in
   the cloud

   Traditional VPNs (e.g., MPLS based L2/L3 VPNs) that most businesses
   use to connect their branch offices are isolated, secure and
   reliable, but they cannot keep up in the cloud-based world. One of
   the key roadblocks for achieving this dynamic workload instantiation
   is the lack of flexible & secure network connectivity to workloads
   in third party cloud data centers. Another roadblock is the lack of
   a standard way to express and enforce consistent security policies
   to their workload [RFC8192]. The traditional VPN path and bandwidth



Dunbar, et al.          Expires June 30, 2018                  [Page 7]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


   are not flexible enough in supporting the need for enterprises to
   connect to dynamically instantiated (or removed) workloads and
   applications at any place (i.e., third party cloud data centers).

   The current business environment is characterized by dramatic and
   constant changes, especially around the IT space. Those changes
   include:

       - The movement on the part of most businesses to adopt digital
          business initiatives, such as variety of data & behavior
          analytic tools for end customers, employees, and products.
          Those tools need to be running close to their targets to
          achieve optimal results.
       - Broad adoption of public cloud computing services.
       - Deployment of WAN solutions based on new architectural
          approaches.
       - The dramatic increase in the number and sophistication of
          security attacks.

   Traditional MPLS-based VPNs have been widely deployed as an
   effective way to support business and organizations that require
   network performance and reliability. MPLS shifted the burden of
   managing a VPN service from enterprises to service providers. The
   CPEs for MPLS VPN are also simpler and less expensive, since they do
   not need to manage how to send packets to remote sites, they simply
   pass all outbound traffic to the MPLS VPN PEs to which the CPEs are
   attached.  MPLS has addressed the problems of scale, availability,
   and fast recovery from network faults, and incorporates traffic
   engineering to ensure guaranteed bandwidth for high priority
   traffic.

   However, traditional MPLS-based VPNs are not optimized for
   connecting to dynamic applications in cloud data centers because:

     - It's not easy to add/remove VPN's PEs at dynamic locations. It
        takes a relatively long time to deploy provider edge routers at
        new locations. When enterprise's workloads are changed from one
        cloud DC to another (i.e., removed from one DC and re-
        instantiated to another location when demand changes), the
        enterprise branch offices need to be connected to the new cloud
        DC.


Dunbar, et al.          Expires June 30, 2018                  [Page 8]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


        The big drive for moving workloads into the cloud comes from
        widely available cloud DCs at geographically diverse locations
        that apps can be instantiated so that they can be close to
        their users. When the user base changes, the applications can
        be quickly moved to a new cloud DC location closest to the new
        user base.

     - The third party cloud data center where an enterprise chooses
        to host workloads for easy access to its clients may not be
        connected to the Provider Edge (PE) nodes of the enterprise's
        VPN.
     - Many cloud data centers do not expose its internal network for
        provider MPLS based VPNs to reach the workload natively &
        securely.
     - Many data centers use some forms of encapsulation, i.e. VxLAN,
        STT, NSH, etc. There has not been any standard to address the
        interworking to those encapsulations.
     -


5. Requirements for Dynamic Cloud Data Center VPNs

   In order to address the aforementioned issues, any solution for
   enterprise VPNs that includes connectivity to dynamic workloads or
   applications in cloud data centers should satisfy a set of
   requirements:

     - The solution should allow enterprises to take advantage of the
        current state of the art in VPN technology, both in traditional
        MPLS-based VPNs and IPsec-based VPNs (or any combination
        thereof) that run over the top of the public Internet.
     - The solution  shouldn't require enterprise to upgrade all their
        existing CPEs. .
     - The solution shouldn't require either CPEs or routers to
        support more than xx IPsec tunnels simultaneously.
     - The solution needs to support easy and fast VPN connections to
        dynamic workloads and applications in third party data centers,
        and easily allow these workloads to migrate both within a data
        center and between data centers.




Dunbar, et al.          Expires June 30, 2018                  [Page 9]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


     - Allow VPNs to provide bandwidth and other performance
        guarantees.
     - Be a cost-effective solution for enterprises to incorporate
        dynamic cloud-based applications and workloads into their
        existing VPN environment.



6. Security Considerations

   For the most part, we introduce no new security concerns beyond
   those of existing MPLS=based VPNs, which are extremely widely
   deployed. The one addition to MPLS VPNs is selective use of SD-WAN,
   which uses IPsec tunnels.



7. IANA Considerations

   This document requires no IANA actions. RFC Editor: Please remove
   this section before publication.

8. References


    8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

    8.2. Informative References

    [RFC8192] S. Hares, et al "Interface to Network Security Functions
             (I2NSF) Problem Statement and Use Cases", July 2017

    [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation,
             storage, distribution and enforcement of policies for
             network security", Nov 2007.

    [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and
             Internet Key Exchange (IKE) Document Roadmap", Feb 2011.


Dunbar, et al.          Expires June 30, 2018                 [Page 10]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


   [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", Feb 2006

   [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual
             Private Networks (L2VPNs)", Sept 2006.

9. Acknowledgments

   Acknowledgements to Jim Guichard for his review and contributions.

   This document was prepared using 2-Word-v2.0.template.dot.




































Dunbar, et al.          Expires June 30, 2018                 [Page 11]


Internet-Draft        VPN Ext to Dynamic Cloud DC          October 2017


Authors' Addresses


   Linda Dunbar
   Huawei
   Email: Linda.Dunbar@huawei.com

   Andrew G. Malis
   Huawei
   Email: agmalis@gmail.com

   Christian Jacquenet
   France Telecom
   Rennes, 35000
   France
   Email: Christian.jacquenet@orange.com






























Dunbar, et al.          Expires June 30, 2018                 [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/