    Internet Engineering Task Force (IETF)                         V. Fuller
    Request for Comments: 6833
    Category: Experimental                                      D. Farinacci
    ISSN: 2070-1721                                            Cisco Systems
                                                                January 2013

           Locator/ID Separation Protocol (LISP) Map-Server Interface

    Abstract

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

       By using this service interface and communicating with Map-Resolvers
       and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel
       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 Memo

       This document is not an Internet Standards Track specification; it is
       published for examination, experimental implementation, and
       evaluation.

       This document defines an Experimental Protocol for the Internet
       community.  This document is a product of the Internet Engineering
       Task Force (IETF).  It represents the consensus of 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 candidate for any level of
       Internet Standard; see Section 2 of RFC 5741.

       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.

    Fuller & Farinacci            Experimental                      [Page 1]

    RFC 6833                LISP Map-Server Interface           January 2013

    Copyright Notice

       Copyright (c) 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 ....................................................2
       2. Definition of Terms .............................................3
       3. Basic Overview ..................................................4
       4. Interactions with Other LISP Components .........................5
          4.1. ITR EID-to-RLOC Mapping Resolution .........................5
          4.2. EID-Prefix Configuration and ETR Registration ..............6
          4.3. Map-Server Processing ......................................8
          4.4. Map-Resolver Processing ....................................9
               4.4.1. Anycast Map-Resolver Operation .....................10
       5. Open Issues and Considerations .................................10
       6. Security Considerations ........................................11
       7. References .....................................................12
          7.1. Normative References ......................................12
          7.2. Informative References ....................................12
       Appendix A. Acknowledgments .......................................13

    1.  Introduction

       The Locator/ID Separation 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; 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; among 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 Alternative
       Logical Topology (LISP+ALT) [RFC6836].

    Fuller & Farinacci            Experimental                      [Page 2]

    RFC 6833                LISP Map-Server Interface           January 2013

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

       Conceptually, LISP Map-Servers share some of the same basic
       configuration and maintenance properties as Domain Name System (DNS)
       [RFC1035] servers; likewise, 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 and
       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 and 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 [RFC6830].

    2.  Definition of Terms

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

       Map-Resolver:   A network infrastructure component 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 finds the appropriate EID-to-RLOC
          mapping by consulting a mapping database system.

    Fuller & Farinacci            Experimental                      [Page 3]

    RFC 6833                LISP Map-Server Interface           January 2013

       Encapsulated Map-Request:   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 routable IP addresses, also known as RLOCs.
          Used by an ITR when sending to a Map-Resolver and by a Map-Server
          when forwarding a Map-Request to an ETR.

       Negative Map-Reply:   A LISP Map-Reply that contains an empty
          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 LISP message sent by an ETR to a Map-Server
          to register its associated EID-Prefixes.  In addition to the set
          of EID-Prefixes to register, the message includes one or more
          RLOCs to be used by the 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
          answer Map-Requests on its behalf by setting the "proxy Map-Reply"
          flag (P-bit) in the message.

       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.
          An ETR requests that a Map-Notify be returned by setting the
          "want-map-notify" 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 -- notably Map-Request, Map-Reply,
       Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
       consult the LISP specification [RFC6830].

    3.  Basic Overview

       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
       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.
       To publish its EID-Prefixes, an ETR periodically sends Map-Register
       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
       when a Map-Server needs to forward a Map-Request to it.

    Fuller & Farinacci            Experimental                      [Page 4]

    RFC 6833                LISP Map-Server Interface           January 2013

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

       A 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 acts
       as a "first-hop" ALT-Router.  It has Generic Routing Encapsulation
       (GRE) tunnels configured to other ALT-Routers and uses BGP to learn
       paths to ETRs for different prefixes in the LISP+ALT database.  The
       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
       responses to improve performance, issues surrounding cache management
       will need to be resolved so that doing so will be reliable and
       practical.  As initially deployed, Map-Resolvers will operate only in
       a non-caching mode, 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 and a Map-Resolver, and in many 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 [RFC6830].

    4.  Interactions with Other LISP Components

    4.1.  ITR EID-to-RLOC Mapping Resolution

       An ITR is configured with one or more Map-Resolver addresses.  These
       addresses are "Locators" (or RLOCs) and must be routable on the
       underlying core network; they must not need to be resolved through
       LISP EID-to-RLOC mapping, as that would introduce a circular
       dependency.  When using a 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
       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
       complexity of the ITR implementation and the costs associated with
       its operation.

    Fuller & Farinacci            Experimental                      [Page 5]

    RFC 6833                LISP Map-Server Interface           January 2013

       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
          "Natively-Forward", 15-minute Time to Live (TTL)) from the
          Map-Resolver if the Map-Resolver can determine that the requested
          EID does not exist.  The ITR saves the EID-Prefix returned in the
          Map-Reply in its cache, marks it as non-LISP-capable, and knows
          not to attempt LISP encapsulation for destinations matching it.

       o  A Negative Map-Reply, with action code of "Natively-Forward", from
          a Map-Server that is authoritative for an EID-Prefix that matches
          the requested EID but that does not have an actively registered,
          more-specific ID-prefix.  In this case, the requested EID is said
          to match a "hole" in the authoritative EID-Prefix.  If the
          requested EID matches a more-specific EID-Prefix that has been
          delegated by the Map-Server but for which no ETRs are currently
          registered, a 1-minute TTL is returned.  If the requested EID
          matches a non-delegated part of the 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 and details
          of 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 answering on behalf of the ETR.  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
       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 learned via ALT BGP.  Such a configuration is expected to
       be 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
       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 is present before sending that
       Map-Request.

    4.2.  EID-Prefix Configuration and ETR Registration

       An ETR publishes its EID-Prefixes on a 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 must be configured with a shared secret or other
       relevant authentication information.  A Map-Server's configuration
       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-Server accepts only EID-Prefixes that are configured for that

    Fuller & Farinacci            Experimental                      [Page 6]

    RFC 6833                LISP Map-Server Interface           January 2013

       ETR.  Failure to implement such a check would leave the mapping
       system vulnerable to trivial 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 defined for each ETR that may
       register, a 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 are implemented as discard routes and advertised into
       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
       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 with a suggested interval between messages of one minute.
       A 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 minutes.  When first contacting a Map-Server after restart or
       changes to its EID-to-RLOC database mappings, an ETR may initially
       send 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 explicitly acknowledge receipt
       and processing of a Map-Register message by setting the
       "want-map-notify" (M-bit) flag.  A 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 but then set it only occasionally during
       steady-state maintenance of its association with that 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-Map-Server association places a 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 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].

    Fuller & Farinacci            Experimental                      [Page 7]

    RFC 6833                LISP Map-Server Interface           January 2013

       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-Requests instead of forwarding them to the ETR.  See [RFC6830]
       for details on how the Map-Server sets certain flags (such as those
       indicating whether the message is authoritative and how returned
       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 being registered, along with
       the routable flag ("R-bit") setting for each RLOC.  The Map-Server
       includes all of this information in Map-Reply messages that it sends
       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 that uses a 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 does not preclude an ETR from also
       connecting to the mapping database (i.e., it could also connect to
       the LISP+ALT network), but doing so doesn't seem particularly useful,
       as the whole purpose of using a Map-Server is to avoid the complexity
       of the mapping database protocols.

    4.3.  Map-Server Processing

       Once a Map-Server has 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 first checks to see if the destination EID
       matches a configured EID-Prefix.  If there is no match, the
       Map-Server returns a Negative Map-Reply with action code
       "Natively-Forward" and a 15-minute TTL.  This may occur if a Map
       Request is received for a configured aggregate EID-Prefix for which
       no more-specific EID-Prefix exists; it indicates the presence of a
       non-LISP "hole" in the aggregate EID-Prefix.

       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
       a Negative Map-Reply with action code "Natively-Forward" and a
       1-minute TTL.

    Fuller & Farinacci            Experimental                      [Page 8]

    RFC 6833                LISP Map-Server Interface           January 2013

       If any of the registered ETRs for the EID-Prefix have requested proxy
       reply service, then the Map-Server answers the request instead of
       forwarding it.  It returns a Map-Reply with the 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 re-encapsulates and forwards the resulting Encapsulated
       Map-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 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 such messages should be discarded without response,
       perhaps accompanied by the logging of a diagnostic message if the
       rate of Map-Replies is suggestive of malicious traffic.

    4.4.  Map-Resolver Processing

       Upon receipt of an Encapsulated Map-Request, a 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 is also a
       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 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 will have an ALT forwarding
       table that covers the full EID space), it immediately returns a
       negative LISP Map-Reply, with action code "Natively-Forward" and a
       15-minute TTL.  To minimize the number of negative cache entries
       needed by an ITR, the Map-Resolver should return the least-specific
       prefix that both matches the original query and does not match any
       EID-Prefix known to exist in the LISP-capable infrastructure.

       If the Map-Resolver does not have sufficient information to know
       whether the EID exists, it needs to forward the Map-Request to
       another device 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 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 does not send any response
       to the ITR; since the source RLOC is that of the ITR, the ETR or
       Map-Server that receives the Map-Request over the ALT and responds
       will do so directly to the ITR.

    Fuller & Farinacci            Experimental                      [Page 9]

    RFC 6833                LISP Map-Server Interface           January 2013

    4.4.1.  Anycast Map-Resolver Operation

       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
       routing, to facilitate the use of a topologically close Map-Resolver
       by each ITR.

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

    5.  Open Issues and Considerations

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

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

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

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

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

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

    Fuller & Farinacci            Experimental                     [Page 10]

    RFC 6833                LISP Map-Server Interface           January 2013

    6.  Security Considerations

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

       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
       a pair-wise shared key.  An implementation must support use of
       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 should verify that all
       EID-Prefixes registered by an ETR match the configuration stored on
       the Map-Server.

       The 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.

       While beyond the scope of securing an individual Map-Server or
       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.

    Fuller & Farinacci            Experimental                     [Page 11]

    RFC 6833                LISP Map-Server Interface           January 2013

    7.  References

    7.1.  Normative References

       [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.

       [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

       [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", Work in Progress,
                    April 2008.

       [LISP-MN]    Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
                    Mobile Node", Work in Progress, October 2012.

       [LISP-SEC]   Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O.
                    Bonaventure, "LISP-Security (LISP-SEC)", Work
                    in Progress, October 2012.

       [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.

    Fuller & Farinacci            Experimental                     [Page 12]

    RFC 6833                LISP Map-Server Interface           January 2013

    Appendix A.  Acknowledgments

       The authors would like to thank 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.

    Authors' Addresses

       Vince Fuller

       EMail: vaf@vaf.net

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

       EMail: farinacci@gmail.com

    Fuller & Farinacci            Experimental                     [Page 13]