< draft-ietf-rtgwg-net2cloud-gap-analysis-01.txt   draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt >
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft A. Malis Internet Draft A. Malis
Intended status: Informational Huawei Intended status: Informational Futurewei
Expires: September 25, 2019 C. Expires: December 19, 2019 C. Jacquenet
Jacquenet
Orange Orange
March 25, 2019 June 19, 2019
Gap Analysis of Interconnecting Underlay with Cloud Overlay Gap Analysis of Dynamic Networks to Hybrid Cloud DCs
draft-ietf-rtgwg-net2cloud-gap-analysis-01 draft-ietf-rtgwg-net2cloud-gap-analysis-02
Abstract Abstract
This document analyzes the technological gaps when using SD-WAN to This document analyzes the technological gaps when using SD-WAN to
interconnect workloads & apps hosted in various locations, dynamically interconnect workloads and applications hosted in
especially cloud data centers when the network service providers do rd various 3 party cloud data centers.
not have or have limited physical infrastructure to reach the
locations [Net2Cloud-problem].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 39
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 25, 2019. This Internet-Draft will expire on December 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. Gap Analysis of C-PEs WAN Ports Registration...................4 3. Gap Analysis of C-PEs WAN Port Registration....................4
4. Gap Analysis in aggregating VPN paths and Internet paths.......5 4. Aggregating VPN paths and Internet paths.......................5
4.1. Gap analysis of Using BGP for SD-WAN......................6 4.1. Key Control Plane Components of SD-WAN....................6
4.2. Gaps in preventing attacks from Internet-facing ports.....9 4.2. Using BGP Tunnel-Encap....................................7
5. Gap analysis of CPEs not directly connected to VPN PEs........10 4.3. SECURE-L3VPN/EVPN.........................................9
5.1. Gap Analysis of Floating PEs to connect to Remote CPEs...12 4.4. Preventing attacks from Internet-facing ports............10
5.2. NAT Traversal............................................12 5. CPEs not directly connected to VPN PEs........................10
5.3. Complication of using BGP between PEs and remote CPEs via 5.1. Floating PEs to connect to Remote CPEs...................13
Internet......................................................12 5.2. NAT Traversal............................................13
5.4. Designated Forwarder to the remote edges.................13 5.3. Complexity of using BGP between PEs and remote CPEs via
5.5. Traffic Path Management..................................14 Internet......................................................13
6. Manageability Considerations..................................14 5.4. Designated Forwarder to the remote edges.................14
7. Security Considerations.......................................14 5.5. Traffic Path Management..................................15
8. IANA Considerations...........................................15 6. Manageability Considerations..................................15
9. References....................................................15 7. Security Considerations.......................................15
9.1. Normative References.....................................15 8. IANA Considerations...........................................16
9.2. Informative References...................................15 9. References....................................................16
10. Acknowledgments..............................................16 9.1. Normative References.....................................16
9.2. Informative References...................................16
10. Acknowledgments..............................................17
1. Introduction 1. Introduction
[Net2Cloud-Problem] describes the problems that enterprises face [Net2Cloud-Problem] describes the problems that enterprises face
today in transitioning their IT infrastructure to support digital today in transitioning their IT infrastructure to support digital
economy, such as connecting enterprises' branch offices to dynamic economy, such as connecting enterprises' branch offices to dynamic
workloads in different Cloud DCs. workloads in different Cloud DCs.
This document analyzes the technological gaps to interconnect This document analyzes the technological gaps to interconnect
dynamic workloads & apps hosted in various locations and in Cloud dynamic workloads & apps hosted in cloud data centers that the
DCs that the enterprise's VPN service provider may not own/operate enterprise's VPN service provider may not own/operate or may be
or may be unable to provide the required connectivity to access unable to provide the enterprise with the required connectivity to
these locations. When enterprise' VPN service providers have access such locations. When VPN service providers have insufficient
insufficient bandwidth to reach a location, SD-WAN techniques can be bandwidth to reach a location, SD-WAN techniques can be used to
used to aggregate bandwidth of multiple networks, such as MPLS VPNs, aggregate bandwidth of multiple networks, such as MPLS VPNs or the
the Public Internet, to achieve better performance and visibility. Public Internet to achieve better performance. This document
This document primarily focuses on the technological gaps of SD-WAN. primarily focuses on the technological gaps raised by using SD-WAN
techniques to connect enterprise premises to cloud data centers
operated by third parties.
For ease of description, a SD-WAN edge, a SD-WAN end-point, C-PE, or For the sake of readability, a SD-WAN edge, a SD-WAN endpoint, C-PE,
CPE are used interchangeably throughout this document. or CPE are used interchangeably throughout this document. However,
each term has some minor emphasis, especially when used in other
related documents:
. SD-WAN Edge: could include multiple devices (virtual or
physical);
. SD-WAN endpoint: to refer to a WAN port of SD-WAN devices or a
single SD-WAN device;
. C-PE: more for provider owned SD-WAN edge, e.g. for SECURE-
EVPN's PE based VPN, when PE is the edge node of SD-WAN;
. CPE: more for enterprise owned SD-WAN edge.
2. Conventions used in this document 2. Conventions used in this document
Cloud DC: Third party Data Centers that usually host applications Cloud DC: Third party Data Centers that usually host applications
and workload owned by different organizations or and workload owned by different organizations or
tenants. tenants.
Controller: Used interchangeably with SD-WAN controller to manage Controller: Used interchangeably with SD-WAN controller to manage
SD-WAN overlay path creation/deletion and monitor the SD-WAN overlay path creation/deletion and monitor the
path conditions between sites. path conditions between sites.
CPE-Based VPN: Virtual Private Network designed and deployed from CPE-Based VPN: Virtual Private Network designed and deployed from
CPEs. This is to differentiate from most commonly used CPEs. This is to differentiate from most commonly used
PE-based VPNs a la RFC 4364. PE-based VPNs a la RFC 4364.
OnPrem: On Premises data centers and branch offices OnPrem: On Premises data centers and branch offices
SD-WAN: Software Defined Wide Area Network, "SDWAN" refers to SD-WAN: Software Defined Wide Area Network, "SD-WAN" refers to
the solutions of pooling WAN bandwidth from multiple the solutions of pooling WAN bandwidth from multiple
underlay networks to get better WAN bandwidth underlay networks to get better WAN bandwidth
management, visibility & control. When the underlay is management, visibility & control. When the underlay is a
private network, traffic can traverse without additional private network, traffic may be forwarded without any
encryption; when the underlay networks are public, such additional encryption; when the underlay networks are
as the Internet, some traffic needs to be encrypted when public, such as the Internet, some traffic needs to be
traversing through (depending on user-provided encrypted when passing through (depending on user-
policies). provided policies).
3. Gap Analysis of C-PEs WAN Ports Registration 3. Gap Analysis of C-PEs WAN Port Registration
The SD-WAN WG stemmed out from ONUG (Open Network User Group) in SD-WAN technology has emerged as means to dynamically and securely
2014 and was the placeholder to define SD-WAN as a means to
aggregate multiple underlay networks between any two points. SD-WAN
technology has emerged as an on-demand technology to securely
interconnect the OnPrem branches with the workloads instantiated in interconnect the OnPrem branches with the workloads instantiated in
Cloud DCs that do not connect to BGP/MPLS VPN PEs or have very Cloud DCs that do not have direct connectivity to BGP/MPLS VPN PEs
limited bandwidth. or have very limited bandwidth.
Some SD-WAN networks use the NHRP protocol [RFC2332] to register WAN Some SD-WAN networks use the NHRP protocol [RFC2332] to register WAN
ports of SD-WAN edges with a "Controller" (or NHRP server), which ports of SD-WAN edges with a "Controller" (or NHRP server), which
then has the ability to map a private VPN address to a public IP then has the ability to map a private VPN address to a public IP
address of the destination node. DSVPN [DSVPN] or DMVPN [DMVPN] are address of the destination node. DSVPN [DSVPN] or DMVPN [DMVPN] are
used to establish tunnels between WAN ports of SD-WAN edge nodes. used to establish tunnels between WAN ports of SD-WAN edge nodes.
NHRP was originally intended for ATM address resolution, and as a NHRP was originally intended for ATM address resolution, and as a
result, it misses many attributes that are necessary for dynamic result, it misses many attributes that are necessary for dynamic
endpoint C-PE registration to controller, such as: endpoint C-PE registration to the controller, such as:
- Interworking with MPLS VPN control plane. A SD-WAN edge can have - Interworking with the MPLS VPN control plane. A SD-WAN edge can
some ports facing MPLS VPN network over which packets can be sent have some ports facing the MPLS VPN network over which packets can
natively without encryption and some ports facing the public be forwarded without any encryption and some ports facing the
Internet over which sensitive traffic needs to be encrypted before public Internet over which sensitive traffic needs to be encrypted
being sent. before being sent.
- Scalability. NHRP/DSVPN/DMVPN works fine with small numbers of
edge nodes. When a network has more than 100 nodes, the protocol - Scalability: NHRP/DSVPN/DMVPN works fine with small numbers of
does not work well. edge nodes. When a network has more than 100 nodes, these
protocols do not scale well.
- NHRP does not have the IPsec attributes, which are needed for - NHRP does not have the IPsec attributes, which are needed for
peers to build Security Associations over public internet. peers to build Security Associations over the public internet.
- NHRP messages do not have any field to encode the C-PE supported - NHRP messages do not have any field to encode the C-PE supported
encapsulation types, such as IPsec-GRE or IPsec-VxLAN,. encapsulation types, such as IPsec-GRE or IPsec-VxLAN.
- NHRP messages do not have any field to encode C-PE Location - NHRP messages do not have any field to encode C-PE Location
identifiers, such as Site Identifier, System ID, and/or Port ID. identifiers, such as Site Identifier, System ID, and/or Port ID.
- NHRP messages do not have any field to describe the gateway(s) to - NHRP messages do not have any field to describe the gateway(s) to
which the C-PE is attached. When a C-PE is instantiated in a Cloud which the C-PE is attached. When a C-PE is instantiated in a Cloud
DC, to establish connection to the C-PE, it is necessary to know DC, it is desirable for C-PE's owner to be informed of how/where
the Cloud DC operator's Gateway to which the CPE is attached. the C-PE is attached.
- NHRP messages do not have any field to describe C-PE's NAT - NHRP messages do not have any field to describe C-PE's NAT
properties if the C-PE is using private addresses, such as the NAT properties if the C-PE is using private addresses, such as the NAT
type, Private address, Public address, Private port, Public port, type, Private address, Public address, Private port, Public port,
etc. etc.
[BGP-SDWAN-PORT] describes how to use BGP for SD-WAN edge nodes to [BGP-SDWAN-PORT] describes how SD-WAN edge nodes use BGP to register
register their WAN ports properties to the SD-WAN controller, which their WAN ports properties to the SD-WAN controller, which then
then disseminates the information to other SD-WAN edge nodes that propagates the information to other SD-WAN edge nodes that are
are authenticated before the SD-WAN controller and the other SD-WAN authenticated and authorized to communicate with them.
edge nodes can communicate with them.
4. Gap Analysis in aggregating VPN paths and Internet paths 4. Aggregating VPN paths and Internet paths
Most likely, enterprises (especially the largest ones) already have Most likely, enterprises (especially the largest ones) already have
their CPEs interconnected by providers' VPNs, based upon VPN their CPEs interconnected by providers' VPNs, based upon VPN
techniques such as EVPN, L2VPN, or L3VPN. The VPN can be PE-based or techniques such as EVPN, L2VPN, or L3VPN. The VPN can be PE-based or
CPE-based. The commonly used PE-based VPNs have CPE directly CPE-based. The commonly used PE-based VPNs have CPE directly
attached to PEs, therefore the communication between CPEs & PEs is attached to PEs, therefore the communication between CPEs and PEs is
considered as secure. MP-BGP is used to learn & distribute routes considered as secure. MP-BGP is used to learn & distribute routes
among CPEs, even though sometimes routes among CPEs are statically among CPEs, even though sometimes routes among CPEs are statically
configured. configured on the CPEs.
To aggregate paths over the Internet and paths over the VPN, the C- To aggregate paths over the Internet and paths over the VPN, the C-
PEs need to have some WAN ports connected to the PEs of the VPNs and PEs need to have some WAN ports connected to the PEs of the VPNs and
other WAN ports connected to the Internet. It is necessary for the other WAN ports connected to the Internet. It is necessary for the
CPEs to use a protocol so that they can register the WAN port CPEs to use a protocol so that they can register the WAN port
properties with their SD-WAN Controller(s): this information properties with their SD-WAN Controller(s): this information
conditions the establishment and the maintenance of IPsec SA conditions the establishment and the maintenance of IPsec SA
associations among relevant C-PEs. associations among relevant C-PEs.
If using NHRP for registration purposes, C-PEs need to participate When using NHRP for registration purposes, C-PEs need to run two
in two separate control planes: EVPN&BGP for CPE-based VPNs and NHRP separate control planes: EVPN&BGP for CPE-based VPNs, and NHRP &
& DSVPN/DMVPN for ports connected to the Internet. Two separate DSVPN/DMVPN for ports connected to the Internet. Two separate
control planes not only add complexity to C-PEs, but also increase control planes not only add complexity to C-PEs, but also increase
operational cost. operational cost.
+---+ +---+
+--------------|RR |----------+ +--------------|RR |----------+
/ Untrusted +-+-+ \ / Untrusted +-+-+ \
/ \ / \
/ \ / \
+----+ +---------+ packets encrypted over +------+ +----+ +----+ +---------+ packets encrypted over +------+ +----+
| TN3|--| A1-----+ Untrusted +------ B1 |--| TN1| | TN3|--| A1-----+ Untrusted +------ B1 |--| TN1|
+----+ | C-PE A2-\ | C-PE | +----+ +----+ | C-PE A2-\ | C-PE | +----+
+----+ | A A3--+--+ +---+---B2 B | +----+ +----+ | A A3--+--+ +---+---B2 B | +----+
| TN2|--| | |PE+--------------+PE |---B3 |--| TN3| | TN2|--| | |PE+--------------+PE |---B3 |--| TN3|
skipping to change at page 6, line 27 skipping to change at page 6, line 32
+----+ +---------+ +--+ packets +---+ +------+ +----+ +----+ +---------+ +--+ packets +---+ +------+ +----+
| TN1|--| C1--|PE| go natively |PE |-- D1 |--| TN1| | TN1|--| C1--|PE| go natively |PE |-- D1 |--| TN1|
+----+ | C-PE C2--+--+ without encry+---+ | C-PE | +----+ +----+ | C-PE C2--+--+ without encry+---+ | C-PE | +----+
| C | +--------------+ | D | | C | +--------------+ | D |
| | | | | | | |
+----+ | C3--| without encrypt over | | +----+ +----+ | C3--| without encrypt over | | +----+
| TN2|--| C4--+---- Untrusted --+------D2 |--| TN2| | TN2|--| C4--+---- Untrusted --+------D2 |--| TN2|
+----+ +---------+ +------+ +----+ +----+ +---------+ +------+ +----+
Figure 1: CPEs interconnected by VPN paths and Internet Paths Figure 1: CPEs interconnected by VPN paths and Internet Paths
4.1. Gap analysis of Using BGP for SD-WAN 4.1. Key Control Plane Components of SD-WAN
This section analyzes the gaps of using BGP to control SD-WAN.
As described in [BGP-SDWAN-Usage], SD-WAN Overlay Control Plane has As described in [BGP-SDWAN-Usage], the SD-WAN Overlay Control Plane
three distinct aspects: has three distinct properties:
- SD-WAN node's WAN Ports Property registration to the SD-WAN - SD-WAN node's WAN Port Property registration to the SD-WAN
Controller. Controller.
o It is to inform the SD-WAN controller and potential peers o To inform the SD-WAN controller and authorized peers of
of the WAN ports property of the C-PE [SDWAN-Port]. When the WAN port properties of the C-PE [SDWAN-Port]. When the
the WAN ports are using private addresses, this step can WAN ports are assigned private addresses, this step can
register the type of NAT that translate private addresses register the type of NAT that translates private addresses
into public ones. into public ones.
- Controller Facilitated IPsec SA management and NAT information - Controller facilitated IPsec SA management and NAT information
distribution distribution
o It is for SD-WAN controller to facilitate or manage the o It is for SD-WAN controller to facilitate or manage the
IPsec configuration and peer authentication for all IPsec IPsec configuration and peer authentication for all IPsec
tunnels terminated at the SDWAN nodes. tunnels terminated at the SD-WAN nodes.
- Establishing and Managing the topology and reachability for - Establishing and Managing the topology and reachability for
services attached to the client ports of SD-WAN nodes. services attached to the client ports of SD-WAN nodes.
o This is for the overlay layer's route distribution, so o This is for the overlay layer's route distribution, so
that a C-PE can populate its overlay routing table with that a C-PE can populate its overlay routing table with
entries that identify the next hop for reaching a specific entries that identify the next hop for reaching a specific
route/service attached to remote nodes. [SECURE-EVPN] route/service attached to remote nodes. [SECURE-EVPN]
describes EVPN and other options. describes EVPN and other options.
RFC5512 and [Tunnel-Encap] describe methods for endpoints to 4.2. Using BGP Tunnel-Encap
advertise tunnel information and trigger tunnel establishment.
RFC5512 & [Tunnel-Encap] use the Endpoint Address that indicates an RFC5512 and [Tunnel-Encap] describe methods to construct BGP UPDATE
IPv4 or an IPv6 address, and the Tunnel Encapsulation attribute to messages that advertise endpoints' tunnel encapsulation capability
indicate different encapsulation formats, such as L2TPv3, GRE, and the respective attached client routes, so that the peers that
VxLAN, IP-in-IP, etc. There are sub-TLVs to describe the detailed receive of the BGP UPDATE can establish appropriate tunnels with the
tunnel information for each of the encapsulation types. endpoints for the aforementioined routes. RFC5512 uses the Endpoint
Address subTLV, whereas [Tunnel-Encap] uses Remote Endpoint Address
subTLV to indicates address of the tunnel endpoint which can be an
IPv4 or an IPv6 address. There are Tunnel Encapsulation attribute
subTLVs to indicate the supported encapsulation types, such as
L2TPv3, GRE, VxLAN, IP-in-IP, etc.
[Tunnel-Encap] removed SAFI =7 (which was specified by RFC5512) for [Tunnel-Encap] removed SAFI =7 (which was specified by RFC5512) for
distributing encapsulation tunnel information. [Tunnel-Encap] distributing encapsulation tunnel information. [Tunnel-Encap]
requires that tunnels need to be associated with routes. requires that tunnels need to be associated with routes.
There is also the Color sub-TLV to describe customer-specified There is also the Color sub-TLV to describe customer-specified
information about the tunnels (which can be creatively used for SD- information about the tunnels (which can be creatively used for SD-
WAN). WAN).
Here are some of the gaps using [Tunnel-Encap] to control SD-WAN: Here are some of the gaps using [Tunnel-Encap] to control SD-WAN
Tunnels:
- Lacking C-PE WAN Port Property Registration functionality - [Tunnel-Encap] doesn't have the functionality that would help the
- Lacking IPsec Tunnel type C-PE to register its WAN Port properties.
- [Tunnel-Encap] has Remote Address SubTLV, but does not have any - A SD-WAN tunnel, e.g. IPsec-based, requires a negotiation between
field to indicate the Tunnel originating interface, as defined in the tunnel's end points for supported encryption algorithms and
RFC5512. tunnel types before it can be properly established, whereas
- The mechanisms described by [Tunnel-Encap] cannot be effectively [Tunnel-Encap] only allow the announcement of one endpoint's
used for SD-WAN overlay network because a SD-WAN Tunnel can be supported encapsulation capabilities for specific attached routes
established between Internet-facing WAN ports of two C-Pes. This and no negotiation between tunnel end points is needed. The
tunnel needs to be established before data arrival because the establishment of a SD-WAN tunnel can fail, e.g., in case the two
tunnel establishment can fail, e.g., in case the two end-points endpoints support different encryption algorithms. That is why a
support different encryption algorithms. SD-WAN tunnel needs to be established and maintained independently
- Client traffic can either be forwarded through the MPLS network from advertising client routes attached to the edge node.
natively without any encryption for better performance, or through - [Tunnel-Encap] requires all tunnels updates are associated with
the Internet-facing ports with IPsec encryption. routes. There can be many client routes associated with the SD-WAN
- There can be many client routes associated with the SD-WAN IPsec IPsec tunnel between two C-PEs' WAN ports; the corresponding
tunnel between two C-PE's Internet-facing WAN ports, but the destination prefixes (as announced by the aforementioned routes)
corresponding destination prefixes (as announced by the may also be reached through the VPN underlay without any
aforementioned routes) can also be reached over the VPN underlay encryption. A more realistic approach to separate SD-WAN tunnel
natively without encryption. A more realistic approach to separate management from client routes association with the SD-WAN tunnels.
IPsec SA management from client routes association with IPsec. - When SD-WAN tunnel and clients routes are separate, the SD-WAN
Tunnel establishment may not have routes associated.
There is a suggestion on using a "Fake Route" for a SD-WAN node to There is a suggestion on using a "Fake Route" for a SD-WAN node to
use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points
properties. However, using "Fake Route" can raise some design properties. However, using "Fake Route" can raise some design
complexity for large SD-WAN networks with many tunnels. For complexity for large SD-WAN networks with many tunnels. For
example, for a SD-WAN network with hundreds of nodes, with each example, for a SD-WAN network with hundreds of nodes, with each
node having many ports & many end-points to establish SD-WAN node having many ports & many endpoints to establish SD-WAN
tunnels with their corresponding peers, the node would need as tunnels with their corresponding peers, the node would need as
many "fake addresses". For large SD-WAN networks (such as those many "fake addresses". For large SD-WAN networks (such as those
comprised of more than 10000 nodes), each node might need 10's comprised of more than 10000 nodes), each node might need 10's
thousands of "fake addresses", which is very difficult to manage thousands of "fake addresses", which is very difficult to manage
and needs lots of configuration to get the nodes provisioned. and requires lots of configuration tasks to get the nodes properly
- Does not have any field to carry detailed information about the set up.
remote C-PE, such as Site-ID, System-ID, Port-ID - [Tunnel-Encap] does not have any field to carry detailed
- Does not have any field to express IPsec attributes for the SD-WAN information about the remote C-PE, such as Site-ID, System-ID,
edge nodes to establish IPsec Security Associations with others. Port-ID
- Does not have any proper way for two peer CPEs to negotiate IPsec - [Tunnel-Encap] Does not have any field to carry IPsec attributes
keys, based on the configuration sent by the Controller. for the SD-WAN edge nodes to establish IPsec Security Associations
- Does not have any field to indicate the UDP NAT private address with others. It does not have any proper way for two peer CPEs to
<-> public address mapping negotiate IPsec keys either, based on the configuration sent by
the Controller.
- [Tunnel-Encap] does not have any field to indicate the UDP NAT
private address <-> public address mapping
- C-PEs tend to communicate with a subset of the other C-PEs, not - C-PEs tend to communicate with a subset of the other C-PEs, not
all the C-PEs need to form mesh connections. Without any BGP all the C-PEs need to be connected through a mesh topology.
extension, many nodes can get dumped with too much information Without any BGP extension, many nodes can get dumped with too much
coming from other nodes that they never need to communicate with. information coming from other nodes that they never need to
communicate with.
[SECURE-L3VPN] describes how to extend the RFC4364 VPN to allow some 4.3. SECURE-L3VPN/EVPN
PEs to connect to other PEs via public networks. [SECURE-L3VPN]
introduces the concept of Red Interface & Black Interface on those
PEs, where the RED interfaces are used to forward traffic into the
VPN, and the Black Interfaces are used between WAN ports over which
only IPsec-protected packets to the Internet or other backbone
network are sent thereby eliminating the need for MPLS transport in
the backbone.
[SECURE-L3VPN] assumes PEs terminate MPLS packets, and use MPLS over [SECURE-L3VPN] describes how to extend the BGP/MPLS VPN [RFC4364]
IPsec when sending traffic through the Black Interfaces. capabilities to allow some PEs to connect to other PEs via public
networks. [SECURE-L3VPN] introduces the concept of Red Interface &
Black Interface used by PEs, where the RED interfaces are used to
forward traffic into the VPN, and the Black Interfaces are used
between WAN ports through which only IPsec-protected packets are
forwarded to the Internet or to other backbone network thereby
eliminating the need for MPLS transport in the backbone.
[SECURE-L3VPN] assumes PEs using MPLS over IPsec when sending
traffic through the Black Interfaces.
[SECURE-EVPN] describes a solution where point-to-multipoint BGP [SECURE-EVPN] describes a solution where point-to-multipoint BGP
signaling is used in the control plane for SDWAN Scenario #1. It signaling is used in the control plane for SDWAN Scenario #1. It
relies upon a BGP cluster design to facilitate the key and policy relies upon a BGP cluster design to facilitate the key and policy
exchange among PE devices to create private pair-wise IPsec Security exchange among PE devices to create private pair-wise IPsec Security
Associations without IKEv2 point-to-point signaling or any other Associations without IKEv2 point-to-point signaling or any other
direct peer-to-peer session establishment messages. direct peer-to-peer session establishment messages.
Both [SECURE-L3VPN] and [SECURE-EVPN] are useful, however, they both Both [SECURE-L3VPN] and [SECURE-EVPN] are useful, however, they both
miss the aspects of aggregating VPN and Internet underlays. In miss the aspects of aggregating VPN and Internet underlays. In
summary: summary:
- These documents do not address the scenario of C-PE having some - These documents do not address the scenario of C-PE having some
ports facing VPN PEs and other ports facing the Internet. ports facing VPN PEs and other ports facing the Internet.
-
- The [SECURE-L3VPN] assumes that CPE "registers" with the RR. - The [SECURE-L3VPN] assumes that a CPE "registers" with the RR.
However, it does not say how. It assumes that the remote CPEs are However, it does not say how. It assumes that the remote CPEs are
pre-configured with the IPsec SA manually. In SD-WAN, Zero Touch pre-configured with the IPsec SA manually. In SD-WAN, Zero Touch
Provisioning is expected. Manual configuration is not an option, Provisioning is expected. Manual configuration is not an option,
given the dimensioning figures but also the purpose of SD-WAN to as it contradicts the objectives of SD-WAN to automate
automate configuration tasks. configuration tasks.
- For RR communication with CPEs, this draft only mentions IPsec. - For RR communication with C-PEs, this draft only mentions IPsec.
Missing TLS/DTLS. Missing TLS/DTLS.
- The draft assumes that CPEs and RR are connected with an IPsec - The draft assumes that C-PEs and RR are connected with an IPsec
tunnel. With zero touch provisioning, we need an automatic way to tunnel. With zero touch provisioning, we need an automatic way to
synchronize the IPsec SAs between CPE and RR. The draft assumes: synchronize the IPsec SAs between C-PEs and RR. The draft assumes:
A CPE must also be provisioned with whatever additional A CPE must also be provisioned with whatever additional
information is needed in order to set up an IPsec SA with information is needed in order to set up an IPsec SA with
each of the red RRs each of the red RRs
- IPsec requires periodic refreshment of the keys. The draft does - IPsec requires periodic refreshment of the keys. The draft does
not provide any information about how to synchronize the not provide any information about how to synchronize the
refreshment among multiple nodes. refreshment among multiple nodes.
- IPsec usually sends configuration parameters to two endpoints only - IPsec usually sends configuration parameters to two endpoints only
and lets these endpoints negotiate the key. Let us assume that the and lets these endpoints negotiate the key. Let us assume that the
RR is responsible for creating the key for all endpoints: When one RR is responsible for creating the key for all endpoints: When one
endpoint is compromised, all other connections will be impacted. endpoint is compromised, all other connections will be impacted.
4.2. Gaps in preventing attacks from Internet-facing ports 4.4. Preventing attacks from Internet-facing ports
When C-PEs have Internet-facing ports, additional security risks are When C-PEs have Internet-facing ports, additional security risks are
raised. raised.
To mitigate security risks, in addition to requiring Anti-DDoS To mitigate security risks, in addition to requiring Anti-DDoS
features on C-PEs, it is necessary for CPEs to support means to features on C-PEs, it is necessary for CPEs to support means to
determine whether traffic sent by remote peers is legitimate to determine whether traffic sent by remote peers is legitimate to
prevent spoofing attacks. prevent spoofing attacks.
5. Gap analysis of CPEs not directly connected to VPN PEs 5. CPEs not directly connected to VPN PEs
Because of the ephemeral property of the selected Cloud DCs, an Because of the ephemeral property of the selected Cloud DCs, an
enterprise or its network service provider may not have direct enterprise or its network service provider may not have direct
connections to the Cloud DCs that are used for hosting the connections to the Cloud DCs that are used for hosting the
enterprise's specific workloads/Apps. Under those circumstances, SD- enterprise's specific workloads/Apps. Under those circumstances, SD-
WAN is a very flexible choice to interconnect the enterprise on- WAN is a very flexible choice to interconnect the enterprise on-
premises data centers & branch offices to its desired Cloud DCs. premises data centers & branch offices to its desired Cloud DCs.
However, SD-WAN paths over public Internet can have unpredictable However, SD-WAN paths established over the public Internet can have
performance, especially over long distances and across domains. unpredictable performance, especially over long distances and across
Therefore, it is highly desirable to place as much as possible the operators' domains. Therefore, it is highly desirable to steer as
portion of SD-WAN paths over service provider VPN (e.g., much as possible the portion of SD-WAN paths over service provider
enterprise's existing VPN) that have guaranteed SLA to minimize the VPN (e.g., enterprise's existing VPN) that have guaranteed SLA to
distance/segments over public Internet. minimize the distance or the number of segments over the public
Internet.
MEF Cloud Service Architecture [MEF-Cloud] also describes a use case MEF Cloud Service Architecture [MEF-Cloud] also describes a use case
of network operators that use SD-WAN over LTE or the public of network operators that uses SD-WAN over LTE or the public
Internet for last mile access where the VPN providers cannot Internet for last mile access where the VPN service providers cannot
necessarily provide the required physical infrastructure. necessarily provide the required physical infrastructure.
Under those scenarios, one or two of the SD-WAN endpoints may not be Under those scenarios, one or two of the SD-WAN endpoints may not be
directly attached to the PEs of a VPN Domain. directly attached to the PEs of a VPN Domain.
When using SD-WAN to connect the enterprise's existing sites with When using SD-WAN to connect the enterprise's existing sites with
the workloads in Cloud DC, the corresponding CPEs have to be the workloads hosted in Cloud DCs, the corresponding CPEs have to be
upgraded to support SD-WAN. If the workloads in Cloud DCs need to upgraded to support SD-WAN. If the workloads hosted in Cloud DCs
be connected to many sites, the upgrade process can be very need to be connected to many sites, the upgrade process can be very
expensive. expensive.
[Net2Cloud-Problem] describes a hybrid network approach that [Net2Cloud-Problem] describes a hybrid network approach that
integrates SD-WAN with traditional MPLS-based VPNs, to extend the integrates SD-WAN with traditional MPLS-based VPNs, to extend the
existing MPLS-based VPNs to the Cloud DC Workloads over the access existing MPLS-based VPNs to the Cloud DC Workloads over the access
paths that are not under the VPN provider's control. To make it work paths that are not under the VPN provider's control. To make it work
properly, a small number of the PEs of the MPLS VPN can be properly, a small number of the PEs of the MPLS VPN can be
designated to connect to the remote workloads via SD-WAN secure designated to connect to the remote workloads via SD-WAN secure
IPsec tunnels. Those designated PEs are shown as fPE (floating PE IPsec tunnels. Those designated PEs are shown as fPE (floating PE
or smart PE) in Figure 3. Once the secure IPsec tunnels are or smart PE) in Figure 3. Once the secure IPsec tunnels are
established, the workloads in Cloud DC can be reached by the established, the workloads hosted in Cloud DCs can be reached by the
enterprise's VPN without upgrading all of the enterprise's existing enterprise's VPN without upgrading all of the enterprise's existing
CPEs. The only CPE that needs to support SD-WAN would be a CPEs. The only CPE that needs to support SD-WAN would be a
virtualized CPE instantiated within the cloud DC. virtualized CPE instantiated within the cloud DC.
+--------+ +--------+ +--------+ +--------+
| Host-a +--+ +----| Host-b | | Host-a +--+ +----| Host-b |
| | | (') | | | | | (') | |
+--------+ | +-----------+ ( ) +--------+ +--------+ | +-----------+ ( ) +--------+
| +-+--+ ++-+ ++-+ +--+-+ (_) | +-+--+ ++-+ ++-+ +--+-+ (_)
| | CPE|--|PE| |PE+--+ CPE| | | | CPE|--|PE| |PE+--+ CPE| |
skipping to change at page 12, line 5 skipping to change at page 12, line 37
+-+----+ +-+----+
----+-------+-------+----- ----+-------+-------+-----
| | | |
+---+----+ +---+----+ +---+----+ +---+----+
| Remote | | Remote | | Remote | | Remote |
| App-1 | | App-2 | | App-1 | | App-2 |
+--------+ +--------+ +--------+ +--------+
Figure 3: VPN Extension to Cloud DC Figure 3: VPN Extension to Cloud DC
In Figure 3, the optimal Cloud DC to host the workloads (due to In Figure 3, the optimal Cloud DC to host the workloads (as a
proximity, capacity, pricing, or other criteria chosen by the function of the proximity, capacity, pricing, or other criteria
enterprises) does not have a direct connection to the PEs of the chosen by the enterprises) does not have a direct connection to the
MPLS VPN that interconnects the enterprise's existing sites. PEs of the MPLS VPN that interconnects the enterprise's existing
sites.
5.1. Gap Analysis of Floating PEs to connect to Remote CPEs 5.1. Floating PEs to connect to Remote CPEs
To extend MPLS VPNs to remote CPEs, it is necessary to establish To extend MPLS VPNs to remote CPEs, it is necessary to establish
secure tunnels (such as IPsec tunnels) between the Floating PEs and secure tunnels (such as IPsec tunnels) between the Floating PEs and
the remote CPEs. the remote CPEs.
Gap:
Even though a set of PEs can be manually selected to act as the Even though a set of PEs can be manually selected to act as the
floating PEs for a specific cloud data center, there are no standard floating PEs for a specific cloud data center, there are no standard
protocols for those PEs to interact with the remote CPEs (most protocols for those PEs to interact with the remote CPEs (most
likely virtualized) instantiated in the third party cloud data likely virtualized) instantiated in the third party cloud data
centers (such as exchanging performance or route information). centers (such as exchanging performance or route information).
When there is more than one fPE available for use (as there should When there is more than one fPE available for use (as there should
be for resiliency or the ability to support multiple cloud DCs be for resiliency purposes or the ability to support multiple cloud
geographically scattered), it is not straightforward to designate an DCs geographically scattered), it is not straightforward to
egress fPE to remote CPEs based on applications. There is too much designate an egress fPE to remote CPEs based on applications. There
applications' traffic traversing PEs, and it is not feasible for PEs is too much applications' traffic traversing PEs, and it is not
to recognize applications from the payload of packets. feasible for PEs to recognize applications from the payload of
packets.
5.2. NAT Traversal 5.2. NAT Traversal
Most cloud DCs only assign private addresses to the instantiated Cloud DCs that only assign private IPv4 addresses to the
workloads. Therefore, traffic to/from the workload usually needs to instantiated workloads assume that traffic to/from the workload
traverse NATs. usually needs to traverse NATs.
A SD-WAN edge node can solicit a STUN (Session Traversal of UDP A SD-WAN edge node can solicit a STUN (Session Traversal of UDP
Through Network Address Translation RFC 3489) Server to get the NAT Through Network Address Translation RFC 3489) Server to get the NAT
property, the public IP address and the Public Port number to pass property, the public IP address and the Public Port number so that
to peers. such information can be communicated to the relevant peers.
5.3. Complication of using BGP between PEs and remote CPEs via Internet 5.3. Complexity of using BGP between PEs and remote CPEs via Internet
Even though an EBGP (external BGP) Multi-hop design can be used to Even though an EBGP (external BGP) Multi-hop design can be used to
connect peers that are not directly connected to each other, there connect peers that are not directly connected to each other, there
are still some complications/gaps in extending BGP from MPLS VPN PEs are still some complications in extending BGP from MPLS VPN PEs to
to remote CPEs via any access paths (e.g., Internet). remote CPEs via any access path (e.g., Internet).
The path between the remote CPEs and VPN PE can traverse untrusted The path between the remote CPEs and VPN PEs that maintain VPN
nodes. routes may very well traverse untrusted nodes.
EBGP Multi-hop design requires static configuration on both peers. EBGP Multi-hop design requires static configuration on both peers.
To use EBGP between a PE and remote CPEs, the PE has to be manually To use EBGP between a PE and remote CPEs, the PE has to be manually
configured with the "next-hop" set to the IP address of the CPEs. configured with the "next-hop" set to the IP address of the CPEs.
When remote CPEs, especially remote virtualized CPEs are dynamically When remote CPEs, especially remote virtualized CPEs are dynamically
instantiated or removed, the configuration of Multi-Hop EBGP on the instantiated or removed, the configuration of Multi-Hop EBGP on the
PE has to be changed accordingly. PE has to be changed accordingly.
Gap: Egress peering engineering (EPE) is not sufficient. Running BGP on
virtualized CPEs in Cloud DCs requires GRE tunnels to be
Egress peering engineering (EPE) is not enough. Running BGP on established first, which requires the remote CPEs to support
virtualized CPEs in Cloud DC requires GRE tunnels being address and key management capabilities. RFC 7024 (Virtual Hub &
established first, which in turn requires address and key Spoke) and Hierarchical VPN do not support the required
management for the remote CPEs. RFC 7024 (Virtual Hub & Spoke) and properties.
Hierarchical VPN is not enough.
Also there is a need for a mechanism to automatically trigger Also, there is a need for a mechanism to automatically trigger
configuration changes on PEs when remote CPEs' are instantiated or configuration changes on PEs when remote CPEs' are instantiated or
moved (leading to an IP address change) or deleted. moved (leading to an IP address change) or deleted.
EBGP Multi-hop design does not include a security mechanism by EBGP Multi-hop design does not include a security mechanism by
default. The PE and remote CPEs need secure communication channels default. The PE and remote CPEs need secure communication channels
when connecting via the public Internet. when connecting via the public Internet.
Remote CPEs, if instantiated in Cloud DCs, might have to traverse Remote CPEs, if instantiated in Cloud DCs, might have to traverse
NATs to reach PE. It is not clear how BGP can be used between NATs to reach PEs. It is not clear how BGP can be used between
devices outside the NAT and the entities behind the NAT. It is not devices located beyond the NAT and the devices located behind the
clear how to configure the Next Hop on the PEs to reach private IPv4 NAT. It is not clear how to configure the Next Hop on the PEs to
addresses. reach private IPv4 addresses.
5.4. Designated Forwarder to the remote edges 5.4. Designated Forwarder to the remote edges
Among the multiple floating PEs that are available for a remote CPE, Among the multiple floating PEs that are reachable from a remote
multicast traffic sent by the remote CPE towards the MPLS VPN can be CPE, multicast traffic sent by the remote CPE towards the MPLS VPN
forwarded back to the remote CPE due to the PE receiving the can be forwarded back to the remote CPE due to the PE receiving the
multicast data frame forwarding the multicast/broadcast frame to multicast packets forwarding the multicast/broadcast frame to other
other PEs that in turn send to all attached CPEs. This process may PEs that in turn send to all attached CPEs. This process may cause
cause traffic loops. traffic loops.
Therefore, it is necessary to designate one floating PE as the CPE's Therefore, it is necessary to designate one floating PE as the CPE's
Designated Forwarder, similar to TRILL's Appointed Forwarders Designated Forwarder, similar to TRILL's Appointed Forwarders
[RFC6325]. [RFC6325].
Gap: the MPLS VPN does not have features like TRILL's Appointed MPLS VPNs do not have features like TRILL's Appointed Forwarders.
Forwarders.
5.5. Traffic Path Management 5.5. Traffic Path Management
When there are multiple floating PEs that have established IPsec When there are multiple floating PEs that have established IPsec
tunnels with the remote CPE, the remote CPE can forward outbound tunnels with the remote CPE, the remote CPE can forward outbound
traffic to the Designated Forwarder PE, which in turn forwards traffic to the Designated Forwarder PE, which in turn forwards
traffic to egress PEs and then to the final destinations. However, traffic to egress PEs and then to the final destinations. However,
it is not straightforward for the egress PE to send back the return it is not straightforward for the egress PE to send back the return
traffic to the Designated Forwarder PE. traffic to the Designated Forwarder PE.
Example of Return Path management using Figure 3 above. Example of Return Path management using Figure 3 above.
- fPE-1 is DF for communication between App-1 <-> Host-a due to - fPE-1 is DF for communication between App-1 <-> Host-a due to
latency, pricing or other criteria. latency, pricing or other criteria.
- fPE-2 is DF for communication between App-1 <-> Host-b. - fPE-2 is DF for communication between App-1 <-> Host-b.
6. Manageability Considerations 6. Manageability Considerations
Zero touch provisioning of SD-WAN edge nodes is expected in SD-WAN Zero touch provisioning of SD-WAN edge nodes should be a major
deployment. It is necessary for a newly powered up SD-WAN edge feature of SD-WAN deployments. It is necessary for a newly powered
node to establish a secure connection (by means of TLS, DTLS, up SD-WAN edge node to establish a secure connection (by means of
etc.) with its controller. TLS, DTLS, etc.) with its controller.
7. Security Considerations 7. Security Considerations
The intention of this draft is to identify the gaps in current and The intention of this draft is to identify the gaps in current and
proposed SD-WAN approaches that can address requirements proposed SD-WAN approaches that can address requirements
identified in [Net2Cloud-problem]. identified in [Net2Cloud-problem].
Several of these approaches have gaps in meeting enterprise Several of these approaches have gaps in meeting enterprise
security requirements when tunneling their traffic over the security requirements when tunneling their traffic over the
Internet, since this is the purpose of SD-WAN. See the individual Internet, since this is the purpose of SD-WAN. See the individual
sections above for further discussion of these security gaps. sections above for further discussion of these security gaps.
8. IANA Considerations 8. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove This document requires no IANA actions. RFC Editor: Please remove
this section before publication. this section before publication.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[RFC8192] S. Hares, et al, "Interface to Network Security Functions [RFC8192] S. Hares, et al, "Interface to Network Security Functions
(I2NSF) Problem Statement and Use Cases", July 2017 (I2NSF) Problem Statement and Use Cases", July 2017
[RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent [RFC5521] P. Mohapatra, E. Rosen, "The BGP Encapsulation Subsequent
Address Family Identifier (SAFI) and the BGP Tunnel Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute", April 2009. Encapsulation Attribute", April 2009.
[BGP-SDWAN-PORT]L. Dunbar, et al, "Subsequent Address Family [BGP-SDWAN-PORT]L. Dunbar, et al, "Subsequent Address Family
Indicator for SDWAN Ports", draft-dunbar-idr-sdwan-port- Indicator for SDWAN Ports", draft-dunbar-idr-sdwan-port-
safi-00, Work-in-progress, March 2019. safi-00, Work-in-progress, March 2019.
[BGP-SDWAN-Usage] L. Dunbar, et al, "Framework of Using BGP for [BGP-SDWAN-Usage] L. Dunbar, et al, "Framework of Using BGP for
SDWAN Overlay Networks", draft-dunbar-idr-sdwan-framework- SDWAN Overlay Networks", draft-dunbar-idr-sdwan-framework-
00, work-in-progress, Feb 2019. 00, work-in-progress, Feb 2019.
[Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation [Tunnel-Encap]E. Rosen, et al, "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-10, July 2018. Attribute", draft-ietf-idr-tunnel-encaps-10, July 2018.
[SECURE-EVPN A. Sajassi, et al, draft-sajassi-bess-secure-evpn-01,
work in progress, March 2019.
[SECURE-L3VPN] E. Rosen, "Provide Secure Layer L3VPNs over Public [SECURE-L3VPN] E. Rosen, "Provide Secure Layer L3VPNs over Public
Infrastructure", draft-rosen-bess-secure-l3vpn-00, work- Infrastructure", draft-rosen-bess-secure-l3vpn-00, work-
in-progress, July 2018 in-progress, July 2018
[DMVPN] Dynamic Multi-point VPN: [DMVPN] Dynamic Multi-point VPN:
https://www.cisco.com/c/en/us/products/security/dynamic- https://www.cisco.com/c/en/us/products/security/dynamic-
multipoint-vpn-dmvpn/index.html multipoint-vpn-dmvpn/index.html
[DSVPN] Dynamic Smart VPN: [DSVPN] Dynamic Smart VPN:
http://forum.huawei.com/enterprise/en/thread-390771-1- http://forum.huawei.com/enterprise/en/thread-390771-1-
skipping to change at page 17, line 8 skipping to change at page 18, line 8
10. Acknowledgments 10. Acknowledgments
Acknowledgements to xxx for his review and contributions. Acknowledgements to xxx for his review and contributions.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Linda Dunbar Linda Dunbar
Huawei Futurewei
Email: Linda.Dunbar@huawei.com Email: ldunbar@futurewei.com
Andrew G. Malis Andrew G. Malis
Huawei Futurewei
Email: agmalis@gmail.com Email: agmalis@gmail.com
Christian Jacquenet Christian Jacquenet
Orange Orange
Rennes, 35000 Rennes, 35000
France France
Email: Christian.jacquenet@orange.com Email: Christian.jacquenet@orange.com
 End of changes. 68 change blocks. 
213 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/