draft-ietf-lisp-ms-11.txt   draft-ietf-lisp-ms-12.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Experimental cisco Systems Intended status: Experimental cisco Systems
Expires: March 2, 2012 August 30, 2011 Expires: April 27, 2012 October 25, 2011
LISP Map Server LISP Map Server Interface
draft-ietf-lisp-ms-11.txt draft-ietf-lisp-ms-12.txt
Abstract Abstract
This draft describes the LISP Map Server (LISP-MS), a computing This draft describes the Maping Service for the Locator Identifier
system which provides a simplified LISP protocol interface as a Separation Protocol (LISP), implemented by two new types of LISP-
"front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) speaking devices, the LISP Map Resolver and LISP Map Server, that
mapping database and associated virtual network of LISP protocol provides a simplified "front end" to for one or more Endpoint ID to
elements. Routing Locator mapping databases.
The purpose of the Map Server is to reduce implementation and By using this service interface and communicating with Map Resolvers
operational complexity of LISP Ingress Tunnel Routers (ITRs) and and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel
Egress Tunnel Routers (ETRs), the devices that implement the "edge" Routers, are not dependent on the details of mapping database
of the LISP infrastructure and which connect directly to LISP-capable systems, which facilitates experimentation with different database
Internet end sites. designs. Since these devices implement the "edge" of the LISP
infrastructure, connect directly to LISP-capable Internet end sites,
and comprise the bulk of LISP-speaking devices, reducing their
implementation and operational complexity should also reduce the
overall cost and effort of deploying LISP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 2, 2012. This Internet-Draft will expire on April 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[LISP] specifies an architecture and mechanism for replacing the [LISP], the Locator Identifier Separation Protocol, specifies an
addresses currently used by IP with two separate name spaces: EIDs, architecture and mechanism for replacing the addresses currently used
used within sites, and RLOCs, used on the transit networks that make by IP with two separate name spaces: Endpoint IDs (EIDs), used within
up the Internet infrastructure. To achieve this separation, LISP sites, and Routing Locators (RLOCs), used on the transit networks
defines protocol mechanisms for mapping from EIDs to RLOCs. In that make up the Internet infrastructure. To achieve this
addition, LISP assumes the existence of a database to store and separation, LISP defines protocol mechanisms for mapping from EIDs to
propagate those mappings globally. Several such databases have been RLOCs. In addition, LISP assumes the existence of a database to
proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] and LISP+ store and propagate those mappings globally. Several such databases
ALT [ALT]. have been proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD]
and LISP+ALT [ALT].
There are two types of operation for a LISP Map Server: as a Map The LISP Mapping Service defines two new types of LISP-speaking
Resolver, which accepts Map-Requests from an ITR and "resolves" the devices: the Map Resolver, which accepts Map-Requests from an Ingress
EID-to-RLOC mapping using the distributed mapping database, and as a Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
Map Server, which learns authoritative EID-to-RLOC mappings from an mapping database, and the Map Server, which learns authoritative EID-
ETR and publish them in the database. A single device may implement to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
one or both types of operation. 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 and caching resolvers. With this in mind, this [RFC1035] servers; likewise, Map Resolvers are conceptually similar
specification borrows familiar terminology (resolver and server) from to DNS caching resolvers. With this in mind, this specification
the DNS specifications. borrows familiar terminology (resolver and server) from the DNS
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 Map
Resolver operation, this is not intended to preclude the use of Map Resolver operation, the Mapping Service interface can (and likely
Servers and Map Resolvers as a standardized interface for ITRs and will) be used by ITRs and ETRs to access other mapping database
ETRs to access other mapping database systems. systems as the LISP infrastructure evolves.
2. Definition of Terms 2. Definition of Terms
Map Server: a network infrastructure component which learns EID-to- Map Server: a network infrastructure component which learns of EID-
RLOC mapping entries from an authoritative source (typically, an prefix mapping entries from an ETR, via the registration mechanism
ETR, via the registration mechanism described below). A Map described below, or some other authoritative source if one exists.
Server publishes these mappings in the distributed mapping A Map Server publishes these EID-prefixes in a mapping database.
database.
Map Resolver: a network infrastructure component which accepts LISP Map Resolver: a network infrastructure component which accepts LISP
Encapsulated Map-Requests, typically from an ITR, quickly Encapsulated Map-Requests, typically from an ITR, determines
determines whether or not the destination IP address is part of whether or not the destination IP address is part of the EID
the EID namespace; if it is not, a Negative Map-Reply is namespace; if it is not, a Negative Map-Reply is returned.
immediately returned. Otherwise, the Map Resolver finds the Otherwise, the Map Resolver finds the appropriate EID-to-RLOC
appropriate EID-to-RLOC mapping by consulting the distributed mapping by consulting a mapping database system.
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-routeable IP addresses, also known as
RLOCs. Used by an ITR when sending to a Map Resolver and by a Map RLOCs. Used by an ITR when sending to a Map Resolver and by a Map
Server when forwarding a Map-Request to an ETR. Server 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
"want-map-notify" or "M" bit in the Map-Register message. Unlike "want-map-notify" or "M" bit in the Map-Register message. Unlike
a Map-Reply, a Map-Notify uses UDP port 4342 for both source and a Map-Reply, a Map-Notify uses UDP port 4342 for both source and
destination. 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 [LISP].
3. Basic Overview 3. Basic Overview
A Map Server is a device which publishes EID-prefix information on A Map Server is a device which publishes EID-prefixes in a LISP
behalf of ETRs and connects to the LISP distributed mapping database mapping database on behalf of a set of ETRs. When it receives a Map
system to help answer LISP Map-Requests seeking the RLOCs for those Request (typically from an ITR) it consults the mapping database to
EID-prefixes. To publish its EID-prefixes, an ETR periodically sends find an ETR that can answer with the set of RLOCs for an EID-prefix.
Map-Register messages to the Map Server. A Map-Register message To publish its EID-prefixes, an ETR periodically sends Map-Register
contains a list of EID-prefixes plus a set of RLOCs that can be used messages to the Map Server. A Map-Register message contains a list
to reach the ETR when a Map Server needs to forward a Map-Request to of EID-prefixes plus a set of RLOCs that can be used to reach the ETR
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 ALT network and acts as a "last-hop" ALT router. Intermediate ALT
routers forward Map-Requests to the Map Server that advertises a 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.
The LISP Map Server design also includes the operation of a Map A Map Resolver receives Encapsulated Map-Requests from its client
Resolver, which receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR
ITRs and uses the distributed mapping database system to find the to answer those requests. On a LISP+ALT network, a Map Resolver acts
appropriate ETR to answer those requests. On a LISP+ALT network, a as a "first-hop" ALT router. It has GRE tunnels configured to other
Map Resolver acts as a "first-hop" ALT router. It has GRE tunnels ALT routers and uses BGP to learn paths to ETRs for different
configured to other ALT routers and uses BGP to learn paths to ETRs prefixes in the LISP+ALT database. The Map Resolver uses this path
for different prefixes in the LISP+ALT database. The Map Resolver information to forward Map-Requests over the ALT to the correct ETRs.
uses this path information to forward Map-Requests over the ALT to During initial deployment, a Map Resolver will operate only in a non-
the correct ETRs. A Map Resolver may operate in a non-caching mode, caching mode, where it simply de-capsulates and forwards the
where it simply de-capsulates and forwards the Encapsulated Map- Encapsulated Map-Requests that it receives from ITRs.
Requests that it receives from ITRs.
Alternatively, a Map Resolver may operate in a caching mode, where it In future deployments, a Map Resolver may operate in a caching mode,
saves information about outstanding Map-Requests, originates new Map- where it saves information about outstanding Map-Requests, originates
Requests to the correct ETR(s), accepts and caches the Map-Replies, new Map-Requests to the correct ETR(s), accepts and caches the Map-
and finally forwards the Map-Replies to the original ITRs. One Replies, and finally forwards the Map-Replies to the original ITRs.
significant issue with use of caching in a Map Resolver is that it One significant issue with use of caching in a Map Resolver is that
hides the original ITR source of a Map-Request, which prevents an ETR it hides the original ITR source of a Map-Request, which prevents an
from tailoring its responses to that source; this reduces the inbound ETR from tailoring its responses to that source; this reduces the
traffic- engineering capability for the site owning the ETR. In inbound traffic- engineering capability for the site owning the ETR.
addition, caching in a Map Resolver exacerbates problems associated In addition, caching in a Map Resolver exacerbates problems
with old mappings being cached; an outdated, cached mapping in an ITR associated with old mappings being cached; an outdated, cached
affects only that ITR and traffic originated by its site while an mapping in an ITR affects only that ITR and traffic originated by its
outdate, cached mapping in a Map Resolver could cause a problem with site while an outdated, cached mapping in a Map Resolver could cause
a wider scope. More experience with caching Map Resolvers on the a problem with a wider scope. More experience with caching Map
LISP pilot network will be needed to determine whether their use can Resolvers on the LISP pilot network will be needed to determine
be recommended. whether their use can be recommended.
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 Map
Server and a Map Resolver and, in many cases, the functions will be Server and a Map Resolver and, in many cases, the functions will be
co-located in that way. 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 [LISP].
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 the address of a Map Resolver. This An ITR is configured with one or more Map Resolver addresses. These
address is a "locator" or RLOC in that it must be routeable on the addresses are "locators" (or RLOCs) and must be routeable on the
underlying core network; it must not need to be resolved through LISP underlying core network; they must not need to be resolved through
EID-to-RLOC mapping as that would introduce a circular dependency. LISP EID-to-RLOC mapping as that would introduce a circular
When using a Map Resolver, an ITR does not need to connect to any dependency. When using a Map Resolver, an ITR does not need to
other database mapping system. In particular, the ITR need not connect to any other database mapping system. In particular, the ITR
connect to the LISP+ALT infrastructure or implement the BGP and GRE need not connect to the LISP+ALT infrastructure or implement the BGP
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:
skipping to change at page 7, line 46 skipping to change at page 7, line 46
Map-Request but where the EID matches a "hole" in the aggregate. Map-Request but where the EID matches a "hole" in the aggregate.
If the "hole" is for a LISP EID-prefix that is defined in the Map If the "hole" is for a LISP EID-prefix that is defined in the Map
Server configuration but for which no ETRs are currently Server configuration but for which no ETRs are currently
registered, a 1-minute TTL is returned. If the "hole" is for an registered, a 1-minute TTL is returned. If the "hole" is for an
unassigned part of the aggregate, then it is not a LISP EID and a unassigned part of the aggregate, then it is not a LISP EID and a
15-minute TTL is returned. See Section 4.2 for discussion of 15-minute TTL is returned. See Section 4.2 for discussion of
aggregate EID-prefixes and details of Map Server EID-prefix aggregate EID-prefixes and details of Map Server EID-prefix
matching. 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. Note possibly from a Map Server answering on behalf of the ETR. See
that the stateless nature of non-caching Map Resolver forwarding (Section 4.4) for more details on Map Resolver message processing.
means that the Map-Reply may not be from the Map Resolver to which
the Encapsulated Map-Request was sent unless the target Map
Resolver offers caching. See (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 EID-
prefix learned via ALT BGP. Such a configuration is expected to be prefix learned via ALT BGP. Such a configuration is expected to be
very rare, since there is little benefit to using a Map Resolver if very rare, since there is little benefit to using a Map Resolver if
an ITR is already using LISP+ALT. There would be, for example, no 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 secret shared-key. A ETR and Map Server must be configured with a shared secret or other
Map Server's configuration must also include a list of the EID- relevant authentication information. A Map Server's configuration
prefixes for which each ETR is authoritative. Upon receipt of a Map- must also include a list of the EID-prefixes for which each ETR is
Register from an ETR, a Map Server accepts only EID-prefixes that are authoritative. Upon receipt of a Map-Register from an ETR, a Map
configured for that ETR. Failure to implement such a check would Server accepts only EID-prefixes that are configured for that ETR.
leave the mapping system vulnerable to trivial EID-prefix hijacking Failure to implement such a check would leave the mapping system
attacks. As developers and operators gain experience with the vulnerable to trivial EID-prefix hijacking attacks. As developers
mapping system, additional, stronger security measures may be added and operators gain experience with the mapping system, additional,
to the registration process. 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 be configured with one or register, a Map Server is typically also configured with one or more
more aggregate prefixes that define the part of the EID numbering aggregate prefixes that define the part of the EID numbering space
space assigned to it. When LISP+ALT is the database in use, assigned to it. When LISP+ALT is the database in use, aggregate EID-
aggregate EID-prefixes are implemented as discard routes and prefixes are implemented as discard routes and advertised into ALT
advertised into ALT BGP. The existance of aggregate EID-prefixes in BGP. The existance of aggregate EID-prefixes in a Map Server's
a Map Server's database means that it may receive Map Requests for database means that it may receive Map Requests for EID-prefixes that
EID-prefixes that match an aggregate but do not match a registered match an aggregate but do not match a registered prefix; Section 4.3
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 Map
Server with a suggested interval between messages of one minute. A Server with a suggested interval between messages of one minute. A
Map Server should time-out and remove an ETR's registration if it has Map Server should time-out and remove an ETR's registration if it has
not received a valid Map-Register message within the past three not received a valid Map-Register message within the past three
minutes. When first contacting a Map Server after restart or changes minutes. When first contacting a Map Server after restart or changes
to its EID-to-RLOC database mappings, an ETR may initially send Map- to its EID-to-RLOC database mappings, an ETR may initially send Map-
Register messages at an increased frequency, up to one every 20 Register messages at an increased frequency, up to one every 20
seconds. This "quick registration" period is limited to five minutes seconds. This "quick registration" period is limited to five minutes
in duration. in duration.
skipping to change at page 9, line 14 skipping to change at page 9, line 10
notify" ("M" bit) flag. A Map Server that receives a Map-Register notify" ("M" bit) flag. A Map Server that receives a Map-Register
with this flag set will respond with a Map-Notify message. Typical with this flag set will respond with a Map-Notify message. Typical
use of this flag by an ETR would be to set it for Map-Register use of this flag by an ETR would be to set it for Map-Register
messages sent during the initial "quick registration" with a Map messages sent during the initial "quick registration" with a Map
Server but then set it only occasionally during steady-state Server but then set it only occasionally during steady-state
maintenance of its association with that Map Server. Note that the maintenance of its association with that Map Server. Note that the
Map-Notify message is sent to UDP destination port 4342, not to the Map-Notify message is sent to UDP destination port 4342, not to the
source port specified in the original Map-Register message. 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 does set a lower-bound on how maintenance of an ETR-MS association places a lower-bound on how
quickly and how frequently a mapping database entry can be updated. quickly and how frequently a mapping database entry can be updated.
This may have implications for what sorts of mobility can supported This may have implications for what sorts of mobility can be
directly by the mapping system. For a discussion on one way that supported directly by the mapping system; shorter registration
faster mobility may be implemented for individual devices, please see intervals or other mechanisms might be needed to suopport faster
mobility in some cases. For a discussion on one way that faster
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-Regsiter message, that a Map Server answer Map- (P-bit) in the Map-Register message, that a Map Server answer Map-
Requests instead of forwarding them to the ETR. See [LISP] for Requests instead of forwarding them to the ETR. See [LISP] for
details on how the Map Server sets certain flags (such as those 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 "R" bit setting for each RLOC. The Map Server includes all of the routable flag ("R-bit") setting for each RLOC. The Map Server
this information in Map Reply messages that it sends on behalf of the includes all of this information in Map Reply messages that it sends
ETR. 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
to use for forwarding Map-Requests; the registration information is
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 which 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 the
skipping to change at page 10, line 13 skipping to change at page 10, line 15
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 Map
Server returns a negative Map-Reply with action code "forward-native" Server returns a negative Map-Reply with action code "forward-native"
and a 15-minute TTL. This may occur if a Map Request is received for and a 15-minute TTL. This may occur if a Map Request is received for
a configured aggreate EID-prefix for which no more-specific EID- a configured aggreate EID-prefix for which no more-specific EID-
prefix exists; it indicates the presence of a non-LISP "hole" in the prefix exists; it indicates the presence of a non-LISP "hole" in the
agregate EID-prefix. agregate 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 "forward-native" and a 1-minute
TTL. 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 answered 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 Map
Server re-encapsulates and forwards the resulting Encapsulated Map- Server re-encapsulates and forwards the resulting Encapsulated Map-
Request to one of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not otherwise alter
the Map-Request so any Map-Reply sent by the ETR is returned to the the Map-Request so any Map-Reply sent by the ETR is returned to the
RLOC in the Map-Request, not to the Map Server. Unless also acting RLOC in the Map-Request, not to the Map Server. Unless also acting
as a Map Resolver, a Map Server should never receive Map-Replies; any as a Map Resolver, a Map Server should never receive Map-Replies; any
such messages should be discarded without response, perhaps such messages should be discarded without response, perhaps
accompanied by logging of a diagnostic message if the rate of Map- accompanied by logging of a diagnostic message if the rate of Map-
Replies is suggestive of malicious traffic. Replies is suggestive of malicious traffic.
A Map Server may also receive a Map-Request that is contained inside A Map Server may also receive a Map-Request that is contained inside
of an Encapsulated Control Message (an Encapsulated Map-Request) with of an Encapsulated Control Message (an Encapsulated Map-Request) with
the "Security" bit (S-bit) set. It processes the security parameters the "Security" bit ("S-bit") set. It processes the security
as described in [LISP-SEC] then handles the Map-Request as as parameters as described in [LISP-SEC] then handles the Map-Request as
described above. as described above.
Note that a Map Server that is sending a Map-Reply on behalf of an Note that a Map Server that is sending a Map-Reply on behalf of an
ETR (performing proxy reply service) must perform security processing ETR (performing proxy reply service) must perform security processing
for that ETR as well; see [LISP-SEC] for details. for that ETR as well; see [LISP-SEC] for details.
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 de-
capsulates the enclosed message then searches for the requested EID capsulates the enclosed message then searches for the requested EID
in its local database of mapping entries (statically configured, in its local database of mapping entries (statically configured,
skipping to change at page 11, line 19 skipping to change at page 11, line 21
by an ITR, the Map Resolver should return the least-specific prefix by an ITR, the Map Resolver should return the least-specific prefix
which both matches the original query and does not match any EID- which both matches the original query and does not match any EID-
prefix known to exist in the LISP-capable infrastructure. 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 which has more information about the EID being
requested. This is done in one of two ways: requested. This is done in one of two ways:
1. A non-caching Map Resolver simply forwards the unencapsulated 1. A non-caching Map Resolver simply forwards the unencapsulated
Map-Request, with the original ITR RLOC as the source, on to the Map-Request, with the original ITR RLOC as the source, to the
distributed mapping database. Using a LISP+ALT mapping database, mapping database system. Using LISP+ALT, the Map Resolver is
the Map Resolver is connected to the ALT network and sends the connected to the ALT network and sends the Map-Request to the
Map-Request to the next ALT hop learned from its ALT BGP next ALT hop learned from its ALT BGP neighbors. The Map
neighbors. The Map Resolver does not send any response to the Resolver does not send any response to the ITR; since the source
ITR; since the source RLOC is that of the ITR, the ETR or Map RLOC is that of the ITR, the ETR or Map Server which receives the
Server which receives the Map-Request over the ALT and responds Map-Request over the ALT and responds will do so directly to the
will do so directly to the ITR. ITR.
2. A caching Map Resolver queues information from the Encapsulated 2. A caching Map Resolver queues information from the Encapsulated
Map-Request, including the ITR RLOC and the original nonce. It Map-Request, including the ITR RLOC and the original Map-Request
then modifies the Map-Request to use its own RLOC, generates a message nonce. It then modifies the Map-Request to use its own
"local nonce" (which is also saved in the request queue entry), RLOC, generates a "local nonce" (which is also saved in the
and forwards the Map-Request as above. When the Map Resolver request queue entry), and forwards the Map-Request as above.
receives a Map-Reply, it looks in its request queue to match the When the Map Resolver receives a Map-Reply, it looks in its
reply nonce to a "local nonce" entry then de-queues the entry and request queue to match the reply nonce to a "local nonce" entry
uses the saved original nonce and ITR RLOC to re-write those then de-queues the entry and uses the saved original nonce and
fields in the Map-Reply before sending to the ITR. The request ITR RLOC to re-write those fields in the Map-Reply before sending
queue entry is also deleted and the mapping entries from the Map- to the ITR. The request queue entry is also deleted and the
Reply are saved in the Map Resolver's cache. mapping entries from the Map-Reply are saved in the Map
Resolver's cache.
If a Map Resolver receives a Map-Request contained in an Encapsulated If a Map Resolver receives a Map-Request contained in an Encapsulated
Control Message (an Encapsulated Map-Request) with the "security" Control Message (an Encapsulated Map-Request) with the "security"
option (S-Bit) set, additional processing is required. It extracts option ("S-Bit") set, additional processing is required. It extracts
the enclosed Map-Request and uses the attached security paramaters to the enclosed Map-Request and uses the attached security paramaters to
generate a new Encapsulated Control Message containing the original generate a new Encapsulated Control Message containing the original
Map-Rqeuest and additional signature information used to protect both Map-Request and additional signature information used to protect both
the Map-Request and the Map-Reply that will be generated by the the Map-Request and the Map-Reply that will be generated by the
destination ETR or Map Server. The outgoing message will have the destination ETR or Map Server. The outgoing message will have the
S-bit set, will use the requested EID as its outer header destination "S-bit" set, will use the requested EID as its outer header
IP address plus Map Resolver RLOC as source IP address, and will destination IP address plus Map Resolver RLOC as source IP address,
include security parameters added by the Map Resolver. See and will include security parameters added by the Map Resolver. See
[LISP-SEC] for details of the checks that are performed and the [LISP-SEC] for details of the checks that are performed and the
security information that is added during the de-encapsulation and security information that is added during the de-encapsulation and
re-encapsulation process. re-encapsulation process.
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. each ITR.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
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. registation 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,
retransmission timeouts, retransmission limits, negative Map-Reply
TTLs, et al are subject to further refinement as more experience
with prototype deployment is gained.
o Feasibility, performance, and complexity trade-offs of o Feasibility, performance, and complexity trade-offs of
implementing caching in Map Resolvers implementing caching in Map Resolvers, as discussed in Section 3,
Paragraph 4.
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 trade-offs 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
skipping to change at page 15, line 7 skipping to change at page 15, line 7
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. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
7. Security Considerations 7. Security Considerations
The 2-way nonce exchange documented in [LISP] can be used to avoid The 2-way LISP header nonce exchange documented in [LISP] can be used
ITR spoofing attacks. 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- pair-wise shared key. An implementation must support use of HMAC-
SHA-1-160 [RFC2104] and should support use of HMAC-SHA-256-128 SHA-1-160 [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, authentication key During experimental and prototype deployment, all authentication key
changes will be manual. Should LISP and its components be considered configuration will be manual. Should LISP and its components be
for IETF standardization, further work will be required to follow the considered for IETF standardization, further work will be required to
BCP 107 [RFC4107] recommendations on automated key management. follow the BCP 107 [RFC4107] recommendations on automated key
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 EID-
prefixes registered by an ETR match configuration stored on the Map prefixes registered by an ETR match configuration stored on the Map
Server. Server.
[LISP-SEC] defines a mechanism for providing origin authentication, [LISP-SEC] defines a mechanism for providing origin authentication,
integrity, anti-reply protection, and prevention of man-in-the-middle integrity, anti-reply protection, and prevention of man-in-the-middle
and "overclaiming" attacks on the Map-Request/Map-Reply exchange. and "overclaiming" attacks on the Map-Request/Map-Reply exchange.
While beyond the scope of securing an individual Map Server or Map While beyond the scope of securing an individual Map Server or Map
skipping to change at page 16, line 11 skipping to change at page 16, line 11
group or either S-BGP [I-D.murphy-bgp-secr] or soBGP group or either S-BGP [I-D.murphy-bgp-secr] or soBGP
[I-D.white-sobgparchitecture] should they be developed and widely [I-D.white-sobgparchitecture] should they be developed and widely
deployed. deployed.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-07.txt (work in progress), June 2011. draft-ietf-lisp-alt-10.txt (work in progress),
October 2011.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-15.txt (work in progress), July 2011. draft-ietf-lisp-15.txt (work in progress), July 2011.
[LISP-SEC] [LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt
(work in progress), July 2011. (work in progress), July 2011.
 End of changes. 35 change blocks. 
155 lines changed or deleted 168 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/