draft-ietf-lisp-vpn-01.txt   draft-ietf-lisp-vpn-02.txt 
Network Working Group V. Moreno Network Working Group V. Moreno
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental D. Farinacci Intended status: Experimental D. Farinacci
Expires: May 19, 2018 lispers.net Expires: November 16, 2018 lispers.net
November 15, 2017 May 15, 2018
LISP Virtual Private Networks (VPNs) LISP Virtual Private Networks (VPNs)
draft-ietf-lisp-vpn-01 draft-ietf-lisp-vpn-02
Abstract Abstract
This document describes the use of the Locator/ID Separation Protocol This document describes the use of the Locator/ID Separation Protocol
(LISP) to create Virtual Private Networks (VPNs). LISP is used to (LISP) to create Virtual Private Networks (VPNs). LISP is used to
provide segmentation in both the LISP data plane and control plane. provide segmentation in both the LISP data plane and control plane.
These VPNs can be created over the top of the Internet or over These VPNs can be created over the top of the Internet or over
private transport networks, and can be implemented by Enterprises or private transport networks, and can be implemented by Enterprises or
Service Providers. The goal of these VPNs is to leverage the Service Providers. The goal of these VPNs is to leverage the
characteristics of LISP - routing scalability, simply expressed characteristics of LISP - routing scalability, simply expressed
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2018. This Internet-Draft will expire on November 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 45 skipping to change at page 3, line 45
2. Definition of Terms 2. Definition of Terms
LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-
Resolver (MR) are defined in the LISP specification [RFC6830]. Resolver (MR) are defined in the LISP specification [RFC6830].
Terms defining interactions with the LISP Mapping System are defined Terms defining interactions with the LISP Mapping System are defined
in [RFC6833]. in [RFC6833].
Terms related to the procedures for signal free multicast are defined Terms related to the procedures for signal free multicast are defined
in [I-D.ietf-lisp-signal-free-multicast]. in [RFC8378].
The following terms are here defined to facilitate the descriptions The following terms are here defined to facilitate the descriptions
and discussions within this particular document. and discussions within this particular document.
Forwarding Context - Logical segment of a device's forwarding table Forwarding Context - Logical segment of a device's forwarding table
and its associated interfaces. This is usually in the form of a VRF and its associated interfaces. This is usually in the form of a VRF
for IP forwarding, may also be in the form of a Bridge Domain or VLAN for IP forwarding, may also be in the form of a Bridge Domain or VLAN
for MAC forwarding. for MAC forwarding.
Home-IID - In the context of cross VPN connectivity, a particular EID Home-IID - In the context of cross VPN connectivity, a particular EID
skipping to change at page 4, line 44 skipping to change at page 4, line 44
VPNs must be allowed to have overlapping address space. It is VPNs must be allowed to have overlapping address space. It is
necessary to disambiguate the EID namespace in both the control and necessary to disambiguate the EID namespace in both the control and
data plane as well as maintain forwarding segmentation within the data plane as well as maintain forwarding segmentation within the
XTRs. The LISP Instance ID (IID) is used to provide a VPN wide XTRs. The LISP Instance ID (IID) is used to provide a VPN wide
unique identifier that can be used both in the control and data unique identifier that can be used both in the control and data
planes. planes.
The LISP Instance ID is a 32 bit unstructured namespace that The LISP Instance ID is a 32 bit unstructured namespace that
identifies a LISP VPN. The tuple of EID Prefix and IID is referred identifies a LISP VPN. The tuple of EID Prefix and IID is referred
to as an Extended EID (XEID) [I-D.ietf-lisp-ddt]. The LISP IID is to as an Extended EID (XEID) [RFC8111]. The LISP IID is used in the
used in the data plane of the LISP header [RFC6830], as well as in data plane of the LISP header [RFC6830], as well as in the LISP
the LISP control plane [I-D.ietf-lisp-lcaf]. control plane [RFC8060].
The operation of a LISP VPN is consistent with the operation of LISP The operation of a LISP VPN is consistent with the operation of LISP
in a non-VPN environment as defined in [RFC6830]. The operation of a in a non-VPN environment as defined in [RFC6830]. The operation of a
LISP VPN is here described at a high level in terms of EID LISP VPN is here described at a high level in terms of EID
registrations, EID lookups and traffic forwarding: registrations, EID lookups and traffic forwarding:
EID registration: In a LISP VPN, XTRs that are members of the VPN EID registration: In a LISP VPN, XTRs that are members of the VPN
should be configured with a forwarding context (e.g. VRF) and the should be configured with a forwarding context (e.g. VRF) and the
associated IID for the VPN. Based on this configuration, the ETRs associated IID for the VPN. Based on this configuration, the ETRs
must register the EIDs within the forwarding context as Extended EIDs must register the EIDs within the forwarding context as Extended EIDs
skipping to change at page 6, line 27 skipping to change at page 6, line 27
an example of this control plane segmentation. an example of this control plane segmentation.
3.1. The LISP IID in the Control Plane 3.1. The LISP IID in the Control Plane
In a LISP Mapping System supporting VPNs, EID Prefixes should be In a LISP Mapping System supporting VPNs, EID Prefixes should be
registered as Extended EID tuples of information that include the EID registered as Extended EID tuples of information that include the EID
prefix as well as its corresponding Instance ID (IID) information. prefix as well as its corresponding Instance ID (IID) information.
In a segmented LISP network, whenever an EID is present in a LISP In a segmented LISP network, whenever an EID is present in a LISP
message, the EID must be encoded as an extended EID using the message, the EID must be encoded as an extended EID using the
Instance ID LCAF type defined in [I-D.ietf-lisp-lcaf]. This includes Instance ID LCAF type defined in [RFC8060]. This includes all LISP
all LISP messages pertinent to the EIDs in the segmented space, messages pertinent to the EIDs in the segmented space, including, but
including, but not limited to, Map-Register, Map-Request, Map-Reply, not limited to, Map-Register, Map-Request, Map-Reply, Map-Notify,
Map-Notify, SMRs, etc. SMRs, etc.
On EID registration by an ETR, the Map-Register message sent by the On EID registration by an ETR, the Map-Register message sent by the
ETR must contain the corresponding IID encoded as part of the EID ETR must contain the corresponding IID encoded as part of the EID
using the Instance ID LCAF type. using the Instance ID LCAF type.
On EID lookup, when an ITR issues a Map-Request, both the Map-Request On EID lookup, when an ITR issues a Map-Request, both the Map-Request
message and the resulting Map-Reply must contain the IID for the EID message and the resulting Map-Reply must contain the IID for the EID
encoded using the IID LCAF type. The IID to use for a Map-Request encoded using the IID LCAF type. The IID to use for a Map-Request
may be derived from the configuration of the ITR Ingress VRF. The may be derived from the configuration of the ITR Ingress VRF. The
mappings received by an ITR in a Map-Reply should be cached in the mappings received by an ITR in a Map-Reply should be cached in the
skipping to change at page 10, line 50 skipping to change at page 10, line 50
4.1.3.1. Home-IID encoded in LCAF List type 4.1.3.1. Home-IID encoded in LCAF List type
The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2). The Home-IID may be encoded as LCAF AFI of type Instance ID (Type 2).
The IID LCAF AFI entry should be nested within a List Type LCAF (Type The IID LCAF AFI entry should be nested within a List Type LCAF (Type
1). The list type is used to include a distinguished name type that 1). The list type is used to include a distinguished name type that
would provide the semantical information that identifies this field would provide the semantical information that identifies this field
as a Home-IID to be used for the purposes of Extranet VPNs. Map- as a Home-IID to be used for the purposes of Extranet VPNs. Map-
Servers and XTRs receiving the encoded messages would leverage the Servers and XTRs receiving the encoded messages would leverage the
semantical information to parse the control plane message properly. semantical information to parse the control plane message properly.
The different LCAF types are documented in [I-D.ietf-lisp-lcaf]. The The different LCAF types are documented in [RFC8060]. The logical
logical structure of the nested LCAF structure is depicted below: structure of the nested LCAF structure is depicted below:
AFI = LCAF(16387) AFI = LCAF(16387)
Type = LIST(1) Type = LIST(1)
ITEM1 ITEM1
AFI = Distinguished Name AFI = Distinguished Name
Value = "Home-IID" Value = "Home-IID"
ITEM2 ITEM2
AFI = LCAF(16387) AFI = LCAF(16387)
Type = IID(2) Type = IID(2)
Value = <Home-IID.value> Value = <Home-IID.value>
skipping to change at page 11, line 38 skipping to change at page 11, line 38
an ITR, unicast traffic will be encapsulated using the Home-IID for an ITR, unicast traffic will be encapsulated using the Home-IID for
the destination EID as the Instance-ID in the encapsulation header. the destination EID as the Instance-ID in the encapsulation header.
On de-capsulation, the Instance-ID in the header points to the On de-capsulation, the Instance-ID in the header points to the
destination VPN already so no further procedures are required. destination VPN already so no further procedures are required.
4.3. LISP Extranet VPN Multicast Considerations 4.3. LISP Extranet VPN Multicast Considerations
When Multicast traffic needs to be forwarded across VPNs, there are When Multicast traffic needs to be forwarded across VPNs, there are
special considerations that are closely tied to the definition of the special considerations that are closely tied to the definition of the
Extranet functionality. This specification will focus on the use of Extranet functionality. This specification will focus on the use of
Signal Free Multicast [I-D.ietf-lisp-signal-free-multicast] for the Signal Free Multicast [RFC8378] for the delivery of a cross VPN
delivery of a cross VPN multicast service. multicast service.
4.3.1. LISP Extranet VPN Multicast Control Plane 4.3.1. LISP Extranet VPN Multicast Control Plane
The Receiver-site Registration procedures described in The Receiver-site Registration procedures described in [RFC8378] are
[I-D.ietf-lisp-signal-free-multicast] are expanded to allow the expanded to allow the formation of a replication-list inclusive of
formation of a replication-list inclusive of Receivers detected in Receivers detected in the different VPNs within the scope of the
the different VPNs within the scope of the Extranet Policy. Extranet Policy.
Once the Receiver-ETRs detect the presence of Receivers at the Once the Receiver-ETRs detect the presence of Receivers at the
Receiver-site, the Receiver-ETRs will issue Map-Register messages to Receiver-site, the Receiver-ETRs will issue Map-Register messages to
include the Receiver-ETR RLOCs in the replication-list for the include the Receiver-ETR RLOCs in the replication-list for the
multicast-entry the Receivers joined. multicast-entry the Receivers joined.
The encodings for Map-Register messages and the EIDs and RLOCs within The encodings for Map-Register messages and the EIDs and RLOCs within
follow the guidelines defined in follow the guidelines defined in [RFC8378].
[I-D.ietf-lisp-signal-free-multicast].
For VPNs within the scope of the Extranet Policy the multicast For VPNs within the scope of the Extranet Policy the multicast
receiver registrations will be used to build a common replication receiver registrations will be used to build a common replication
list across all VPNs in the Extranet Policy scope. This replication list across all VPNs in the Extranet Policy scope. This replication
list is maintained within the scope of the VPN where the multicast list is maintained within the scope of the VPN where the multicast
source resides. When Receivers are in the Extranet-Subscriber-VPN, source resides. When Receivers are in the Extranet-Subscriber-VPN,
Multicast sources are assumed to be in the Extranet-VPN and Multicast sources are assumed to be in the Extranet-VPN and
viceversa. viceversa.
The Instance-ID used to Register the Receiver-ETR RLOCs in the The Instance-ID used to Register the Receiver-ETR RLOCs in the
replication-list is the Instance-ID of the Extranet-VPN, i.e. the VPN replication-list is the Instance-ID of the Extranet-VPN, i.e. the VPN
where the Multicast Source resides. When listeners are detected in where the Multicast Source resides. When listeners are detected in
the Extranet-VPN, then multiple Registrations must be sent with the the Extranet-VPN, then multiple Registrations must be sent with the
Instance-IDs of the Extranet-Subscriber-VPNs under the assumption Instance-IDs of the Extranet-Subscriber-VPNs under the assumption
that the Multicast sources could be in one or more of the Extranet- that the Multicast sources could be in one or more of the Extranet-
Subscriber-VPNs. Subscriber-VPNs.
Source-ITRs will complete lookups for the replication-list of a Source-ITRs will complete lookups for the replication-list of a
particular multicast group destination as well as the forwarding of particular multicast group destination as well as the forwarding of
traffic to this multicast group following the procedures defined in traffic to this multicast group following the procedures defined in
[I-D.ietf-lisp-signal-free-multicast] without any change. [RFC8378] without any change.
4.3.2. LISP Extranet VPN Multicast Data Plane 4.3.2. LISP Extranet VPN Multicast Data Plane
It is desirable to send a single copy of the Multicast traffic over It is desirable to send a single copy of the Multicast traffic over
the transit network and have the Receiver-ETRs locally replicate the the transit network and have the Receiver-ETRs locally replicate the
traffic to all Receiver-VPNs necessary. This replication is governed traffic to all Receiver-VPNs necessary. This replication is governed
by the Extranet Policy configured at the ETR. Thus, ITRs will by the Extranet Policy configured at the ETR. Thus, ITRs will
encapsulate the traffic with the Instance-ID for the VPN where the encapsulate the traffic with the Instance-ID for the VPN where the
Multicast Source resides. ETRs will receive traffic in the source Multicast Source resides. ETRs will receive traffic in the source
IID and replicate it to the Receiver VPNs per the Extranet Policy. IID and replicate it to the Receiver VPNs per the Extranet Policy.
skipping to change at page 13, line 35 skipping to change at page 13, line 35
segmentation. in-flight modifications of this IID value could result segmentation. in-flight modifications of this IID value could result
in violations to the tenant segmentation provided by the IID. in violations to the tenant segmentation provided by the IID.
Protection against this attack can be achieved by using the integrity Protection against this attack can be achieved by using the integrity
protection mechanisms afforded by LISP Crypto, with or without protection mechanisms afforded by LISP Crypto, with or without
encryption depending on users' confidentiality requirements (see encryption depending on users' confidentiality requirements (see
below). below).
5.1. LISP VPNs and LISP Crypto 5.1. LISP VPNs and LISP Crypto
The procedures for data plane confidentiality in LISP are documented The procedures for data plane confidentiality in LISP are documented
in [I-D.ietf-lisp-crypto] and are primarily aimed at negotiating in [RFC8061] and are primarily aimed at negotiating secret shared
secret shared keys between ITR and ETR in map-request and map-reply keys between ITR and ETR in map-request and map-reply messages.
messages. These secret shared keys are negotiated on a per RLOC These secret shared keys are negotiated on a per RLOC basis and
basis and without regard for any VPN segmentation done in the EID without regard for any VPN segmentation done in the EID space. Thus,
space. Thus, multiple VPNs using a shared RLOC may also share a multiple VPNs using a shared RLOC may also share a common secret key
common secret key to encrypt communications of the multiple VPNs. to encrypt communications of the multiple VPNs.
It is possible to negotiate secret shared keys on a per EID basis by It is possible to negotiate secret shared keys on a per EID basis by
applying the procedures described in [I-D.ietf-lisp-crypto] to RLOC applying the procedures described in [RFC8061] to RLOC probes. In a
probes. In a VPN environment, RLOC probes would be aimed at Extended VPN environment, RLOC probes would be aimed at Extended EIDs that
EIDs that contain Instance-ID semantics, therefore resulting in the contain Instance-ID semantics, therefore resulting in the calculation
calculation of different secret shared keys for different XEID. of different secret shared keys for different XEID. Since the keys
Since the keys are calculated per XEID prefix rather than per VPN, are calculated per XEID prefix rather than per VPN, there are scale
there are scale considerations when implementing this level of key considerations when implementing this level of key negotiation
negotiation granularity. granularity.
6. IANA Considerations 6. IANA Considerations
This document has no IANA implications This document has no IANA implications
7. Acknowledgements 7. Acknowledgements
The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson The authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson
Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Darrel Lewis and Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Darrel Lewis and
Greg Schudel for their insightful contribution to shaping the ideas Greg Schudel for their insightful contribution to shaping the ideas
skipping to change at page 15, line 22 skipping to change at page 15, line 22
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-09 (work in progress), January 2017. ddt-09 (work in progress), January 2017.
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in
progress), November 2016. progress), November 2016.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15
(work in progress), October 2017. (work in progress), April 2018.
[I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-06 (work in
progress), August 2017.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407, of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>. October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
skipping to change at page 16, line 12 skipping to change at page 16, line 5
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013,
<https://www.rfc-editor.org/info/rfc6833>. <https://www.rfc-editor.org/info/rfc6833>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>.
Authors' Addresses Authors' Addresses
Victor Moreno Victor Moreno
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Email: vimoreno@cisco.com Email: vimoreno@cisco.com
 End of changes. 16 change blocks. 
44 lines changed or deleted 57 lines changed or added

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