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]