doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6833.txt b/doc/rfc/rfc6833.txt
new file mode 100644
index 0000000..2780f6a
--- /dev/null
+++ b/doc/rfc/rfc6833.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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]
+