Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
draft-saucez-lisp-8111bis-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Damien Saucez , Luigi Iannone | ||
| Last updated | 2024-11-05 | ||
| Replaces | draft-saucez-8111bis | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-saucez-lisp-8111bis-00
LISP Working Group D. Saucez, Ed.
Internet-Draft Inria
Obsoletes: 8111 (if approved) L. Iannone, Ed.
Intended status: Standards Track Huawei
Expires: 9 May 2025 5 November 2024
Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
draft-saucez-lisp-8111bis-00
Abstract
This document describes the Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT), a hierarchical distributed database that
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.
This document obsoletes RFC 8111.
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 https://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 9 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Saucez & Iannone Expires 9 May 2025 [Page 1]
Internet-Draft LISP-DDT November 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . 5
4. Database Organization . . . . . . . . . . . . . . . . . . . . 7
4.1. XEID-Prefixes . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Structure of the DDT Database . . . . . . . . . . . . . . 8
4.3. Configuring Prefix Delegation . . . . . . . . . . . . . . 8
4.3.1. The Root DDT Node . . . . . . . . . . . . . . . . . . 9
5. The Map-Referral Message . . . . . . . . . . . . . . . . . . 9
5.1. Action Codes . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Referral Set . . . . . . . . . . . . . . . . . . . . . . 10
5.3. "Incomplete" Flag . . . . . . . . . . . . . . . . . . . . 10
5.4. Map-Referral Message Format . . . . . . . . . . . . . . . 11
5.4.1. Signature Section . . . . . . . . . . . . . . . . . . 13
6. DDT Network Elements and Their Operation . . . . . . . . . . 14
6.1. DDT Node . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Matching of a Delegated Prefix (or Sub-prefix) . . . 15
6.1.2. Missing Delegation from an Authoritative Prefix . . . 16
6.2. DDT Map-Server . . . . . . . . . . . . . . . . . . . . . 16
6.3. DDT Client . . . . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Queuing and Sending DDT Map-Requests . . . . . . . . 17
6.3.2. Receiving and Following Referrals . . . . . . . . . . 18
6.3.3. Handling Referral Errors . . . . . . . . . . . . . . 19
6.3.4. Referral Loop Detection . . . . . . . . . . . . . . . 20
7. Pseudo-code and Decision Tree Diagrams . . . . . . . . . . . 20
7.1. Map-Resolver Processing of ITR Map-Request . . . . . . . 21
7.1.1. Pseudo-code Summary . . . . . . . . . . . . . . . . . 21
7.1.2. Decision Tree Diagram . . . . . . . . . . . . . . . . 21
7.2. Map-Resolver Processing of Map-Referral Message . . . . . 22
7.2.1. Pseudo-code Summary . . . . . . . . . . . . . . . . . 22
7.2.2. Decision Tree Diagram . . . . . . . . . . . . . . . . 24
7.3. DDT Node Processing of DDT Map-Request Message . . . . . 25
7.3.1. Pseudo-code Summary . . . . . . . . . . . . . . . . . 25
7.3.2. Decision Tree Diagram . . . . . . . . . . . . . . . . 27
8. Example Topology and Request/Referral Following . . . . . . . 28
8.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 30
8.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 31
Saucez & Iannone Expires 9 May 2025 [Page 2]
Internet-Draft LISP-DDT November 2024
8.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 32
8.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 33
8.5. Lookup of 2001:db8:0500::1/128 (Nonexistent EID) . . . . 33
9. Securing the Database and Message Exchanges . . . . . . . . . 34
9.1. XEID-Prefix Delegation . . . . . . . . . . . . . . . . . 35
9.2. DDT Node Operation . . . . . . . . . . . . . . . . . . . 35
9.2.1. DDT Public Key Revocation . . . . . . . . . . . . . . 35
9.3. Map-Server Operation . . . . . . . . . . . . . . . . . . 36
9.4. Map-Resolver Operation . . . . . . . . . . . . . . . . . 36
10. Deployment Experience . . . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Normative References . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . 38
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
The Locator/ID Separation Protocol (LISP) [RFC9300] specifies an
architecture and mechanism for replacing the addresses currently used
by IP with two separate namespaces:
* Endpoint Identifiers (EIDs), used end to end for terminating
transport-layer associations, and
* Routing Locators (RLOCs), which are bound to topological locations
and are used for routing and forwarding.
[RFC9301] specifies an interface between a database storing EID-to-
RLOC mappings and LISP devices that need this information to forward
packets. The internal organization of such a database is beyond the
scope of [RFC9301]. Multiple architectures of the database have been
proposed, each having its advantages and disadvantages (see, for
example, [RFC6836] and [RFC6837]).
This document specifies an architecture for a distributed database of
LISP EID-to-RLOC mappings, with an emphasis on high scalability. The
LISP Delegated Database Tree (LISP-DDT) is a hierarchical distributed
database that 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 that needs to locate a given mapping will
follow a path through the tree-structured database and will contact,
one after another, the nodes along that path until it reaches the
leaf node(s) authoritative for the mapping it is seeking.
Saucez & Iannone Expires 9 May 2025 [Page 3]
Internet-Draft LISP-DDT November 2024
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:
* Database-ID (DBID) (16 bits),
* Instance Identifier (IID) (32 bits),
* Address Family Identifier (AFI) (16 bits), and
* EID-prefix (variable, according to the AFI value).
The resulting concatenation of these fields is termed an "Extended
EID-prefix", or XEID-prefix.
LISP-DDT defines a new device type, the "DDT Node", that is
configured as authoritative for one or more XEID-prefixes. It is
also 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 DDT Map-Server (MS) to which an Egress Tunnel Router (ETR) has
registered that sub-prefix or points to another DDT Node in the
database tree that further delegates the sub-prefix. See [RFC9301]
for a description of the functionality of the 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 the Map-Referral LISP message type, 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
Section 5 for the definition of the Map-Referral message.
To find an EID-to-RLOC mapping, a LISP-DDT Client, usually a DDT Map-
Resolver, starts by sending an Encapsulated Map-Request to a pre-
configured DDT Node RLOC. The DDT Node responds with a Map-Referral
message indicating that either (1) it will find the requested mapping
to complete processing of the request or (2) the DDT Client should
contact another DDT Node that has more-specific information; in the
latter case, the DDT Node then sends a new Encapsulated Map-Request
to the next DDT Node and the process repeats in an iterative manner.
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 .
Saucez & Iannone Expires 9 May 2025 [Page 4]
Internet-Draft LISP-DDT November 2024
This document obsoletes [RFC8111].
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definitions of Terms
Extended EID (XEID): a LISP EID extended with data uniquely
identifying the address space to which it belongs (LISP IID,
address family, etc.). See Section 4.1 for a detailed description
of XEID data.
Extended EID-prefix (XEID-prefix): a LISP EID-prefix prepended with
XEID data. An XEID-prefix is used as a key index into the DDT
database. XEID-prefixes are used to describe database
organization and are not seen as a single entity in protocol
messages, though messages contain individual fields constituting
XEID-prefixes.
DDT Node: a network infrastructure component responsible for
specific XEID-prefix(es) and for the delegation of more-specific
sub-prefixes to other DDT Nodes.
DDT Client: a network infrastructure component that sends DDT Map-
Request messages and implements the iterative following of Map-
Referral results. Typically, a DDT Client will be a Map-Resolver
(as defined by [RFC9301]), but it is also possible for an Ingress
Tunnel Router (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 a proxy Map-Reply service) for a subset of its
delegated prefixes. Map-Server functions, including proxying Map-
Replies, are described in [RFC9301].
DDT Map-Server peers: a list of all DDT Map-Servers performing Map-
Server functionality for the same prefix. If peers are configured
on a DDT Map-Server, then the latter will provide complete
information about the prefix in its Map-Replies; otherwise, the
Map-Server will mark the returned reply as potentially incomplete.
DDT Map-Resolver: a network infrastructure element that implements
Saucez & Iannone Expires 9 May 2025 [Page 5]
Internet-Draft LISP-DDT November 2024
both DDT Client functionality and Map-Resolver functionality as
defined by [RFC9301]. A DDT Map-Resolver accepts Map-Requests
from ITRs, sends DDT Map-Requests to DDT Nodes, and implements the
iterative following of Map-Referrals. Note that Map-Resolvers do
not respond to clients that sent Map-Requests; they only ensure
that the Map-Request has been forwarded to a LISP device (ETR or
proxy Map-Server) that will provide an authoritative response to
the original requester. A DDT Map-Resolver will typically
maintain a cache (termed the "XXX define term?? referral cache")
of previously received Map-Referral message results containing
RLOCs for DDT Nodes responsible for XEID-prefixes of interest.
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 6.3.1 describes how DDT Map-
Requests are sent. [RFC9301] defines the position of the "DDT-
originated" flag in the Encapsulated Control Message header.
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 in response to a DDT
Map-Request for an XEID that matches a configured XEID-prefix
delegation. A non-Negative Map-Referral includes a "referral"
consisting in set of RLOCs for DDT Nodes that have information
about the more-specific XEID-prefix covering the requested XEID.
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 an XEID-prefix that
is even more specific. See Section 6.1 and Section 6.3 for
details on the sending and processing of Map-Referral messages.
Negative Map-Referral: a reply from an authoritative DDT Node that
there is no mapping for the requested XEID. A Negative Map-
Referral is a Map-Referral sent in response to a DDT Map-Request
that matches an authoritative XEID-prefix but for which there is
no delegation configured (or no ETR registration, if sent by a DDT
Map-Server).
Pending Requests List: the set of outstanding requests for which a
DDT Map-Resolver has received Encapsulated Map-Requests from its
clients seeking EID-to-RLOC mapping for an XEID. Each entry in
the list contains additional state needed by the referral-
following process, including the XEID, requester(s) of the XEID
(typically one or more ITRs), saved information about the last
Saucez & Iannone Expires 9 May 2025 [Page 6]
Internet-Draft LISP-DDT November 2024
referral received and followed (matching XEID-prefix, action code,
RLOC set, index of the last RLOC queried in the RLOC set), and any
LISP-Security (LISP-SEC) information [RFC9303] that was included
in the DDT Client Map-Request. An entry in the list may be
interchangeably termed a "pending requests list entry" or simply a
"pending request".
For definitions of other terms, notably Map-Request, Encapsulated
Map-Request,Map-Reply, ITR, ETR, Map-Server, and Map-Resolver, please
consult the LISP specification [RFC9300] and the LISP Control Plane
specification [RFC9301].
4. Database Organization
4.1. XEID-Prefixes
A DDT database is indexed by Extended EID-prefixes (XEID-prefixes).
An XEID-prefix is a LISP EID-prefix that includes additional data to
uniquely identify the address space associated with the prefix. An
XEID-prefix is composed of four binary-encoded fields, ordered by
significance:
* DBID (16 bits),
* Instance ID (32 bits),
* AFI (16 bits),
* and EID-prefix (variable, according to the AFI value).
* DBID (16 bits),
* Padding (8 bits),
* Instance ID (24 bits),
* AFI (16 bits),
* and EID-prefix (variable, according to the AFI value).
The fields are concatenated, with the most significant fields as
listed above .
The DBID is the LISP-DDT Database-ID, a 16-bit field provided to
allow the definition of multiple databases. Implementations that are
compliant with this document must always set this field to 0. Other
values of the DBID are reserved for future use.
Saucez & Iannone Expires 9 May 2025 [Page 7]
Internet-Draft LISP-DDT November 2024
The Instance ID (IID), defined in [RFC9300], is a 24-bit value
describing the context of the EID-prefix See Section 8 of [RFC9300]
for more discussion of Instance IDs. In this specification the
Instance ID is extended on a 32-bit field by prepending 8 bits. The
prepended bits MUST be set to zero.
The AFI is a 16-bit value defining the syntax of the EID-prefix. AFI
values are assigned by IANA [AFI].
4.2. Structure of the DDT Database
The LISP-DDT database for each DDT Node is organized as a tree
structure that is indexed by XEID-prefixes . Leaves of the database
tree describe the delegation of authority between DDT Nodes (see
Section 4.3 for details regarding delegation and information kept in
the database entries).
DDT Map-Requests sent by the DDT Client to DDT Nodes always contain
specific values for the DBID, IID, and AFI; unspecified values or
ranges of values are never used for any of these fields. Thus, an
XEID-prefix used as a key for searches in the database tree will have
a length of at least 64 bits .
A DDT Node may, for example, be authoritative for a consecutive range
of 3-tuples (DBID, IID, AFI) and all associated EID-prefixes, or only
for a specific EID-prefix of a single 3-tuple. Thus, XEID-prefixes/
keys of the database tree leaves may have lengths less than, equal
to, or more than 64 bits.
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 (ETRs that registered their EIDs with DDT Map-
Servers) that can be queried with LISP to obtain those mappings.
Changes to EID-to-RLOC mappings are made on the ETRs that 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.
4.3. Configuring 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 to other DDT Nodes. A DDT Node is required to maintain a
list of delegations for all sub-prefixes of its authoritative XEID-
prefixes; it 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
Saucez & Iannone Expires 9 May 2025 [Page 8]
Internet-Draft LISP-DDT November 2024
knowledge of the XEID-prefix, and accompanying security information
(for details regarding security information exchange and its use, see
Section 9). 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 reply, if it provides a proxy Map-Reply service) Map-
Requests.
One or more XEID-prefixes for which a DDT Node is authoritative, and
the delegation of authority for sub-prefixes, are provided as part of
the configuration of the DDT Node.
4.3.1. The Root DDT Node
The root DDT Node is the logical "top" of the distributed database
hierarchy. It is authoritative for all XEID-prefixes, namely, for
all valid 3-tuples (DBID, IID, AFI) and their EID-prefixes. A DDT
Map-Request that matches no configured XEID-prefix will be referred
to the root node (see Section 7 for a formal description of
conditions where a DDT Map-Request is forwarded to the root node).
The root node in a particular instantiation of LISP-DDT therefore
MUST be configured, at a minimum, with delegations for all defined
Instance IDs and AFIs .
5. The Map-Referral Message
This specification defines a new LISP message called the Map-Referral
message. A Map-Referral message is sent by a DDT Node to a DDT
Client in response to a DDT Map-Request message. See Section 5.4 for
a detailed layout of the Map-Referral message fields.
The message consists of an action code along with delegation
information about the XEID-prefix that matches the requested XEID.
5.1. Action Codes
The action codes are as follows:
NODE-REFERRAL (0): indicates that the replying DDT Node has
delegated an XEID-prefix that matches the requested XEID to one or
more other DDT Nodes. The Map-Referral message contains a "map-
record" with additional information, most significantly, the set
of RLOCs to which the prefix has been delegated, which is used by
a DDT Client to "follow" the referral.
MS-REFERRAL (1): indicates that the replying DDT Node has delegated
Saucez & Iannone Expires 9 May 2025 [Page 9]
Internet-Draft LISP-DDT November 2024
an XEID-prefix that matches the requested XEID to one or more DDT
Map-Servers. It contains the same additional information as a
NODE-REFERRAL, but is handled slightly differently by the
receiving DDT Client (see Section 6.3.2).
MS-ACK (2): indicates that the replying DDT Map-Server received a
DDT Map-Request that matches an authoritative XEID-prefix for
which it has one or more registered ETRs. This means that the
request has been forwarded to one of those ETRs to provide an
answer to the querying ITR.
MS-NOT-REGISTERED (3): indicates that the replying DDT Map-Server
received a Map-Request for one of its configured XEID-prefixes
that has no ETRs registered.
DELEGATION-HOLE (4): indicates that the requested XEID matches a
non-delegated sub-prefix of the XEID space. This is a non-LISP
"hole", which has not been delegated to any DDT Map-Server or ETR.
See Section 6.1.2 for details. Also sent by a DDT Map-Server with
authoritative configuration covering the requested EID but for
which no specific site ETR is configured.
NOT-AUTHORITATIVE (5): indicates that the replying DDT Node received
a Map-Request for an XEID for which it is not authoritative and
has no configured matching hint referrals. This can occur if a
cached referral has become invalid due to a change in the database
hierarchy. However, if such a DDT Node has a "hint" delegation
covering the requested EID, it MAY choose to return NODE-REFERRAL
or MS-REFERRAL as appropriate. When returning action code NOT-
AUTHORITATIVE, the DDT Node MUST provide the EID-prefix received
in the request and the TTL MUST be set to 0.
5.2. Referral Set
For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a
DDT Node MUST include in the Map-Referral message a list of RLOCs for
DDT Nodes that are authoritative for the XEID-prefix being returned.
A DDT Client uses this information to contact one of those DDT Nodes
as it "follows" a referral.
5.3. "Incomplete" Flag
A DDT Node sets the "Incomplete" flag in a Map-Referral message if
the Referral Set is incomplete; this is intended to prevent a DDT
Client from caching a referral with incomplete information. A DDT
node MUST set the "Incomplete" flag in the following cases:
Saucez & Iannone Expires 9 May 2025 [Page 10]
Internet-Draft LISP-DDT November 2024
* If it is setting action code MS-ACK or MS-NOT-REGISTERED but the
matching XEID-prefix is not flagged as "complete" in the
configuration. The XEID-prefix configuration on the DDT Map-
Server SHOULD be marked as "complete" when the configuration of
the XEID-prefix lists all "peer" DDT Nodes that are also
authoritative for the same XEID-prefix or when it is known that a
local DDT Node is the only authoritative node for the XEID-prefix
.
* If it is setting action code NOT-AUTHORITATIVE.
5.4. Map-Referral Message Format
The format of the Map-Referral message is depicted in Figure 1.
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 |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e | Unused Flags |L|p|R| Loc-AFI |
| f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ Sig section ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Map-Referral message format.
Type: This document allocates type value 6 to identify Map-Referral
messages (see Section 11).
ACT: The ACT (Action) field of the mapping Record in a Map-Referral
Saucez & Iannone Expires 9 May 2025 [Page 11]
Internet-Draft LISP-DDT November 2024
message encodes one of the action types. See Section 5.1 for
descriptions of action types defined in the present specification.
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 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 |
+---------------------+------------+--------------+------------+
Table 1: I/TTL/ACT Settings
The "Incomplete" flag setting for the Map-Server-originated
referral of MS-ACK and MS-NOT-REGISTERED types depends 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.
The "Incomplete" bit is not set when the Map-Server has encoded
the information; this means that the Referral Set includes all the
RLOCs of all Map-Servers that serve the prefix. It MUST be set
when the configuration of the Map-Server does not flag the
matching prefix as configured with the complete information about
"peer" Map-Servers or when the Map-Server does not return all
configured locators.
Referral Count: Number of RLOCs in the current Referral Set. This
number is equal to the number of "Ref" sections in the message (as
shown Figure 1).
SigCnt: Indicates the number of signatures (Signature section)
present in the Record. If SigCnt is larger than 0, the signature
information captured in a Signature section as described in
Section 5.4.1 will be appended to the end of the Record. The
number of Signature sections at the end of the Record MUST match
the SigCnt.
Saucez & Iannone Expires 9 May 2025 [Page 12]
Internet-Draft LISP-DDT November 2024
Loc-AFI: AFI of the Locator field. If the AFI value is equal to an
LISP Canonical Address Format (LCAF) AFI, the contents of the LCAF
depend on the Type field of the LCAF. LCAF Type 11, is used to
store security material along with the AFI of the locator. DDT
Nodes and DDT Map-Servers uses this LCAF Type to include public
keys associated with their child DDT Nodes for an XEID-prefix Map-
Referral Record. LCAF Types and formats are defined in [RFC8060].
If the AFI value is different from the LISP Canonical Address
Format (LCAF) AFI, then security keys are not included in the
Record.
Locator: RLOC of a DDT Node to which the DDT Client is being
referred. This is a variable-length field; its length is
determined by the Loc-AFI setting.
All other fields and their descriptions are equivalent to those in
the Map-Reply message, as defined in LISP [RFC9301]. Note, though,
that the set of RLOCs correspond to the DDT Node to be queried as a
result of the referral and not to the RLOCs for an actual EID-to-RLOC
mapping.
5.4.1. Signature Section
SigCnt counts the number of signature sections that appear at the end
of the Record. The format of the signature section is described
Figure 2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| Original Record TTL |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature Expiration |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Signature Inception |
i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
g | Key Tag | Sig Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Sig-Algorithm | Reserved | Reserved |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Map-Referral Signature Section format.
Original Record TTL: The original Record TTL for this Record that is
covered by the signature. The Record TTL value is specified in
minutes.
Signature Expiration and Signature Inception: Specify the validity
Saucez & Iannone Expires 9 May 2025 [Page 13]
Internet-Draft LISP-DDT November 2024
period for the signature. The signature MUST NOT be used for
authentication prior to the inception date and MUST NOT be used
for authentication after the expiration date. Each field
specifies 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.
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 in bytes.
Sig-Algorithm: The identifier of the cryptographic algorithm used
for the signature. Sig-Algorithm values defined in this
specification are listed in Table 2. Implementations conforming
to this specification MUST implement at least RSA-SHA256 for DDT
signing. Sig-Algorithm type 1 (RSA-SHA1) is deprecated and SHOULD
NOT be used.
+===============+============+===========+============+
| Sig-Algorithm | Name | Reference | Notes |
+===============+============+===========+============+
| 1 | RSA-SHA1 | [RFC8017] | DEPRECATED |
+---------------+------------+-----------+------------+
| 2 | RSA-SHA256 | [RFC8017] | MANDATORY |
+---------------+------------+-----------+------------+
Table 2: Sig-Algorithm Values
Reserved: MUST be set to 0 on transmit and MUST be ignored on
receipt.
Signature: Contains the cryptographic signature that covers the
entire Map-Referral Record to which this signature belongs. For
the purpose of computing the signature, the Record TTL
(Section 5.4) value is set to the value of Original Record TTL and
the Signature field is filled with zeros.
6. DDT Network Elements and Their Operation
As described above, LISP-DDT introduces a new network element, namely
the DDT Node and extends the functionality of Map-Servers and Map-
Resolvers to send and receive Map-Referral messages. The operation
of each of these devices is described below.
Saucez & Iannone Expires 9 May 2025 [Page 14]
Internet-Draft LISP-DDT November 2024
6.1. DDT Node
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 depending on whether or not there is
a match, different actions are taken, as described below.
6.1.1. Matching 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). If at least one DDT Node of the
delegation is known to be a DDT Map-Server, then the Map-Referral
message SHOULD be sent with action code MS-REFERRAL to indicate to
the receiver that LISP-SEC information (if saved in the pending
request) SHOULD be included in the next DDT Map-Request; otherwise,
the action code NODE-REFERRAL SHOULD be used.
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 it may be a useful heuristic for reducing the number
of iterations needed to find an EID, particularly for private network
deployments.
Referral hints, if used properly, may reduce the number of referrals
a DDT Client needs to follow to locate a DDT Map-Server authoritative
for the XEID-prefix being resolved. On the other hand, the incorrect
use of hints may create circular dependencies (or "referral loops")
between DDT Nodes. A DDT Client MUST be prepared to handle such
circular referrals. See Section 6.3.4 for a discussion of referral
loops and measures that the DDT Client must implement in order to
detect circular referrals and prevent infinite looping.
Another danger related to the use of hints is when a DDT deployment
spans multiple administrative domains (i.e., different authorities
manage DDT Nodes in the same DDT database). In this case, an
operator managing a DDT Node may not be aware of the fact that the
node is being referred to by hints. Locator addresses in hints may
become stale when referred DDT Nodes are taken out of service or
change their locator addresses.
Saucez & Iannone Expires 9 May 2025 [Page 15]
Internet-Draft LISP-DDT November 2024
6.1.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 MUST return a
Negative Map-Referral that uses the least-specific XEID-prefix that
does not match any XEID-prefix delegated by the DDT Node. The action
code is set to DELEGATION-HOLE, which indicates that the XEID is not
a LISP destination.
If the requested XEID did not match either a configured delegation,
an authoritative XEID-prefix, or a hint, then a Negative Map-Referral
with action code NOT-AUTHORITATIVE MUST be returned.
6.2. DDT Map-Server
When a DDT Map-Server receives a DDT Map-Request, its operation is
similar to that of a DDT Node, with additional processing as follows:
* 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 a proxy Map-
Reply service), and a Map-Referral with action code MS-ACK MUST be
returned to the sender of the DDT Map-Request.
* If the requested XEID matches a configured XEID-prefix for which
no ETR registration has been received, then a Negative Map-
Referral with action code MS-NOT-REGISTERED MUST be returned to
the sender of the DDT Map-Request.
6.3. DDT Client
A DDT Client queries one or more DDT Nodes and uses an iterative
process of following returned referrals until it receives one with
action code MS-ACK (or an error indication). MS-ACK 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 locator address
in the Map-Request.
DDT Client functionality will typically be implemented by DDT Map-
Resolvers. Just as would 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. However, a DDT Map-Resolver implements DDT
Client functionality to find the correct ETR to answer a Map-Request,
which in turns requires a DDT Map-Resolver to maintain additional
state, namely a Map-Referral cache and a pending requests list of
XEIDs that are going through the iterative referral process.
Saucez & Iannone Expires 9 May 2025 [Page 16]
Internet-Draft LISP-DDT November 2024
DDT Client functionality may be implemented on ITRs. In this case,
the DDT Client will not receive a Map-Request from another network
element; instead, equivalent information will be provided to the DDT
Client via a programming interface.
6.3.1. Queuing and Sending DDT Map-Requests
When a DDT Client receives a request to resolve an XEID (in the case
of a DDT Map-Resolver, this will be in the form of a received
Encapsulated Map-Request), it first performs a longest-match search
for the XEID in its referral cache. If no match is found or if a
negative cache entry is found, then the destination is not in the
database; a Negative Map-Reply MUST be returned, and no further
processing is performed by the DDT Client.
If a match is found, the DDT Client creates a pending request list
entry for the XEID and saves the original request (in the case of a
DDT Map-Resolver, this will be the original Map-Request minus the
encapsulation header) along with other information needed to track
progress through the iterative referral process; the "referral XEID-
prefix" is also initialized to indicate that no referral has yet been
received. The DDT Client 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 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 Client is not required to cache
referrals, but doing so will decrease latency and reduce lookup
delays.
Note that in normal use, the statically configured initial referral
cache for a DDT Client should include a "default" entry with RLOCs
for either the root DDT Node or one or more DDT Nodes that contain
hints for the root DDT Node. If a DDT client does not have such a
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. If DDT message exchanges are authenticated as described in
Section 9, then the DDT Client MUST also be configured with public
keys of DDT Nodes pointed to by the "default" cache entry. In this
case, the "default" entry will typically be for the root DDT Node.
Saucez & Iannone Expires 9 May 2025 [Page 17]
Internet-Draft LISP-DDT November 2024
6.3.2. Receiving and Following Referrals
After sending a DDT Map-Request, a DDT Client expects to receive a
Map-Referral response. If none occurs within the timeout period, the
DDT Client retransmits the request, sending it to the next RLOC in
the referral cache entry if one is available. If all RLOCs have been
tried and the maximum number of retransmissions has occurred for
each, then the pending request list entry is dequeued and discarded.
In this case, the DDT Client returns no response to the sender of the
original request.
A DDT Client processes a received Map-Referral message according to
each action code:
NODE-REFERRAL: The DDT Client checks for a possible referral loop as
described in Section 6.3.4. If no loop is found, the DDT Client
saves the prefix returned in the Map-Referral message in the
referral cache, updates the saved prefix and saved RLOCs in the
pending request list entry, and follows the referral by sending a
new DDT Map-Request to one of the DDT Node RLOCs listed in the
Referral Set. Security information saved with the original Map-
Request SHOULD NOT be included.
MS-REFERRAL: The DDT Client processes an MS-REFERRAL in the same
manner as a NODE-REFERRAL, except that security information saved
with the original Map-Request MUST be included in the new Map-
Request sent to a Map-Server (see Section 9 for details on
security).
MS-ACK: An MS-ACK is returned by a DDT Map-Server to indicate that
it has one or more registered ETRs that can answer a Map-Request
for the XEID and the request has been forwarded to one of them
(or, if the Map-Server is providing a proxy service for the
prefix, then a reply has been sent to the querying ITR). If the
pending request did not include saved LISP-SEC information or if
that information was already included in the previous DDT Map-
Request (sent by the DDT Client in response to either an MS-
REFERRAL or a previous MS-ACK referral), then the pending request
for the XEID is complete, processing of the request stops, and all
request state can be discarded. Otherwise, LISP-SEC information
is required and has not yet been sent to the authoritative DDT
Map-Server; the DDT Client MUST resend the DDT Map-Request with
LISP-SEC information included, and the pending request queue entry
remains until another Map-Referral with action code MS-ACK is
received. If the "Incomplete" flag is not set, the prefix is
saved in the referral cache.
MS-NOT-REGISTERED: The DDT Map-Server queried could not process the
Saucez & Iannone Expires 9 May 2025 [Page 18]
Internet-Draft LISP-DDT November 2024
request because it did not have any ETRs registered for a
matching, authoritative XEID-prefix. If the DDT Client has not
yet tried all of the RLOCs saved with the pending request, then it
sends a Map-Request to the next RLOC in that list. If all RLOCs
have been tried, then the destination XEID is not registered and
is unreachable. The DDT Client MUST return a Negative Map-Reply
to the requester (or, in the case of a DDT Map-Resolver, to the
sender of the original Map-Request). This Map-Reply contains the
least-specific XEID-prefix in the range for which this DDT Map-
Server is authoritative and in which no registrations exist. The
TTL value of the Negative Map-Reply SHOULD be set to 1 minute. A
negative referral cache entry is created for the prefix (whose TTL
also SHOULD be set to 1 minute), and processing of the request
stops.
DELEGATION-HOLE: The DDT Map-Server queried did not have an XEID-
prefix defined that matched the requested XEID, so the XEID does
not exist in the mapping database. The DDT Client MUST return a
Negative Map-Reply to the requester (or, in the case of a DDT Map-
Resolver, to the sender of the original Map-Request); this Map-
Reply SHOULD indicate the least-specific XEID-prefix matching the
requested XEID for which no delegations exist and SHOULD have a
TTL value of 15 minutes. A negative referral cache entry is
created for the prefix (which also SHOULD have a TTL of 15
minutes), and processing of the pending request stops.
NOT-AUTHORITATIVE: The DDT Map-Server queried is not authoritative
for the requested XEID. This can occur if a cached referral has
become invalid due to a change in the database hierarchy. If the
DDT Client receiving this message can determine that it is using
old cached information, it MAY choose to delete that cached
information and retry the original Map-Request, starting from its
"root" cache entry. If this action code is received in response
to a query that did not use cached referral information, then it
indicates a database synchronization problem or configuration
error. The pending request is silently discarded; i.e., all state
for the request that caused this answer is removed, and no answer
is returned to the original requester.
6.3.3. 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
client; they should be considered errors and logged as such. It is
not clear exactly what else the DDT Client should do in such cases;
one possibility is to remove the pending request list entry and send
a Negative Map-Reply to the requester (or, in the case of a DDT Map-
Resolver, to the sender of the original Map-Request Alternatively, if
Saucez & Iannone Expires 9 May 2025 [Page 19]
Internet-Draft LISP-DDT November 2024
a DDT Client detects unexpected behavior by a DDT node, it could mark
that node as unusable in its referral cache and update the pending
request to try a different DDT Node if more than one is listed in the
referral cache. In any case, any prefix contained in a Map-Referral
message that causes a referral error (including a referral loop) is
not saved in the DDT Client referral cache.
6.3.4. Referral Loop Detection
In response to a Map-Referral message with action code NODE-REFERRAL
or MS-REFERRAL, a DDT Client is directed to query a new set of DDT
node RLOCs that are expected to have more-specific XEID-prefix
information for the requested XEID. To prevent a possible "iteration
loop" (following referrals back and forth among a set of DDT Nodes
without ever finding an answer), a DDT Client saves the last received
referral XEID-prefix for each pending request and checks to see if a
newly received NODE-REFERRAL or MS-REFERRAL message contains a more-
specific referral XEID-prefix; an exact or less-specific match of the
saved XEID-prefix indicates a referral loop. If a loop is detected,
the DDT Map-Resolver handles the request as described in
Section 6.3.3. Otherwise, the DDT Client saves the most recently
received referral XEID-prefix with the pending request 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 DDT Client adds an entry to its lookup queue and
sends an initial Map-Request for an XEID, the queue entry 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 hierarchy. This, in turn, allows a DDT Client 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 on all DDT Clients.
7. Pseudo-code and Decision Tree Diagrams
To illustrate the DDT algorithms described above and to aid in
implementation, each of the major DDT Map-Server and DDT Map-Resolver
functions are described below, first using simple "pseudo-code" and
then in the form of a decision tree.
Saucez & Iannone Expires 9 May 2025 [Page 20]
Internet-Draft LISP-DDT November 2024
7.1. Map-Resolver Processing of ITR Map-Request
7.1.1. Pseudo-code Summary
if ( request pending, i.e., (ITR,EID) of request same ) {
replace old request with new, & use new request nonce
for future requests
} else if ( no match in refcache ) {
return Negative Map-Reply to ITR
} else if ( match type DELEGATION-HOLE ) {
return Negative Map-Reply to ITR
} else if ( match type MS-ACK ) {
fwd DDT Map-Request to Map-Server
} else {
store & fwd DDT Map-Request w/o security material
to node delegation
}
7.1.2. Decision Tree Diagram
Saucez & Iannone Expires 9 May 2025 [Page 21]
Internet-Draft LISP-DDT November 2024
+-----------------+ Yes
| Is request |---> Replace old request with
| pending? | new nonce for future requests
+-----------------+
|No
|
V
+-----------------+ No
| Match in |
| referral cache? |---> Send Negative Map-Reply
+-----------------+ (unlikely event, as root or hint
|Yes configured on every Map-Resolver)
|
V
+-----------------+
| Match type | Yes
| DELEGATION-HOLE |---> Send Negative Map-Reply
+-----------------+
|No
|
V
+-----------------+
| Match type | Yes
| MS-ACK? |---> Forward DDT Map-Request to
+-----------------+ Map-Server
|No
|
V
Store original request & send DDT Map-Request
w/o security material to DDT Node delegation
7.2. Map-Resolver Processing of Map-Referral Message
7.2.1. Pseudo-code Summary
if ( authentication signature validation failed ) {
silently drop
}
if ( no request pending matched by referral nonce ) {
silently drop
}
if ( pfx in referral less specific than last referral used ) {
if ( gone through root ) {
silently drop
} else {
send request to root
Saucez & Iannone Expires 9 May 2025 [Page 22]
Internet-Draft LISP-DDT November 2024
}
}
switch (map_referral_type) {
case NOT_AUTHORITATIVE:
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
case DELEGATION_HOLE:
cache & send Negative Map-Reply to ITR
case MS_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; include security material
}
case NODE_REFERRAL:
if ( referral equal to last used ) {
if ( gone through root ) {
return Negative Map-Reply to ITR
} else {
send request to root
}
} else {
cache
follow the referral; strip security material
}
case MS_ACK:
if ( security material stripped ) {
resend request with security material
if { !incomplete } {
cache
}
}
case MS_NOT_REGISTERED:
Saucez & Iannone Expires 9 May 2025 [Page 23]
Internet-Draft LISP-DDT November 2024
if { all Map-Server delegations not tried } {
follow delegations not tried
if ( !incomplete ) {
cache
}
} else {
send Negative Map-Reply to ITR
if { !incomplete } {
cache
}
}
case DEFAULT:
drop
}
7.2.2. Decision Tree Diagram
+-----------------------+ No
| Auth signature Valid ?|--> Silently drop
+-----------------------+
| Yes
|
V
+------------------------+No
| Is request pending? |--> Silently drop
+------------------------+
| Yes
|
V
+------------------------------+Yes
| Pfx less specific than last? |--> Silently drop
+------------------------------+
|No
|
V
+----------------------------------------------+
| What is Map-Referral type? |--> Unknown--+
+----------------------------------------------+ |
| | | | | DEL_HOLE v
| | | | MS_ACK | Drop
| | | | | V
| | MS_REF NODE_REF | Cache & return
| | | | V Negative Map-Reply
| | | | +----------+
| NOT_AUTH | | | Was sec | Yes
| | | | | material |---> Done
| | | | |stripped? |
Saucez & Iannone Expires 9 May 2025 [Page 24]
Internet-Draft LISP-DDT November 2024
| | V V +----------+
| | +-----------+ |No
| | Yes| Pfx equal | V
MS_NOT_REGISTERED | +---| to last | +------------+
| | | | used? | |"Incomplete"|Yes
| | | +-----------+ | bit set? |--> Resend DDT
| V V |No +------------+ request w/
| +------------+ | |No security
| |Gone through| V | material
| | root? | Cache & follow |
| +------------+ the referral |
| |No |Yes v
| | | Cache & resend DDT
| V V request with
| Send req Send Negative security material
| to root Map-Reply
V
+-----------+Yes +----------+Yes
| Other MS |-Follow other MS---------->|Incomplete|--> Do not cache
| not tried?| | bit set? |
| |-Send Negative Map-Reply-->| |--> Cache
+-----------+No +----------+No
7.3. DDT Node Processing of DDT Map-Request Message
7.3.1. Pseudo-code Summary
Saucez & Iannone Expires 9 May 2025 [Page 25]
Internet-Draft LISP-DDT November 2024
if ( I am not authoritative ) {
send Map-Referral NOT_AUTHORITATIVE with
"Incomplete" bit set and TTL 0
} else if ( delegation exists ) {
if ( delegated Map-Servers ) {
send Map-Referral MS_REFERRAL with
TTL 'Default_DdtNode_Ttl'
} else {
send Map-Referral NODE_REFERRAL with
TTL 'Default_DdtNode_Ttl'
}
} else {
if ( EID in site) {
if ( site registered ) {
forward Map-Request to ETR
if ( Map-Server peers configured ) {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl'
} else {
send Map-Referral MS_ACK with
TTL 'Default_Registered_Ttl' and "Incomplete" bit set
}
} else {
if ( Map-Server peers configured ) {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
} else {
send Map-Referral MS_NOT_REGISTERED with
TTL 'Default_Configured_Not_Registered_Ttl'
and "Incomplete" bit set
}
}
} else {
send Map-Referral DELEGATION_HOLE with
TTL 'Default_Negative_Referral_Ttl'
}
}
where architectural constants for TTL are set as follows:
* Default_DdtNode_Ttl 1440 minutes
* Default_Registered_Ttl 1440 minutes
* Default_Negative_Referral_Ttl 15 minutes
* Default_Configured_Not_Registered_Ttl 1 minute
Saucez & Iannone Expires 9 May 2025 [Page 26]
Internet-Draft LISP-DDT November 2024
7.3.2. Decision Tree Diagram
+------------+
| Am I |No
| authori- |--> Return NOT_AUTHORITATIVE
| tative? | Incomplete = 1
+------------+ TTL = Default_DdtNode_Ttl
|Yes
|
V
+------------+ +-------------+
| Delegation |Yes | Delegations |Yes
| exists? |---->| are |---> Return MS_REFERRAL
| | | Map-Servers?| TTL = Default_DdtNode_Ttl
+------------+ +-------------+
| |No
|No +--> Return NODE_REFERRAL
| TTL = Default_DdtNode_Ttl
V
+------------+ +------------+ +------------+
| EID in |Yes | Site |Yes | Map-Server |
| site |---->| registered?|-->Forward---->| peers |
| config? | | | Map-Request | configured?|
+------------+ +------------+ to ETR +------------+
|No |No No| |Yes
| | | |
| | V V
| | Return MS_ACK Return MS_ACK
| V with INC=1
| +------------+ TTL = Default_Registered_Ttl
| | Map-Server |Yes
| | peers |-->Return MS_NOT_REGISTERED
| | configured?| TTL = Default_Negative_Referral_Ttl
| +------------+
| |No
| +--> Return MS_NOT_REGISTERED
| Incomplete = 1
V TTL = Default_Negative_Referral_Ttl
Return DELEGATION_HOLE
TTL = Default_Negative_Referral_Ttl
Saucez & Iannone Expires 9 May 2025 [Page 27]
Internet-Draft LISP-DDT November 2024
8. Example Topology and Request/Referral Following
This section shows an example of DDT tree and several possible
scenarios of Map-Requests coming to a Map-Resolver and subsequent
iterative DDT referrals. In this example, RLOCs of DDT Nodes are
shown in the IPv4 address space while the EIDs are in the IPv6
address space. The same principle of hierarchical delegation and
pinpointing referrals is equally applicable to any address family
whose address hierarchy can be expressed as a bit string with
associated length.
To show how referrals are followed to find the RLOCs for a number of
EIDs, consider the example of EID topology for DBID=0, IID=0, AFI=2,
and EID=0/0 in Figure 3.
Saucez & Iannone Expires 9 May 2025 [Page 28]
Internet-Draft LISP-DDT November 2024
+---------------------+ +---------------------+
| root1: 192.0.2.1 | | root2: 192.0.2.2 |
| authoritative: ::/0 | | authoritative: ::/0 |
+---------------------+ +---------------------+
| \ / |
| \/ |
| /\ |
| / \ |
V V V V
+-----------------------+ +-----------------------+
| DDT Node1: 192.0.2.11 | | DDT Node2: 192.0.2.12 |
| authoritative: | | authoritative: |
| 2001:db8::/32 | | 2001:db8::/32 |
+-----------------------+ +-----------------------+
| \ / |
| \/ |
| /\ |
| / \ |
| / \ |
V V V V
+--------------------------+ +------------------------+
| Map-Server1: 192.0.2.101 | | DDT Node3: 192.0.2.201 |
| authoritative: | | authoritative: |
| 2001:db8:0100::/40 | | 2001:db8:0500::/40 |
| site1: 2001:db8:0103::/48| +------------------------+
| site2: 2001:db8:0104::/48| | |
+--------------------------+ | |
V V
+---------------------------+ +---------------------------+
| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |
| authoritative: | | authoritative: |
| 2001:db8:0500::/48 | | 2001:db8:0501::/48 |
|site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64|
|site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64|
+---------------------------+ +---------------------------+
Figure 3: Example of DDT tree topology.
DDT Nodes are configured for this "root" at IP addresses 192.0.2.1
and 192.0.2.2. DDT Map-Resolvers are configured with default
referral cache entries for these addresses.
The root DDT Nodes delegate 2001:db8::/32 to two DDT Nodes with IP
addresses 192.0.2.11 and 192.0.2.12.
The DDT Nodes for 2001:db8::/32 delegate 2001:db8:0100::/40 to a DDT
Map-Server with RLOC 192.0.2.101.
Saucez & Iannone Expires 9 May 2025 [Page 29]
Internet-Draft LISP-DDT November 2024
The DDT Map-Server for 2001:db8:0100::/40 is configured to allow ETRs
to register the sub-prefixes 2001:db8:0103::/48 and
2001:db8:0104::/48.
The DDT Nodes for 2001:db8::/32 also delegate 2001:db8:0500::/40 to a
DDT Node with RLOC 192.0.2.201.
The DDT Node for 2001:db8:0500::/40 is further configured to delegate
2001:db8:0500::/48 to a DDT Map-Server with RLOC 192.0.2.211 and
2001:db8:0501::/48 to a DDT Map-Server with RLOC 192.0.2.221.
The DDT Map-Server for 2001:db8:0500::/48 is configured to allow ETRs
to register the sub-prefixes 2001:db8:0500:1::/64 and
2001:db8:0500:2::/64.
The DDT Map-Server for 2001:db8:0501::/48 is configured to allow ETRs
to register the sub-prefixes 2001:db8:0501:8::/64 and
2001:db8:0501:9::/64.
8.1. Lookup of 2001:db8:0103:1::1/128
The first example shows a DDT Map-Resolver following a delegation
from the root to a DDT Node followed by another delegation to a DDT
Map-Server.
ITR1 sends an Encapsulated Map-Request for 2001:db8:0103:1::1 to one
of its configured (DDT) Map-Resolvers. The DDT Map-Resolver proceeds
as follows:
1. Send a DDT Map-Request (for 2001:db8:0103:1::1) to one of the
root DDT Nodes (192.0.2.1 or 192.0.2.2).
2. Receive (and save in the referral cache) the Map-Referral for
EID-prefix 2001:db8::/32, action code NODE-REFERRAL, RLOC set
(192.0.2.11, 192.0.2.12).
3. Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.
4. Receive (and save in the referral cache) the Map-Referral for
EID-prefix 2001:db8:0100::/40, action code MS-REFERRAL, RLOC set
(192.0.2.101).
5. Send a DDT Map-Request to 192.0.2.101; if the ITR-originated
Encapsulated Map-Request had a LISP-SEC signature, it is
included.
Saucez & Iannone Expires 9 May 2025 [Page 30]
Internet-Draft LISP-DDT November 2024
6. The DDT Map-Server at 192.0.2.101 decapsulates the DDT Map-
Request and forwards the Map-Request to a registered site1 ETR
for 2001:db8:0103::/48.
7. The DDT Map-Server at 192.0.2.101 sends a Map-Referral message
for EID-prefix 2001:db8:0103::/48, action code MS-ACK, to the DDT
Map-Resolver.
8. The DDT Map-Resolver receives the Map-Referral message and
dequeues the pending request for 2001:db8:0103:1::1.
9. The site1 ETR for 2001:db8:0103::/48 receives the Map-Request
forwarded by the DDT Map-Server and sends a Map-Reply to ITR1.
8.2. Lookup of 2001:db8:0501:8:4::1/128
The next example shows a three-level delegation: root to first DDT
node, first DDT Node to second DDT Node, and second DDT Node to DDT
Map-Server.
ITR2 sends an Encapsulated Map-Request for 2001:db8:0501:8:4::1 to
one of its configured (DDT) Map-Resolvers, which are different from
those for ITR1. The DDT Map-Resolver proceeds as follows:
1. Send a DDT Map-Request (for 2001:db8:0501:8:4::1) to one of the
root DDT Nodes (192.0.2.1 or 192.0.2.2).
2. Receive (and save in the referral cache) the Map-Referral for
EID-prefix 2001:db8::/32, action code NODE-REFERRAL, RLOC set
(192.0.2.11, 192.0.2.12).
3. Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.
4. Receive (and save in the referral cache) the Map-Referral for
EID-prefix 2001:db8:0500::/40, action code NODE-REFERRAL, RLOC
set (192.0.2.201).
5. Send a DDT Map-Request to 192.0.2.201.
6. Receive (and save in the referral cache) the Map-Referral for
EID-prefix 2001:db8:0501::/48, action code MS-REFERRAL, RLOC set
(192.0.2.221).
7. Send a DDT Map-Request to 192.0.2.221; if the ITR-originated
Encapsulated Map-Request had a LISP-SEC signature, it is
included.
Saucez & Iannone Expires 9 May 2025 [Page 31]
Internet-Draft LISP-DDT November 2024
8. The DDT Map-Server at 192.0.2.221 decapsulates the DDT Map-
Request and forwards the Map-Request to a registered site5 ETR
for 2001:db8:0501:8::/64.
9. The DDT Map-Server at 192.0.2.221 sends a Map-Referral message
for EID-prefix 2001:db8:0501:8::/64, action code MS-ACK, to the
DDT Map-Resolver.
10. The DDT Map-Resolver receives a Map-Referral(MS-ACK) message and
dequeues the pending request for 2001:db8:0501:8:4::1.
11. The site5 ETR for 2001:db8:0501:8::/64 receives a Map-Request
forwarded by the DDT Map-Server and sends a Map-Reply to ITR2.
8.3. Lookup of 2001:db8:0104:2::2/128
This example shows how a DDT Map-Resolver uses a saved referral cache
entry to skip the referral process and go directly to a DDT Map-
Server for a prefix that is similar to one previously requested.
In this case, ITR1 uses the same Map-Resolver used in the example in
Section 8.1. It sends an Encapsulated Map-Request for
2001:db8:0104:2::2 to that (DDT) Map-Resolver. The DDT Map-Resolver
finds an MS-REFERRAL cache entry for 2001:db8:0100::/40 with RLOC set
(192.0.2.101) and proceeds as follows:
1. Send a DDT Map-Request (for 2001:db8:0104:2::2) to 192.0.2.101;
if the ITR-originated Encapsulated Map-Request had a LISP-SEC
signature, it is included.
2. The DDT Map-Server at 192.0.2.101 decapsulates the DDT Map-
Request and forwards the Map-Request to a registered site2 ETR
for 2001:db8:0104::/48.
3. The DDT Map-Server at 192.0.2.101 sends a Map-Referral message
for EID-prefix 2001:db8:0104::/48, action code MS-ACK, to the DDT
Map-Resolver.
4. The DDT Map-Resolver receives the Map-Referral (MS-ACK) and
dequeues the pending request for 2001:db8:0104:2::2.
5. The site2 ETR for 2001:db8:0104::/48 receives a Map-Request and
sends a Map-Reply to ITR1.
Saucez & Iannone Expires 9 May 2025 [Page 32]
Internet-Draft LISP-DDT November 2024
8.4. Lookup of 2001:db8:0500:2:4::1/128
This example shows how a DDT Map-Resolver uses a saved referral cache
entry to start the referral process at a non-root, intermediate DDT
node for a prefix that is similar to one previously requested.
In this case, ITR2 uses the same Map-Resolver used in the example in
Section 8.1. It sends an Encapsulated Map-Request for
2001:db8:0500:2:4::1 to that (DDT) Map-Resolver, which finds a NODE-
REFERRAL cache entry for 2001:db8:0500::/40 with RLOC set
(192.0.2.201). It proceeds as follows:
1. Send a DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201.
2. Receive (and save in the referral cache) the Map-Referral for
EID-prefix 2001:db8:0500::/48, action code MS-REFERRAL, RLOC set
(192.0.2.211).
3. Send a DDT Map-Request to 192.0.2.211; if the ITR-originated
Encapsulated Map-Request had a LISP-SEC signature, it is
included.
4. The DDT Map-Server at 192.0.2.211 decapsulates the DDT Map-
Request and forwards the Map-Request to a registered site4 ETR
for 2001:db8:0500:2::/64.
5. The DDT Map-Server at 192.0.2.211 sends a Map-Referral message
for EID-prefix 2001:db8:0500:2::/64, action code MS-ACK, to the
DDT Map-Resolver.
6. The DDT Map-Resolver receives the Map-Referral (MS-ACK) and
dequeues the pending request for 2001:db8:0500:2:4::1.
7. The site4 ETR for 2001:db8:0500:2::/64 receives a Map-Request and
sends a Map-Reply to ITR2.
8.5. Lookup of 2001:db8:0500::1/128 (Nonexistent EID)
This example uses the cached MS-REFERRAL for 2001:db8:0500::/48
learned above to start the lookup process at the DDT Map-Server at
192.0.2.211. The DDT Map-Resolver proceeds as follows:
1. Send a DDT Map-Request (for 2001:db8:0500::1) to 192.0.2.211; if
the ITR-originated Encapsulated Map-Request had a LISP-SEC
signature, it is included.
Saucez & Iannone Expires 9 May 2025 [Page 33]
Internet-Draft LISP-DDT November 2024
2. The DDT Map-Server at 192.0.2.211, which is authoritative for
2001:db8:0500::/48, does not have a matching delegation for
2001:db8:0500::1. It responds with a Map-Referral message for
2001:db8:0500::/64, action code DELEGATION-HOLE, to the DDT Map-
Resolver. The prefix 2001:db8:0500::/64 is used because it is
the least-specific prefix that does match the requested EID but
does not match one of the configured delegations
(2001:db8:0500:1::/64 and 2001:db8:0500:2::/64).
3. The DDT Map-Resolver receives the delegation, adds a negative
referral cache entry for 2001:db8:0500::/64, dequeues the pending
request for 2001:db8:0500::1, and returns a Negative Map-Reply to
ITR2.
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 scope
for this document.
Each DDT Node is configured with one or more public/private key pairs
that are used to digitally sign Map-Referral Records for XEID-
prefix(es) for which the DDT Node is authoritative. In other words,
each public/private key pair is associated with the combination of a
DDT Node and an XEID-prefix for which it is authoritative. Every DDT
Node is also configured with the public keys of its child DDT Nodes.
By including the 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 child DDT nodes. A DDT Node
configured to provide hints must also have the public keys of the DDT
Nodes to which its hints point. DDT Node keys can be encoded using
LCAF Type 11 to associate the key to the RLOC of the referred DDT
Node. If a node has more than one public key, it should sign its
Records with at least one of these keys. When a node has N keys, it
can sustain up to N-1 key compromises. The revocation mechanism is
described in Section 9.2.1.
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 by either (1) having it configured
as a trust anchor or (2) 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's public keys should
Saucez & Iannone Expires 9 May 2025 [Page 34]
Internet-Draft LISP-DDT November 2024
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 child DDT Nodes, a
parent DDT Node signs its Map-Referrals. Every signed Map-Referral
MUST also include the public keys associated with each child DDT
node. Such a signature indicates that the parent DDT Node is
delegating the specified XEID-prefix to a given child DDT Node. The
signature is also authenticating the public keys associated with the
child DDT Nodes, and authorizing them to be used by the child 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
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 6. 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 child 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 DDT 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 Node is configured to
advertise that key, the parent DDT 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.
Saucez & Iannone Expires 9 May 2025 [Page 35]
Internet-Draft LISP-DDT November 2024
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. (See Section 4.7 of [RFC8060] for details regarding
the R bit.) 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 advertised 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.
However, unlike DDT Nodes, Map-Servers do not delegate prefixes and
as a result 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 either 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 (Section 5.4.1)
of the signature can be used to select the correct 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 to verify
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 (1) no matching key is found,
(2) none of the matching keys is authoritative for the XEID-prefix in
the Map-Referral Record, or (3) 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-
Saucez & Iannone Expires 9 May 2025 [Page 36]
Internet-Draft LISP-DDT November 2024
Resolver MAY try other siblings of this node if there is an alternate
node that is 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 Map-Resolver cannot verify the signature after several
attempts.
Once the signature is verified, the Map-Resolver has verified the
XEID-prefix delegation in the Map-Referral. This also means that
public keys of the child DDT Nodes were authenticated; 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.
10. Deployment Experience
TBD
11. IANA Considerations
IANA has made the an early temporary allocation for message type 6,
"LISP DDT Map-Referral", in the "LISP Packet Types" registry group.
IANA is requested to make the allocation permanent and modify the
"LISP Packet Types" as shown in Table 3.
+======+=======================+=================+
| Code | Message | Reference |
+======+=======================+=================+
| 6 | LISP DDT Map-Referral | [This document] |
+------+-----------------------+-----------------+
Table 3: LISP DDT Map-Referral Message Type
Allocation
12. Security Considerations
Section 9 describes a DDT security architecture that provides data
origin authentication, data integrity protection, and XEID-prefix
delegation within the DDT infrastructure.
This document specifies how DDT security and LISP-SEC [RFC9303]
complement one another to secure the DDT infrastructure, Map-Referral
messages, and the Map-Request/Map-Reply protocols.
LISP-SEC can use the DDT public-key infrastructure to secure the
transport of LISP-SEC key material (the One-Time Key) from a Map-
Resolver to the corresponding Map-Server. For this reason, when
LISP-SEC is deployed in conjunction with a LISP-DDT mapping database
Saucez & Iannone Expires 9 May 2025 [Page 37]
Internet-Draft LISP-DDT November 2024
and the path between the Map-Resolver and Map-Server needs to be
protected, DDT security as described in Section 9 MUST be enabled as
well.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/rfc/rfc5011>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/rfc/rfc8060>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/rfc/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/rfc/rfc9301>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/rfc/rfc9303>.
13.2. Informative References
[AFI] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/>.
Saucez & Iannone Expires 9 May 2025 [Page 38]
Internet-Draft LISP-DDT November 2024
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/rfc/rfc6836>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/rfc/rfc6837>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/rfc/rfc8111>.
Contributors
Vince Fuller
VAF.NET Internet Consulting
Email: vince.fuller@gmail.com
Darrel Lewis
ICANN
Los Angeles, CA 90292
United States of America
Email: darrel.lewis@icann.org
Vina Ermagan
Google
United States of America
Email: ermagan@gmail.com
Amit Jain
Juniper Networks
Email: atjain@juniper.net
Saucez & Iannone Expires 9 May 2025 [Page 39]
Internet-Draft LISP-DDT November 2024
Anton Smirnov
Cisco Systems, Inc.
De Kleetlaan 6a
1831 Diegem
Belgium
Email: as@cisco.com
Authors' Addresses
Damien Saucez (editor)
Inria
France
Email: damien.saucez@inria.fr
Luigi Iannone (editor)
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: luigi.iannone@huawei.com
Saucez & Iannone Expires 9 May 2025 [Page 40]