Network Working Group
Internet Engineering Task Force (IETF)                         V. Fuller
Internet-Draft
Request for Comments: 6833
Category: Experimental                                      D. Farinacci
Intended status: Experimental                              cisco
ISSN: 2070-1721                                            Cisco Systems
Expires: September 5, 2012                                 March 4, 2012

                       LISP Map Server
                                                            January 2013

       Locator/ID Separation Protocol (LISP) Map-Server Interface
                       draft-ietf-lisp-ms-16.txt

Abstract

   This draft document describes the Maping Mapping Service for the Locator Identifier Locator/ID
   Separation Protocol (LISP), implemented by two new types of LISP-
   speaking devices, devices -- the LISP Map Resolver Map-Resolver and LISP Map Server, Map-Server -- that
   provides a simplified "front end" to for one or more Endpoint ID to
   Routing Locator mapping databases.

   By using this service interface and communicating with Map Resolvers Map-Resolvers
   and Map Servers, Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel
   Routers,
   Routers are not dependent on the details of mapping database systems,
   which facilitates experimentation with different database 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 This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF
   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 maximum candidate for any level of
   Internet Standard; see Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 5, 2012.
   http://www.rfc-editor.org/info/rfc6833.

Copyright Notice

   Copyright (c) 2012 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3 ....................................................2
   2. Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4 .............................................3
   3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  5 ..................................................4
   4. Interactions With with Other LISP Components  . . . . . . . . . . .  6 .........................5
      4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . .  6 .........................5
      4.2.  EID Prefix EID-Prefix Configuration and ETR Registration  . . . . . .  7 ..............6
      4.3.  Map Server Map-Server Processing  . . . . . . . . . . . . . . . . . .  8 ......................................8
      4.4.  Map Resolver Map-Resolver Processing  . . . . . . . . . . . . . . . . .  9 ....................................9
           4.4.1. Anycast Map Resolver Map-Resolver Operation . . . . . . . . . . . . 10 .....................10
   5. Open Issues and Considerations . . . . . . . . . . . . . . . . 11 .................................10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8. ........................................11
   7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1. .....................................................12
      7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2. ......................................12
      7.2. Informative References . . . . . . . . . . . . . . . . . . 14 ....................................12
   Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 .......................................13

1.  Introduction

   [LISP], the Locator Identifier

   The Locator/ID Separation Protocol, Protocol [RFC6830] specifies an
   architecture and mechanism for replacing the addresses currently used
   by IP with two separate name spaces: Endpoint IDs (EIDs), used within
   sites,
   sites; and Routing Locators (RLOCs), used on the transit networks
   that make up the Internet infrastructure.  To achieve this
   separation, LISP defines protocol mechanisms for mapping from EIDs to
   RLOCs.  In addition, LISP assumes the existence of a database to
   store and propagate those mappings globally.  Several such databases
   have been proposed, proposed; among them: LISP-CONS [CONS], LISP-NERD, [NERD] them are the Content distribution Overlay
   Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD
   (a Not-so-novel EID-to-RLOC Database) [RFC6837], and LISP+ALT [ALT]. LISP Alternative
   Logical Topology (LISP+ALT) [RFC6836].

   The LISP Mapping Service defines two new types of LISP-speaking
   devices: the Map Resolver, Map-Resolver, which accepts Map-Requests from an Ingress
   Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
   mapping database, database; and the Map Server, Map-Server, which learns authoritative EID-
   to-RLOC
   EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
   them in a database.

   Conceptually, LISP Map Servers Map-Servers share some of the same basic
   configuration and maintenance properties as Domain Name System (DNS)
   [RFC1035] servers; likewise, Map Resolvers Map-Resolvers are conceptually similar
   to DNS caching resolvers.  With this in mind, this specification
   borrows familiar terminology (resolver and server) from the DNS
   specifications.

   Note that while this document assumes a LISP+ALT database mapping
   infrastructure to illustrate certain aspects of Map Server Map-Server and Map
   Resolver
   Map-Resolver operation, the Mapping Service interface can (and likely
   will) be used by ITRs and ETRs to access other mapping database
   systems as the LISP infrastructure evolves.

   Section 5 of this document notes a number of issues with the Map
   Server
   Map-Server and Map Resolver Map-Resolver design that are not yet completely
   understood and are subjects of further experimentation.

   The LISP Mapping Service is an important component of the LISP
   toolset.  Issues and concerns about the deployment of LISP for
   Internet traffic are discussed in [LISP]. [RFC6830].

2.  Definition of Terms

   Map Server:   a

   Map-Server:   A network infrastructure component which that learns of EID-
      prefix
      EID-Prefix mapping entries from an ETR, via the registration
      mechanism described below, or some other authoritative source if
      one exists.  A Map Server Map-Server publishes these EID-prefixes EID-Prefixes in a
      mapping database.

   Map Resolver:   a

   Map-Resolver:   A network infrastructure component which that accepts LISP
      Encapsulated Map-Requests, typically from an ITR, and determines
      whether or not the destination IP address is part of the EID
      namespace; if it is not, a Negative Map-Reply is returned.
      Otherwise, the Map Resolver Map-Resolver finds the appropriate EID-to-RLOC
      mapping by consulting a mapping database system.

   Encapsulated Map-Request:   a   A LISP Map-Request carried within an
      Encapsulated Control Message, which has an additional LISP header
      prepended.  Sent to UDP destination port 4342.  The "outer"
      addresses are globally-routeable globally routable IP addresses, also known as RLOCs.
      Used by an ITR when sending to a Map Resolver Map-Resolver and by a Map
      Server Map-Server
      when forwarding a Map-Request to an ETR.

   Negative Map-Reply:   a   A LISP Map-Reply that contains an empty
      locator-set.
      Locator-Set.  Returned in response to a Map-Request if the
      destination EID does not exist in the mapping database.
      Typically, this means that the "EID" being requested is an IP
      address connected to a non-LISP site.

   Map-Register message:   a   A LISP message sent by an ETR to a Map Server Map-Server
      to register its associated EID-prefixes. EID-Prefixes.  In addition to the set
      of EID-prefixes EID-Prefixes to register, the message includes one or more
      RLOCs to be be used by the Map Server Map-Server when forwarding Map-Requests
      (re-formatted as Encapsulated Map-Requests) received through the
      database mapping system.  An ETR may request that the Map Server Map-Server
      answer Map-Requests on its behalf by setting the "proxy-map-reply" "proxy Map-Reply"
      flag (P-bit) in the message.

   Map-Notify message:   a   A LISP message sent by a Map Server Map-Server to an ETR
      to confirm that a Map-Register has been received and processed.
      An ETR requests that a Map-Notify be returned by setting the
      "want-map-notify" or "M" bit flag (M-bit) in the Map-Register message.
      Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both
      source and destination.

   For definitions of other terms, terms -- notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), (ETR) -- please
   consult the LISP specification [LISP]. [RFC6830].

3.  Basic Overview

   A Map Server Map-Server is a device which that publishes EID-prefixes EID-Prefixes in a LISP
   mapping database on behalf of a set of ETRs.  When it receives a Map
   Request (typically from an ITR) ITR), it consults the mapping database to
   find an ETR that can answer with the set of RLOCs for an EID-prefix. EID-Prefix.
   To publish its EID-prefixes, EID-Prefixes, an ETR periodically sends Map-Register
   messages to the Map Server. Map-Server.  A Map-Register message contains a list
   of EID-prefixes EID-Prefixes plus a set of RLOCs that can be used to reach the ETR
   when a Map Server Map-Server needs to forward a Map-Request to it.

   When LISP+ALT is used as the mapping database, a Map Server Map-Server connects
   to the ALT network and acts as a "last-hop" ALT router. ALT-Router.  Intermediate ALT
   routers
   ALT-Routers forward Map-Requests to the Map Server Map-Server that advertises a
   particular EID-prefix EID-Prefix, and the Map Server Map-Server forwards them to the owning
   ETR, which responds with Map-Reply messages.

   A Map Resolver Map-Resolver receives Encapsulated Map-Requests from its client
   ITRs and uses a mapping database system to find the appropriate ETR
   to answer those requests.  On a LISP+ALT network, a Map Resolver Map-Resolver acts
   as a "first-hop" ALT router. ALT-Router.  It has GRE Generic Routing Encapsulation
   (GRE) tunnels configured to other
   ALT routers ALT-Routers and uses BGP to learn
   paths to ETRs for different prefixes in the LISP+ALT database.  The Map Resolver
   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 Map-Resolver could cache
   responses to improve performance, issues surrounding cache management
   will need to be resolved for so that doing so to will be reliable and
   practical.  As initially deployed, Map Resolvers Map-Resolvers will operate only in
   a non-
   caching non-caching mode, de-decapsulating decapsulating and forwarding Encapsulated Map
   Requests received from ITRs.  Any specification of caching
   functionality is left for future work.

   Note that a single device can implement the functions of both a Map
   Server
   Map-Server and a Map Resolver and, Map-Resolver, and in many cases, cases the functions will
   be co-located in that way.

   Detailed descriptions of the LISP packet types referenced by this
   document may be found in [LISP]. [RFC6830].

4.  Interactions With with Other LISP Components

4.1.  ITR EID-to-RLOC Mapping Resolution

   An ITR is configured with one or more Map Resolver Map-Resolver addresses.  These
   addresses are "locators" "Locators" (or RLOCs) and must be routeable routable on the
   underlying core network; they must not need to be resolved through
   LISP EID-to-RLOC mapping mapping, as that would introduce a circular
   dependency.  When using a Map Resolver, Map-Resolver, an ITR does not need to
   connect to any other database mapping system.  In particular, the ITR
   need not connect to the LISP+ALT infrastructure or implement the BGP
   and GRE protocols that it uses.

   An ITR sends an Encapsulated Map-Request to a configured Map Resolver Map-Resolver
   when it needs an EID-to-RLOC mapping that is not found in its local
   map-cache.  Using the Map Resolver Map-Resolver greatly reduces both the
   complexity of the ITR implementation and the costs associated with
   its operation.

   In response to an Encapsulated Map-Request, the ITR can expect one of
   the following:

   o  An immediate Negative Map-Reply (with action code of "forward-
      native",
      "Natively-Forward", 15-minute TTL) Time to Live (TTL)) from the Map Resolver
      Map-Resolver if the Map Resolver Map-Resolver can determine that the requested
      EID does not exist.  The ITR saves the EID-prefix EID-Prefix returned in the
      Map-Reply in its cache,
      marking marks it as non-LISP-capable non-LISP-capable, and knows
      not to attempt LISP encapsulation for destinations matching it.

   o  A Negative Map-Reply (with Map-Reply, with action code of "forward-native") "Natively-Forward", from
      the Map Server
      a Map-Server that has is authoritative for an aggregate EID-covering EID-Prefix that matches
      the requested EID in the
      Map-Request but where that does not have an actively registered,
      more-specific ID-prefix.  In this case, the requested EID matches is said
      to match a "hole" in the aggregate.
      If the "hole" is for authoritative EID-Prefix.  If the
      requested EID matches a LISP EID-prefix more-specific EID-Prefix that is defined in has been
      delegated by the Map
      Server configuration Map-Server but for which no ETRs are currently
      registered, a 1-minute TTL is returned.  If the "hole" is for an
      unassigned requested EID
      matches a non-delegated part of the aggregate, authoritative EID-Prefix, then
      it is not a LISP EID and a 15-minute TTL is returned.  See
      Section 4.2 for discussion of aggregate EID-prefixes EID-Prefixes and details
      of Map Server EID-prefix Map-Server EID-Prefix matching.

   o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
      possibly from a Map Server Map-Server answering on behalf of the ETR.  See
      (Section 4.4)
      Section 4.4 for more details on Map Resolver Map-Resolver message processing.

   Note that an ITR may be configured to both use a Map Resolver Map-Resolver and to
   participate in a LISP+ALT logical network.  In such a situation, the
   ITR should send Map-Requests through the ALT network for any EID-
   prefix
   EID-Prefix learned via ALT BGP.  Such a configuration is expected to
   be very rare, since there is little benefit to using a Map Resolver Map-Resolver
   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
   EID (and rely on Negative Map-Replies) if it can consult the ALT
   database to verify that an EID-prefix EID-Prefix is present before sending that
   Map-Request.

4.2.  EID Prefix  EID-Prefix Configuration and ETR Registration

   An ETR publishes its EID-prefixes EID-Prefixes on a Map Server Map-Server by sending LISP
   Map-Register messages.  A Map-Register message includes
   authentication data, so prior to sending a Map-Register message, the
   ETR and Map Server Map-Server must be configured with a shared secret or other
   relevant authentication information.  A Map Server's Map-Server's configuration
   must also include a list of the EID-prefixes EID-Prefixes for which each ETR is
   authoritative.  Upon receipt of a Map-Register from an ETR, a Map
   Server
   Map-Server accepts only EID-prefixes EID-Prefixes that are configured for that
   ETR.  Failure to implement such a check would leave the mapping
   system vulnerable to trivial EID-prefix EID-Prefix hijacking attacks.  As
   developers and operators gain experience with the mapping system,
   additional, stronger security measures may be added to the
   registration process.

   In addition to the set of EID-prefixes EID-Prefixes defined for each ETR that may
   register, a Map Server Map-Server is typically also configured with one or more
   aggregate prefixes that define the part of the EID numbering space
   assigned to it.  When LISP+ALT is the database in use, aggregate EID-
   prefixes
   EID-Prefixes are implemented as discard routes and advertised into
   ALT BGP.  The existance existence of aggregate EID-prefixes EID-Prefixes in a Map Server's Map-Server's
   database means that it may receive Map Requests for EID-prefixes EID-Prefixes that
   match an aggregate but do not match a registered prefix; Section 4.3
   describes how this is handled.

   Map-Register messages are sent periodically from an ETR to a Map
   Server
   Map-Server with a suggested interval between messages of one minute.
   A
   Map Server Map-Server should time-out time out and remove an ETR's registration if it
   has not received a valid Map-Register message within the past
   three minutes.  When first contacting a Map Server Map-Server after restart or
   changes to its EID-to-RLOC database mappings, an ETR may initially
   send Map-
   Register Map-Register messages at an increased frequency, up to one every
   20 seconds.  This "quick registration" period is limited to
   five minutes in duration.

   An ETR may request that a Map Server Map-Server explicitly acknowledge receipt
   and processing of a Map-Register message by setting the "want-map-
   notify" ("M" bit)
   "want-map-notify" (M-bit) flag.  A Map Server Map-Server that receives a
   Map-Register 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 messages sent during the initial "quick registration"
   with a Map
   Server Map-Server but then set it only occasionally during
   steady-state maintenance of its association with that Map Server. Map-Server.
   Note that the Map-Notify message is sent to UDP destination port
   4342, not to the source port specified in the original Map-Register
   message.

   Note that a one-minute minimum registration interval during
   maintenance of an ETR-MS ETR-Map-Server association places a lower-bound lower bound on
   how quickly and how frequently a mapping database entry can be
   updated.  This may have implications for what sorts of mobility can
   be supported directly by the mapping system; shorter registration
   intervals or other mechanisms might be needed to suopport support faster
   mobility in some cases.  For a discussion on one way that faster
   mobility may be implemented for individual devices, please see
   [LISP-MN].

   An ETR may also request, by setting the "proxy-map-reply" "proxy Map-Reply" flag
   (P-bit) in the Map-Register message, that a Map Server Map-Server answer Map-
   Requests
   Map-Requests instead of forwarding them to the ETR.  See [LISP] [RFC6830]
   for details on how the Map Server Map-Server sets certain flags (such as those
   indicating whether the message is authoritative and how returned
   locators
   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
   RLOCs for all ETRs for the EID-prefix EID-Prefix being registered, along with
   the routable flag ("R-bit") setting for each RLOC.  The Map Server Map-Server
   includes all of this information in Map Reply Map-Reply messages that it sends
   on behalf of the ETR.  This differs from a non-proxy registration registration,
   since the latter need only provide one or more RLOCs for a Map Server Map-Server
   to use for forwarding Map-Requests; the registration information is
   not used in Map-Replies Map-Replies, so it being incomplete is not incorrect.

   An ETR which that uses a Map Server Map-Server to publish its EID-to-RLOC mappings
   does not need to participate further in the mapping database
   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
   greatly simplifies its configuration and reduces its cost of
   operation.

   Note that use of a Map Server Map-Server does not preclude an ETR from also
   connecting to the mapping database (i.e. (i.e., it could also connect to
   the LISP+ALT network) network), but doing so doesn't seem particularly useful useful,
   as the whole purpose of using a Map Server Map-Server is to avoid the complexity
   of the mapping database protocols.

4.3.  Map Server  Map-Server Processing

   Once a Map Server Map-Server has EID-prefixes EID-Prefixes registered by its client ETRs, it
   can accept and process Map-Requests for them.

   In response to a Map-Request (received over the ALT if LISP+ALT is in
   use), the Map Server Map-Server first checks to see if the destination EID
   matches a configured EID-prefix. EID-Prefix.  If there is no match, the Map
   Server
   Map-Server returns a negative Negative Map-Reply with action code "forward-native"
   "Natively-Forward" and a 15-minute TTL.  This may occur if a Map
   Request is received for a configured aggreate EID-prefix aggregate EID-Prefix for which
   no more-specific EID-
   prefix EID-Prefix exists; it indicates the presence of a
   non-LISP "hole" in the
   agregate EID-prefix. aggregate EID-Prefix.

   Next, the Map Server Map-Server checks to see if any ETRs have registered the
   matching EID-prefix. EID-Prefix.  If none are found, then the Map Server Map-Server returns
   a negative Negative Map-Reply with action code "forward-native" "Natively-Forward" and a
   1-minute TTL.

   If any of the registered ETRs for the EID-prefix EID-Prefix have requested proxy
   reply service, then the Map Server Map-Server answers the request instead of
   forwarding it.  It returns a Map-Reply with the EID-prefix, EID-Prefix, RLOCs,
   and other information learned through the registration process.

   If none of the ETRs have requested proxy reply service, then the Map
   Server
   Map-Server re-encapsulates and forwards the resulting Encapsulated Map-
   Request
   Map-Request to one of the registered ETRs.  It does not otherwise
   alter the Map-Request Map-Request, so any Map-Reply sent by the ETR is returned
   to the RLOC in the Map-Request, not to the Map Server. Map-Server.  Unless also
   acting as a Map Resolver, Map-Resolver, a Map Server Map-Server should never receive
   Map-Replies; any such messages should be discarded without response,
   perhaps accompanied by the logging of a diagnostic message if the
   rate of Map-
   Replies Map-Replies is suggestive of malicious traffic.

4.4.  Map Resolver  Map-Resolver Processing

   Upon receipt of an Encapsulated Map-Request, a Map Resolver de-
   capsulates Map-Resolver
   decapsulates the enclosed message and then searches for the requested
   EID in its local database of mapping entries (statically configured
   or learned from associated ETRs if the Map Resolver Map-Resolver is also a Map Server
   Map-Server offering proxy reply service).  If it finds a matching
   entry, it returns a LISP Map-Reply with the known mapping.

   If the Map Resolver Map-Resolver does not have the mapping entry and if it can
   determine that the EID is not in the mapping database (for example,
   if LISP+ALT is used, the Map Resolver Map-Resolver will have an ALT forwarding
   table that covers the full EID space) space), it immediately returns a
   negative LISP Map-Reply, with action code "forward-native" "Natively-Forward" and a 15-
   minute
   15-minute TTL.  To minimize the number of negative cache entries
   needed by an ITR, the Map Resolver Map-Resolver should return the least-specific
   prefix
   which that both matches the original query and does not match any EID-
   prefix
   EID-Prefix known to exist in the LISP-capable infrastructure.

   If the Map Resolver Map-Resolver does not have sufficient information to know
   whether the EID exists, it needs to forward the Map-Request to
   another device which that has more information about the EID being
   requested.  To do this, it forwards the unencapsulated Map-Request,
   with the original ITR RLOC as the source, to the mapping database
   system.  Using LISP+ALT, the Map Resolver Map-Resolver is connected to the ALT
   network and sends the Map-Request to the next ALT hop learned from
   its ALT BGP neighbors.  The Map Resolver Map-Resolver does not send any response
   to the ITR; since the source RLOC is that of the ITR, the ETR or Map
   Server which
   Map-Server that receives the Map-Request over the ALT and responds
   will do so directly to the ITR.

4.4.1.  Anycast Map Resolver Map-Resolver Operation

   A Map Resolver Map-Resolver can be set up to use "anycast", where the same address
   is assigned to multiple Map Resolvers Map-Resolvers and is propagated through IGP
   routing, to facilitate the use of a topologically-close Map Resolver topologically close Map-Resolver
   by each ITR.

   Note that Map Server Map-Server associations with ETRs should not use anycast
   addresses
   addresses, as registrations need to be established between an ETR and
   a specific set of Map Servers, Map-Servers, each identified by a specific
   registation
   registration association.

5.  Open Issues and Considerations

   There are a number of issues with the Map Server Map-Server and Map Resolver Map-Resolver
   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 Negative Map-Reply
      TTLs, et al al. are subject to further refinement as more experience
      with prototype deployment is gained.

   o  Convergence time when an EID-to-RLOC mapping changes changes, and
      mechanisms for detecting and refreshing or removing stale, cached
      information
      information.

   o  Deployability and complexity trade-offs tradeoffs of implementing stronger
      security measures in both EID-prefix EID-Prefix registration and Map-Request/
      Map-Reply processing processing.

   o  Requirements for additional state in the registration process
      between Map Servers Map-Servers and ETRs ETRs.

   A discussion of other issues surrounding LISP deployment may also be
   found in Section 15 of [LISP]. [RFC6830].

   The authors expect that experimentation on the LISP pilot network
   will help answer open questions surrounding these and other issues.

6.  IANA Considerations

   This document makes no request of the IANA.

7.  Security Considerations

   The 2-way LISP header nonce exchange documented in [LISP] [RFC6830] can be
   used to avoid ITR spoofing attacks.

   To publish an authoritative EID-to-RLOC mapping with a Map Server, Map-Server, an
   ETR includes authentication data that is a hash of the message using
   a pair-wise shared key.  An implementation must support use of HMAC-
   SHA-1-96
   HMAC-SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128
   [RFC6234] (SHA-256 truncated to 128 bits).

   During experimental and prototype deployment, all authentication key
   configuration will be manual.  Should LISP and its components be
   considered for IETF standardization, further work will be required to
   follow the BCP 107 [RFC4107] recommendations on automated key
   management.

   As noted in Section 4.2, a Map Server Map-Server should verify that all EID-
   prefixes
   EID-Prefixes registered by an ETR match the configuration stored on
   the Map
   Server. Map-Server.

   The currently-defined currently defined authentication mechanism for Map-Register
   messages does not provide protection against "replay" attacks by a
   "man-in-the-middle".  Additional work is needed in this area.

   [LISP-SEC] defines a proposed mechanism for providing origin
   authentication, integrity, anti-replay protection, and prevention of
   man-in-the-middle and "overclaiming" attacks on the Map-Request/
   Map-Reply exchange.  Work is ongoing on this and other proposals for
   resolving these open security issues issues.

   While beyond the scope of securing an individual Map Server Map-Server or Map
   Resolver,
   Map-Resolver, it should be noted that a BGP-based LISP+ALT network
   (if ALT is used as the mapping database infrastructure) can take
   advantage of standards work on adding security to BGP.

8.

7.  References

8.1.

7.1.  Normative References

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-10.txt (work in progress),
              December 2011.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-22.txt (work in progress), February 2012.

   [RFC1035]    Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, November 1987.

   [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
                Hashing for Message Authentication", RFC 2104,
                February 1997.

   [RFC6234]    Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
                (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

8.2.

   [RFC6830]    Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
                Locator/ID Separation Protocol (LISP)", RFC 6830,
                January 2013.

   [RFC6836]    Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
                "Locator/ID Separation Protocol Alternative Logical
                Topology (LISP+ALT)", RFC 6836, January 2013.

7.2.  Informative References

   [CONS]

   [LISP-CONS]  Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis,
                D., and D. Meyer, "LISP-CONS: A Content distribution
                Overlay Network Service for LISP",
              draft-meyer-lisp-cons-04.txt (work Work in progress), Progress,
                April 2008.

   [LISP-MN]    Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
                Mobile Node Architecture", draft-meyer-lisp-mn-06.txt
              (work Node", Work in progress), Progress, October 2011. 2012.

   [LISP-SEC]   Maino, F., Ermagan, V., Cabellos, A., Sanchez, Saucez, D., and O.
                Bonaventure, "LISP-Security", draft-ietf-lisp-sec-01.txt
              (work "LISP-Security (LISP-SEC)", Work
                in progress), January Progress, October 2012.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08.txt (work in progress),
              March 2010.

   [RFC4107]    Bellovin, S. and R. Housley, "Guidelines for
                Cryptographic Key Management", BCP 107, RFC 4107,
                June 2005.

   [RFC6837]    Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
                Routing Locator (RLOC) Database", RFC 6837,
                January 2013.

Appendix A.  Acknowledgments

   The authors would like to thank Greg Gregg Schudel, Darrel Lewis, John
   Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
   Fabio Maino, and members of the lisp@ietf.org mailing list for their
   feedback and helpful suggestions.

   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. Map-Resolvers.

Authors' Addresses

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   EMail: vaf@vaf.net

   Dino Farinacci
   cisco
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   EMail: farinacci@gmail.com