Internet DRAFT - draft-maino-gpe-vpn
draft-maino-gpe-vpn
LISP Working Group F. Maino
Internet-Draft V. Ermagan
Intended status: Informational J. Evans
Expires: September 22, 2016 H. Miclea
Cisco Systems
March 21, 2016
GPE-VPN: Programmable LISP-based Virtual Private Networks
draft-maino-gpe-vpn-00
Abstract
GPE-VPN is an architecture for programmable SD-WAN solutions that
leverages the Generic Protocol Encapsulation (GPE) overlay.
GPE-VPN uses an extended LISP-based map-assisted control plane to
dynamically lookup forwarding policies on demand. A northbound
programmable mapping system is used to store and retrieve mappings
and forwarding policies.
The GPE-VPN data plane is secured with IPsec based encryption.
Overlay tunnels, as well as cryptographic parameters, are provisioned
on demand.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Maino, et al. Expires September 22, 2016 [Page 1]
Internet-Draft draft-maino-gpe-vpn March 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. GPE-VPN Overall Architecture . . . . . . . . . . . . . . . . 3
4. Data Plane Encapsulation . . . . . . . . . . . . . . . . . . 4
5. Data Plane Operations . . . . . . . . . . . . . . . . . . . . 7
5.1. Per Destination Mapping . . . . . . . . . . . . . . . . . 8
5.2. FlowMapping . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Generic Mapping . . . . . . . . . . . . . . . . . . . . . 8
5.4. Interworking . . . . . . . . . . . . . . . . . . . . . . 9
6. Control Plane Operations . . . . . . . . . . . . . . . . . . 9
6.1. Dynamic Policy Rendering . . . . . . . . . . . . . . . . 10
6.1.1. In-Bound Load Balancing . . . . . . . . . . . . . . . 10
6.1.2. Overlay Re-encapsulation . . . . . . . . . . . . . . 11
6.1.3. Group Based Access Control . . . . . . . . . . . . . 12
6.1.4. Service Chaining . . . . . . . . . . . . . . . . . . 12
6.2. Key Management Services . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
GPE-VPN is an architecture for programmable Software Defined VPNs
that leverages the Generic Protocol Encapsulation (GPE) overlay
[I-D.ietf-nvo3-vxlan-gpe].
GPE is effectively merging VXLAN [RFC7348] and LISP [RFC6830]
encapsulation in a single format with supports for multi-tenancy and
multi-protocol payloads.
Maino, et al. Expires September 22, 2016 [Page 2]
Internet-Draft draft-maino-gpe-vpn March 2016
GPE-VPN uses an extended LISP-based map-assisted control plane to
dynamically lookup forwarding policies on demand. A controller-based
mapping system is used to store and retrieve the mapping and
forwarding policies. The mapping system is programmable via
northbound API.
GPE-VPN data plane is secured with IPsec based encryption.
Overlay tunnels, as well as cryptographic parameters, are provisioned
on demand.
2. Definition of Terms
CPE: Customer-premises equipment or customer-provided equipment
(CPE) is the VPN Tunnel Endpoint that enables access to the VPN.
In this memo CPE and xTR are used interchangeably.
GPE: Generic Protocol Encapsulation. In this memo is used to
refer to both VXLAN-GPE and LISP-GPE frame formats.
For definitions of other terms, notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server
(MS), and Map-Resolver (MR) please consult the LISP specification
[RFC6830].
3. GPE-VPN Overall Architecture
A GPE-VPN is designed to enable VPN administrators to specify a high
level intent-based policy that shall be implemented by the VPN. This
includes policies such as connectivity, encryption, access control,
and service chaining.
Maino, et al. Expires September 22, 2016 [Page 3]
Internet-Draft draft-maino-gpe-vpn March 2016
Intent-based Policy
|
V
+------------------------------------+
| Autoconfiguration, Orchestration, | STATELESS
| and Policy Resolution |
| +----------------------------+
| | Resolved Policy
| | |
| | v
| | +----NorthBound API----+
| | | Mapping | Key Mngmnt| STATEFUL
| | +-> | Server | Server |
+---+---+ | +----------------------+
| | ^ ^
+-----+ | |
| +-----------+
| |
+-------Provisioning--+ |
| | |
| +-----Lookup---------+
| | | |
+---V---+--+ +-v--+----+
| xTR/CPE | | xTR/CPE |
+----------+ +---------+
GPE-VPN Architecture
As specified by the intent-based policy, the GPE-VPN auto-configures
the CPEs that implement the data plane of the VPN, and orchestrates
and provisions the infrastructure needed to operate the VPN. The
intent-based policy is then resolved into network forwarding policy,
and is stored in the GPE-VPN mapping infrastructure along with other
provisioned network state. The network state is then made available,
on demand, to the CPEs using the LISP control protocol. Similarly,
the cryptographic state is provisioned on demand by the Key
Management Server.
4. Data Plane Encapsulation
In a GPE-VPN frames are encapsulated accordingly to the VXLAN-GPE
specification.
Maino, et al. Expires September 22, 2016 [Page 4]
Internet-Draft draft-maino-gpe-vpn March 2016
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Ethernet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|R|R|Ver|I|P|R|O| Reserved | Next Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE
| Virtual Network Identifier (VNI) | Reserved | Hdr
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Payload (Ethernet, IPv4, IPv6, NSH, ...) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VXLAN-GPE Encapsulation
Confidentiality and integrity protection are afforded by the use of
ESP (Encapsulating Security Payload) in transport mode. ESP is used
with an authenticated encryption with associated data (AEAD) cipher
such as GCM [RFC4106] that provides confidentiality, integrity, and
anti-replay protection to the payload. The use of an AEAD cipher
provides integrity and anti-replay protection to the GPE header as
well as protection for the Virtual Network Identifier (VNI) and the
other GPE fields from being hijacked over the network.
Maino, et al. Expires September 22, 2016 [Page 5]
Internet-Draft draft-maino-gpe-vpn March 2016
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Ethernet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
|R|R|Ver|I|P|R|O| Reserved | NP = ESP | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AAD |
| Virtual Network Identifier (VNI) | Reserved | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
| SPI | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV
| Sequence Number | |Scope
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | ESP |
| Encrypted Payload + Padding | | |
| | | |
+ +-+-+-+-+-+-+-+-+ | |
| | NP = IP/Eth | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
| ICV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GPE with ESP-GCM
GPE can also be used in combination with the Network Service Header
(NSH), as defined in [I-D.ietf-sfc-nsh], to provide application-level
service chaining. Encryption and NSH are combined thanks to GPE
multiprotocol support.
Maino, et al. Expires September 22, 2016 [Page 6]
Internet-Draft draft-maino-gpe-vpn March 2016
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Ethernet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|R|O| Reserved | NP = ESP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
| NSH Base Header | NP = IP/Eth | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| NSH Service Path Header | NSH|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| NSH Context Headers | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
| | |
| | Enc.
| Payload + Padding | Scope
| | |
+ +-+-+-+-+-+-+-+-+ |
| | NP = NSH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +
| ICV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GPE+NSH with ESP-GCM
5. Data Plane Operations
in a GPE-VPN the CPE performs two main data plane functions:
1. GPE encapsulate un-encapsulated packets that are routed in the
overlay network
2. De-capsulate GPE encapsulated packets that are routed in the
underlay network
In order to perform the encapsulation function, the CPE uses a map-
cache that maps the flow in the overlay to the location(s) (IP
address in the underlay network ) of the next hop or the destination
Maino, et al. Expires September 22, 2016 [Page 7]
Internet-Draft draft-maino-gpe-vpn March 2016
CPE depending on the mapping/forwarding policy defined in the mapping
system.
The map cache is populated on demand using the LISP [RFC6830] map-
request/map-reply protocol. In order to support multi-tenancy, each
entry in the map-cache is associated with a VNI that identifies the
overlay network of a specific tenant.
The map-cache supports multi-homing and load balancing by supporting
mapping a single overlay end point to multiple locations in the
underlay along with their priority and weight.
5.1. Per Destination Mapping
The simplest form of mapping supported by a map-cache is the mapping
between the Endpoint Identifier (EID, the destination IP or MAC
address of the endpoint in the overlay space) and the locator IP
address of the destination CPE (its IP address in the underlay
space).
EIDs can be either an IP address (L3 overlay) or a MAC address (L2
overlay).
This is the basic function that allows to interconnect VPN sites
creating a virtual overlay network that constitutes the VPN. Any
endpoint identified by a source EID in a VPN, can reach any other
endpoint identified by a destination EID as long as the CPE has an
entry in its map-cache for that destination EID.
5.2. FlowMapping
Some CPEs have the capability to map a generic n-tuple (typically a
subset of the <source EID, destination EID, source Port, destination
Port, Protocol> as defined in
[I-D.rodrigueznatal-lisp-multi-tuple-eids]) onto the next hop or
destination CPE location .
This allows a much finer granularity in applying the connectivity
policy of the VPN. A different connectivity policy can be applied to
each pair of endpoints in the overlay, or even per each protocol.
Per Destintion Mapping is, in fact, a subset of FlowMapping.
5.3. Generic Mapping
Some CPEs have the capability to map and encap based on a generic
"tag" (metadata contained in the packet).
Maino, et al. Expires September 22, 2016 [Page 8]
Internet-Draft draft-maino-gpe-vpn March 2016
This enables GPE-VPN to offer overlay services to various protocols
and applications, as a specific flow is tunneled to a given
destination CPE based on the value of the metadata.
As an example a packet may include an NSH header [I-D.ietf-sfc-nsh]
that contains metadata used to identify an application-level service
function chain that should be applied to that packet before reaching
destination. The map-cache can be programmed [I-D.ermagan-lisp-nsh]
to tunnel that packet to the service node that implements the next
hop in that service function chain and, eventually, to its
destination.
5.4. Interworking
Interworking between the VPN and outside networks (e.g. the Internet)
is provided by special gateways (LISP PxTRs) that support the encap
and decap function for incoming (to the VPN) and outgoing packets.
Gateways also provide reachability to the VPN endpoints from the
outside network by advertising highly aggregated EID-Prefix space on
behalf of the GPE-VPN.
6. Control Plane Operations
The rendering of the connectivity policy between GPE-VPN sites is
based on map-and-encap. When an un-encapsulated flow reaches a CPE,
the CPE uses the LISP map-request/map-reply protocol to query the
mapping system for the location of the next hop associated with this
flow.
The CPE then caches the map-reply that contains the mapping
associated with the given flow in its map-cache, so that subsequent
packets in this flow hitting that CPE can be encapsulated right away.
The map-cache entries are aged and refreshed accordingly to their
utilization.
The map-request is encoded using an extensible format
[I-D.ietf-lisp-lcaf] that can include a rich set of information not
only about the specific flow that has generated the map-request, but
also about the CPE sending the request.
As an example, the location of the source CPE can be included in the
map-request, or its unique ID, providing the mapping server with
information about the current location of the source endpoint that
initiated that flow.
Maino, et al. Expires September 22, 2016 [Page 9]
Internet-Draft draft-maino-gpe-vpn March 2016
6.1. Dynamic Policy Rendering
The map-request is sent to a logically centralized map server that is
programmed, via northbound API, with the rendering of the high level
policies of the GPE-VPN.
The mapping is dynamically updated to reflect both high level policy
changes, as well as changes to the state of the network (as measured
by various metrics, including probing sent in the data plane, or
reachability information registered by the CPEs). In general
telemetric infrastructures can be used to provide the mapping server
with a very detailed monitoring of both the underlay and overlay
network. In a typical GPE-VPN implementation a telemetry server will
collect telemetry data from the network via southbound API. Data is
fed to an analytics engine that will update the mapping server via
northbound API.
The mapping server can then leverage this amount of information to
provide a map-reply that is not only the rendering of the
connectivity policy, but also the rendering of a number of other
policies applied to the VPN (overlar re-encapsulation, in-bound load
balancing, virtual topologies, group based access control, service
chaining, ...).
This is one of the most powerful characteristics of a GPE-VPN that
makes the mapping server a logically centralized policy enforcement
point.
To allow for a more dynamic policy change, the LISP protocol is being
extended [I-D.rodrigueznatal-lisp-ms-smr] to support map-server
notifications that are used to implement publish/subscribe
mechanisms.
Below is a list of the most common policy renderings that may be
implemented in a GPE-VPN.
6.1.1. In-Bound Load Balancing
For each overlay end point, the mapping system can specify a list of
the locator IP addresses associated with the destination CPE. Each
locator is associated with a priority and weight that will determine
the in-bound load balancing at the destination CPE.
The sending CPE, upon receiving a map-reply, will encapsulate the
outgoing traffic according to the priority and weight associated with
the locators in the mapping. This is used to implement active/active
or active/stand-by inbound load balancing.
Maino, et al. Expires September 22, 2016 [Page 10]
Internet-Draft draft-maino-gpe-vpn March 2016
6.1.2. Overlay Re-encapsulation
The high level policy of a GPE-VPN may include overlay re-
encapsulation at Re-encapsulating Tunnel Routers (RTRs). The re-
encapsulation network function is rendered by the mapping system by
providing a different next hop to mapping requests coming from
different CPEs/routers.
This section provides a few examples of the use of the re-
encapsulation network function.
6.1.2.1. Virtual Topologies
While a GPE-VPN supports any-to-any connectivity, it is possible to
implement virtual topologies by manipulating the mappings and using
overlay re-encapsulation.
For example to implement an hub-and-spoke topology, the mapping
system will be programmed in such a way that map-requests coming from
a spoke will always generate map-replays containing the address of
the hub as destination locator. In this way all the traffic
generated at a spoke will be directed to the hub first, de-capsulated
and then re-encapsulated to the destination spoke.
6.1.2.2. Hierarchical VPNs
some GPE-VPNs may have an hierarchical structure with CPEs grouped in
regions that convey traffic to a core via a set od data centers
positioned at the edge of the core. Depending on its geographical
location, a CPE will send traffic to the RTR located at the edge data
center that oversees that region.
Re-encapsulation may be required for a number of reasons, including
traffic inspection.
Once a flow from a VPN site A directed to VPN site B hits CPE A, it
will generate a map-request that will contain not only the
destination EID, but also information about the requesting CPE (e.g.
its location, or a site ID). The mapping system, in order to render
the hierarchical VPN policy, will return a map-replay to CPE A
specifying the location of the re-encapsulating router R as tunnel
destination. Once the flow gets to the re-encapsulating router R, it
will generate another map-request, for the same flow, but with
attributes associated with router R. The mapping system will then
render the hierarchical VPN policy by returning the locations of CPE
B.
Maino, et al. Expires September 22, 2016 [Page 11]
Internet-Draft draft-maino-gpe-vpn March 2016
The dynamic manipulation of the mapping is what allows the mapping
system to render complex re-encapsulation policies.
6.1.3. Group Based Access Control
Mapping manipulation can also be used to render Group Based Policies
(GBP). The intent-based GBP will define groups of endpoints, and the
ACLs that shall apply to each group. This is resolved into mapping
state so that when the mapping system is resolving a map-request to
connect endpoint A to endpoint B, the mapping will reflect the GBP
policy, and will not provide connectivity if there's an ACL
preventing communication between the groups to which A and B belongs.
6.1.4. Service Chaining
A GPE-VPN renders application-level Service Chaining Policies by
using the mapping system to support the NSH protocol, as described in
[I-D.ermagan-lisp-nsh]. NSH uses classification engines to classify
flows that should be forced through a given service chain and tags
them with an NSH header that contains a certain Service Path
Identifier (SPI). Once classified and tagged, the packet needs to be
routed to the associated next hop service node(s) that will implement
the service chain. The mapping system in this case is programmed to
support an SPI to Service Node Location lookup, so that a CPE
receiving a packet with a given SPI and Service Index can lookup the
address(es) of the next hop service nodes for the specified service
chain.
This is an example of a generic mapping service provided by the GPE-
VPN mapping system to support a specific protocol other than IP or
Ethernet.
6.2. Key Management Services
Provisioning of Security Associations (SAs) for a GPE-VPN is a trade-
off between the time needed to set up on demand the security
association and the overall security afforded by the GPE-VPN security
infrastructure.
There is a continuum of solutions that can be listed in (approximate)
increasing order of security afforded:
1. Leverage the LISP map-request/map-reply protocol to provision on
demand uni-directional security associations. The LISP crypto
draft [I-D.ietf-lisp-crypto], is an example where the LISP map-
request/map-reply protocol is augmented with an un-authenticated
Diffie-Hellman exchange that provisions encryption keys to the
CPEs tunnel endpoints. These mechanisms provide the most
Maino, et al. Expires September 22, 2016 [Page 12]
Internet-Draft draft-maino-gpe-vpn March 2016
efficient setup time of the SAs (that in [I-D.ietf-lisp-crypto]
requires just an additional round-trip between the CPEs) as a
trade-off with the security afforded, that relies on the security
of the LISP map-request/map-replay protocol and on the relatively
simple structure of the security messages exchanged between the
CPEs.
2. Leverage a Group Domain of Interpretation (GDOI) crypto protocol,
such as the GDOI IPsec extension [RFC6407], for key management.
These protocols use group key distribution mechanisms to securely
provision IPsec encryption keys (and SA parameters) to the CPEs
that belong to the same GPE-VPN. This typically requires
slightly longer SA setup times, compared with the previous
solutions, but the key management infrastructure is independent
from the LISP mapping infrastructure. This, typically, offers a
higher level of security compared to the previous solutions.
3. Leverage the traditional IKEv2 [RFC5996] protocol to negotiate
pairwise SAs between CPEs. While this typically offers the
highest level of security, the setup of SAs is quite time
consuming, and it has a significant impact on the advantages
introduced by creating tunnels on demand using a map-and-encap
protocol.
7. Security Considerations
Security considerations that applies to a GPE-VPN are discuss through
this memo.
8. IANA Considerations
No IANA considerations.
9. Acknowledgements
10. Normative References
[I-D.ermagan-lisp-nsh]
Ermagan, V., Quinn, P., Lewis, D., Maino, F., and F.
Coras, "LISP Control Plane integration with NSH", draft-
ermagan-lisp-nsh-00 (work in progress), October 2015.
[I-D.ietf-lisp-crypto]
Farinacci, D. and B. Weis, "LISP Data-Plane
Confidentiality", draft-ietf-lisp-crypto-03 (work in
progress), December 2015.
Maino, et al. Expires September 22, 2016 [Page 13]
Internet-Draft draft-maino-gpe-vpn March 2016
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in
progress), September 2015.
[I-D.ietf-nvo3-vxlan-gpe]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
P., and D. Melman, "Generic Protocol Extension for VXLAN",
draft-ietf-nvo3-vxlan-gpe-01 (work in progress), November
2015.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-02 (work in progress), January 2016.
[I-D.rodrigueznatal-lisp-ms-smr]
Rodriguez-Natal, A., Cabellos-Aparicio, A., Ermagan, V.,
Maino, F., and S. Barkai, "MS-originated SMRs", draft-
rodrigueznatal-lisp-ms-smr-00 (work in progress),
September 2015.
[I-D.rodrigueznatal-lisp-multi-tuple-eids]
Rodriguez-Natal, A., Cabellos-Aparicio, A., Barkai, S.,
Ermagan, V., Lewis, D., Maino, F., and D. Farinacci, "LISP
support for Multi-Tuple EIDs", draft-rodrigueznatal-lisp-
multi-tuple-eids-01 (work in progress), January 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005,
<http://www.rfc-editor.org/info/rfc4106>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<http://www.rfc-editor.org/info/rfc5996>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <http://www.rfc-editor.org/info/rfc6407>.
Maino, et al. Expires September 22, 2016 [Page 14]
Internet-Draft draft-maino-gpe-vpn March 2016
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
Authors' Addresses
Fabio Maino
Cisco Systems
Email: fmaino@cisco.com
Vina Ermagan
Cisco Systems
Email: vermagan@cisco.com
John Evans
Cisco Systems
Email: joevans@cisco.com
Horia Miclea
Cisco Systems
Email: hmiclea@cisco.com
Maino, et al. Expires September 22, 2016 [Page 15]
