Network Working Group V. Fuller Internet-Draft D. Lewis Intended status: Experimental V. Ermagan Expires: September 14, 2012 cisco Systems March 13, 2012 LISP Delegated Database Tree draft-fuller-lisp-ddt-01.txt Abstract This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents 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 14, 2012. Copyright Notice Copyright (c) 2012 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 Fuller, et al. Expires September 14, 2012 [Page 1] Internet-Draft LISP Delegated Database Tree March 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. EID-prefix tree structure and instance IDs . . . . . . . . . . 8 4. Configuring XEID-prefix delegation . . . . . . . . . . . . . . 9 4.1. Example DDT node configuration . . . . . . . . . . . . . . 9 4.2. The root DDT node . . . . . . . . . . . . . . . . . . . . 10 5. DDT node operation - sending referrals . . . . . . . . . . . . 11 5.1. Match of a delegated prefix (or sub-prefix) . . . . . . . 11 5.2. Missing delegation from an authoritative prefix . . . . . 11 6. DDT Map-Server operation . . . . . . . . . . . . . . . . . . . 12 7. DDT Map-Resolver operation . . . . . . . . . . . . . . . . . . 13 7.1. Queuing, Sending, and Retransmitting DDT Map-Requests . . 13 7.2. Receiving and following referrals . . . . . . . . . . . . 13 7.2.1. Referral Set . . . . . . . . . . . . . . . . . . . . . 14 7.2.2. Referral list incomplete flag . . . . . . . . . . . . 14 7.2.3. Action Types . . . . . . . . . . . . . . . . . . . . . 14 7.2.4. Handling referral errors . . . . . . . . . . . . . . . 16 7.2.5. Referral loop detection . . . . . . . . . . . . . . . 16 8. Example message flow . . . . . . . . . . . . . . . . . . . . . 18 8.1. ITR sends a Map-Request to a DDT Map-Resolver . . . . . . 18 8.2. DDT Map-Resolver receives and processes Map-Request . . . 18 8.3. DDT Map-Resolver searches referral cache for XEID . . . . 18 8.4. DDT Map-Resolver creates and sends DDT Map-Request . . . . 19 8.5. DDT node receives and processes DDT Map-Request . . . . . 19 8.6. DDT Map-Resolver processes Map-Referral . . . . . . . . . 19 8.7. DDT Map-Server receives Map-Request . . . . . . . . . . . 20 8.8. DDT Map-Resolver finished . . . . . . . . . . . . . . . . 20 8.9. DDT Map-Server receives LISP-SEC-enabled Map-Request . . . 20 8.10. ETR sends Map-Reply to ITR . . . . . . . . . . . . . . . . 21 9. Securing the database and message exchanges . . . . . . . . . 22 9.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . . 22 9.2. DDT node operation . . . . . . . . . . . . . . . . . . . . 23 9.2.1. DDT public key revocation . . . . . . . . . . . . . . 23 9.3. Map-Server operation . . . . . . . . . . . . . . . . . . . 23 9.4. Map-Resolver operation . . . . . . . . . . . . . . . . . . 24 10. Open Issues and Considerations . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 Fuller, et al. Expires September 14, 2012 [Page 2] Internet-Draft LISP Delegated Database Tree March 2012 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 30 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Encapsulated Control Message Format . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Fuller, et al. Expires September 14, 2012 [Page 3] Internet-Draft LISP Delegated Database Tree March 2012 1. Introduction [LISP] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: relatively static Endpoint Identifiers (EIDs), used end-to-end for terminating transport-layer associations, and Routing Locators (RLOCs), which are more dynamic, are bound to topological location, and are used for routing and forwarding through the Internet infrastructure. LISP offers a general-purpose mechanism for mapping between EIDs and RLOCs. In organizing a database of EID to RLOC mappings, this specification extends the definition of the EID numbering space by logically prepending and appending several fields for purposes of defining the database index key: Key-ID (16 bits), Instance Identifier (IID, 32-bits), Address Family Identifier (16 bits), and EID-prefix (variable, according to AFI value). The resulting concatenation of these fields is termed an "Extended EID prefix" or XEID-prefix. The term "Extended EID" (XEID) is also used for an individual LISP EID that is further qualified through the use of an Instance ID. See [LCAF] for further discussion of the use of Instance IDs. The Key-ID is provided for possible use in case a need evolves for another, higher level in the hierarchy, to allow the creation of multiple, separate database trees. LISP-DDT is a hierarchical distributed database which embodies the delegation of authority to provide mappings, i.e. its internal structure mirrors the hierarchical delegation of address space. It also provides delegation information to Map-Resolvers, which use the information to locate EID-to-RLOC mappings. A Map-Resolver which needs to locate a given mapping will follow a path through the tree- structured database, contacting, one after another, the DDT nodes along that path until it reaches the leaf DDT node(s) authoritative for the mapping it is seeking. LISP-DDT defines a new device type, the DDT node, that is configured as authoritative for one or more XEID-prefixes. It also is configured with the set of more-specific sub-prefixes that are further delegated to other DDT nodes. To delegate a sub-prefix, the "parent" DDT node is configured with the RLOCs of each child DDT node that is authoritative for the sub-prefix. Each RLOC either points to a Map-Server (sometimes termed a "terminal DDT node") to which an Egress Tunnel Routers (ETRs) registers that sub-prefix or points to another DDT node in the database tree that further delegates the sub- prefix. See [LISP-MS] for a description of the functionality of the Fuller, et al. Expires September 14, 2012 [Page 4] Internet-Draft LISP Delegated Database Tree March 2012 Map-Server and Map-Resolver. Note that the target of a delegation must always be an RLOC (not an EID) to avoid any circular dependency. To provide a mechanism for traversing the database tree, LISP-DDT defines a new LISP message type, the Map-Referral, which is returned to the sender of a Map-Request when the receiving DDT node can refer the sender to another DDT node that has more detailed information. See Appendix B for the definition of the Map-Referral message. A DDT client uses LISP-DDT to find an EID-to-RLOC mapping by first sending a Map-Request to the RLOC of a DDT node. The initial choice of DDT node is configured on the client. If the receiving DDT node is also a Map-Server that is responsible for the XEID queried, the Map-Request is handled as described in [LISP-MS], with the DDT Map- Server also returning a Map-Referral message with the "done" flag set to the Map-Request sender. Otherwise, the DDT node answers the Map- Request with a Map-Referral; the DDT client then re-sends its DDT Map-Request to one of the RLOCs listed in the Map-Referral. This iterative process of sending requests and following referrals continues until the client receives a Map-Referral with the "done" flag set. This is an indication that the terminal DDT Map-Server has either answered the Map-Request (if offering proxy service, as described in [LISP-MS]) or has forwarded it to the correct ETR which will answer it. Conceptually, this is similar to the way that a client of the Domain Name System (DNS) follows referrals (DNS responses that contain only NS records) from a series of DNS servers until it finds an answer. Fuller, et al. Expires September 14, 2012 [Page 5] Internet-Draft LISP Delegated Database Tree March 2012 2. Definition of Terms Extended EID (XEID): a LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where [RFC1918] address space is used. See "Using Virtualization and Segmentation with LISP" in [LISP] for more discussion of Instance IDs. XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT Key-ID (provided to allow the definition of multiple databases; currently always zero in this version of DDT, with other values reserved for future use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used as a key index into the database. DDT node: a network infrastructure component responsible for specific XEID-prefix and for delegation of more-specific sub- prefixes to other DDT nodes. DDT client: a network infrastructure component that sends Map- Request messages and implements the iterative following of Map- Referral results. Typically, a DDT client will be a Map-Resolver but it is also possible for an ITR to implement DDT client functionality. DDT Map-Server: a DDT node that also implements Map Server functionality (forwarding Map-Requests and/or returning Map- Replies if offering proxy-mode service) for a subset of its delegated prefixes. DDT Map-Resolver: a network infrastructure element that accepts a Map-Request, adds the XEID to its lookup queue, then queries one or more DDT nodes for the requested EID, following returned referrals until it receives one with the "done" flag. This indicates that the Map-Request has been sent to a Map-Server that will forward it to an ETR that, in turn, will provide a Map-Reply to the original sender. A DDT Map-Resolver maintains both a cache of Map-Referral message results containing RLOCs for DDT nodes responsible for XEID-prefixes of interest (termed the "referral cache") plus a lookup queue of XEIDs that are being resolved through iterative querying of DDT nodes. 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 as documented in Fuller, et al. Expires September 14, 2012 [Page 6] Internet-Draft LISP Delegated Database Tree March 2012 [LISP-MS]. DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to a DDT node. The "DDT-originated" flag is set in the encapsulation header indicating that the DDT node should return Map-Referral messages if the Map-Request EID matches a delegated XEID-prefix known to the DDT node. Section 7.1 describes how DDT Map-Requests are sent. Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node and for which the DDT node may provide further delegations of more-specific sub-prefixes. Map-Referral: a LISP message sent by a DDT node when it receives a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. The Map-Referral message includes a "referral", a set of RLOCs for DDT nodes that have more information about the sub- prefix; a DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs to obtain either an answer or another referral to DDT nodes responsible for a more-specific XEID-prefix. See Section 5 and Section 7.2 for details on the sending and processing of Map-Referral messages. negative Map-Referral: a LISP message sent by a DDT node when it receives a DDT Map-Request for an EID that matches a configured authoritative XEID-prefix but for which no delegation (or registration if the DDT node is also a Map-Server) is configured. For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, and Map-Resolver, please consult the LISP specification [LISP] and the LISP Mapping Service specification [LISP-MS]. Fuller, et al. Expires September 14, 2012 [Page 7] Internet-Draft LISP Delegated Database Tree March 2012 3. EID-prefix tree structure and instance IDs LISP-DDT defines a tree structure that is indexed by a binary encoding of five fields, in order of significance: Key-ID (16 bits), Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 16 bits), and EID-prefix (variable, according to AFI value). The fields are concatenated, with the most significant fields as listed above. The index into this structure is also referred to as an Extended EID-prefix (XEID-prefix). It is important to note that LISP-DDT does not store actual EID-to- RLOC mappings; it is, rather, a distributed index that can be used to find the devices (Map-Servers and their registered EIDs) that can be queried with LISP to obtain those mappings. Changes to EID-to-RLOC mappings are made on the ETRs which define them, not to any DDT node configuration. DDT node configuration changes are only required when branches of the database hierarchy are added, removed, or modified. Fuller, et al. Expires September 14, 2012 [Page 8] Internet-Draft LISP Delegated Database Tree March 2012 4. Configuring XEID-prefix delegation Every DDT node is configured with one or more XEID-prefixes for which it is authoritative along with a list of delegations of XEID-prefixes that are known to other DDT nodes. A DDT node is required to maintain a list of delegations for all sub- prefixes of its authoritative XEID-prefixes but also may list "hints", which are prefixes that it knows about that belong to its parents, to the root, or to any other point in the XEID-prefix hierarchy. A delegation (or hint) consists of an XEID-prefix, a set of RLOCs for DDT nodes that have more detailed knowledge of the XEID-prefix, and acompanying security information. Those RLOCs are returned in Map-Referral messages when the DDT node receives a DDT Map-Request with an xEID that matches a delegation. A DDT Map-Server will also have a set of sub-prefixes for which it accepts ETR mapping registrations and for which it will forward (or answer, if it implements proxy mode) Map- Requests. For details of security infomation in Map-Referrals see Section 9. 4.1. Example DDT node configuration The following is an example of parent and child DDT nodes, where the parent has all of 10.0.0.0/8 and delegates two sub-prefixes, 10.0.0.0/12 and 10.0.16.0/12 to two child DDT nodes. All of these prefixes are within the DDT sub-tree Key-ID=0, IID=223, and AFI=1 (IPv4). lisp ddt authoritative-prefix instance-id 223 10.0.0.0/8 lisp ddt child 192.168.1.100 instance-id 223 eid-prefix 10.0.0.0/12 lisp ddt child 192.168.1.200 instance-id 223 eid-prefix 10.16.0.0/12 This defines delegation of the EID-prefix 10.0.0.0/12 to a DDT Map Server with RLOC 192.168.1.100 and delegation of the EID-prefix 10.16.0.0/12 to a DDT Map-Server with RLOC 192.168.1.200. The child DDT Map-Server for 10.16.0.0/12 is further configured to allow ETRs to register the sub-prefixes 10.18.0.0/16 and 10.17.0.0/16: Fuller, et al. Expires September 14, 2012 [Page 9] Internet-Draft LISP Delegated Database Tree March 2012 lisp ddt authoritative-prefix instance-id 223 eid-prefix 10.16.0.0/12 lisp site site-1 eid-prefix 10.18.0.0/16 instance-id 223 lisp site site-2 eid-prefix 10.17.0.0/16 instance-id 223 4.2. The root DDT node The root DDT node is the logical "top" of the database hierarchy: Key-ID=0, EID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches no configured XEID-prefix will be referred to the root node. The root node in a particular instantiation of LISP-DDT must therefore be configured with delegations for at least all defined IIDs and AFIs. To aid in defining a "sub-root" DDT node that is responsible for all EID-prefixes within multiple IIDs (say, for using LISP to create virtual networks that use overlapping address space), it may be useful to implement configuration language that allows for a range of IIDs to be delegated together. Additional configuration shorthand for delegating of a range of IIDs (and all of the EIDs under them) may also be helpful. Fuller, et al. Expires September 14, 2012 [Page 10] Internet-Draft LISP Delegated Database Tree March 2012 5. DDT node operation - sending referrals When a DDT node receives a DDT Map-Request, it compares the requested XEID against its list of XEID-prefix delegations and its list of authoritative XEID-prefixes and acts as follows: 5.1. Match of a delegated prefix (or sub-prefix) If the requested XEID matches one of the DDT node's delegated prefixes, then a Map-Referral message is returned with the matching more-specific XEID-prefix and the set of RLOCs for the referral target DDT nodes including associated security information (see Section 9 for details on security). Note that a matched delegation does not have to be for a sub-prefix of an authoritative prefix; in addition to being configured to delegate sub-prefixes of an authoritative prefix, a DDT node may also be configured with other XEID-prefixes for which it can provide referrals to DDT nodes anywhere in the database hierarchy. This capability to define "shortcut hints" is never required to be configured but may be a useful heuristic for reducing the number of iterations needed to find an EID, particular for private network deployments. 5.2. Missing delegation from an authoritative prefix If the requested XEID did not match a configured delegation but does match an authoritative XEID-prefix, then the DDT node returns a negative Map-Referral that includes the least-specific XEID-prefix that does not match any of the DDT node's authoritative XEID- prefixes, including associated security information. This indicates that the XEID is not a LISP destination. If the requested XEID did not match either a configured delegation or an authoritative XEID-prefix, then the request is dropped. This should only happen if either a DDT Map-Resolver or DDT Map-Server is misconfigured. Logging an error message may be a good idea to assist in detecting and resolving such configuration problems. Fuller, et al. Expires September 14, 2012 [Page 11] Internet-Draft LISP Delegated Database Tree March 2012 6. DDT Map-Server operation When a DDT Map-Server receives a DDT Map-Request, its operation is similar to that of a DDT node with one exception: if the requested XEID matches a registered XEID-prefix, then the Map-Request is forwarded to one of the destination ETR RLOCs (or the Map-Server sends a Map-Reply, if it is providing proxy service) and a Map- Referral with the MS-ACK action is returned to the sender of the DDT Map-Request. Fuller, et al. Expires September 14, 2012 [Page 12] Internet-Draft LISP Delegated Database Tree March 2012 7. DDT Map-Resolver operation Just as any other Map-Resolver, a DDT Map-Resolver accepts Map- Requests from its clients (typically, ITRs) and ensures that those Map-Requests are forwarded to the correct ETR, which generates Map- Replies. Unlike a Map-Resolver that uses the ALT mapping system [LISP-ALT], however, a DDT Map-Resolver needs to maintain more state as it uses an iterative process of following referrals to find the correct ETR to answer a Map-Request. 7.1. Queuing, Sending, and Retransmitting DDT Map-Requests When a DDT Map-Resolver receives an encapsulated Map-Request, it first performs a longest-match search for the XEID in its referral cache. If nothing is found or if a negative cache entry is found, then the destination is not in the database; a negative Map-Reply is returned and no further processing is done by the DDT Map-Resolver. Next, the DDT Map-Resolver creates a lookup queue entry for the XEID and saves the original Map-Request along with other information, such as the longest XEID-prefix matched so far, needed for tracking progress through the iterative referral process. The Map-Resolver then creates a DDT Map-Request (which is an encapsulated Map-Request with the "DDT-originated" flag set in the message header) for the XEID but without any authentication data that may have been included in the original Map-Request. It sends the DDT Map-Request to one of the RLOCs in the chosen referral cache entry. The referral cache is initially populated with one or more statically-configured entries; additional entries are added when referrals are followed, as described below. A DDT Map-Resolver is not absolutely required to cache referrals but it not doing so will significantly increase latency and cause lookup delays. Note that in normal use on the public Internet, the statically- configured initial referral cache for a DDT Map-Resolver should include a "default" entry with RLOCs for one or more DDT nodes that can reach the DDT root node. If a Map-Resolver does not have such configuration, it will return a Negative Map-Reply if it receives a query for an EID outside the subset of the mapping database known to it. While this may be desirable on private network deployments or during early transition to LISP when few sites are using it, this behavior is not appropriate when LISP is in general use on the Internet. 7.2. Receiving and following referrals After sending a DDT Map-Request, a DDT Map-Resolver can expect one of the following to occur: Fuller, et al. Expires September 14, 2012 [Page 13] Internet-Draft LISP Delegated Database Tree March 2012 o No response. The DDT Map-Resolver retransmits the request, choosing a different RLOC from the referral cache entry if one is available. If the maximum number of retransmissions has occurred, then the lookup queue entry is dequeued and a negative Map-Reply is returned to the original Map-Request sender. o A Map-Referral message. This indicates that the replying DDT node or DDT Map-Server doesn't know the ETRs for the specific XEID but does know another DDT node or DDT Map-Server that has information about a matching XEID-prefix. The Map-Referral message contains a "map-record" with additional information that is used by a DDT Map-Resolver to "follow" the referral. The subsections below describe how a DDT Map-Resolver uses the fields in the Map- Referral message to detemine the next step in processing a lookup queue entry. See Appendix B for a detailed description of all Map-Referral message fields. 7.2.1. Referral Set The set of RLOCs for DDT-nodes that are authoritative for the XEID- prefix returned in the Map-Referral message. A DDT Map-Resolver sends subsequent Map-Requests to one or more of these RLOCs as it "follows" a referral. 7.2.2. Referral list incomplete flag The "Incomplete" flag is set by a DDT Node when it returns a Map- Referral message if the Referral Set is incomplete. A DDT Map- Resolver receiving such a message will need to take appropriate action, specifically not caching the referral. A DDT node must set the "incomplete" flag in the following cases: o The DDT Map-Server would return Map-Referral with the type of either MS-ACK or ms-not-registerd, but it does not have any configuration about other, "peer" Map-Servers for that also authoritative for the matched XEID-prefix. o The DDT node returns a Map-Referral with the action of NOT- AUTHORITATIVE. 7.2.3. Action Types A DDT node sets the "Action" field to indicate to a Map-Resolver what action it should take upon receipt of a Map-Referral message. The defined actions are as follows: Fuller, et al. Expires September 14, 2012 [Page 14] Internet-Draft LISP Delegated Database Tree March 2012 Type 0, NODE-REFERRAL: Follow the referral by saving the prefix in the referral cache and sending a new Map-Request to the first DDT node listed in the Referral Set. A DDT node sends this action code to instruct a DDT Map-Resolver to query a child DDT node. Type 1, MS-REFERRAL: Follow the referral by saving the prefix in the referral cache and sending a new Map-Request to the first DDT Map- Server listed in the Referral Set. A DDT node sends this action code to instruct a DDT Map-Resolver to query a DDT Map-Server which should have one or more ETRs registered for the matched XEID-prefix. Type 2, MS-ACK: If the "incomplete" flag is not set, then the referral process is complete; save the prefix in the referral cache and de-queue the original Map-Request. A DDT Map-Server sends an "MS-ACK" response to a DDT Map-Resolver when it forwards a Map-Resolver-originated Map-Request to an ETR. Type 3, MS-NOT-REGISTERED: This action code indicates that a DDT Map-Server has received a Map-Request for one of its XEID-prefixes but for which it has no ETR registered. If the DDT Map-Resolver has not yet tried all of the DDT Map-Server RLOCs in its referral cache entry, then sends a Map-Request to the next available DDT Map-Server RLOC. If all RLOCs have been tried, then the destination XEID is not registered and is unreachable. The Map- Resolver returns a negative Map-Reply to the original Map-Request sender; this Map-Reply contains the non-registered XEID prefix with TTL value of one minute. It also removes the lookup queue entry. Type 4, DELEGATION-HOLE: Cache the prefix and return a negative Map- Reply to the original Map-Request sender. The negative Map- Request will indicate the least-specific XEID- prefix matching requested XEID for which no delegations exist; it is sent with a TTL value of 15 minutes. Type 5, NOT-AUTHORITATIVE: A DDT node returns this action code if it receives a Map-Request for an XEID-request for which it is not authoritative. This can occur if a cached referral has become invalid due to a change in the database hierarchy. If the a DDT Map-Resolver that receives this action code can determine that it is using old cached information, it may choose to delete that cached information and re-try the original Map-Request, starting from its "root" cache entry. If this action code is received in response to a query that was not to cached referral information, then it indicates a serious misconfiguration in the database; the original Map-Request should be removed, unanswered, from the lookup queue. Fuller, et al. Expires September 14, 2012 [Page 15] Internet-Draft LISP Delegated Database Tree March 2012 7.2.4. Handling referral errors Other states are possible, such as a misconfigured DDT node (acting as a proxy Map-Server, for example) returning a Map-Reply to the DDT Map-Resolver; they should be considered errors and logged as such. It is not clear exactly what else the DDT Map-Resolver should do in such cases; one possibility is to dequeue the lookup queue entry and send a negative Map-Reply to the original Map-Request sender. Alternatively, if a DDT Map-Resolver detects unexpected behavior by a DDT node, it could mark that node as unusable in its referral cache and update the lookup queue entry to try a different DDT node if more than one is listed in the referral cache. 7.2.5. Referral loop detection With any iterative process, there is always the danger of an iteration loop. To prevent this, a DDT Map-Resolver keeps track of the most recent "referral XEID-prefix" in each lookup queue entry. When it receives a Map-Referral message, it performs the following check for looping: o For Action Types NODE-REFERRAL and MS-REFERRAL, the new XEID- prefix must be more-specific than the saved prefix; an exact or less-specific match, indicates a referral loop. o For Action Types MS-ACK, MS-NOT-REGISTERED, or DELEGATION-HOLE, the new XEID-prefix must be an exact or more-specific match of the saved prefix; a less-specific match indicates a referral loop. The exact match is allowed here since these messages indicate that the referral process has completed. Note, though, that the cached RLOCs are NOT updated for an exact match since doing so may lose information needed for preventing loops. If a loop is detected, then the Map-Resolver handles the request as described in Section 7.2.4. Otherwise, the Map-Resolver saves the most rececent referral XEID-prefix in the lookup queue entry when it follows the referral. As an extra measure to prevent referral loops, it is probably also wise to limit the total number of referrals for any request to some reasonable number; the exact value of that number will be determined during experimental deployment of LISP-DDT but is bounded by the maximum length of the XEID. Note that when a Map-Request is originally received and an entry has been added to the lookup queue, the new request has no previous referral XEID-prefix; this means that the first DDT node contacted by a DDT Map-Resolver may provide a referral to anywhere in the DDT Fuller, et al. Expires September 14, 2012 [Page 16] Internet-Draft LISP Delegated Database Tree March 2012 hierarchy. This, in turn, allows a DDT Map-Resolver to use essentially any DDT node RLOCs for its initial cache entries and depend on the initial referral to provide a good starting point for Map-Requests; there is no need to configure the same set of root DDT nodes in all DDT Map-Resolvers. Fuller, et al. Expires September 14, 2012 [Page 17] Internet-Draft LISP Delegated Database Tree March 2012 8. Example message flow The following describes the message flows among an ITR, a DDT Map Resolver, a number of DDT nodes, a DDT Map-Server, and an ETR. It assumes no security associations between the DDT nodes but does show how [LISP-SEC] can be used between the ITR, Map Resolver, Map-Server, and ETR. 8.1. ITR sends a Map-Request to a DDT Map-Resolver The first step in using LISP-DDT is the same as for any other Map- Request using the Map-Server interface: an ITR sends an encapsulated Map-Request to one of its configured Map-Resolvers, in this case a DDT Map-Resolver. The outer header source IP address is the ITR and the outer header destination IP address is the DDT Map Resolver. If [LISP-SEC] is in use, then LISP-SEC ECM Authentication Data field is included. 8.2. DDT Map-Resolver receives and processes Map-Request The DDT Map-Resolver receives and processes the encapsulated Map- Request by stripping the encapsulation header and creating a lookup queue entry for the XEID, saving the resulting, non-encapsulated Map- Request for later retransmission and re-use during the referral process. If [LISP-SEC] information was included in the original, encapsulated Map-Request then it is also saved in the lookup queue entry for later use. The lookup queue entry will be dequeued when the DDT Map-Resolver is finished with the request (see Section 8.8). Note that if a lookup queue entry already exists for the destination XEID and the requesting ITR (which could happen if an ITR has retransmitted a Map-Request), the Map-Request is replaced to ensure that the ITR-generated nonce and any ECM Authentication Data field are updated. 8.3. DDT Map-Resolver searches referral cache for XEID Next, the DDT Map-Resolver searches its referral cache for the XEID. If none is found or if a negative cache entry is found, then the XEID does not exist in the database; a negative Map-Reply is returned to the original sender and the lookup queue entry is dequeued. If the referral cache entry found is for a DDT Map-Server, then the DDT Map-Resolver has found the appropriate terminal node in the DDT hierarchy. It finishes processing the lookup queue entry as described in Section 8.8. At this point, the referral cache entry must be for a DDT node that Fuller, et al. Expires September 14, 2012 [Page 18] Internet-Draft LISP Delegated Database Tree March 2012 can provide more-specific information for the requested XEID so a DDT Map-Request is created and sent (see below). 8.4. DDT Map-Resolver creates and sends DDT Map-Request To follow a referral and query the next DDT node, the DDT Map Resolver creates a new DDT Map-Request, an encapsulated Map-Request using one of the RLOCs of the target DDT node as the outer header destination IP address and itself as the outer header source IP address. The "DDT-originated" flag is set in the encapsulation header to inform the target DDT node that it should return referrals. The original Map-Request LISP-SEC information, if any was saved in the lookup queue entry, is NOT included. The original Map-Request destination XEID is used in the new Map-Request while the source is one of the DDT Map-Resolver's RLOCs. The new "DDT Map-Request" is transmitted to the destination DDT node. If no response is received within a timeout, it is re-transmitted, preferably using a different destination DDT node RLOC. If the maximum number of retransmissions is exceeded, the request is dequeued and a negative Map-Reply is returned to the ITR that sent the original Map-Request. 8.5. DDT node receives and processes DDT Map-Request The destination DDT node searches its configured delegations and authoritative prefixes for the XEID in the received encapsulated Map- Request. If no match is found, then the DDT Map-Request is silently discarded and, optionally, an error is logged. If a delegation is found, the DDT node sends a Map-Referral message back to the DDT Map-Resolver with the matched XEID-prefix and the set of RLOCs for DDT nodes that can be used to resolve XEIDs within that prefix. If no matching delegation was found and the XEID matches one of the DDT node's authoritative prefixes, then the destination is not a LISP XEID (or a configuration error has occurred); the DDT node returns a negative Map-Referral message to the DDT Map-Resolver as described in Section 5.2. 8.6. DDT Map-Resolver processes Map-Referral When the DDT Map-Resolver receives a Map-Referral from a DDT-node, it first verifies that it has a corresponding lookup queue entry; if none can be found, then the Map-Referral is silently ignored, with optional error logging. Fuller, et al. Expires September 14, 2012 [Page 19] Internet-Draft LISP Delegated Database Tree March 2012 If the received Map-Referral was negative, then the destination XEID is not in the database; a negative Map-Reply is returned to the original Map-Request sender, a negative referral cache entry is created for the returned XEID-prefix (with TTL from the Map-Referral message), and the lookup queue entry is dequeued. For a non-negative Map-Referral, the lookup queue entry is updated with the new referral XEID-prefix and new DDT-node RLOCs. At this point, it also checks to make sure that a referral loop has not occurred (see Section 7.2.5). To speed processing of future Map-Requests for the same XEID-prefix, the DDT Map-Resolver adds a new entry (or updates an existing, matching entry) in its referral cache for the XEID-prefix, RLOC set, and TTL value in the Map-Referral message. Finally, processing continues to Section 8.4 to query the new destination DDT-node. 8.7. DDT Map-Server receives Map-Request At this point, the DDT Map-Resolver has found the DDT Map-Server responsible for the destination XEID-prefix and has sent its Map- Request there. The DDT Map-Server receives the DDT Map-Request, strips the encapsulation header, and searches for the destination XEID in its set of configured XEID-prefixes. If the XEID is found and an ETR has registered for it, then DDT Map-Server returns a Map- Referral to the DDT Map-Resolver indicating (by setting the MS-ACK action) that it has found the terminal DDT node. The Map-Request is forwarded to one of the registered ETRs for further processing (Section 8.10). 8.8. DDT Map-Resolver finished At this point, the DDT Map-Resolver has finished the referral iteration process. If security processing was requested, the DDT Map Resolver now re-sends the DDT Map-Request to the DDT Map-Server with the LISP-SEC information included in the encapsulation header. The DDT Map-Resolver dequeues the lookup queue entry for the XEID and cleans-up any other saved state. 8.9. DDT Map-Server receives LISP-SEC-enabled Map-Request When the DDT Map-Server receives the re-sent DDT Map-Request, with LISP-SEC information included, it decrypts the LISP-SEC information, performs normal LISP-SEC processing, and forwards the resulting Map- Request to the target ETR. Fuller, et al. Expires September 14, 2012 [Page 20] Internet-Draft LISP Delegated Database Tree March 2012 8.10. ETR sends Map-Reply to ITR The ETR receives a Map-Request as documented in [LISP], performs any necessary processing of security information, as documented in [LISP-SEC], and sends a Map-Reply to the ITR that sent the original Map-Request. Fuller, et al. Expires September 14, 2012 [Page 21] Internet-Draft LISP Delegated Database Tree March 2012 9. Securing the database and message exchanges This section specifies the DDT security architecture that provides data origin authentication, data integrity protection, and XEID prefix delegation. Global XEID prefix authorization is out of the scope of this document. Each DDT node is configured with one or more public/private key pair(s) that are used to digitally sign referral records for XEID- prefix(es) that the DDT node is authoritative for. In other words, each public/private key pair is associated with the combination of a DDT node and the XEID-prefix that it is authoritative for. Every DDT node is also configured with the public keys of its children DDT nodes. By including public keys of target child DDT nodes in the Map-Referral records, and signing each record with the DDT node's private key, a DDT node can securely delegate sub-prefixes of its authoritative XEID-prefixes to its children DDT nodes. Map-Resolvers are configured with one or more trusted public keys referred to as trust anchors. Trust anchors are used to authenticate the DDT security infrastructure. Map-Resolvers can discover a DDT node's public key either by having it configured as a trust anchor, or by obtaining it from the node's parent as part of a signed Map- Referral. When a public key is obtained from a node's parent, it is considered trusted if it is signed by a trust anchor, or if it is signed by a key that was previously trusted. Typically, in a Map- Resolver, the root DDT node public keys should be configured as trust anchors. Once a Map-Resolver authenticates a public key it locally caches the key along with the associated DDT node RLOC and XEID- prefix for future use. 9.1. XEID-prefix Delegation In order to delegate XEID sub-prefixes to its children, a parent DDT node signs its Map-Referrals. Every signed Map-Referral also includes the public keys associated with each child DDT node. Such a signature indicates that the parent node is delegating the specified XEID -prefix to a given child DDT node. The signature is also authenticating the public keys associated with the children nodes, and authorizing them to be used by the children DDT nodes to provide origin authentication and integrity protection for further delegations and mapping information of the XEID-prefix allocated to the DDT node. As a result, for a given XEID-prefix, a Map-Resolver can form an authentication chain from a configured trust anchor (typically the root DDT node) to the leaf nodes (Map-Servers). Map-Resolvers leverage this authentication chain to verify the Map-Referral Fuller, et al. Expires September 14, 2012 [Page 22] Internet-Draft LISP Delegated Database Tree March 2012 signatures while walking the DDT tree until they reach a Map-Server authoritative for the given XEID-prefix. 9.2. DDT node operation Upon receiving a Map-Request, the DDT node responds with a Map- Referral as specified in Section 5. For every record present in the Map-Referral, the DDT node also includes the public keys associated with the record's XEID-prefix and the RLOCs of the children DDT nodes. Each record contained in the Map-Referral is signed using the DDT node's private key. 9.2.1. DDT public key revocation The node that owns a public key can also revoke that public key. For instance if a parent node advertises a public key for one of its child DDT nodes, the child DDT node can at a later time revoke that key. Since DDT nodes do not keep track of the Map-Resolvers that query them, revocation is done in a pull model, where the Map- Resolver is informed of the revocation of a key only when it queries the node that owns that key. If the parent DDT is configured to advertise this key, the parent node must also be signaled to remove the key from the records it advertises for the child DDT node; this is necessary to avoid further distribution of the revoked key. To securely revoke a key, the DDT node creates a new Record for the associated XEID-prefix and locator, including the revoked key with the R bit set. The DDT node must also include a signature in the Record that covers this record; this is computed using the private key corresponding to the key being revoked. Such a record is termed a "revocation record". By including this record in its Map- Referrals, the DDT node informs querying Map-Resolvers about the revoked key. A digital signature computed with a revoked key can only be used to authenticate the revocation, and should not be used to validate any data. To prevent a compromised key from revoking other valid keys, a given key can only be used to sign a revocation for that specific key; it cannot be used to revoke other keys. This prevents the use of a compromised key to revoke other valid keys as described in [RFC5011]. A revocation record must be advertised for a period of time equal to or greater than the TTL value of the Record that initially advertisied the key, starting from the time that the advertisement of the key was stopped by removal from the parent DDT node. 9.3. Map-Server operation Similar to a DDT node, a Map-Server is configured with one (or more) public/private key pairs that it must use to sign Map-Referrals. Fuller, et al. Expires September 14, 2012 [Page 23] Internet-Draft LISP Delegated Database Tree March 2012 However unlike DDT nodes, Map-Servers do not delegate prefixes and as a result they do not need to include keys in the Map-Referrals they generate. 9.4. Map-Resolver operation Upon receiving a Map-Referral, the Map-Resolver must first verify the signature(s) by using a trust anchor, or a previously authenticated public key, associated with the DDT node sending the Map-Referral. If multiple authenticated keys are associated with the DDT node sending this Map-Referral, the Key Tag field of the signature can be used to select the right public key for verifying the signature. If the key tag matches more than one key associated with that DDT node, the Map-Resolver must try verifying the signature with all matching keys. For every matching key that is found the Map-Resolver must also verify that the key is authoritative for the XEID-prefix in the Map-Referral record. If such a key is found, the Map-Resolver must use it to verify the associated signature in the record. If no matching key is found, or if none of the matching keys is authoritative for the XEID-prefix in the Map-Referral record, or if such a key is found but the signature is not valid the Map-Referral record is considered corrupted and must be discarded. This may be due to expired keys. The Map-Resolver can try other siblings of this node if there is an alternative node authoritative for the same prefix. If not, the Map-Resolver can query the DDT node's parent to retrieve a valid key. It is good practice to use a counter or timer to avoid repeating this process if the resolver cannot verify the signature after several trials. Once the signature is verified, the Map-Resolver has verified the XEID-prefix delegation in the Map-Referral, and authenticated the public keys of the children DDT nodes. The Map-Resolver must add these keys to the authenticated keys associated with each child DDT node and XEID-prefix. These keys are considered valid for the duration specified in the record's TTL field. Fuller, et al. Expires September 14, 2012 [Page 24] Internet-Draft LISP Delegated Database Tree March 2012 10. Open Issues and Considerations There are a number of issues with the organization of the mapping database that need further investigation. Among these are: o Unlike in [LISP-ALT], DDT does not currently define a mechanism for propagating ETR-to-Map-Server registration state. This requires DDT Map-Servers to suppress returning negative Map-Reply messages for defined but unregistered XEID-prefixes to avoid loss of connectivity during partial ETR registration failures. Suppressing these messages may cause a delay for an ITR obtaining a mapping entry when such a failure is occurring. o Defining an interface to implement interconnection and/or interoperability with other mapping databases, such as LISP+ALT. o Additional key structures for use with LISP-DDT, such as to support additional EID formats as defined in [LCAF]. o Authentication of delegations between DDT nodes. o Possibility of a new, more general format for the Map-Referral messages to facilitate the use of LISP-DDT with additional Key-ID/ IID/EID combinations. Currently-defined packet formats should be considered to be preliminary and provisional until this issue has received greater attention. o Management of the DDT Map-Resolver referral cache, in particular, detecting and removing outdated entries. The authors expect that experimentation on the LISP pilot network will help answer open questions surrounding these and other issues. Fuller, et al. Expires September 14, 2012 [Page 25] Internet-Draft LISP Delegated Database Tree March 2012 11. IANA Considerations This document makes no request of the IANA. Fuller, et al. Expires September 14, 2012 [Page 26] Internet-Draft LISP Delegated Database Tree March 2012 12. Security Considerations See Section 9 for a detailed description of protocol mechanisms intended to secure the database. Open security issues include: xxx Fuller, et al. Expires September 14, 2012 [Page 27] Internet-Draft LISP Delegated Database Tree March 2012 13. References 13.1. Normative References [LCAF] Farinacci, D. and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-06.txt (work in progress), October 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. [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface", draft-ietf-lisp-ms-16.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. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. 13.2. Informative References [LISP-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-SEC] Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. Bonaventure, "LISP-Security", draft-ietf-lisp-sec-01.txt (work in progress), January 2012. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. Fuller, et al. Expires September 14, 2012 [Page 28] Internet-Draft LISP Delegated Database Tree March 2012 Appendix A. Acknowledgments The authors with to express their thanks to Damien Saucez, Lorand Jakab, and Olivier Bonaventure for work on LISP-TREE and LISP iterable mappings that inspired the hierarchical database structure and lookup iteration approach described in this document. Special thanks also go to Amit Jain, Isidor Kouvelas, Jesper Skriver, Andrew Partan, and Noel Chiappa, all of whom have participated in (and put up with) seemingly endless hours of discussion of LISP mapping database ideas and issues. Fuller, et al. Expires September 14, 2012 [Page 29] Internet-Draft LISP Delegated Database Tree March 2012 Appendix B. Map-Referral Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=6 | Reserved | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Referral Count| EID mask-len | ACT |A|I| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c |SigCnt | Map Version Number | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix ... | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |R| Loc/LCAF-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator ... | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACT: The "action" field of the mapping record in a Map-Referral message encodes 6 action types. The values for the action types are: Type 0, NODE-REFERRAL: Sent by a DDT node with a child delegation which is authoritative for the EID. Type 1, MS-REFERRAL: Sent by a DDT node that has information about Map-Server(s) for the EID but it is not one of the Map-Servers listed, i.e. the DDT-Node sending the referral is not a Map- Server. Type 2, MS-ACK: Sent by a DDT Map-Server that has one or more ETR registered for the EID. Type 3, MS-NOT-REGISTERED: Sent by a DDT Map-Server that is configured for the EID-prefix but for which no ETRs are registered. Fuller, et al. Expires September 14, 2012 [Page 30] Internet-Draft LISP Delegated Database Tree March 2012 Type 4, DELEGATION-HOLE: Sent by an intermediate DDT node with authoritative configuration covering the requested EID but without any child delegation for the EID. Also sent by a DDT Map-Server with authoritative configuration covering the requested EID but for which no specific site ETR is configured. Type 5, NOT-AUTHORITATIVE: Sent by a DDT node that does not have authoritative configuration for the requested EID. The EID-prefix returned MUST be the original requested EID and the TTL MUST be set to 0. However, if such a DDT node has a child delegation covering the requested EID, it may choose to return NODE-REFERRAL or MS-REFERRAL as appropriate. A DDT Map-Server with site information may choose to return of type MS-ACK or MS-NOT- REGISTERED as appropriate. Incomplete: The "I" bit indicates that a DDT node's referral-set of locators is incomplete and the receiver of this message should not cache the referral. A DDT sets the "incomplete" flag, the TTL, and the Action Type field as follows: ------------------------------------------------------------------- Type (Action field) Incomplete Referral-set TTL values ------------------------------------------------------------------- 0 NODE-REFERRAL NO YES 1440 1 MS-REFERRAL NO YES 1440 2 MS-ACK * * 1440 3 MS-NOT-REGISTERED * * 1 4 DELEGATION-HOLE NO NO 15 5 NOT-AUTHORITATIVE YES NO 0 ------------------------------------------------------------------- *: The "Incomplete" flag setting on Map-Server originated referral of MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map- Server has the full peer Map-Server configuration for the same prefix and has encoded the information in the mapping record. Incomplete bit is not set when the Map-Server has encoded the information, which means the referral-set includes all the RLOCs of all Map-Servers that serve the prefix. It is set when the Map- Server has not encoded the Map-Server set information. SigCnt: Indicates the number of signatures (sig section) present in the Record. If SigCnt is larger than 0, the signature information Fuller, et al. Expires September 14, 2012 [Page 31] Internet-Draft LISP Delegated Database Tree March 2012 captured in a sig section as described in Appendix B.1 will be appended to the end of the record. The number of sig sections at the end of the Record must match the SigCnt. Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the record. If this is a LCAF AFI, the contents of the LCAF depend on the Type field of the LCAF. Security material are stored in LCAF Type 11. DDT nodes and Map-Servers can use this LCAF Type to include public keys associated with their Child DDT nodes for a XEID-prefix referral record. LCAF types and formats are defined in [LCAF]. All the field descriptions are equivalent to those in the Map-Reply message, as defined in [LISP]. Note, though, that the set of RLOCs correspond to the DDT node to be queried as a result of the referral not the RLOCs for an actual EID-to-RLOC mapping. B.1. SIG section If SigCnt field in the Map-Referral is not 0, the signature information is included at the end of captured in a sig section as described below. SigCnt counts the number of sig sections that appear at the end of the Record. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /| Original Record TTL | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Signature Expiration | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s | Signature Inception | i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ g | Key Tag | Sig Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Sig-Algorithm | Reserved | Reserved | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ~ Signature ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Original Record TTL: The original Record TTL for this record that is covered by the signature. Record TTL is in minutes. Key Tag: An identifier to specify which key is used for this signature if more than one valid key exists for the signing DDT node. Sig Length: The length of the Signature field. Sig-Algorithm: The identifier of the cryptographic algorithm used for the signature. Default value is RSA-SHA1. Fuller, et al. Expires September 14, 2012 [Page 32] Internet-Draft LISP Delegated Database Tree March 2012 Reserved: This field must be set to 0 on transmit and must be ignored on receipt. Signature Expiration and Inception: Specify the validity period for the signature. Each specify a date and time in the form of a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. Signature: Contains the cryptographic signature that covers the entire record. The Record TTL and the sig fields are set to zero for the purpose of computing the Signature Fuller, et al. Expires September 14, 2012 [Page 33] Internet-Draft LISP Delegated Database Tree March 2012 Appendix C. Encapsulated Control Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = 4342 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=8 |S|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = yyyy | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "D" is the "DDT-originated" flag and is set by a DDT client to indicate that the receiver can and should return Map-Referral messages as appropriate. Fuller, et al. Expires September 14, 2012 [Page 34] Internet-Draft LISP Delegated Database Tree March 2012 Authors' Addresses Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Darrel Lewis cisco Systems Tasman Drive San Jose, CA 95134 USA Email: darlewis@cisco.com Vina Eermagan cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vermagan@cisco.com Fuller, et al. Expires September 14, 2012 [Page 35]