draft-ietf-lisp-ms-16.txt   rfc6833.txt 
Network Working Group V. Fuller Internet Engineering Task Force (IETF) V. Fuller
Internet-Draft D. Farinacci Request for Comments: 6833
Intended status: Experimental cisco Systems Category: Experimental D. Farinacci
Expires: September 5, 2012 March 4, 2012 ISSN: 2070-1721 Cisco Systems
January 2013
LISP Map Server Interface Locator/ID Separation Protocol (LISP) Map-Server Interface
draft-ietf-lisp-ms-16.txt
Abstract Abstract
This draft describes the Maping Service for the Locator Identifier This document describes the Mapping Service for the Locator/ID
Separation Protocol (LISP), implemented by two new types of LISP- Separation Protocol (LISP), implemented by two new types of LISP-
speaking devices, the LISP Map Resolver and LISP Map Server, that speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that
provides a simplified "front end" to for one or more Endpoint ID to provides a simplified "front end" for one or more Endpoint ID to
Routing Locator mapping databases. Routing Locator mapping databases.
By using this service interface and communicating with Map Resolvers By using this service interface and communicating with Map-Resolvers
and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel
Routers, are not dependent on the details of mapping database Routers are not dependent on the details of mapping database systems,
systems, which facilitates experimentation with different database which facilitates experimentation with different database designs.
designs. Since these devices implement the "edge" of the LISP Since these devices implement the "edge" of the LISP infrastructure,
infrastructure, connect directly to LISP-capable Internet end sites, connect directly to LISP-capable Internet end sites, and comprise the
and comprise the bulk of LISP-speaking devices, reducing their bulk of LISP-speaking devices, reducing their implementation and
implementation and operational complexity should also reduce the operational complexity should also reduce the overall cost and effort
overall cost and effort of deploying LISP. of deploying LISP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on September 5, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6833.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms .............................................3
3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Overview ..................................................4
4. Interactions With Other LISP Components . . . . . . . . . . . 6 4. Interactions with Other LISP Components .........................5
4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 6 4.1. ITR EID-to-RLOC Mapping Resolution .........................5
4.2. EID Prefix Configuration and ETR Registration . . . . . . 7 4.2. EID-Prefix Configuration and ETR Registration ..............6
4.3. Map Server Processing . . . . . . . . . . . . . . . . . . 8 4.3. Map-Server Processing ......................................8
4.4. Map Resolver Processing . . . . . . . . . . . . . . . . . 9 4.4. Map-Resolver Processing ....................................9
4.4.1. Anycast Map Resolver Operation . . . . . . . . . . . . 10 4.4.1. Anycast Map-Resolver Operation .....................10
5. Open Issues and Considerations . . . . . . . . . . . . . . . . 11 5. Open Issues and Considerations .................................10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations ........................................11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References .....................................................12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References ......................................12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References ....................................12
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments .......................................13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
[LISP], the Locator Identifier Separation Protocol, specifies an The Locator/ID Separation Protocol [RFC6830] specifies an
architecture and mechanism for replacing the addresses currently used architecture and mechanism for replacing the addresses currently used
by IP with two separate name spaces: Endpoint IDs (EIDs), used within by IP with two separate name spaces: Endpoint IDs (EIDs), used within
sites, and Routing Locators (RLOCs), used on the transit networks sites; and Routing Locators (RLOCs), used on the transit networks
that make up the Internet infrastructure. To achieve this that make up the Internet infrastructure. To achieve this
separation, LISP defines protocol mechanisms for mapping from EIDs to separation, LISP defines protocol mechanisms for mapping from EIDs to
RLOCs. In addition, LISP assumes the existence of a database to RLOCs. In addition, LISP assumes the existence of a database to
store and propagate those mappings globally. Several such databases store and propagate those mappings globally. Several such databases
have been proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] have been proposed; among them are the Content distribution Overlay
and LISP+ALT [ALT]. Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD
(a Not-so-novel EID-to-RLOC Database) [RFC6837], and LISP Alternative
Logical Topology (LISP+ALT) [RFC6836].
The LISP Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of LISP-speaking
devices: the Map Resolver, which accepts Map-Requests from an Ingress devices: the Map-Resolver, which accepts Map-Requests from an Ingress
Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
mapping database, and the Map Server, which learns authoritative EID- mapping database; and the Map-Server, which learns authoritative
to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
them in a database. them in a database.
Conceptually, LISP Map Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same basic
configuration and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain Name System (DNS)
[RFC1035] servers; likewise, Map Resolvers are conceptually similar [RFC1035] servers; likewise, Map-Resolvers are conceptually similar
to DNS caching resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this specification
borrows familiar terminology (resolver and server) from the DNS borrows familiar terminology (resolver and server) from the DNS
specifications. specifications.
Note that while this document assumes a LISP+ALT database mapping Note that while this document assumes a LISP+ALT database mapping
infrastructure to illustrate certain aspects of Map Server and Map infrastructure to illustrate certain aspects of Map-Server and
Resolver operation, the Mapping Service interface can (and likely Map-Resolver operation, the Mapping Service interface can (and likely
will) be used by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other mapping database
systems as the LISP infrastructure evolves. systems as the LISP infrastructure evolves.
Section 5 of this document notes a number of issues with the Map Section 5 of this document notes a number of issues with the
Server and Map Resolver design that are not yet completely understood Map-Server and Map-Resolver design that are not yet completely
and are subjects of further experimentation. understood and are subjects of further experimentation.
The LISP Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of the LISP
toolset. Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of LISP for
Internet traffic are discussed in [LISP]. Internet traffic are discussed in [RFC6830].
2. Definition of Terms 2. Definition of Terms
Map Server: a network infrastructure component which learns of EID- Map-Server: A network infrastructure component that learns of
prefix mapping entries from an ETR, via the registration mechanism EID-Prefix mapping entries from an ETR, via the registration
described below, or some other authoritative source if one exists. mechanism described below, or some other authoritative source if
A Map Server publishes these EID-prefixes in a mapping database. one exists. A Map-Server publishes these EID-Prefixes in a
mapping database.
Map Resolver: a network infrastructure component which accepts LISP Map-Resolver: A network infrastructure component that accepts LISP
Encapsulated Map-Requests, typically from an ITR, determines Encapsulated Map-Requests, typically from an ITR, and determines
whether or not the destination IP address is part of the EID whether or not the destination IP address is part of the EID
namespace; if it is not, a Negative Map-Reply is returned. namespace; if it is not, a Negative Map-Reply is returned.
Otherwise, the Map Resolver finds the appropriate EID-to-RLOC Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC
mapping by consulting a mapping database system. mapping by consulting a mapping database system.
Encapsulated Map-Request: a LISP Map-Request carried within an Encapsulated Map-Request: A LISP Map-Request carried within an
Encapsulated Control Message, which has an additional LISP header Encapsulated Control Message, which has an additional LISP header
prepended. Sent to UDP destination port 4342. The "outer" prepended. Sent to UDP destination port 4342. The "outer"
addresses are globally-routeable IP addresses, also known as addresses are globally routable IP addresses, also known as RLOCs.
RLOCs. Used by an ITR when sending to a Map Resolver and by a Map Used by an ITR when sending to a Map-Resolver and by a Map-Server
Server when forwarding a Map-Request to an ETR. when forwarding a Map-Request to an ETR.
Negative Map-Reply: a LISP Map-Reply that contains an empty Negative Map-Reply: A LISP Map-Reply that contains an empty
locator-set. Returned in response to a Map-Request if the Locator-Set. Returned in response to a Map-Request if the
destination EID does not exist in the mapping database. destination EID does not exist in the mapping database.
Typically, this means that the "EID" being requested is an IP Typically, this means that the "EID" being requested is an IP
address connected to a non-LISP site. address connected to a non-LISP site.
Map-Register message: a LISP message sent by an ETR to a Map Server Map-Register message: A LISP message sent by an ETR to a Map-Server
to register its associated EID-prefixes. In addition to the set to register its associated EID-Prefixes. In addition to the set
of EID-prefixes to register, the message includes one or more of EID-Prefixes to register, the message includes one or more
RLOCs to be be used by the Map Server when forwarding Map-Requests RLOCs to be used by the Map-Server when forwarding Map-Requests
(re-formatted as Encapsulated Map-Requests) received through the (re-formatted as Encapsulated Map-Requests) received through the
database mapping system. An ETR may request that the Map Server database mapping system. An ETR may request that the Map-Server
answer Map-Requests on its behalf by setting the "proxy-map-reply" answer Map-Requests on its behalf by setting the "proxy Map-Reply"
flag (P-bit) in the message. flag (P-bit) in the message.
Map-Notify message: a LISP message sent by a Map Server to an ETR Map-Notify message: A LISP message sent by a Map-Server to an ETR
to confirm that a Map-Register has been received and processed. to confirm that a Map-Register has been received and processed.
An ETR requests that a Map-Notify be returned by setting the An ETR requests that a Map-Notify be returned by setting the
"want-map-notify" or "M" bit in the Map-Register message. Unlike "want-map-notify" flag (M-bit) in the Map-Register message.
a Map-Reply, a Map-Notify uses UDP port 4342 for both source and Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both
destination. source and destination.
For definitions of other terms, notably Map-Request, Map-Reply, For definitions of other terms -- notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
consult the LISP specification [LISP]. consult the LISP specification [RFC6830].
3. Basic Overview 3. Basic Overview
A Map Server is a device which publishes EID-prefixes in a LISP A Map-Server is a device that publishes EID-Prefixes in a LISP
mapping database on behalf of a set of ETRs. When it receives a Map mapping database on behalf of a set of ETRs. When it receives a Map
Request (typically from an ITR) it consults the mapping database to Request (typically from an ITR), it consults the mapping database to
find an ETR that can answer with the set of RLOCs for an EID-prefix. find an ETR that can answer with the set of RLOCs for an EID-Prefix.
To publish its EID-prefixes, an ETR periodically sends Map-Register To publish its EID-Prefixes, an ETR periodically sends Map-Register
messages to the Map Server. A Map-Register message contains a list messages to the Map-Server. A Map-Register message contains a list
of EID-prefixes plus a set of RLOCs that can be used to reach the ETR of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR
when a Map Server needs to forward a Map-Request to it. when a Map-Server needs to forward a Map-Request to it.
When LISP+ALT is used as the mapping database, a Map Server connects When LISP+ALT is used as the mapping database, a Map-Server connects
to ALT network and acts as a "last-hop" ALT router. Intermediate ALT to the ALT network and acts as a "last-hop" ALT-Router. Intermediate
routers forward Map-Requests to the Map Server that advertises a ALT-Routers forward Map-Requests to the Map-Server that advertises a
particular EID-prefix and the Map Server forwards them to the owning particular EID-Prefix, and the Map-Server forwards them to the owning
ETR, which responds with Map-Reply messages. ETR, which responds with Map-Reply messages.
A Map Resolver receives Encapsulated Map-Requests from its client A Map-Resolver receives Encapsulated Map-Requests from its client
ITRs and uses a mapping database system to find the appropriate ETR ITRs and uses a mapping database system to find the appropriate ETR
to answer those requests. On a LISP+ALT network, a Map Resolver acts to answer those requests. On a LISP+ALT network, a Map-Resolver acts
as a "first-hop" ALT router. It has GRE tunnels configured to other as a "first-hop" ALT-Router. It has Generic Routing Encapsulation
ALT routers and uses BGP to learn paths to ETRs for different (GRE) tunnels configured to other ALT-Routers and uses BGP to learn
prefixes in the LISP+ALT database. The Map Resolver uses this path paths to ETRs for different prefixes in the LISP+ALT database. The
information to forward Map-Requests over the ALT to the correct ETRs. Map-Resolver uses this path information to forward Map-Requests over
the ALT to the correct ETRs.
Note that while it is conceivable that a Map Resolver could cache Note that while it is conceivable that a Map-Resolver could cache
responses to improve performance, issues surrounding cache management responses to improve performance, issues surrounding cache management
will need to be resolved for doing so to be reliable and practical. will need to be resolved so that doing so will be reliable and
As initially deployed, Map Resolvers will operate only in a non- practical. As initially deployed, Map-Resolvers will operate only in
caching mode, de-decapsulating and forwarding Encapsulated Map a non-caching mode, decapsulating and forwarding Encapsulated Map
Requests received from ITRs. Any specification of caching Requests received from ITRs. Any specification of caching
functionality is left for future work. functionality is left for future work.
Note that a single device can implement the functions of both a Map Note that a single device can implement the functions of both a
Server and a Map Resolver and, in many cases, the functions will be Map-Server and a Map-Resolver, and in many cases the functions will
co-located in that way. be co-located in that way.
Detailed descriptions of the LISP packet types referenced by this Detailed descriptions of the LISP packet types referenced by this
document may be found in [LISP]. document may be found in [RFC6830].
4. Interactions With Other LISP Components 4. Interactions with Other LISP Components
4.1. ITR EID-to-RLOC Mapping Resolution 4.1. ITR EID-to-RLOC Mapping Resolution
An ITR is configured with one or more Map Resolver addresses. These An ITR is configured with one or more Map-Resolver addresses. These
addresses are "locators" (or RLOCs) and must be routeable on the addresses are "Locators" (or RLOCs) and must be routable on the
underlying core network; they must not need to be resolved through underlying core network; they must not need to be resolved through
LISP EID-to-RLOC mapping as that would introduce a circular LISP EID-to-RLOC mapping, as that would introduce a circular
dependency. When using a Map Resolver, an ITR does not need to dependency. When using a Map-Resolver, an ITR does not need to
connect to any other database mapping system. In particular, the ITR connect to any other database mapping system. In particular, the ITR
need not connect to the LISP+ALT infrastructure or implement the BGP need not connect to the LISP+ALT infrastructure or implement the BGP
and GRE protocols that it uses. and GRE protocols that it uses.
An ITR sends an Encapsulated Map-Request to a configured Map Resolver An ITR sends an Encapsulated Map-Request to a configured Map-Resolver
when it needs an EID-to-RLOC mapping that is not found in its local when it needs an EID-to-RLOC mapping that is not found in its local
map-cache. Using the Map Resolver greatly reduces both the map-cache. Using the Map-Resolver greatly reduces both the
complexity of the ITR implementation and the costs associated with complexity of the ITR implementation and the costs associated with
its operation. its operation.
In response to an Encapsulated Map-Request, the ITR can expect one of In response to an Encapsulated Map-Request, the ITR can expect one of
the following: the following:
o An immediate Negative Map-Reply (with action code of "forward- o An immediate Negative Map-Reply (with action code of
native", 15-minute TTL) from the Map Resolver if the Map Resolver "Natively-Forward", 15-minute Time to Live (TTL)) from the
can determine that the requested EID does not exist. The ITR Map-Resolver if the Map-Resolver can determine that the requested
saves the EID-prefix returned in the Map-Reply in its cache, EID does not exist. The ITR saves the EID-Prefix returned in the
marking it as non-LISP-capable and knows not to attempt LISP Map-Reply in its cache, marks it as non-LISP-capable, and knows
encapsulation for destinations matching it. not to attempt LISP encapsulation for destinations matching it.
o A Negative Map-Reply (with action code of "forward-native") from o A Negative Map-Reply, with action code of "Natively-Forward", from
the Map Server that has an aggregate EID-covering the EID in the a Map-Server that is authoritative for an EID-Prefix that matches
Map-Request but where the EID matches a "hole" in the aggregate. the requested EID but that does not have an actively registered,
If the "hole" is for a LISP EID-prefix that is defined in the Map more-specific ID-prefix. In this case, the requested EID is said
Server configuration but for which no ETRs are currently to match a "hole" in the authoritative EID-Prefix. If the
registered, a 1-minute TTL is returned. If the "hole" is for an requested EID matches a more-specific EID-Prefix that has been
unassigned part of the aggregate, then it is not a LISP EID and a delegated by the Map-Server but for which no ETRs are currently
15-minute TTL is returned. See Section 4.2 for discussion of registered, a 1-minute TTL is returned. If the requested EID
aggregate EID-prefixes and details of Map Server EID-prefix matches a non-delegated part of the authoritative EID-Prefix, then
matching. it is not a LISP EID and a 15-minute TTL is returned. See
Section 4.2 for discussion of aggregate EID-Prefixes and details
of Map-Server EID-Prefix matching.
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
possibly from a Map Server answering on behalf of the ETR. See possibly from a Map-Server answering on behalf of the ETR. See
(Section 4.4) for more details on Map Resolver message processing. Section 4.4 for more details on Map-Resolver message processing.
Note that an ITR may be configured to both use a Map Resolver and to Note that an ITR may be configured to both use a Map-Resolver and to
participate in a LISP+ALT logical network. In such a situation, the participate in a LISP+ALT logical network. In such a situation, the
ITR should send Map-Requests through the ALT network for any EID- ITR should send Map-Requests through the ALT network for any
prefix learned via ALT BGP. Such a configuration is expected to be EID-Prefix learned via ALT BGP. Such a configuration is expected to
very rare, since there is little benefit to using a Map Resolver if be very rare, since there is little benefit to using a Map-Resolver
an ITR is already using LISP+ALT. There would be, for example, no if an ITR is already using LISP+ALT. There would be, for example, no
need for such an ITR to send a Map-Request to a possibly non-existent need for such an ITR to send a Map-Request to a possibly non-existent
EID (and rely on Negative Map-Replies) if it can consult the ALT EID (and rely on Negative Map-Replies) if it can consult the ALT
database to verify that an EID-prefix is present before sending that database to verify that an EID-Prefix is present before sending that
Map-Request. Map-Request.
4.2. EID Prefix Configuration and ETR Registration 4.2. EID-Prefix Configuration and ETR Registration
An ETR publishes its EID-prefixes on a Map Server by sending LISP An ETR publishes its EID-Prefixes on a Map-Server by sending LISP
Map-Register messages. A Map-Register message includes Map-Register messages. A Map-Register message includes
authentication data, so prior to sending a Map-Register message, the authentication data, so prior to sending a Map-Register message, the
ETR and Map Server must be configured with a shared secret or other ETR and Map-Server must be configured with a shared secret or other
relevant authentication information. A Map Server's configuration relevant authentication information. A Map-Server's configuration
must also include a list of the EID-prefixes for which each ETR is must also include a list of the EID-Prefixes for which each ETR is
authoritative. Upon receipt of a Map-Register from an ETR, a Map authoritative. Upon receipt of a Map-Register from an ETR, a
Server accepts only EID-prefixes that are configured for that ETR. Map-Server accepts only EID-Prefixes that are configured for that
Failure to implement such a check would leave the mapping system ETR. Failure to implement such a check would leave the mapping
vulnerable to trivial EID-prefix hijacking attacks. As developers system vulnerable to trivial EID-Prefix hijacking attacks. As
and operators gain experience with the mapping system, additional, developers and operators gain experience with the mapping system,
stronger security measures may be added to the registration process. additional, stronger security measures may be added to the
registration process.
In addition to the set of EID-prefixes defined for each ETR that may In addition to the set of EID-Prefixes defined for each ETR that may
register, a Map Server is typically also configured with one or more register, a Map-Server is typically also configured with one or more
aggregate prefixes that define the part of the EID numbering space aggregate prefixes that define the part of the EID numbering space
assigned to it. When LISP+ALT is the database in use, aggregate EID- assigned to it. When LISP+ALT is the database in use, aggregate
prefixes are implemented as discard routes and advertised into ALT EID-Prefixes are implemented as discard routes and advertised into
BGP. The existance of aggregate EID-prefixes in a Map Server's ALT BGP. The existence of aggregate EID-Prefixes in a Map-Server's
database means that it may receive Map Requests for EID-prefixes that database means that it may receive Map Requests for EID-Prefixes that
match an aggregate but do not match a registered prefix; Section 4.3 match an aggregate but do not match a registered prefix; Section 4.3
describes how this is handled. describes how this is handled.
Map-Register messages are sent periodically from an ETR to a Map Map-Register messages are sent periodically from an ETR to a
Server with a suggested interval between messages of one minute. A Map-Server with a suggested interval between messages of one minute.
Map Server should time-out and remove an ETR's registration if it has A Map-Server should time out and remove an ETR's registration if it
not received a valid Map-Register message within the past three has not received a valid Map-Register message within the past
minutes. When first contacting a Map Server after restart or changes three minutes. When first contacting a Map-Server after restart or
to its EID-to-RLOC database mappings, an ETR may initially send Map- changes to its EID-to-RLOC database mappings, an ETR may initially
Register messages at an increased frequency, up to one every 20 send Map-Register messages at an increased frequency, up to one every
seconds. This "quick registration" period is limited to five minutes 20 seconds. This "quick registration" period is limited to
in duration. five minutes in duration.
An ETR may request that a Map Server explicitly acknowledge receipt An ETR may request that a Map-Server explicitly acknowledge receipt
and processing of a Map-Register message by setting the "want-map- and processing of a Map-Register message by setting the
notify" ("M" bit) flag. A Map Server that receives a Map-Register "want-map-notify" (M-bit) flag. A Map-Server that receives a
with this flag set will respond with a Map-Notify message. Typical Map-Register with this flag set will respond with a Map-Notify
use of this flag by an ETR would be to set it for Map-Register message. Typical use of this flag by an ETR would be to set it for
messages sent during the initial "quick registration" with a Map Map-Register messages sent during the initial "quick registration"
Server but then set it only occasionally during steady-state with a Map-Server but then set it only occasionally during
maintenance of its association with that Map Server. Note that the steady-state maintenance of its association with that Map-Server.
Map-Notify message is sent to UDP destination port 4342, not to the Note that the Map-Notify message is sent to UDP destination port
source port specified in the original Map-Register message. 4342, not to the source port specified in the original Map-Register
message.
Note that a one-minute minimum registration interval during Note that a one-minute minimum registration interval during
maintenance of an ETR-MS association places a lower-bound on how maintenance of an ETR-Map-Server association places a lower bound on
quickly and how frequently a mapping database entry can be updated. how quickly and how frequently a mapping database entry can be
This may have implications for what sorts of mobility can be updated. This may have implications for what sorts of mobility can
supported directly by the mapping system; shorter registration be supported directly by the mapping system; shorter registration
intervals or other mechanisms might be needed to suopport faster intervals or other mechanisms might be needed to support faster
mobility in some cases. For a discussion on one way that faster mobility in some cases. For a discussion on one way that faster
mobility may be implemented for individual devices, please see mobility may be implemented for individual devices, please see
[LISP-MN]. [LISP-MN].
An ETR may also request, by setting the "proxy-map-reply" flag An ETR may also request, by setting the "proxy Map-Reply" flag
(P-bit) in the Map-Register message, that a Map Server answer Map- (P-bit) in the Map-Register message, that a Map-Server answer
Requests instead of forwarding them to the ETR. See [LISP] for Map-Requests instead of forwarding them to the ETR. See [RFC6830]
details on how the Map Server sets certain flags (such as those for details on how the Map-Server sets certain flags (such as those
indicating whether the message is authoritative and how returned indicating whether the message is authoritative and how returned
locators should be treated) when sending a Map-Reply on behalf of an Locators should be treated) when sending a Map-Reply on behalf of an
ETR. When an ETR requests proxy reply service, it should include all ETR. When an ETR requests proxy reply service, it should include all
RLOCs for all ETRs for the EID-prefix being registered, along with RLOCs for all ETRs for the EID-Prefix being registered, along with
the routable flag ("R-bit") setting for each RLOC. The Map Server the routable flag ("R-bit") setting for each RLOC. The Map-Server
includes all of this information in Map Reply messages that it sends includes all of this information in Map-Reply messages that it sends
on behalf of the ETR. This differs from a non-proxy registration on behalf of the ETR. This differs from a non-proxy registration,
since the latter need only provide one or more RLOCs for a Map Server since the latter need only provide one or more RLOCs for a Map-Server
to use for forwarding Map-Requests; the registration information is to use for forwarding Map-Requests; the registration information is
not used in Map-Replies so it being incomplete is not incorrect. not used in Map-Replies, so it being incomplete is not incorrect.
An ETR which uses a Map Server to publish its EID-to-RLOC mappings An ETR that uses a Map-Server to publish its EID-to-RLOC mappings
does not need to participate further in the mapping database does not need to participate further in the mapping database
protocol(s). When using a LISP+ALT mapping database, for example, protocol(s). When using a LISP+ALT mapping database, for example,
this means that the ETR does not need to implement GRE or BGP, which this means that the ETR does not need to implement GRE or BGP, which
greatly simplifies its configuration and reduces its cost of greatly simplifies its configuration and reduces its cost of
operation. operation.
Note that use of a Map Server does not preclude an ETR from also Note that use of a Map-Server does not preclude an ETR from also
connecting to the mapping database (i.e. it could also connect to the connecting to the mapping database (i.e., it could also connect to
LISP+ALT network) but doing so doesn't seem particularly useful as the LISP+ALT network), but doing so doesn't seem particularly useful,
the whole purpose of using a Map Server is to avoid the complexity of as the whole purpose of using a Map-Server is to avoid the complexity
the mapping database protocols. of the mapping database protocols.
4.3. Map Server Processing 4.3. Map-Server Processing
Once a Map Server has EID-prefixes registered by its client ETRs, it Once a Map-Server has EID-Prefixes registered by its client ETRs, it
can accept and process Map-Requests for them. can accept and process Map-Requests for them.
In response to a Map-Request (received over the ALT if LISP+ALT is in In response to a Map-Request (received over the ALT if LISP+ALT is in
use), the Map Server first checks to see if the destination EID use), the Map-Server first checks to see if the destination EID
matches a configured EID-prefix. If there is no match, the Map matches a configured EID-Prefix. If there is no match, the
Server returns a negative Map-Reply with action code "forward-native" Map-Server returns a Negative Map-Reply with action code
and a 15-minute TTL. This may occur if a Map Request is received for "Natively-Forward" and a 15-minute TTL. This may occur if a Map
a configured aggreate EID-prefix for which no more-specific EID- Request is received for a configured aggregate EID-Prefix for which
prefix exists; it indicates the presence of a non-LISP "hole" in the no more-specific EID-Prefix exists; it indicates the presence of a
agregate EID-prefix. non-LISP "hole" in the aggregate EID-Prefix.
Next, the Map Server checks to see if any ETRs have registered the Next, the Map-Server checks to see if any ETRs have registered the
matching EID-prefix. If none are found, then the Map Server returns matching EID-Prefix. If none are found, then the Map-Server returns
a negative Map-Reply with action code "forward-native" and a 1-minute a Negative Map-Reply with action code "Natively-Forward" and a
TTL. 1-minute TTL.
If any of the registered ETRs for the EID-prefix have requested proxy If any of the registered ETRs for the EID-Prefix have requested proxy
reply service, then the Map Server answers the request instead of reply service, then the Map-Server answers the request instead of
forwarding it. It returns a Map-Reply with the EID-prefix, RLOCs, forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs,
and other information learned through the registration process. and other information learned through the registration process.
If none of the ETRs have requested proxy reply service, then the Map If none of the ETRs have requested proxy reply service, then the
Server re-encapsulates and forwards the resulting Encapsulated Map- Map-Server re-encapsulates and forwards the resulting Encapsulated
Request to one of the registered ETRs. It does not otherwise alter Map-Request to one of the registered ETRs. It does not otherwise
the Map-Request so any Map-Reply sent by the ETR is returned to the alter the Map-Request, so any Map-Reply sent by the ETR is returned
RLOC in the Map-Request, not to the Map Server. Unless also acting to the RLOC in the Map-Request, not to the Map-Server. Unless also
as a Map Resolver, a Map Server should never receive Map-Replies; any acting as a Map-Resolver, a Map-Server should never receive
such messages should be discarded without response, perhaps Map-Replies; any such messages should be discarded without response,
accompanied by logging of a diagnostic message if the rate of Map- perhaps accompanied by the logging of a diagnostic message if the
Replies is suggestive of malicious traffic. rate of Map-Replies is suggestive of malicious traffic.
4.4. Map Resolver Processing 4.4. Map-Resolver Processing
Upon receipt of an Encapsulated Map-Request, a Map Resolver de- Upon receipt of an Encapsulated Map-Request, a Map-Resolver
capsulates the enclosed message then searches for the requested EID decapsulates the enclosed message and then searches for the requested
in its local database of mapping entries (statically configured or EID in its local database of mapping entries (statically configured
learned from associated ETRs if the Map Resolver is also a Map Server or learned from associated ETRs if the Map-Resolver is also a
offering proxy reply service). If it finds a matching entry, it Map-Server offering proxy reply service). If it finds a matching
returns a LISP Map-Reply with the known mapping. entry, it returns a LISP Map-Reply with the known mapping.
If the Map Resolver does not have the mapping entry and if it can If the Map-Resolver does not have the mapping entry and if it can
determine that the EID is not in the mapping database (for example, determine that the EID is not in the mapping database (for example,
if LISP+ALT is used, the Map Resolver will have an ALT forwarding if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
table that covers the full EID space) it immediately returns a table that covers the full EID space), it immediately returns a
negative LISP Map-Reply, with action code "forward-native" and a 15- negative LISP Map-Reply, with action code "Natively-Forward" and a
minute TTL. To minimize the number of negative cache entries needed 15-minute TTL. To minimize the number of negative cache entries
by an ITR, the Map Resolver should return the least-specific prefix needed by an ITR, the Map-Resolver should return the least-specific
which both matches the original query and does not match any EID- prefix that both matches the original query and does not match any
prefix known to exist in the LISP-capable infrastructure. EID-Prefix known to exist in the LISP-capable infrastructure.
If the Map Resolver does not have sufficient information to know If the Map-Resolver does not have sufficient information to know
whether the EID exists, it needs to forward the Map-Request to whether the EID exists, it needs to forward the Map-Request to
another device which has more information about the EID being another device that has more information about the EID being
requested. To do this, it forwards the unencapsulated Map-Request, requested. To do this, it forwards the unencapsulated Map-Request,
with the original ITR RLOC as the source, to the mapping database with the original ITR RLOC as the source, to the mapping database
system. Using LISP+ALT, the Map Resolver is connected to the ALT system. Using LISP+ALT, the Map-Resolver is connected to the ALT
network and sends the Map-Request to the next ALT hop learned from network and sends the Map-Request to the next ALT hop learned from
its ALT BGP neighbors. The Map Resolver does not send any response its ALT BGP neighbors. The Map-Resolver does not send any response
to the ITR; since the source RLOC is that of the ITR, the ETR or Map to the ITR; since the source RLOC is that of the ITR, the ETR or
Server which receives the Map-Request over the ALT and responds will Map-Server that receives the Map-Request over the ALT and responds
do so directly to the ITR. will do so directly to the ITR.
4.4.1. Anycast Map Resolver Operation 4.4.1. Anycast Map-Resolver Operation
A Map Resolver can be set up to use "anycast", where the same address A Map-Resolver can be set up to use "anycast", where the same address
is assigned to multiple Map Resolvers and is propagated through IGP is assigned to multiple Map-Resolvers and is propagated through IGP
routing, to facilitate the use of a topologically-close Map Resolver routing, to facilitate the use of a topologically close Map-Resolver
each ITR. by each ITR.
Note that Map Server associations with ETRs should not use anycast Note that Map-Server associations with ETRs should not use anycast
addresses as registrations need to be established between an ETR and addresses, as registrations need to be established between an ETR and
a specific set of Map Servers, each identified by a specific a specific set of Map-Servers, each identified by a specific
registation association. registration association.
5. Open Issues and Considerations 5. Open Issues and Considerations
There are a number of issues with the Map Server and Map Resolver There are a number of issues with the Map-Server and Map-Resolver
design that are not yet completely understood. Among these are: design that are not yet completely understood. Among these are:
o Constants, such as those used for Map-Register frequency, o Constants, such as those used for Map-Register frequency,
retransmission timeouts, retransmission limits, negative Map-Reply retransmission timeouts, retransmission limits, Negative Map-Reply
TTLs, et al are subject to further refinement as more experience TTLs, et al. are subject to further refinement as more experience
with prototype deployment is gained. with prototype deployment is gained.
o Convergence time when an EID-to-RLOC mapping changes and o Convergence time when an EID-to-RLOC mapping changes, and
mechanisms for detecting and refreshing or removing stale, cached mechanisms for detecting and refreshing or removing stale, cached
information information.
o Deployability and complexity trade-offs of implementing stronger o Deployability and complexity tradeoffs of implementing stronger
security measures in both EID-prefix registration and Map-Request/ security measures in both EID-Prefix registration and Map-Request/
Map-Reply processing Map-Reply processing.
o Requirements for additional state in the registration process o Requirements for additional state in the registration process
between Map Servers and ETRs between Map-Servers and ETRs.
A discussion of other issues surrounding LISP deployment may also be A discussion of other issues surrounding LISP deployment may also be
found in Section 15 of [LISP]. found in Section 15 of [RFC6830].
The authors expect that experimentation on the LISP pilot network The authors expect that experimentation on the LISP pilot network
will help answer open questions surrounding these and other issues. will help answer open questions surrounding these and other issues.
6. IANA Considerations 6. Security Considerations
This document makes no request of the IANA.
7. Security Considerations
The 2-way LISP header nonce exchange documented in [LISP] can be used The 2-way LISP header nonce exchange documented in [RFC6830] can be
to avoid ITR spoofing attacks. used to avoid ITR spoofing attacks.
To publish an authoritative EID-to-RLOC mapping with a Map Server, an To publish an authoritative EID-to-RLOC mapping with a Map-Server, an
ETR includes authentication data that is a hash of the message using ETR includes authentication data that is a hash of the message using
pair-wise shared key. An implementation must support use of HMAC- a pair-wise shared key. An implementation must support use of
SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 HMAC-SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128
[RFC6234] (SHA-256 truncated to 128 bits). [RFC6234] (SHA-256 truncated to 128 bits).
During experimental and prototype deployment, all authentication key During experimental and prototype deployment, all authentication key
configuration will be manual. Should LISP and its components be configuration will be manual. Should LISP and its components be
considered for IETF standardization, further work will be required to considered for IETF standardization, further work will be required to
follow the BCP 107 [RFC4107] recommendations on automated key follow the BCP 107 [RFC4107] recommendations on automated key
management. management.
As noted in Section 4.2, a Map Server should verify that all EID- As noted in Section 4.2, a Map-Server should verify that all
prefixes registered by an ETR match configuration stored on the Map EID-Prefixes registered by an ETR match the configuration stored on
Server. the Map-Server.
The currently-defined authentication mechanism for Map-Register The currently defined authentication mechanism for Map-Register
messages does not provide protection against "replay" attacks by a messages does not provide protection against "replay" attacks by a
"man-in-the-middle". Additional work is needed in this area. "man-in-the-middle". Additional work is needed in this area.
[LISP-SEC] defines a proposed mechanism for providing origin [LISP-SEC] defines a proposed mechanism for providing origin
authentication, integrity, anti-replay protection, and prevention of authentication, integrity, anti-replay protection, and prevention of
man-in-the-middle and "overclaiming" attacks on the Map-Request/ man-in-the-middle and "overclaiming" attacks on the Map-Request/
Map-Reply exchange. Work is ongoing on this and other proposals for Map-Reply exchange. Work is ongoing on this and other proposals for
resolving these open security issues resolving these open security issues.
While beyond the scope of securing an individual Map Server or Map While beyond the scope of securing an individual Map-Server or
Resolver, it should be noted that a BGP-based LISP+ALT network (if Map-Resolver, it should be noted that a BGP-based LISP+ALT network
ALT is used as the mapping database infrastructure) can take (if ALT is used as the mapping database infrastructure) can take
advantage standards work on adding security to BGP. advantage of standards work on adding security to BGP.
8. References 7. References
8.1. Normative References 7.1. Normative References
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [RFC1035] Mockapetris, P., "Domain names - implementation and
Alternative Topology (LISP-ALT)", specification", STD 13, RFC 1035, November 1987.
draft-ietf-lisp-alt-10.txt (work in progress),
December 2011.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
"Locator/ID Separation Protocol (LISP)", Hashing for Message Authentication", RFC 2104,
draft-ietf-lisp-22.txt (work in progress), February 2012. February 1997.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
specification", STD 13, RFC 1035, November 1987. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Hashing for Message Authentication", RFC 2104, Locator/ID Separation Protocol (LISP)", RFC 6830,
February 1997. January 2013.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013.
8.2. Informative References 7.2. Informative References
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [LISP-CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis,
Content distribution Overlay Network Service for LISP", D., and D. Meyer, "LISP-CONS: A Content distribution
draft-meyer-lisp-cons-04.txt (work in progress), Overlay Network Service for LISP", Work in Progress,
April 2008. April 2008.
[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node Architecture", draft-meyer-lisp-mn-06.txt Mobile Node", Work in Progress, October 2012.
(work in progress), October 2011.
[LISP-SEC] [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O.
Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", Work
Bonaventure, "LISP-Security", draft-ietf-lisp-sec-01.txt in Progress, October 2012.
(work in progress), January 2012.
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [RFC4107] Bellovin, S. and R. Housley, "Guidelines for
draft-lear-lisp-nerd-08.txt (work in progress), Cryptographic Key Management", BCP 107, RFC 4107,
March 2010. June 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Key Management", BCP 107, RFC 4107, June 2005. Routing Locator (RLOC) Database", RFC 6837,
January 2013.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Greg Schudel, Darrel Lewis, John The authors would like to thank Gregg Schudel, Darrel Lewis, John
Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
Fabio Maino, and members of the lisp@ietf.org mailing list for their Fabio Maino, and members of the lisp@ietf.org mailing list for their
feedback and helpful suggestions. feedback and helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work on Special thanks are due to Noel Chiappa for his extensive work on
caching with LISP-CONS, some of which may be used by Map Resolvers. caching with LISP-CONS, some of which may be used by Map-Resolvers.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Email: vaf@cisco.com EMail: vaf@vaf.net
Dino Farinacci Dino Farinacci
cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dino@cisco.com EMail: farinacci@gmail.com
 End of changes. 117 change blocks. 
331 lines changed or deleted 328 lines changed or added

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