RFC 6833

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

Okay bestie, this is RFC 6833, written by V. Fuller and D. Farinacci from Cisco Systems 💅 It was published in January 2013 as an Experimental document, so it's a "let's try it and see" kind of spec, not a standards track thing 🧪 The ISSN is 2070-1721. The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own main character energy 🦋

Abstract ✨

This doc describes the Mapping Service for the Locator/ID Separation Protocol (LISP) 🌸 It's built from two brand new kinds of LISP-speaking devices, the LISP Map-Resolver and the LISP Map-Server, and together they act like a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases 💖

Because LISP Ingress Tunnel Routers and Egress Tunnel Routers talk to this service instead, they don't have to care about the nitty-gritty of how the mapping database works internally, which makes it way easier to experiment with different database designs 🧪 These routers are the "edge" of the LISP setup, they plug straight into LISP-capable end sites, and they make up most of the LISP-speaking devices. So making them simpler to build and run should also bring down the overall cost and effort of deploying LISP 🫶

Status of This Memo ✨

This doc is not an Internet Standards Track spec. It's published for examination, experimental implementation, and evaluation 🔬

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6833 🌈

Copyright Notice ✨

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they explain your rights and restrictions for this document 📜 Any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💜

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] lays out an architecture and mechanism for swapping out the addresses IP uses today for two separate name spaces 🦋 One is Endpoint IDs (EIDs), which are used within sites. The other is Routing Locators (RLOCs), which are used on the transit networks that make up the Internet infrastructure. To pull off this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs 🗺️ LISP also assumes there's a database that stores and spreads those mappings around globally. A few of these databases have been proposed, including 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] 🌸

The LISP Mapping Service adds two new kinds of LISP-speaking devices. The first is the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database. The second is 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. Map-Resolvers are conceptually similar to DNS caching resolvers too 🧚 So this spec borrows the familiar terms resolver and server from the DNS specs 💖

Heads up, while this doc assumes a LISP+ALT database mapping infrastructure to illustrate certain parts of Map-Server and Map-Resolver operation, the Mapping Service interface can (and likely will) be used by ITRs and ETRs to reach other mapping database systems as LISP evolves 🦋

Section 5 of this document notes a bunch of issues with the Map-Server and Map-Resolver design that aren't fully understood yet and are subjects of further experimentation 🔬

The LISP Mapping Service is a big deal in the LISP toolset ✨ Issues and concerns about deploying LISP for Internet traffic are discussed in [RFC6830] 🫶

2. Definition of Terms ✨

• Map-Server: A network infrastructure component that learns EID-Prefix mapping entries from an ETR, through the registration mechanism described below, or from 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 figures out whether or not the destination IP address is part of the EID namespace. If it isn't, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the right EID-to-RLOC mapping by consulting a mapping database system 🔍
• Encapsulated Map-Request: A LISP Map-Request carried within an Encapsulated Control Message, which has an extra LISP header prepended. It's sent to UDP destination port 4342. The "outer" addresses are globally routable IP addresses, also known as RLOCs. An ITR uses it when sending to a Map-Resolver, and a Map-Server uses it when forwarding a Map-Request to an ETR 📦
• Negative Map-Reply: A LISP Map-Reply that contains an empty Locator-Set. It's returned in response to a Map-Request if the destination EID doesn't exist in the mapping database. Typically, this means 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. Along with the set of EID-Prefixes to register, the message includes one or more RLOCs for the Map-Server to use when forwarding Map-Requests (re-formatted as Encapsulated Map-Requests) received through the database mapping system. An ETR can ask the Map-Server to 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 asks for a Map-Notify to be sent back 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), check the LISP spec [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 gets 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 💫

When LISP+ALT is 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 then 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 right 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 info to forward Map-Requests over the ALT to the correct ETRs 🧭

Quick note: a Map-Resolver could cache responses to improve performance, but cache management issues will need to be sorted out first so that caching is reliable and practical 🤔 As initially deployed, Map-Resolvers will only operate in a non-caching mode, decapsulating and forwarding Encapsulated Map Requests received from ITRs. Any spec for caching functionality is left for future work 🔮

Also, 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 that way 👑

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

4. Interactions with Other LISP Components ✨

4.1. ITR EID-to-RLOC Mapping Resolution 🦋

okay so an ITR gets configured with one or more Map-Resolver addresses 💖. These addresses are "Locators" (or RLOCs), and they must be routable on the underlying core network. They must not need to be resolved through LISP EID-to-RLOC mapping, because that would be a circular dependency and absolutely not it 🙈. When it's using a Map-Resolver, an ITR does not need to connect to any other database mapping system. It doesn't have to plug into the LISP+ALT infrastructure or implement the BGP and GRE protocols that LISP+ALT uses. main character energy, literally ✨

An ITR sends an Encapsulated Map-Request to a configured Map-Resolver whenever it needs an EID-to-RLOC mapping that isn't in its local map-cache 🌸. Using the Map-Resolver greatly reduces both the complexity of the ITR implementation and the costs of running it. Iconic 👑

So when an ITR sends an Encapsulated Map-Request, it can expect one of the following:

• An immediate Negative Map-Reply (with action code Natively-Forward and a 15-minute Time to Live (TTL)) from the Map-Resolver, if the Map-Resolver can tell that the requested EID doesn't 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 try LISP encapsulation for destinations that match it.
• A Negative Map-Reply, with action code Natively-Forward, from a Map-Server that's authoritative for an EID-Prefix matching the requested EID, but that doesn't 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 the Map-Server has delegated but no ETRs are currently registered for it, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it's not a LISP EID and a 15-minute TTL is returned. See Section 4.2 for the discussion of aggregate EID-Prefixes and the details of Map-Server EID-Prefix matching 🧚
• A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping, or possibly from a Map-Server answering on the ETR's behalf. 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 participate in a LISP+ALT logical network. In that situation, the ITR should send Map-Requests through the ALT network for any EID-Prefix learned via ALT BGP. This kind of setup is expected to be very rare, though, since there's little benefit to using a Map-Resolver if an ITR is already on LISP+ALT 🤷‍♀️. For example, there's no need for such an ITR to send a Map-Request for a possibly non-existent EID and then rely on Negative Map-Replies, if it can check the ALT database first to confirm that the EID-Prefix is there 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 before an ETR sends one, 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 each ETR is authoritative for. When a Map-Server gets a Map-Register from an ETR, it accepts only the EID-Prefixes configured for that ETR. Skipping this check would leave the mapping system open to trivial EID-Prefix hijacking attacks 🚨 (not it!). As developers and operators get more experience with the mapping system, additional, stronger security measures may be added to the registration process 💅.

Besides 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. This means a Map-Server may receive Map-Requests for EID-Prefixes that match an aggregate but don't match any registered prefix. Section 4.3 describes how that gets handled ✨.

Map-Register messages are sent periodically from an ETR to a Map-Server, with a suggested interval of one minute between messages ⏰. A Map-Server should time out and remove an ETR's registration if it hasn't received a valid Map-Register message within the past three minutes 🙈. When first contacting a Map-Server after a restart, or after 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 ask a Map-Server to explicitly acknowledge receipt and processing of a Map-Register message by setting the want-map-notify (M-bit) flag. A Map-Server that gets a Map-Register with this flag set will respond with a Map-Notify message 📬. The typical move here is for an ETR to set it on Map-Registers sent during the initial "quick registration" with a Map-Server, then set it only occasionally during steady-state maintenance of that association 🫶. Note that the Map-Notify message is sent to UDP destination port 4342, not to the source port from the original Map-Register message 🦋.

Heads up: a one-minute minimum registration interval during maintenance of an ETR-Map-Server association puts a lower bound on how quickly and how often a mapping database entry can be updated 😭. This may have implications for what kinds of mobility the mapping system can support directly. Shorter registration intervals or other mechanisms might be needed to support faster mobility in some cases. For one way faster mobility may be implemented for individual devices, see [LISP-MN] 💜.

An ETR may also set the "proxy Map-Reply" flag (P-bit) in the Map-Register message to ask 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 it sends 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 the Map-Replies it sends on the ETR's behalf. This is different from a non-proxy registration, which only needs to provide one or more RLOCs for the Map-Server to use when forwarding Map-Requests. The registration information isn't used in Map-Replies in that case, so it being incomplete isn't incorrect 🌸.

An ETR that uses a Map-Server to publish its EID-to-RLOC mappings doesn't need to participate further in the mapping database protocol(s) 🧁. When using a LISP+ALT mapping database, for example, this means the ETR doesn't need to implement GRE or BGP, which greatly simplifies its configuration and cuts its cost of operation 💰.

Note that using a Map-Server doesn't stop an ETR from also connecting to the mapping database (it could still connect to the LISP+ALT network). But doing so doesn't seem particularly useful, since the whole point 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 💖.

When a Map-Request comes in (over the ALT, if LISP+ALT is in use), the Map-Server first checks whether the destination EID matches a configured EID-Prefix 👀. If there's no match, the Map-Server returns a Negative Map-Reply with action code Natively-Forward and a 15-minute TTL. This can happen when a Map-Request arrives for a configured aggregate EID-Prefix that has no more-specific EID-Prefix under it. It signals a non-LISP "hole" in the aggregate EID-Prefix 🕳️.

Next, the Map-Server checks whether any ETRs have registered the matching EID-Prefix. If none have, the Map-Server returns a Negative Map-Reply with action code Natively-Forward and a 1-minute TTL ⏱️.

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

If none of the ETRs have requested proxy reply service, the Map-Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs. It doesn't otherwise alter the Map-Request, so any Map-Reply the ETR sends is returned to the RLOC in the Map-Request, not to the Map-Server 📨. Unless it's also acting as a Map-Resolver, a Map-Server should never receive Map-Replies. Any such messages should be discarded without response, perhaps with a diagnostic message logged if the rate of Map-Replies looks like malicious traffic 🚫.

4.4. Map-Resolver Processing 🔍

When a Map-Resolver receives an Encapsulated Map-Request, it decapsulates the enclosed message and then searches for the requested EID in its local database of mapping entries 🗂️. That database is either statically configured or, if the Map-Resolver is also a Map-Server offering proxy reply service, learned from its associated ETRs. If it finds a matching entry, it returns a LISP Map-Reply with the known mapping 🎉.

If the Map-Resolver doesn't have the mapping entry, and it can determine that the EID isn't in the mapping database, it immediately returns a negative LISP Map-Reply with action code Natively-Forward and a 15-minute TTL 💀. For example, if LISP+ALT is used, the Map-Resolver will have an ALT forwarding table that covers the full EID space, so it can tell. To keep the number of negative cache entries an ITR needs to a minimum, the Map-Resolver should return the least-specific prefix that both matches the original query and doesn't match any EID-Prefix known to exist in the LISP-capable infrastructure 🧠.

If the Map-Resolver doesn't have enough information to know whether the EID exists, it needs to forward the Map-Request to another device that has more information about the requested EID 🛰️. To do that, 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 it learned from its ALT BGP neighbors. The Map-Resolver doesn't send any response to the ITR. Since the source RLOC is the ITR's, the ETR or Map-Server that receives the Map-Request over the ALT and responds will reply directly to the ITR 🦋✨

4.4.1. Anycast Map-Resolver Operation ✨

okay so a Map-Resolver can be set up to use "anycast" 🌸. That's when the same address gets assigned to multiple Map-Resolvers and gets spread around through IGP routing, so each ITR can hop onto a topologically close one. main character routing, honestly 💅

Note that Map-Server associations with ETRs SHOULD NOT use anycast addresses 🙈. The reason is that registrations need to be set up between an ETR and a specific set of Map-Servers, and each one is identified by its own specific registration association. no mixing it up, bestie 🫶

5. Open Issues and Considerations 🧩

there are still a bunch of Map-Server and Map-Resolver things that nobody has fully figured out yet 😭 Here's what's still on the table:

• The constants (stuff like Map-Register frequency, retransmission timeouts, retransmission limits, Negative Map-Reply TTLs, et al.) are still getting tuned as more experience comes in from prototype deployments 🔧
• Convergence time after an EID-to-RLOC mapping changes, plus how to detect stale cached info and then refresh or remove it 🕰️
• The tradeoffs between deployability and complexity when you add stronger security to both EID-Prefix registration and Map-Request/Map-Reply processing 🔐
• Extra state that might be needed in the registration process between Map-Servers and ETRs 📦

more LISP deployment drama is covered in Section 15 of [RFC6830] 📖. The authors are hoping experiments on the LISP pilot network will help answer these questions and the rest of the open ones ✨

6. Security Considerations 💀

okay this section is serious, so let's go 🔒

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 data is a hash of the message, made with a pair-wise shared key 🔑. An implementation MUST support HMAC-SHA-1-96 [RFC2104], and it SHOULD support HMAC-SHA-256-128 [RFC6234] (that's SHA-256 truncated to 128 bits) 💖

During experimental and prototype deployment, all authentication key configuration will be done manually 🙈. If LISP and its components ever get considered for IETF standardization, more work will be needed 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 authentication mechanism currently defined for Map-Register messages does NOT protect against "replay" attacks by a "man-in-the-middle". Additional work is needed in this area. This is a real gap, so don't skip it 😭

[LISP-SEC] defines a proposed mechanism for 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 still ongoing on this and other proposals for fixing these open security issues.

And while securing an individual Map-Server or Map-Resolver is one thing, it's worth noting that a BGP-based LISP+ALT network (if ALT is the mapping database infrastructure) can take advantage of standards work on adding security to BGP 🌈

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

Appendix A. Acknowledgments 🫶

the authors wanted to thank Gregg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Fabio Maino, and everyone on the lisp@ietf.org mailing list for their feedback and helpful suggestions 💜

Special thanks go 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