LISP Virtual Private Networks (VPNs)Google LLC1600 Amphitheatre Pkwy94043Mountain ViewCAUSAvimoreno@google.comlispers.netSan Jose95120CAUSAfarinacci@gmail.com
Internet
Network Working GroupLISP; deploymentThis document describes the use of the Locator/ID Separation Protocol
(LISP) to create Virtual Private Networks (VPNs). LISP is used to
provide segmentation in both the LISP data plane and control plane.
These VPNs can be created over the top of the Internet or over private
transport networks, and can be implemented by Enterprises or Service
Providers. The goal of these VPNs is to leverage the characteristics of
LISP - routing scalability, simply expressed Ingress site TE Policy, IP
Address Family traversal, and mobility, in ways that provide value to
network operators.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 .Network virtualization creates multiple, logically separated
topologies across one common physical infrastructure. These logically
separated topologies are known as Virtual Private Networks (VPNs) and
are generally used to create closed groups of end-points. Network
reachability within a VPN is restricted to the addresses of the
end-points that are members of the VPN. This level of segmentation is
useful in providing fault isolation, enforcing access-control
restrictions, enabling the use of a single network by multiple tenants
and scoping network policy per VPN.LISP creates two namespaces: The End-point Identifier (EID) namespace
and the Routing Locator (RLOC) namespace. The LISP Mapping System maps
EIDs to RLOCs. Either the EID space, the RLOC space or both may be
segmented. The LISP Mapping System can be used to map a segmented EID
address space to the RLOC space. When the EID namespace is segmented, a
LISP Instance-ID (IID) is encoded in both the data plane and the control
plane to provide segmentation and to disambiguate overlapping EID
Prefixes. This allows multiple VRFs to 'share' a common Routing Locator
network while maintaining EID prefix segmentation.LISP VPNs must support Multicast traffic in the EID space and must
also support the ability to provide controlled reachability across VPNs
which is commonly known as extranet functionality. When data path
security is needed, LISP virtualization can be combined with LISP Crypto
to provide data path confidentiality, integrity, origin authentication
and anti-replay protection.LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and
Map-Resolver (MR) are defined in the LISP specification
.Terms defining interactions with the LISP Mapping System are defined
in .Terms related to the procedures for signal free multicast are defined
in .The following terms are here defined to facilitate the descriptions
and discussions within this particular document.Forwarding Context - Logical segment of a device's forwarding table
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
MAC forwarding.Home-IID - In the context of cross VPN connectivity, a particular EID
will be registered with multiple Instance-IDs, the Home-IID identifies
the Instance-ID associated to the Forwarding Context (VRF) to which an
EID is actually connected.Extranet-VPN - In the context of cross VPN connectivity, a VPN that
is reachable by all Extranet-Subscriber-VPNs and can reach all
Extranet-Subscriber-VPNs.Extranet-Subscriber-VPN - The VPNs that can reach the Extranet-VPN,
but cannot reach each other.Extranet Policy - The definition of which VPNs share reachability
information with each other in the context of cross VPN connectivity.
May be structured as a group of Extranet-Subscriber-VPNs that subscribe
to an Extranet-VPN.A LISP VPN is a collection of LISP Sites building an Overlay Network.
These sites share a common control plane, the LISP Mapping System. The
members of this VPN also share common RLOC connectivity, whether it be
the Internet or a private IP network.Multiple LISP VPNs may run over a common RLOC space and many LISP
VPNs may share one or more locations, requiring XTRs to service multiple
VPNs simultaneously.VPNs must be allowed to have overlapping address space. It is
necessary to disambiguate the EID namespace in both the control and data
plane as well as maintain forwarding segmentation within the 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 planes.The LISP Instance ID is a 32 bit unstructured namespace that
identifies a LISP VPN. The tuple of EID Prefix and IID is referred to as
an Extended EID (XEID) . The LISP IID is used in
the data plane of the LISP header , as well as
in the LISP control plane .An implementation should default to an Instance ID value equal to
zero when LISP VPNs are not in use.The operation of a LISP VPN is consistent with the operation of LISP
in a non-VPN environment as defined in and
. The
operation of a LISP VPN is here described at a high level in terms of
EID registrations, EID lookups and traffic forwarding: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
associated IID for the VPN. Based on this configuration, the ETRs must
register the EIDs within the forwarding context as Extended EIDs
(IID+EID). The LISP mapping system consolidates the registrations from
all the ETRs in the VPN and builds a mapping database for the VPN.EID Lookup: ITRs that are members of the VPN will do forwarding
lookups in the forwarding context where traffic was received. Upon a
cache miss within the forwarding context, the ITR must issue a
Map-Request for the destination EID and include the VPN's IID. This
information must be encoded as an Extended EID (IID+EID) in the
Map-Request issued. The IID to associate with the EID in this
Map-request is derived from the configuration of the VPN's forwarding
context (in which the traffic was received). The Mapping System should
reply to the Map Request with a Mapping for the Extended EID (IID+EID),
the IID of the Extended EID should be used to identify the forwarding
context in which the Mapping received should be cached.Traffic Forwarding: Once a Mapping has been cached in the VPN's
forwarding context, the ITR will encapsulate the traffic towards the
RLOC in the mapping. The IID corresponding to the VPN's forwarding
context must be included in the Instance-ID field of the data plane
header. When the encapsulated traffic is received at the ETR the
encapsulation header is removed and the IID received in the header is
used to identify the forwarding context to use to do a forwarding lookup
for the decapsulated traffic.A more formal description of the Control and Data Plane procedures
for a LISP VPN is documented in the following sections.In order to create VPNs, the following segmentation functions must be
provided:Device Segmentation. The forwarding tables of the devices must be
segmented so that independent forwarding decisions can be made for
each virtual network. Virtual Routing and Forwarding (VRF) contexts
may be used to create multiple instances of Layer 3 routing tables
virtualization (segmentation) at the device level. If the EID space
is in a Layer 2 address family (e.g. MAC addresses), then Layer 2
contexts such as VLANs or bridge domains may be used to segment the
device. We generalize the concept of separate forwarding tables as
forwarding contexts.Data Plane Segmentation. Data Plane Forwarding separation is
necessary for the devices to maintain virtual network semantics at
forwarding time. Data plane separation can be maintained across
network paths using either single-hop path segmentation (hop-by-hop)
or multi-hop path segmentation. Single-hop path segmentation
mechanisms include constructs such as 802.1q VLAN trunks, multi-hop
mechanisms include MPLS, LISP, VXLAN and GRE tunnels.Control Plane Segmentation. In order to correctly populate the
multiple forwarding tables in the segmented network devices, the
control plane needs to be segmented so that the different updates
that are conveyed by the control plane contain the necessary virtual
network semantics to discriminate between information relevant to
one segment vs another. Control plane segmentation is key to
allowing sites to use overlapping network prefixes in these
logically separate topologies. BGP/MPLS VPNs (ref RFC 4364) are an
example of this control plane segmentation.In a LISP Mapping System supporting VPNs, EID Prefixes should be
registered as Extended EID tuples of information that include the EID
prefix as well as its corresponding Instance ID (IID) information.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 Instance
ID LCAF type defined in . This includes all
LISP messages pertinent to the EIDs in the segmented space, including,
but not limited to, Map-Register, Map-Request, Map-Reply, Map-Notify,
SMRs, etc.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
using the Instance ID LCAF type.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 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 mappings received by an ITR in a Map-Reply should be cached
in the VRF corresponding (by configuration) to the IID included in the
Map-Reply message.The Mapping System must maintain the IID information that
corresponds to any EIDs actively registered with the Mapping
System.A LISP xTR will map, by configuration, a LISP Instance ID to a
given forwarding context in its EID namespace. The Instance-ID must be
included in the data plane header to allow an xTR to identify which
VPN the packet belongs to when encapsulating or decapsulating LISP
packets. The LISP header as
well as the VXLAN header reserve a 24 bit
field for the purposes of encoding the Instance-ID (referred to as
VNID in the VXLAN specification).LISP ITRs may receive non-encapsulated traffic on an interface that
is associated with the forwarding context for a VPN (e.g. VRF). A LISP
ITR should do Map-cache lookups for the destination EID within the
forwarding context in which it received the traffic. The LISP ITR must
encapsulate the traffic to the destination RLOC found in the map-cache
and must include, in the header of the encapsulated packet, the IID
associated with the forwarding context for the VPN. In the event of a
map-cache miss, the LISP ITR must issue a Map-request with the IID
associated with the ITR Ingress VRF as described in .On receipt of an encapsulated LISP packet, a LISP ETR will deliver
the decapsulated packets to the VRF associated with the IID received
in the LISP header. Standard routing lookups will then take place
within the context of the VRF for the forwarding of the decapsulated
packet towards its destination.The use of multiple IIDs on a single site xTR, each mapped to a
different EID VRF allows for multiplexing of VPNs over a Locator
network.This document has so far discussed virtualizing the LISP EID
namespace, and communication between xTRs and the LISP Mapping System.
Implicit in this communication requirement is a network between these
devices. LISP VPNs do not require this underlay network connectivity
to be in the "default" VRF, just that a a given LISP Site and its
Mapping System be interconnected via a common VRF.LISP xTRs may have connectivity to each other via multiple distinct
VRFs, as in the case where the LISP VPN is being used to create an
Overlay with multiple MPLS-VPN Service Providers being used as the
transport. In other words, the RLOC space may also be segmented, the
segmentation of the RLOC space is not done by LISP, but the
segmentation of the RLOC space is delivered by the routing protocols
and data plane used by the RLOC space. When the RLOC space is
segmented, different EID segments may use different RLOC segments. An
RLOC segment may service one or many EID segments, allowing a VPN in
the RLOC space to service a subset of the VPNs created in the EID
space.Both Signaled and Signal Free Multicast within a VPN will operate
without modification in VPN environments provided that all LISP
control plane messages include the Instance ID for their VPN as
specified in . Multicast Source (S) state as
well as multicast Group (G) state are both scoped within a VPN and
therefore the values for S and G may be reused in other VPNs.In a multi-tenant network the communication between a shared VPN and
a multitude of otherwise isolated VPNs is generally known as extranet
communication. Reachability is established between an shared
Extranet-VPN and a multitude of Extranet-Subscriber-VPNs without
enabling reachability between the different Extranet-Subscriber-VPNs.
This section specifies the procedures and protocol encodings necessary
to provide extranet functionality in a multi-instance LISP network. The
mechanisms described require cross VPN lookups and therefore assume that
the EID space across all VPNs involved does not overlap or has been
translated to a normalized space that resolves any overlaps.The operation of a LISP VPN Extranet is consistent with the operation
of LISP VPNs as defined in . The operation of a
LISP VPN Extranet is here described at a high level in terms of EID
registrations, EID lookups and traffic forwarding:EID Registration: EIDs in the Extranet-VPN should be registered in
their Home-IID as well as in all other IIDs that are part of the
Extranet scope. EIDs in the Extranet-Subscriber-VPNs should be
registered in their Home-IID and the Extranet-VPN's IID. This makes the
EIDs available for lookups in VPNs other than their Home-VPN. When an
EID is registered in an IID that it does not belong to, the mapping
should include a parameter containing the Home-IID for the EID. As a
result any EID that should be reachable based on the Extranet
configuration will be registered in every relevant VPN, if the EID is
not native to that VPN, the mapping will have a parameter with the
Home-IID for the EID.EID Lookup: Map-requests will be issued within the IID of the
requesting VPN as specified in . If the
destination is across VPNs, the mapping for the destination EID should
contain the EID's Home-IID as a parameter. The mapping, including the
Home-IID parameter is returned in a Map-Reply and cached by the ITR in
the Forwarding Context of the requesting VPN. The cache will include the
destination's Home-IID as a parameter of the mapping.Traffic Forwarding: An ITR will encapsulate traffic to a cross VPN
destination using the destination's Home-IID in the data plane header.
Upon decapsulation at the ETR, traffic is handed directly to the
destination VPN's forwarding context based on the IID used in the
header.A more formal description of the Control and Data Plane procedures
for a LISP VPN Extranet is documented in the following sections.In order to achieve reachability across VPNs, EID mapping entries
in the Extranet-VPN must be accessible for lookups initiated from an
Extranet-Subscriber-VPN and vice-versa.The definition of which VPNs share reachability information is
governed by configurable Extranet Policy. The Extranet Policy will
simply state which VPNs are extranet-subscribers to a particular
extranet-VPN. There may be multiple Extranet-VPNs in a LISP network
and a VPN may subscribe to multiple Extranet-VPNs. An
Extranet-subscriber-VPN may act as an Extranet-VPN to provide
reachability across Extranet-subscriber-VPNs, this effectively merges
the Extranet-subscriber-VPNs together, a scenario that is usually
better achieved by creating a single Extranet-subscriber-VPN.The Instance-ID (IID) for the VPN to which an EID is connected is
referred to as the Home-IID of the EID. As cross VPN registrations and
lookups take place, the Home-IID for an EID must be preserved and
communicated in any pertinent LISP messages.An ETR may register EIDs in their Home-IID as well as in the
other IIDs within the scope of the Extranet Policy. For example, an
EID connected to the Extranet-VPN may be registered by its ETR in
its Home-IID and also in all the IIDs corresponding to the
Extranet-Subscriber-VPNs defined in the Extranet Policy. When
Map-Register messages for an EID are issued in IIDs other than the
EID's Home-IID, the Home-IID for the EID must be included in the
Map-Register. The Home-IID must be encoded as described in .When registering an EID in multiple IIDs, it is advisable to pack
the multiple registrations in a single Map-Register message
containing the multiple XEID records.A Map-Server may be configured with the Extranet Policy. This may
suffice for the Map-Server to be able to satisfy cross VPN lookups.
In such implementations, ETRs may not be required to register an EID
across the entire scope of IIDs defined in the Extranet Policy, but
may only require the registration of the EID in its Home-IID.Which method of cross VPN mapping registration is used (initiated
by the ETR or initiated by the Map-Server) should be a configurable
option on the XTRs and Map-Server.Map-Request messages issued by an ITR, their structure and use do
not change when a destination EID is outside of the Home-IID for the
source EID.When a Map-Request message is forwarded from the Map-Resolver to
an authoritative Map-Server (either directly or by DDT delegation),
the IID of the requesting EID must be preserved so that the
Map-Reply is sent in the correct context.Map-Reply messages must use the IID of the requesting EID and
must also include the Home-IID of the destination EID. The Home-IID
is a parameter of the destination EID, part of the mapping and must
be encoded as described in . The
mapping obtained in the Map-Reply must be cached in the forwarding
context of the requesting EID, which is identified by the IID for
the requesting EID. The mappings cached will contain the Home-IID of
the destination EID whenever this destination EID is cached outside
of its Home-IID.Since each IID at the Map Server has a complete set of EIDs in
the scope of the extranet policy, the deterination of a covering
prefix in the case of a non-LISP or external destination is
straightforward and follows the proceedures delineated in the
procedures for a negative map reply in .When
the Map Server determines that the requested destination EID is
either not an EID or not registered it must calculate the covering
prefix for the requested EID and reply in one of two ways:- With a Negative Map Reply per the procedures outlined in . If using a PeTR, the Home-IID for the PeTR must
be configured at the requesting ITR.- WIth a Map Reply mapping the calculated EID covering prefix to
the RLOCs of a configured or registered PeTR. The Map Reply must
contain the Home-IID of the registered PeTR.When LISP Extranet VPNs are implemented together with LISP
Publish/Subscribe functionality , the following considerations
apply.Subscriptions initiated across VPNs MUST maintain a record of the
IID from which the subscription was requested. An ITR that issues a
Map-Request with the N-bit set from an Extranet-Subscriber-VPN will
use the IID of the Extranet-Subscriber-VPN as the IID for the XEID
it subscribes to. The Map-Request is routed to the Extranet-VPN
(Home-VPN) where the EID is registered, as defined in . The subscription is maintained in the
Home-VPN and will include a record of the IID of the
Extranet-Subscriber-VPN from which the subscription was
initiated.Any changes in the RLOC set for the EID will be published using a
Map-Notify message. The Map-Notify message will include the
Extranet-Subscriber-VPN IID in the XEID and it will also include the
IID of the Home-VPN (Home-IID) encoded as specified in .The Home-IID is an attribute of the EID-RLOC mapping. The
Home-IID must be encoded as an additional RLOC within the record
carried in Map-Reply messages as defined in . The Home-IID should also be
included in Map-Notify messages when LISP Extranet VPNs are
implemented together with LISP Publish/Subscribe functionality .The additional RLOC containing the Home-IID should use AFI =
16387 (LCAF) with a List type as described in .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 1). The list type is used to include a
distinguished name type (as documented in
that would provide
the semantical information that identifies this field as a Home-IID
to be used for the purposes of Extranet VPNs. Map-Servers and XTRs
receiving the encoded messages would leverage the semantical
information to parse the control plane message properly. The
different LCAF types are documented in .
The logical structure of the nested LCAF structure is
depicted below:Alternatively, a new dedicated LCAF type could be used in order
to include application semantics to the encoding of the IID in a
purposely structured type. In the future, this document may be
updated to provide details of the definition of structure and
semantics for a dedicated LCAF type to be used in this
application.Traffic will be forwarded according to the procedures outlined in
. The map-cache will include
the Home-IID for the destination EID as part of the mapping for
the destination EID. In an ITR, unicast traffic will be encapsulated
using the Home-IID for the destination EID as the Instance-ID in the
encapsulation header. On de-capsulation, the Instance-ID in the header
points to the destination VPN already so no further procedures are
required.When Multicast traffic needs to be forwarded across VPNs, there are
special considerations that are closely tied to the definition of the
Extranet functionality. This specification will focus on the use of
Signal Free Multicast for the delivery of a
cross VPN multicast service.The Receiver-site Registration procedures described in are expanded to allow the formation of a
replication-list inclusive of Receivers detected in the different
VPNs within the scope of the Extranet Policy.Once the Receiver-ETRs detect the presence of Receivers at the
Receiver-site, the Receiver-ETRs will issue Map-Register messages to
include the Receiver-ETR RLOCs in the replication-list for the
multicast-entry the Receivers joined.The encodings for Map-Register messages and the EIDs and RLOCs
within follow the guidelines defined in .For VPNs within the scope of the Extranet Policy the multicast
receiver registrations will be used to build a common replication
list across all VPNs in the Extranet Policy scope. This replication
list is maintained within the scope of the VPN where the multicast
source resides. When Receivers are in the Extranet-Subscriber-VPN,
Multicast sources are assumed to be in the Extranet-VPN and
viceversa.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 where the Multicast Source resides. When listeners are detected
in the Extranet-VPN, then multiple Registrations must be sent with
the Instance-IDs of the Extranet-Subscriber-VPNs under the
assumption that the Multicast sources could be in one or more of the
Extranet-Subscriber-VPNs.Source-ITRs will complete lookups for the replication-list of a
particular multicast group destination as well as the forwarding of
traffic to this multicast group following the procedures defined in
without any change.It is desirable to send a single copy of the Multicast traffic
over the transit network and have the Receiver-ETRs locally
replicate the traffic to all Receiver-VPNs necessary. This
replication is governed by the Extranet Policy configured at the
ETR. Thus, ITRs will encapsulate the traffic with the Instance-ID
for the VPN where the Multicast Source resides. ETRs will receive
traffic in the source IID and replicate it to the Receiver VPNs per
the Extranet Policy.Data driven SMRs MUST carry the IID for the VPNs of the receivers
of traffic. Data driven SMRs MAY carry the IID for the VPNs of senders
of traffic if the sender VPN IIDs are known by the ETR generating the
SMR. If the sender VPN's Instance-ID is not known, the ETR SHOULD send
the SMR to the RLOC of the sending ITR without the sender VPN's
IID.The SMR MUST be replicated to all extranet VPNs that are defined in
the Extranet Policy and instantiated at the sending ITR.When the IID of the sender VPN is known at the ETR, the ETR MAY
include the sender VPN's IID in the SMR and issue a separate SMR for
each sender VPN IID known to the ETR. Multicast optimizations could be
used to minimize the amount of traffic replicated when sending these
SMRs and potentially replicate only at the ITR.When the IID of the sender VPN is not known at the ETR, the ETR
SHOULD issue a single SMR to each of the sending ITRs. The SMR will
then be replicated at the ITR to all extranet VPNs that are defined in
the Extranet Policy and instantiated at the sending ITR.The Instance IDs relevant to the SMR signaling will be encoded in
the SMR Map-request message fields as follows:Source-EID field: If known by the ETR, this field SHOULD carry
the instance-ID of the traffic source VPN at the ITR with the
obsolete map-cache. This is the IID of the senders of the traffic.
Otherwise, the Instance-ID in this field MUST be the same as the
Instance-ID of the destination VPN at the ETR generating the
SMR.EID-Prefix field: This field carries the Instance-ID of the
destination VPN at the ETR sending the SMR. This is the IID of the
receivers of the traffic. This field must always be set with the IID
of the receivers.RLOC Probes must be sent with the IID of the VPN originating the
probe. The XTR receiving the probe must identify the VPN for the
target EID. The XTR receiving the probe should run all verifications
as specified in within the
forwarding context corresponding to the VPN where the target EID is
connected. Once verifications are completed, the reply to the probe
should be sent in the IID of the VPN that originated the probe.LISP and incorporates many security mechanisms
as part of the mapping database service when using control-plane
procedures for obtaining EID-to-RLOC mappings. In general, data plane
mechanisms are not of primary concern for general Internet use-case.
However, when LISP VPNs are deployed, several additional security
mechanisms and considerations must be addressed.Data plane traffic uses the LISP instance-id (IID) header field for
segmentation. in-flight modifications of this IID value could result in
violations to the tenant segmentation provided by the IID. Protection
against this attack can be achieved by using the integrity protection
mechanisms afforded by LISP Crypto, with or without encryption depending
on users' confidentiality requirements (see below).The procedures for data plane confidentiality in LISP are
documented in and are primarily aimed at
negotiating secret shared keys between ITR and ETR in map-request and
map-reply messages. These secret shared keys are negotiated on a per
RLOC basis and without regard for any VPN segmentation done in the EID
space. Thus, multiple VPNs using a shared RLOC may also share a common
secret key to encrypt communications of the multiple VPNs.It is possible to negotiate secret shared keys on a per EID basis
by applying the procedures described in to
RLOC probes. In a VPN environment, RLOC probes would be aimed at
Extended EIDs that contain Instance-ID semantics, therefore resulting
in the calculation of different secret shared keys for different XEID.
Since the keys are calculated per XEID prefix rather than per VPN,
there are scale considerations when implementing this level of key
negotiation granularity.This document has no IANA implicationsThe authors want to thank Marc Portoles, Vrushali Ashtaputre, Johnson
Leong, Jesus Arango, Prakash Jain, Sanjay Hooda, Alberto
Rodriguez-Natal, Darrel Lewis and Greg Schudel for their insightful
contribution to shaping the ideas in this document.