Internet DRAFT - draft-dm-vpn-ext-to-cloud-dc-problem-statement
draft-dm-vpn-ext-to-cloud-dc-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-01
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.
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
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]
