< draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt   draft-ietf-rtgwg-net2cloud-gap-analysis-03.txt >
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft A. Malis Internet Draft Futurewei
Intended status: Informational Futurewei Intended status: Informational A. Malis
Expires: December 19, 2019 C. Jacquenet Expires: May 1, 2020 Independent
Orange C. Jacquenet
June 19, 2019 Orange
November 1, 2019
Gap Analysis of Dynamic Networks to Hybrid Cloud DCs Gap Analysis of Dynamic Networks to Hybrid Cloud DCs
draft-ietf-rtgwg-net2cloud-gap-analysis-02 draft-ietf-rtgwg-net2cloud-gap-analysis-03
Abstract Abstract
This document analyzes the technological gaps when using SD-WAN to This document analyzes the technological gaps when using SDWAN to
dynamically interconnect workloads and applications hosted in dynamically interconnect workloads and applications hosted in
rd various 3 party cloud data centers. rd various 3 party cloud data centers.
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 39 skipping to change at page 1, line 40
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 December 19, 2019. This Internet-Draft will expire on May 1, 2009.
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 Port Registration....................4 3. Gap Analysis of C-PEs WAN Port Management......................4
4. Aggregating VPN paths and Internet paths.......................5 4. Aggregating VPN paths and Internet paths.......................6
4.1. Key Control Plane Components of SD-WAN....................6 4.1. Key Control Plane Components of SDWAN Overlay.............7
4.2. Using BGP Tunnel-Encap....................................7 4.2. Using BGP UPDATE Messages.................................8
4.3. SECURE-L3VPN/EVPN.........................................9 4.3. SECURE-L3VPN/EVPN.........................................9
4.4. Preventing attacks from Internet-facing ports............10 4.4. Preventing attacks from Internet-facing ports............10
5. CPEs not directly connected to VPN PEs........................10 5. C-PEs not directly connected to VPN PEs.......................11
5.1. Floating PEs to connect to Remote CPEs...................13 5.1. Floating PEs to connect to Remote CPEs...................13
5.2. NAT Traversal............................................13 5.2. NAT Traversal............................................13
5.3. Complexity of using BGP between PEs and remote CPEs via 5.3. Complexity of using BGP between PEs and remote CPEs via
Internet......................................................13 Internet......................................................13
5.4. Designated Forwarder to the remote edges.................14 5.4. Designated Forwarder to the remote edges.................14
5.5. Traffic Path Management..................................15 5.5. Traffic Path Management..................................15
6. Manageability Considerations..................................15 6. Manageability Considerations..................................15
7. Security Considerations.......................................15 7. Security Considerations.......................................15
8. IANA Considerations...........................................16 8. IANA Considerations...........................................16
9. References....................................................16 9. References....................................................16
skipping to change at page 3, line 12 skipping to change at page 3, line 12
[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 cloud data centers that the dynamic workloads & apps hosted in cloud data centers that the
enterprise's VPN service provider may not own/operate or may be enterprise's VPN service provider may not own/operate or may be
unable to provide the enterprise with the required connectivity to unable to provide the enterprise with the required connectivity to
access such locations. When VPN service providers have insufficient access such locations. When VPN service providers have insufficient
bandwidth to reach a location, SD-WAN techniques can be used to bandwidth to reach a location, SDWAN techniques can be used to
aggregate bandwidth of multiple networks, such as MPLS VPNs or the aggregate bandwidth of multiple networks, such as MPLS VPNs or the
Public Internet to achieve better performance. This document Public Internet to achieve better performance. This document
primarily focuses on the technological gaps raised by using SD-WAN primarily focuses on the technological gaps raised by using SDWAN
techniques to connect enterprise premises to cloud data centers techniques to connect enterprise premises to cloud data centers
operated by third parties. operated by third parties.
For the sake of readability, a SD-WAN edge, a SD-WAN endpoint, C-PE, For the sake of readability, a SDWAN edge, a SDWAN endpoint, C-PE,
or CPE are used interchangeably throughout this document. However, or CPE are used interchangeably throughout this document. However,
each term has some minor emphasis, especially when used in other each term has some minor emphasis, especially when used in other
related documents: related documents:
. SD-WAN Edge: could include multiple devices (virtual or . SDWAN Edge: could include multiple devices (virtual or
physical); physical);
. SD-WAN endpoint: to refer to a WAN port of SD-WAN devices or a . SDWAN endpoint: to refer to a WAN port of SDWAN devices or a
single SD-WAN device; single SDWAN device;
. C-PE: more for provider owned SD-WAN edge, e.g. for SECURE- . C-PE: more for provider owned SDWAN edge, e.g. for SECURE-
EVPN's PE based VPN, when PE is the edge node of SD-WAN; EVPN's PE based VPN, when PE is the edge node of SDWAN;
. CPE: more for enterprise owned SD-WAN edge. . CPE: more for enterprise owned SDWAN 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 SDWAN controller to manage
SD-WAN overlay path creation/deletion and monitor the SDWAN 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, "SD-WAN" refers to SDWAN: Software Defined Wide Area Network, "SDWAN" 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 a management, visibility & control. When the underlay is a
private network, traffic may be forwarded without any private network, traffic may be forwarded without any
additional encryption; when the underlay networks are additional encryption; when the underlay networks are
public, such as the Internet, some traffic needs to be public, such as the Internet, some traffic needs to be
encrypted when passing through (depending on user- encrypted when passing through (depending on user-
provided policies). provided policies).
3. Gap Analysis of C-PEs WAN Port Registration 3. Gap Analysis of C-PEs WAN Port Management
SD-WAN technology has emerged as means to dynamically and securely One of the key characteristics of the networks that interconnect
interconnect the OnPrem branches with the workloads instantiated in workloads in Hybrid Cloud DCs is that those networks' edges can have
Cloud DCs that do not have direct connectivity to BGP/MPLS VPN PEs WAN ports facing networks provided by different ISPs, some can be
or have very limited bandwidth. untrusted public internet, some can be MPLS VPN, some can be Cloud
internal networks, some can be others.
Some SD-WAN networks use the NHRP protocol [RFC2332] to register WAN If an edge node only has one single WAN port facing untrusted
ports of SD-WAN edges with a "Controller" (or NHRP server), which network, then all sensitive data to/from this edge have to be
then has the ability to map a private VPN address to a public IP encrypted, usually by IPsec tunnels which can be terminated at the
address of the destination node. DSVPN [DSVPN] or DMVPN [DMVPN] are single WAN port address or at the edge node's internal address if it
used to establish tunnels between WAN ports of SD-WAN edge nodes. is routable in the wide area network.
If an edge node has multiple WAN ports with some facing private VPN
and some facing public untrusted network, sensitive data can be
forwarded via ports facing VPN natively without encryption and via
ports facing public network with encryption. To achieve this
flexibility, it is necessary to have the IPsec tunnels terminated at
the WAN ports facing the public networks.
In order to establish pair-wise secure encrypted connection among
those WAN ports, it is necessary for peers to be informed of the WAN
port properties.
Some of those overlay networks (a.k.a. SDWAN in the context of this
document) use the modified NHRP protocol [RFC2332] to register WAN
ports of the edges with their "Controller" (or NHRP server), which
then map a private VPN address to a public IP address of the
destination node/port. DSVPN [DSVPN] or DMVPN [DMVPN] are used to
establish tunnels between WAN ports of SDWAN 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 the controller, such as: endpoint C-PE registration to the controller, such as:
- Interworking with the MPLS VPN control plane. A SD-WAN edge can - Interworking with the MPLS VPN control plane. An overlay (SDWAN)
have some ports facing the MPLS VPN network over which packets can edge can have some ports facing the MPLS VPN network over which
be forwarded without any encryption and some ports facing the packets can be forwarded without any encryption and some ports
public Internet over which sensitive traffic needs to be encrypted facing the public Internet over which sensitive traffic needs to
before being sent. be encrypted before being sent.
- Scalability: NHRP/DSVPN/DMVPN works fine with small numbers of - Scalability: NHRP/DSVPN/DMVPN works fine with small numbers of
edge nodes. When a network has more than 100 nodes, these edge nodes. When a network has more than 100 nodes, these
protocols do not scale well. 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 the 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, it is desirable for C-PE's owner to be informed of how/where DC, it is desirable for C-PE's owner to be informed of how/where
the C-PE 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 SD-WAN edge nodes use BGP to register [BGP-SDWAN-PORT] describes how SDWAN edge nodes use BGP to register
their WAN ports properties to the SD-WAN controller, which then their WAN ports properties to the SDWAN controller, which then
propagates the information to other SD-WAN edge nodes that are propagates the information to other SDWAN edge nodes that are
authenticated and authorized to communicate with them. authenticated and authorized to communicate with them.
4. 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 C-PEs interconnected by providers VPNs, such as EVPN, L2VPN,
techniques such as EVPN, L2VPN, or L3VPN. The VPN can be PE-based or or L3VPN, which can be PE-based or CPE-based. The commonly used PE-
CPE-based. The commonly used PE-based VPNs have CPE directly based VPNs have C-PE directly attached to PEs, therefore the
attached to PEs, therefore the communication between CPEs and PEs is communication between C-PEs and PEs is considered as secure. MP-BGP
considered as secure. MP-BGP is used to learn & distribute routes is used to learn & distribute routes among C-PEs, even though
among CPEs, even though sometimes routes among CPEs are statically sometimes routes among C-PEs are statically configured on the C-PEs.
configured on the CPEs.
To aggregate paths over the Internet and paths over the VPN, the C- For enterprises already interconnected by VPNs, it is desirable to
PEs need to have some WAN ports connected to the PEs of the VPNs and aggregate the bandwidth among VPN paths and Internet paths by C-PEs
other WAN ports connected to the Internet. It is necessary for the adding additional ports facing public internet. Under this scenario
CPEs to use a protocol so that they can register the WAN port which is referred to as SDWAN Overlay throughout this document, it
properties with their SD-WAN Controller(s): this information is necessary for the C-PEs to use a protocol to register their WAN
conditions the establishment and the maintenance of IPsec SA port properties with their SDWAN Controller(s). The information is
associations among relevant C-PEs. needed for the establishment and the maintenance of Port-based IPsec
SA associations among relevant C-PEs.
When using NHRP for registration purposes, C-PEs need to run two When using NHRP for registration purposes, C-PEs need to run 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 32 skipping to change at page 7, line 27
+----+ +---------+ +--+ 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. Key Control Plane Components of SD-WAN 4.1. Key Control Plane Components of SDWAN Overlay
As described in [BGP-SDWAN-Usage], the SD-WAN Overlay Control Plane As described in [BGP-SDWAN-Usage], the SDWAN Overlay Control Plane
has three distinct properties: has three distinct properties:
- SD-WAN node's WAN Port Property registration to the SD-WAN - SDWAN node's WAN Port Property registration to the SDWAN
Controller. Controller.
o To inform the SD-WAN controller and authorized peers of o To inform the SDWAN controller and authorized peers of the
the WAN port properties of the C-PE [SDWAN-Port]. When the WAN port properties of the C-PE [SDWAN-Port]. When the WAN
WAN ports are assigned private addresses, this step can ports are assigned private addresses, this step can
register the type of NAT that translates 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 SDWAN 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 SD-WAN nodes. tunnels terminated at the SDWAN 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 SDWAN 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.
4.2. Using BGP Tunnel-Encap 4.2. Using BGP UPDATE Messages
RFC5512 and [Tunnel-Encap] describe methods to construct BGP UPDATE
messages that advertise endpoints' tunnel encapsulation capability
and the respective attached client routes, so that the peers that
receive of the BGP UPDATE can establish appropriate tunnels with the
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
distributing encapsulation tunnel information. [Tunnel-Encap]
requires that tunnels need to be associated with routes.
There is also the Color sub-TLV to describe customer-specified [Tunnel-Encap] describe the BGP UPDATE Tunnel Path Attribute that
information about the tunnels (which can be creatively used for SD- advertise endpoints' tunnel encapsulation capability for the
WAN). respective attached client routes encoded in the MP-NLRI Path
Attribute. The receivers of the BGP UPDATE can use any of the
supported encapsulations encoded in the Tunnel Path Attribute for
the routes encoded in the MP-NLRI Path Attribute.
Here are some of the gaps using [Tunnel-Encap] to control SD-WAN Here are some of the gaps using [Tunnel-Encap] to distribute SDWAN
Tunnels: Edge WAN port properties:
- [Tunnel-Encap] doesn't have the functionality that would help the - [Tunnel-Encap] doesn't yet have the encoding to describe the NAT
C-PE to register its WAN Port properties. information for WAN ports that have private addresses. The NAT
- A SD-WAN tunnel, e.g. IPsec-based, requires a negotiation between information needs to be propagated to the trusted peers via
the tunnel's end points for supported encryption algorithms and Controllers, such as the virtual C-PEs instantiated in public
tunnel types before it can be properly established, whereas Cloud DCs.
[Tunnel-Encap] only allow the announcement of one endpoint's - It is not easy using the current mechanism in [Tunnel-Encap] to
supported encapsulation capabilities for specific attached routes exchange IPsec SA specific parameters independently from
and no negotiation between tunnel end points is needed. The advertising the attached clients' routes, even after adding a new
establishment of a SD-WAN tunnel can fail, e.g., in case the two IPsec tunnel type.
endpoints support different encryption algorithms. That is why a [Tunnel-Encap] requires all tunnels updates are associated with
SD-WAN tunnel needs to be established and maintained independently routes. There can be many client routes associated with the SDWAN
from advertising client routes attached to the edge node.
- [Tunnel-Encap] requires all tunnels updates are associated with
routes. There can be many client routes associated with the SD-WAN
IPsec tunnel between two C-PEs' WAN ports; the corresponding IPsec tunnel between two C-PEs' WAN ports; the corresponding
destination prefixes (as announced by the aforementioned routes) destination prefixes (as announced by the aforementioned routes)
may also be reached through the VPN underlay without any may also be reached through the VPN underlay without any
encryption. A more realistic approach to separate SD-WAN tunnel encryption.
management from client routes association with the SD-WAN tunnels.
- When SD-WAN tunnel and clients routes are separate, the SD-WAN The establishment of an IPsec tunnel can fail, such as due to the
Tunnel establishment may not have routes associated. two endpoints supporting different encryption algorithms or other
There is a suggestion on using a "Fake Route" for a SD-WAN node to reasons. There can be multiple negotiations messages for the IPsec
use [Tunnel-Encap] to advertise its SD-WAN tunnel end-points SA parameters between two end points. That is why IPsec SA
properties. However, using "Fake Route" can raise some design association establishment between end points is independent from
complexity for large SD-WAN networks with many tunnels. For the policies on mapping routes to specific IPSec SA.
example, for a SD-WAN network with hundreds of nodes, with each
node having many ports & many endpoints to establish SD-WAN If C-PEs need to establish WAN Port based IPsec SA, the
tunnels with their corresponding peers, the node would need as information encoded in Tunnel Path Attribute should only apply to
many "fake addresses". For large SD-WAN networks (such as those the WAN ports and should be independent of the clients' routes.
comprised of more than 10000 nodes), each node might need 10's
thousands of "fake addresses", which is very difficult to manage In addition, the SDWAN Tunnel (IPsec SA) may need to be
and requires lots of configuration tasks to get the nodes properly established before clients' routes are attached.
set up.
- [Tunnel-Encap] does not have any field to carry detailed
information about the remote C-PE, such as Site-ID, System-ID,
Port-ID
- [Tunnel-Encap] Does not have any field to carry IPsec attributes
for the SD-WAN edge nodes to establish IPsec Security Associations
with others. It does not have any proper way for two peer CPEs to
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 be connected through a mesh topology. all the C-PEs need to be connected through a mesh topology.
Without any BGP extension, many nodes can get dumped with too much Therefore, the distribution of the SDWAN Overlay Edge WAN ports
information coming from other nodes that they never need to information need be be scoped to the authorized peers.
communicate with.
4.3. SECURE-L3VPN/EVPN 4.3. SECURE-L3VPN/EVPN
[SECURE-L3VPN] describes how to extend the BGP/MPLS VPN [RFC4364] [SECURE-L3VPN] describes how to extend the BGP/MPLS VPN [RFC4364]
capabilities to allow some PEs to connect to other PEs via public capabilities to allow some PEs to connect to other PEs via public
networks. [SECURE-L3VPN] introduces the concept of Red Interface & networks. [SECURE-L3VPN] introduces the concept of Red Interface &
Black Interface used by PEs, where the RED interfaces are used to Black Interface used by PEs, where the RED interfaces are used to
forward traffic into the VPN, and the Black Interfaces are used forward traffic into the VPN, and the Black Interfaces are used
between WAN ports through which only IPsec-protected packets are between WAN ports through which only IPsec-protected packets are
forwarded to the Internet or to other backbone network thereby forwarded to the Internet or to other backbone network thereby
eliminating the need for MPLS transport in the backbone. eliminating the need for MPLS transport in the backbone.
[SECURE-L3VPN] assumes PEs using MPLS over IPsec when sending [SECURE-L3VPN] assumes PEs using MPLS over IPsec when sending
traffic through the Black Interfaces. 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 the SDWAN Scenario #1
relies upon a BGP cluster design to facilitate the key and policy described in [BGP-SDWAN-Usage]. It relies upon a BGP cluster design
exchange among PE devices to create private pair-wise IPsec Security to facilitate the key and policy exchange among PE devices to create
Associations without IKEv2 point-to-point signaling or any other private pair-wise IPsec Security Associations without IKEv2 point-
direct peer-to-peer session establishment messages. to-point signaling or any other 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 - Both documents assume a client traffic is either forwarded all
ports facing VPN PEs and other ports facing the Internet. encrypted through an IPsec tunnel, or not encrypted at all through
a different tunnel regardless which WAN ports the traffic egress
the PEs towards WAN. In SDWAN, one client traffic can be forwarded
encrypted at one time through a WAN port towards untrusted network
and be forwarded unencrypted at different time through a WAN port
to MPLS VPN.
- The [SECURE-L3VPN] assumes that a 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 SDWAN, Zero Touch
Provisioning is expected. Manual configuration is not an option, Provisioning is expected. Manual configuration is not an option,
as it contradicts the objectives of SD-WAN to automate especially for the edge devices that are deployed in faraway
configuration tasks. places.
- For RR communication with C-PEs, this draft only mentions IPsec.
Missing TLS/DTLS.
- The draft assumes that C-PEs and RR are connected with an IPsec
tunnel. With zero touch provisioning, we need an automatic way to
synchronize the IPsec SAs between C-PEs and RR. The draft assumes:
- The [SECURE-L3VPN] assumes that C-PEs and RR are connected via an
IPsec tunnel. Missing TLS/DTLS. The following assumption by
[SECURE-L3VPN] becomes invalid for SDWAN environment where
automatic synchronization of IPsec SA between C-PEs and RR is
needed:
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. The [SECURE-L3VPN]
RR is responsible for creating the key for all endpoints: When one assumes that the RR is responsible for creating/managing the key
endpoint is compromised, all other connections will be impacted. for all endpoints. When one endpoint is compromised, all other
connections will be impacted.
4.4. 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 C-PEs 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. CPEs not directly connected to VPN PEs 5. C-PEs 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 for
enterprise or its network service provider may not have direct specific workloads/Apps, an enterprise or its network service
connections to the Cloud DCs that are used for hosting the provider may not have direct physical connections to the Cloud DCs
enterprise's specific workloads/Apps. Under those circumstances, SD- that are optimal for hosting the enterprise's specific
WAN is a very flexible choice to interconnect the enterprise on- workloads/Apps. Under those circumstances, SDWAN Overlay is a very
premises data centers & branch offices to its desired Cloud DCs. flexible choice to interconnect the enterprise on-premises data
centers & branch offices to its desired Cloud DCs.
However, SD-WAN paths established over the public Internet can have However, SDWAN paths established over the public Internet can have
unpredictable performance, especially over long distances and across unpredictable performance, especially over long distances and across
operators' domains. Therefore, it is highly desirable to steer as operators' domains. Therefore, it is highly desirable to steer as
much as possible the portion of SD-WAN paths over service provider much as possible the portion of SDWAN paths over the enterprise's
VPN (e.g., enterprise's existing VPN) that have guaranteed SLA to existing VPN that has guaranteed SLA to minimize the distance or the
minimize the distance or the number of segments over the public number of segments over the public Internet.
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 uses SD-WAN over LTE or the public of network operators using SDWAN over LTE or the public Internet for
Internet for last mile access where the VPN service providers cannot last mile access where the VPN service providers cannot necessarily
necessarily provide the required physical infrastructure. 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 SDWAN 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 SDWAN to connect the enterprise's existing sites to the
the workloads hosted in Cloud DCs, the corresponding CPEs have to be workloads hosted in Cloud DCs w, the corresponding C-PEs have to be
upgraded to support SD-WAN. If the workloads hosted in Cloud DCs upgraded to support SDWAN. If the workloads hosted in Cloud DCs
need to 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 SDWAN 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 SDWAN secure IPsec
IPsec tunnels. Those designated PEs are shown as fPE (floating PE tunnels. Those designated PEs are shown as fPE (floating PE or
or smart PE) in Figure 3. Once the secure IPsec tunnels are smart PE) in Figure 3. Once the secure IPsec tunnels are
established, the workloads hosted in Cloud DCs 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 SDWAN 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| |
+--| | | | | | | |---+ +--| | | | | | | |---+
+-+--+ ++-+ ++-+ +----+ +-+--+ ++-+ ++-+ +----+
/ | | / | |
/ | MPLS +-+---+ +--+-++--------+ / | MPLS +-+---+ +--+-++--------+
+------+-+ | Network |fPE-1| |CPE || Host | +------+-+ | Network |fPE-1| |CPE || Host |
| Host | | | |- --| || d | | Host | | | |- --| || d |
| c | +-----+ +-+---+ +--+-++--------+ | c | +-----+ +-+---+ +--+-++--------+
+--------+ |fPE-2|-----+ +--------+ |fPE-2|-----+
+---+-+ (|) +---+-+ (|)
(|) (|) SD-WAN (|) (|) SDWAN
(|) (|) over any access (|) (|) over any access
+=\======+=========+ +=\======+=========+
// \ | Cloud DC \\ // \ | Cloud DC \\
// \ ++-----+ \\ // \ ++-----+ \\
+Remote| +Remote|
| CPE | | CPE |
+-+----+ +-+----+
----+-------+-------+----- ----+-------+-------+-----
| | | |
+---+----+ +---+----+ +---+----+ +---+----+
skipping to change at page 13, line 30 skipping to change at page 13, line 30
designate an egress fPE to remote CPEs based on applications. There designate an egress fPE to remote CPEs based on applications. There
is too much applications' traffic traversing PEs, and it is not is too much applications' traffic traversing PEs, and it is not
feasible for PEs to recognize applications from the payload of feasible for PEs to recognize applications from the payload of
packets. packets.
5.2. NAT Traversal 5.2. NAT Traversal
Cloud DCs that only assign private IPv4 addresses to the Cloud DCs that only assign private IPv4 addresses to the
instantiated workloads assume that traffic to/from the workload instantiated workloads assume that traffic to/from the workload
usually needs to traverse NATs. usually needs to traverse NATs.
A SD-WAN edge node can solicit a STUN (Session Traversal of UDP A SDWAN 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 so that property, the public IP address and the Public Port number so that
such information can be communicated to the relevant peers. such information can be communicated to the relevant peers.
5.3. Complexity 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 in extending BGP from MPLS VPN PEs to are still some complications in extending BGP from MPLS VPN PEs to
remote CPEs via any access path (e.g., Internet). remote CPEs via any access path (e.g., Internet).
skipping to change at page 15, line 24 skipping to change at page 15, line 24
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 should be a major Zero touch provisioning of SDWAN edge nodes should be a major
feature of SD-WAN deployments. It is necessary for a newly powered feature of SDWAN deployments. It is necessary for a newly powered
up SD-WAN edge node to establish a secure connection (by means of up SDWAN edge node to establish a secure connection (by means of
TLS, DTLS, 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 SDWAN approaches that can address requirements identified
identified in [Net2Cloud-problem]. 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 SDWAN. 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
skipping to change at page 17, line 23 skipping to change at page 17, line 23
[ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation,
storage, distribution and enforcement of policies for storage, distribution and enforcement of policies for
network security", Nov 2007. network security", Nov 2007.
[Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect [Net2Cloud-Problem] L. Dunbar and A. Malis, "Seamless Interconnect
Underlay to Cloud Overlay Problem Statement", draft-dm- Underlay to Cloud Overlay Problem Statement", draft-dm-
net2cloud-problem-statement-02, June 2018 net2cloud-problem-statement-02, June 2018
10. Acknowledgments 10. Acknowledgments
Acknowledgements to xxx for his review and contributions. Acknowledgements to John Drake for his review and contributions.
Many thanks to John Scudder for stimulating the clarification
discussion on the Tunnel-Encap draft so that our gap analysis can be
more accurate.
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
Futurewei Futurewei
Email: ldunbar@futurewei.com Email: ldunbar@futurewei.com
Andrew G. Malis Andrew G. Malis
Futurewei Independent
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. 59 change blocks. 
185 lines changed or deleted 190 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/