idnits 2.17.1 draft-ietf-lisp-ddt-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2016) is 2784 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-13 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-10 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft 4 Intended status: Experimental D. Lewis 5 Expires: March 12, 2017 V. Ermagan 6 Cisco Systems 7 A. Jain 8 Juniper Networks 9 A. Smirnov 10 Cisco Systems 11 September 8, 2016 13 LISP Delegated Database Tree 14 draft-ietf-lisp-ddt-08 16 Abstract 18 This document describes the LISP Delegated Database Tree (LISP-DDT), 19 a hierarchical, distributed database which embodies the delegation of 20 authority to provide mappings from LISP Endpoint Identifiers (EIDs) 21 to Routing Locators (RLOCs). It is a statically-defined distribution 22 of the EID namespace among a set of LISP-speaking servers, called DDT 23 nodes. Each DDT node is configured as "authoritative" for one or 24 more EID-prefixes, along with the set of RLOCs for Map Servers or 25 "child" DDT nodes to which more-specific EID-prefixes are delegated. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 12, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 64 4. Database organization . . . . . . . . . . . . . . . . . . . . 7 65 4.1. EID-prefix tree structure and instance IDs . . . . . . . 7 66 4.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 67 4.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 68 5. DDT Map-Request . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. The Map-Referral message . . . . . . . . . . . . . . . . . . 8 70 6.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 9 71 6.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 9 72 6.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 10 73 6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10 74 6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12 75 7. DDT network elements and their operation . . . . . . . . . . 13 76 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 14 77 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 14 78 7.1.2. Missing delegation from an authoritative prefix . . . 14 79 7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14 80 7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 15 81 7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15 82 7.3.2. Receiving and following referrals . . . . . . . . . . 16 83 7.3.3. Handling referral errors . . . . . . . . . . . . . . 18 84 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 18 85 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 19 86 8.1. Map Resolver processing of ITR Map-Request . . . . . . . 19 87 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 88 8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 89 8.2. Map Resolver processing of Map-Referral message . . . . . 20 90 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20 91 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 22 92 8.3. DDT Node processing of DDT Map-Request message . . . . . 24 93 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 24 94 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 25 95 9. Example topology and request/referral following . . . . . . . 25 96 9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 27 97 9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 28 98 9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 29 99 9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 30 100 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 30 101 10. Securing the database and message exchanges . . . . . . . . . 31 102 10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 31 103 10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 32 104 10.2.1. DDT public key revocation . . . . . . . . . . . . . 32 105 10.3. Map Server operation . . . . . . . . . . . . . . . . . . 33 106 10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 33 107 11. Open Issues and Considerations . . . . . . . . . . . . . . . 34 108 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 109 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 110 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 111 14.1. Normative References . . . . . . . . . . . . . . . . . . 35 112 14.2. Informative References . . . . . . . . . . . . . . . . . 35 113 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 116 1. Introduction 118 LISP [RFC6830] specifies an architecture and mechanism for replacing 119 the addresses currently used by IP with two separate name spaces: 120 Endpoint Identifiers (EIDs), used end-to-end for terminating 121 transport-layer associations, and Routing Locators (RLOCs), which are 122 bound to topological location, and are used for routing and 123 forwarding through the Internet infrastructure. 125 LISP offers a general-purpose mechanism for mapping between EIDs and 126 RLOCs. In organizing a database of EID to RLOC mappings, this 127 specification extends the definition of the EID numbering space by 128 logically prepending and appending several fields for purposes of 129 defining the database index key: Database-ID (DBID, 16 bits), 130 Instance identifier (IID, 32-bits), Address Family Identifier (16 131 bits), and EID-prefix (variable, according to AFI value). The 132 resulting concatenation of these fields is termed an "Extended EID 133 prefix" or XEID-prefix. 135 The DBID is provided for possible use in case a need evolves for 136 another, higher level in the hierarchy, to allow the creation of 137 multiple, separate database trees. 139 LISP-DDT is a hierarchical distributed database, which embodies the 140 delegation of authority to provide mappings, i.e. its internal 141 structure mirrors the hierarchical delegation of address space. It 142 also provides delegation information to Map Resolvers, which use the 143 information to locate EID-to-RLOC mappings. A Map Resolver, which 144 needs to locate a given mapping, will follow a path through the tree- 145 structured database, contacting, one after another, the DDT nodes 146 along that path until it reaches the leaf DDT node(s) authoritative 147 for the mapping it is seeking. 149 LISP-DDT defines a new device type, the DDT node, that is configured 150 as authoritative for one or more XEID-prefixes. It also is 151 configured with the set of more-specific sub-prefixes that are 152 further delegated to other DDT nodes. To delegate a sub-prefix, the 153 "parent" DDT node is configured with the RLOCs of each child DDT node 154 that is authoritative for the sub-prefix. Each RLOC either points to 155 a Map Server (sometimes termed a "terminal DDT node") to which an 156 Egress Tunnel Router (ETR) has registered that sub-prefix or points 157 to another DDT node in the database tree that further delegates the 158 sub-prefix. See [RFC6833] for a description of the functionality of 159 the Map Server and Map Resolver. Note that the target of a 160 delegation must always be an RLOC (not an EID) to avoid any circular 161 dependency. 163 To provide a mechanism for traversing the database tree, LISP-DDT 164 defines a new LISP message type, the Map-Referral, which is returned 165 to the sender of a Map-Request when the receiving DDT node can refer 166 the sender to another DDT node that has more detailed information. 167 See Section 6 for the definition of the Map-Referral message. 169 To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map 170 Resolver, starts by sending an Encapsulated Map-Request to a 171 preconfigured DDT node RLOC. The DDT node responds with a Map- 172 Referral message that either indicates that it will find the 173 requested mapping to complete processing of the request or that the 174 DDT client should contact another DDT node that has more-specific 175 information; in the latter case, the DDT node then sends a new 176 Encapsulated Map-Request to the next DDT node and the process repeats 177 in an iterative manner. 179 Conceptually, this is similar to the way that a client of the Domain 180 Name System (DNS) follows referrals (DNS responses that contain only 181 NS records) from a series of DNS servers until it finds an answer. 183 2. Requirements Language 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 3. Definition of Terms 191 Extended EID (XEID): a LISP EID, optionally extended with a non- 192 zero Instance ID (IID) if the EID is intended for use in a context 193 where it may not be a unique value, such as on a Virtual Private 194 Network where [RFC1918] address space is used. See "Using 195 Virtualization and Segmentation with LISP" in [RFC6830] for more 196 discussion of Instance IDs. 198 XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided 199 to allow the definition of multiple databases; currently always 200 zero in this version of DDT, with other values reserved for future 201 use), 32-bit IID and 16-bit AFI prepended. Encoding of the 202 prefix, its AFI and the instance ID (IID) are specified by 203 [I-D.ietf-lisp-lcaf]. An XEID-prefix is used as a key index into 204 the database. 206 DDT node: a network infrastructure component responsible for 207 specific XEID-prefix and for delegation of more-specific sub- 208 prefixes to other DDT nodes. 210 DDT client: a network infrastructure component that sends Map- 211 Request messages and implements the iterative following of Map- 212 Referral results. Typically, a DDT client will be a Map Resolver, 213 but it is also possible for an ITR to implement DDT client 214 functionality. 216 DDT Map Server: a DDT node that also implements Map Server 217 functionality (forwarding Map-Requests and/or returning Map- 218 Replies if offering proxy Map-Reply service) for a subset of its 219 delegated prefixes. Map Server functions including proxying Map- 220 Replies are described in [RFC6833]. 222 DDT Map Resolver: a network infrastructure element that accepts a 223 Map-Request, adds the XEID to its pending request list, then 224 queries one or more DDT nodes for the requested EID, following 225 returned referrals until it receives one with action code MS-ACK 226 (or an error indication). MS-ACK indicates that the Map-Request 227 has been sent to a Map Server that will forward it to an ETR that, 228 in turn, will provide a Map-Reply to the original sender. A DDT 229 Map Resolver maintains both a cache of Map-Referral message 230 results containing RLOCs for DDT nodes responsible for XEID- 231 prefixes of interest (termed the "referral cache") and a pending 232 request list of XEIDs that are being resolved through iterative 233 querying of DDT nodes. 235 Encapsulated Map-Request: a LISP Map-Request carried within an 236 Encapsulated Control Message, which has an additional LISP header 237 prepended. Sent to UDP destination port 4342. The "outer" 238 addresses are globally-routable IP addresses, also known as RLOCs. 239 Used by an ITR when sending to a Map Resolver and by a Map Server 240 when forwarding a Map-Request to an ETR as documented in LISP-MS 241 [RFC6833]. 243 DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to 244 a DDT node. The "DDT-originated" flag is set in the encapsulation 245 header indicating that the DDT node should return Map-Referral 246 messages if the Map-Request EID matches a delegated XEID-prefix 247 known to the DDT node. Section 7.3.1 describes how DDT Map- 248 Requests are sent. Section 5 defines position of the "DDT- 249 originated" flag in the Encapsulated Control Message header. 251 Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node 252 and for which the DDT node may provide further delegations of 253 more-specific sub-prefixes. 255 Map-Referral: a LISP message sent by a DDT node in response to a DDT 256 Map-Request for an XEID that matches a configured XEID-prefix 257 delegation. A non-negative Map-Referral includes a "referral", a 258 set of RLOCs for DDT nodes that have more information about the 259 sub-prefix; a DDT client "follows the referral" by sending another 260 DDT Map-Request to one of those RLOCs to obtain either an answer 261 or another referral to DDT nodes responsible for a more-specific 262 XEID-prefix. See Section 7.1 and Section 7.3.2 for details on the 263 sending and processing of Map-Referral messages. 265 Negative Map-Referral: a Map-Referral sent in response to a DDT Map- 266 Request that matches an authoritative XEID-prefix but for which 267 there is no delegation configured (or no ETR registration if sent 268 by a DDT Map-Server). 270 Pending Request List: the set of outstanding requests for which a 271 DDT Map Resolver has received encapsulated Map-Requests from a DDT 272 client for an XEID. Each entry in the list contains additional 273 state needed by the referral following process, including the 274 requestor(s) of the XEID (typically, one or more ITRs), saved 275 information about the last referral received and followed 276 (matching XEID-prefix, action code, RLOC set, index of last RLOC 277 queried in the RLOC set), and any LISP-SEC information 278 ([I-D.ietf-lisp-sec]) that was included in the DDT client Map- 279 Request. An entry in the list may be interchangeably termed a 280 "pending request list entry" or simply a "pending request". 282 For definitions of other terms, notably Map-Request, Map-Reply, 283 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, 284 and Map Resolver, please consult the LISP specification [RFC6830] and 285 the LISP Mapping Service specification [RFC6833]. 287 4. Database organization 289 4.1. EID-prefix tree structure and instance IDs 291 LISP-DDT defines a tree structure that is indexed by a binary 292 encoding of five fields, in order of significance: DBID (16 bits), 293 Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 294 16 bits), and EID-prefix (variable, according to AFI value). The 295 fields are concatenated, with the most significant fields as listed 296 above. The index into this structure is also referred to as an 297 Extended EID-prefix (XEID-prefix). 299 It is important to note that LISP-DDT does not store actual EID-to- 300 RLOC mappings; it is, rather, a distributed index that can be used to 301 find the devices (Map Servers and their registered EIDs) that can be 302 queried with LISP to obtain those mappings. Changes to EID-to-RLOC 303 mappings are made on the ETRs which define them, not to any DDT node 304 configuration. DDT node configuration changes are only required when 305 branches of the database hierarchy are added, removed, or modified. 307 4.2. Configuring prefix delegation 309 Every DDT node is configured with one or more XEID-prefixes for which 310 it is authoritative along with a list of delegations of XEID-prefixes 311 to other DDT nodes. A DDT node is required to maintain a list of 312 delegations for all sub-prefixes of its authoritative XEID-prefixes; 313 it also may list "hints", which are prefixes that it knows about that 314 belong to its parents, to the root, or to any other point in the 315 XEID-prefix hierarchy. A delegation (or hint) consists of an XEID- 316 prefix, a set of RLOCs for DDT nodes that have more detailed 317 knowledge of the XEID-prefix, and accompanying security information 318 (for details of security infomation exchange and its use see 319 Section 10). Those RLOCs are returned in Map-Referral messages when 320 the DDT node receives a DDT Map-Request with an XEID that matches a 321 delegation. A DDT Map Server will also have a set of sub-prefixes 322 for which it accepts ETR mapping registrations and for which it will 323 forward (or answer, if it provides proxy Map-Reply service) Map- 324 Requests. 326 4.2.1. The root DDT node 328 The root DDT node is the logical "top" of the database hierarchy: 329 DBID=0, IID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches 330 no configured XEID-prefix will be referred to the root node (see 331 Section 8 for formal description of conditions when DDT Request is 332 forwarded to the root node). The root node in a particular 333 instantiation of LISP-DDT therefore MUST be configured with 334 delegations for at least all defined IIDs and AFIs. 336 5. DDT Map-Request 338 A DDT client (usualy a Map Resolver) uses LISP Encapsulated Control 339 Message (ECM) to send Map-Request to a DDT node. Format of the ECM 340 is defined by [RFC6830]. This specification adds to ECM flag "DDT- 341 originated". 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 / | IPv4 or IPv6 Header | 347 OH | (uses RLOC addresses) | 348 \ | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 / | Source Port = xxxx | Dest Port = 4342 | 351 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 \ | UDP Length | UDP Checksum | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 LH |Type=8 |S|D| Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 / | IPv4 or IPv6 Header | 357 IH | (uses RLOC or EID addresses) | 358 \ | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 / | Source Port = xxxx | Dest Port = yyyy | 361 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 \ | UDP Length | UDP Checksum | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 LCM | LISP Control Message | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 D: The "DDT-originated" flag. It is set by a DDT client to indicate 368 that the receiver SHOULD return Map-Referral messages as 369 appropriate. Use of the flag is further described in 370 Section 7.3.1. This bit is allocated from LISP message header 371 bits marked as Reserved in [RFC6830]. 373 6. The Map-Referral message 375 This specification defines a new LISP message, the Map-Referral. It 376 is sent by a DDT node to a DDT client in response to a DDT Map- 377 Request message. See Section 6.4 for a detailed layout of the Map- 378 Referral message fields. 380 The message consists of an action code along with delegation 381 information about the XEID-prefix that matches the requested XEID. 383 6.1. Action codes 385 The action codes are as follows: 387 NODE-REFERRAL (0): indicates that the replying DDT node has 388 delegated an XEID-prefix that matches the requested XEID to one or 389 more other DDT nodes. The Map-Referral message contains a "map- 390 record" with additional information, most significantly the set of 391 RLOCs to which the prefix has been delegated, that is used by a 392 DDT Map Resolver to "follow" the referral. 394 MS-REFERRAL (1): indicates that the replying DDT node has delegated 395 an XEID-prefix that matches the requested XEID to one or more DDT 396 Map Servers. It contains the same additional information as a 397 NODE-REFERRAL, but is handled slightly differently by the 398 receiving DDT client (see Section 7.3.2). 400 MS-ACK (2): indicates that a replying DDT Map Server received a DDT 401 Map-Request that matches an authoritative XEID-prefix for which it 402 has one or more registered ETRs. This means that the request has 403 been forwarded to one of those ETRs to provide an answer to the 404 querying ITR. 406 MS-NOT-REGISTERED (3): indicates that the replying DDT Map Server 407 received a Map-Request for one of its configured XEID-prefixes 408 which has no ETRs registered. 410 DELEGATION-HOLE (4): indicates that the requested XEID matches a 411 non-delegated sub-prefix of the XEID space. This is a non-LISP 412 "hole", which has not been delegated to any DDT Map Server or ETR. 413 See Section 7.1.2 for details. 415 NOT-AUTHORITATIVE (5): indicates that the replying DDT node received 416 a Map-Request for an XEID-request for which it is not 417 authoritative. This can occur if a cached referral has become 418 invalid due to a change in the database hierarchy. 420 6.2. Referral set 422 For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a 423 DDT node MUST include in the Map-Referral message a list of RLOCs for 424 DDT nodes that are authoritative for the XEID-prefix being returned; 425 a DDT Map Resolver uses this information to contact one of those DDT 426 nodes as it "follows" a referral. 428 6.3. Incomplete flag 430 A DDT node sets the "Incomplete" flag in a Map-Referral message if 431 the Referral Set is incomplete; this is intended to prevent a DDT Map 432 Resolver from caching a referral with incomplete information. A DDT 433 node MUST set the "incomplete" flag in the following cases: 435 o If it is setting action code MS-ACK or MS-NOT-REGISTERED but does 436 not have configuration for other "peer" DDT nodes that are also 437 authoritative for the matched XEID-prefix. 439 o If it is setting action code NOT-AUTHORITATIVE. 441 6.4. Map-Referral Message Format 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |Type=6 | Reserved | Record Count | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Nonce . . . | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | . . . Nonce | 451 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | Record TTL | 453 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 R | Referral Count| EID mask-len | ACT |A|I| Reserved | 455 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 c |SigCnt | Map Version Number | EID-AFI | 457 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 r | EID-prefix ... | 459 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | /| Priority | Weight | M Priority | M Weight | 461 | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | e | Unused Flags |L|p|R| Loc/LCAF-AFI | 463 | f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | \| Locator ... | 465 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | ~ Sig section ~ 467 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Type: Type value 6 was reserved for future use in RFC6830, this 470 document allocates this value to identify Map-Referral messages. 472 ACT: The "action" field of the mapping record in a Map-Referral 473 message encodes 6 action types. The values for the action types are: 475 NODE-REFERRAL (0): Sent by a DDT node with a child delegation, which 476 is authoritative for the EID. 478 MS-REFERRAL (1): Sent by a DDT node that has information about Map 479 Server(s) for the EID but it is not one of the Map Servers listed, 480 i.e. the DDT-Node sending the referral is not a Map Server. 482 MS-ACK (2): Sent by a DDT Map Server that has one or more ETR 483 registered for the EID. 485 MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured 486 for the EID-prefix, but for which no ETRs are registered. 488 DELEGATION-HOLE (4): Sent by an intermediate DDT node with 489 authoritative configuration covering the requested EID but without 490 any child delegation for the EID. Also sent by a DDT Map Server 491 with authoritative configuration covering the requested EID, but 492 for which no specific site ETR is configured. 494 NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have 495 authoritative configuration for the requested EID. The EID-prefix 496 returned MUST be the original requested EID and the TTL MUST be 497 set to 0. However, if such a DDT node has a "hint" delegation 498 covering the requested EID, it MAY choose to return NODE-REFERRAL 499 or MS-REFERRAL as appropriate. 501 Incomplete: The "I" bit indicates that a DDT node's referral-set of 502 locators is incomplete and the receiver of this message SHOULD NOT 503 cache the referral. A DDT sets the "incomplete" flag, the TTL, and 504 the Action Type field as follows: 506 ------------------------------------------------------------------- 507 Type (Action field) Incomplete Referral-set TTL values 508 ------------------------------------------------------------------- 509 0 NODE-REFERRAL NO YES 1440 511 1 MS-REFERRAL NO YES 1440 513 2 MS-ACK * * 1440 515 3 MS-NOT-REGISTERED * * 1 517 4 DELEGATION-HOLE NO NO 15 519 5 NOT-AUTHORITATIVE YES NO 0 520 ------------------------------------------------------------------- 521 *: The "Incomplete" flag setting on Map Server originated referral of 522 MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map 523 Server has the full peer Map Server configuration for the same 524 prefix and has encoded the information in the mapping record. 525 Incomplete bit is not set when the Map Server has encoded the 526 information, which means the referral-set includes all the RLOCs 527 of all Map Servers that serve the prefix. It MUST be set when the 528 Map Server has not encoded the complete Map Server set 529 information. 531 SigCnt: Indicates the number of signatures (sig section) present in 532 the Record. If SigCnt is larger than 0, the signature information 533 captured in a sig section as described in Section 6.4.1 will be 534 appended to the end of the record. The number of sig sections at the 535 end of the Record MUST match the SigCnt. Note that bits occupied by 536 SigCnt were Reserved in Records embedded into messages defined by 537 [RFC6830] and were required to be set to zero. 539 Loc/LCAF-AFI: If this is a Loc AFI, keys SHOULD NOT be included in 540 the record. If this is a LCAF AFI, the contents of the LCAF depend 541 on the Type field of the LCAF. Security material are stored in LCAF 542 Type 11. DDT nodes and Map Servers can use this LCAF Type to include 543 public keys associated with their Child DDT nodes for a XEID-prefix 544 referral record. LCAF types and formats are defined in 545 [I-D.ietf-lisp-lcaf]. 547 All other fields and their descriptions are equivalent to those in 548 the Map-Reply message, as defined in LISP [RFC6830]. Note, though, 549 that the set of RLOCs correspond to the DDT node to be queried as a 550 result of the referral not the RLOCs for an actual EID-to-RLOC 551 mapping. 553 6.4.1. SIG section 555 SigCnt counts the number of signature sections that appear at the end 556 of the Record. Format of the signature section is described below. 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 /| Original Record TTL | 560 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 / | Signature Expiration | 562 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 s | Signature Inception | 564 i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 g | Key Tag | Sig Length | 566 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 \ | Sig-Algorithm | Reserved | Reserved | 568 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 \ ~ Signature ~ 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Original Record TTL: The original Record TTL for this record that is 573 covered by the signature. Record TTL is in minutes. 575 Signature Expiration and Inception: Specify the validity period for 576 the signature. The signature MUST NOT be used for authentication 577 prior to the inception date and MUST NOT be used for authentication 578 after the expiration date. Each field specifies a date and time in 579 the form of a 32-bit unsigned number of seconds elapsed since 1 580 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte 581 order. 583 Key Tag: An identifier to specify which key is used for this 584 signature if more than one valid key exists for the signing DDT node. 586 Sig Length: The length of the Signature field. 588 Sig-Algorithm: The identifier of the cryptographic algorithm used for 589 the signature. This specification defines only one algorithm: Sig- 590 Algorithm type 1 is RSA-SHA1 (see [RFC3447]). 592 Reserved: This field MUST be set to 0 on transmit and MUST be ignored 593 on receipt. 595 Signature: Contains the cryptographic signature that covers the 596 entire record. The Record TTL and the sig fields are set to zero for 597 the purpose of computing the Signature. 599 7. DDT network elements and their operation 601 As described above, DDT introduces a new network element, the "DDT 602 node", extends the functionality of Map Servers and Map Resolvers to 603 send and receive Map-Referral messages. The operation of each of 604 these devices is described as follows. 606 7.1. DDT node 608 When a DDT node receives a DDT Map-Request, it compares the requested 609 XEID against its list of XEID-prefix delegations and its list of 610 authoritative XEID-prefixes and acts as follows: 612 7.1.1. Match of a delegated prefix (or sub-prefix) 614 If the requested XEID matches one of the DDT node's delegated 615 prefixes, then a Map-Referral message is returned with the matching 616 more-specific XEID-prefix and the set of RLOCs for the referral 617 target DDT nodes including associated security information (see 618 Section 10 for details on security). If the delegation is known to 619 be a DDT Map Server, then the Map-Referral message SHOULD be sent 620 with action code MS-REFERRAL to indicate to the receiver that LISP- 621 SEC information (if saved in the pending request) SHOULD be included 622 in the next DDT Map-Request; otherwise, the action code NODE-REFERRAL 623 SHOULD be used. 625 Note that a matched delegation does not have to be for a sub-prefix 626 of an authoritative prefix; in addition to being configured to 627 delegate sub-prefixes of an authoritative prefix, a DDT node may also 628 be configured with other XEID-prefixes for which it can provide 629 referrals to DDT nodes anywhere in the database hierarchy. This 630 capability to define "shortcut hints" is never required to be 631 configured, but may be a useful heuristic for reducing the number of 632 iterations needed to find an EID, particular for private network 633 deployments. 635 7.1.2. Missing delegation from an authoritative prefix 637 If the requested XEID did not match a configured delegation but does 638 match an authoritative XEID-prefix, then the DDT node MUST return a 639 negative Map-Referral that uses the least-specific XEID-prefix that 640 does not match any XEID-prefix delegated by the DDT node. The action 641 code is set to DELEGATION-HOLE; this indicates that the XEID is not a 642 LISP destination. 644 If the requested XEID did not match either a configured delegation or 645 an authoritative XEID-prefix, then negative Map-Referral with action 646 code NOT-AUTHORITATIVE MUST be returned. 648 7.2. DDT Map Server 650 When a DDT Map Server receives a DDT Map-Request, its operation is 651 similar to that of a DDT node with additional processing as follows: 653 o If the requested XEID matches a registered XEID-prefix, then the 654 Map-Request is forwarded to one of the destination ETR RLOCs (or 655 the Map Server sends a Map-Reply, if it is providing proxy Map- 656 Reply service) and a Map-Referral with the MS-ACK action MUST be 657 returned to the sender of the DDT Map-Request. 659 o If the requested XEID matches a configured XEID-prefix for which 660 no ETR registration has been received then a negative Map-Referral 661 with action code MS-NOT-REGISTERED MUST be returned to the sender 662 of the DDT Map-Request. 664 7.3. DDT Map Resolver 666 Just as any other Map Resolver, a DDT Map Resolver accepts Map- 667 Requests from its clients (typically, ITRs) and ensures that those 668 Map-Requests are forwarded to the correct ETR, which generates Map- 669 Replies. Unlike a Map Resolver that uses the ALT mapping system (see 670 [RFC6836]), however, a DDT Map Resolver uses an iterative process of 671 following referrals to find the correct ETR to answer a Map-Request; 672 this requires a DDT Map Resolver to maintain additional state: a Map- 673 Referral cache and pending request list of XEIDs that are going 674 through the iterative referral process. 676 7.3.1. Queuing and sending DDT Map-Requests 678 When a DDT Map Resolver receives an encapsulated Map-Request, it 679 first performs a longest-match search for the XEID in its referral 680 cache. If no match is found or if a negative cache entry is found, 681 then the destination is not in the database; a negative Map-Reply 682 MUST be returned and no further processing is performed by the DDT 683 Map Resolver. 685 If a match is found, the DDT Map Resolver creates a pending request 686 list entry for the XEID and saves the original Map-Request (minus the 687 encapsulation header) along with other information needed to track 688 progress through the iterative referral process; the "referral XEID- 689 prefix" is also initialized to the null value since no referral has 690 yet been received. The Map Resolver then creates a DDT Map-Request 691 (which is an encapsulated Map-Request with the "DDT-originated" flag 692 set in the message header) for the XEID but without any 693 authentication data that may have been included in the original Map- 694 Request. It sends the DDT Map-Request to one of the RLOCs in the 695 chosen referral cache entry. The referral cache is initially 696 populated with one or more statically-configured entries; additional 697 entries are added when referrals are followed, as described below. A 698 DDT Map Resolver is not absolutely required to cache referrals, but 699 it doing so decreases latency and reduces lookup delays. 701 Note that in normal use on the public Internet, the statically- 702 configured initial referral cache for a DDT Map Resolver should 703 include a "default" entry with RLOCs for one or more DDT nodes that 704 can reach the DDT root node. If a Map Resolver does not have such 705 configuration, it will return a Negative Map-Reply if it receives a 706 query for an EID outside the subset of the mapping database known to 707 it. While this may be desirable on private network deployments or 708 during early transition to LISP when few sites are using it, this 709 behavior is not appropriate when LISP is in general use on the 710 Internet. 712 7.3.2. Receiving and following referrals 714 After sending a DDT Map-Request, a DDT Map Resolver expects to 715 receive a Map-Referral response. If none occurs within the timeout 716 period, the DDT Map Resolver retransmits the request, sending to the 717 next RLOC in the referral cache entry if one is available. If the 718 maximum number of retransmissions has occurred and all RLOCs have 719 been tried, then the pending request list entry is dequeued. 721 A DDT Map Resolver processes a received Map-Referral message 722 according to each action code: 724 NODE-REFERRAL: The DDT Map Resolver checks for a possible referral 725 loop as as described in Section 7.3.4. If no loop is found, the 726 DDT Map Resolver saves the prefix returned in the Map-Referral 727 message in the referral cache, updates the saved prefix and saved 728 RLOCs in the pending request list entry, and follows the referral 729 by sending a new DDT Map-Request to one of the DDT node RLOCs 730 listed in the Referral Set; security information saved with the 731 original Map-Request SHOULD NOT be included. 733 MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same 734 manner as a NODE-REFERRAL except that security information saved 735 with the original Map-Request MUST be included in the new Map- 736 Request sent to a Map Server (see Section 10 for details on 737 security). 739 MS-ACK: This is returned by a DDT Map Server to indicate that it has 740 one or more registered ETRs that can answer a Map-Request for the 741 XEID and the request has been forwarded to one of them (or if the 742 Map Server is doing proxy service for the prefix then reply has 743 been sent to the querying ITR). If the pending request did not 744 include saved LISP-SEC information or if that information was 745 already included in the previous DDT Map-Request (sent by the DDT 746 Map Resolver in response to either an MS-REFERRAL or a previous 747 MS-ACK referral), then the pending request for the XEID is 748 complete; processing of the request stops and all request state 749 can be discarded. Otherwise, LISP-SEC information is required and 750 has not yet been sent to the authoritative DDT Map-Server; the DDT 751 Map Resolver MUST re-send the DDT Map-Request with LISP-SEC 752 information included and the pending request queue entry remains 753 until another Map-Referral with MS-ACK action code is received. 754 If the "incomplete" flag is not set, the prefix is saved in the 755 referral cache. 757 MS-NOT-REGISTERED: The DDT Map Server queried could not process the 758 request because it did not have any ETRs registered for a 759 matching, authoritative XEID-prefix. If the DDT Map Resolver has 760 not yet tried all of the RLOCs saved with the pending request, 761 then it sends a Map-Request to the next RLOC in that list. If all 762 RLOCs have been tried, then the destination XEID is not registered 763 and is unreachable. The DDT Map Resolver MUST return a negative 764 Map-Reply to the original Map-Request sender; this Map-Reply 765 contains the non-registered XEID-prefix whose TTL value SHOULD be 766 set to one minute. A negative referral cache entry is created for 767 the prefix (whose TTL also SHOULD be set to one minute) and 768 processing of the request stops. 770 DELEGATION-HOLE: The DDT Map Server queried did not have an XEID- 771 prefix defined that matched the requested XEID so it does not 772 exist in the mapping database. The DDT Map Resolver MUST return a 773 negative Map-Reply to the original Map-Request sender; this Map- 774 Reply SHOULD indicate the least-specific XEID-prefix matching the 775 requested XEID for which no delegations exist and SHOULD have a 776 TTL value of 15 minutes. A negative referral cache entry is 777 created for the prefix (which also SHOULD have TTL of 15 minutes) 778 and processing of the pending request stops. 780 NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative 781 for the requested XEID. This can occur if a cached referral has 782 become invalid due to a change in the database hierarchy. If the 783 DDT Map Resolver receiving this message can determine that it is 784 using old cached information, it MAY choose to delete that cached 785 information and re-try the original Map-Request, starting from its 786 "root" cache entry. If this action code is received in response 787 to a query that did not use a cached referral information, then it 788 indicates a database synchronization problem or configuration 789 error. The pending request is silently discarded, i.e. all state 790 for the request that caused this answer is removed and no answer 791 is returned to the original requestor. 793 7.3.3. Handling referral errors 795 Other states are possible, such as a misconfigured DDT node (acting 796 as a proxy Map Server, for example) returning a Map-Reply to the DDT 797 Map Resolver; they should be considered errors and logged as such. 798 It is not clear exactly what else the DDT Map Resolver should do in 799 such cases; one possibility is to remove the pending request list 800 entry and send a negative Map-Reply to the original Map-Request 801 sender. Alternatively, if a DDT Map Resolver detects unexpected 802 behavior by a DDT node, it could mark that node as unusable in its 803 referral cache and update the pending request to try a different DDT 804 node if more than one is listed in the referral cache. In any case, 805 any prefix contained in a Map-Referral message that causes a referral 806 error (including a referral loop) is not saved in the DDT Map- 807 Resolver referral cache. 809 7.3.4. Referral loop detection 811 In response to a Map-Referral message with action code NODE-REFERRAL 812 or MS-REFERRAL, a DDT Map Resolver is directed to query a new set of 813 DDT node RLOCs that are expected to have more-specific XEID-prefix 814 information for the requested XEID. To prevent a possible "iteration 815 loop" (following referrals back-and-forth among a set of DDT nodes 816 without ever finding an answer), a DDT Map Resolver saves the last 817 received referral XEID-prefix for each pending request and checks 818 that a newly received NODE-REFERRAL or MS-REFERRAL message contains a 819 more-specific referral XEID-prefix; an exact or less-specific match 820 of the saved XEID-prefix indicates a referral loop. If a loop is 821 detected, the DDT Map Resolver handles the request as described in 822 Section 7.3.3. Otherwise, the Map Resolver saves the most recently 823 received referral XEID-prefix with the pending request when it 824 follows the referral. 826 As an extra measure to prevent referral loops, it is probably also 827 wise to limit the total number of referrals for any request to some 828 reasonable number; the exact value of that number will be determined 829 during experimental deployment of LISP-DDT, but is bounded by the 830 maximum length of the XEID. 832 Note that when a DDT Map Resolver adds an entry to its lookup queue 833 and sends an initial Map-Request for an XEID, the queue entry has no 834 previous referral XEID-prefix; this means that the first DDT node 835 contacted by a DDT Map Resolver may provide a referral to anywhere in 836 the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use 837 essentially any DDT node RLOCs for its initial cache entries and 838 depend on the initial referral to provide a good starting point for 839 Map-Requests; there is no need to configure the same set of root DDT 840 nodes on all DDT Map Resolvers. 842 8. Pseudo Code and Decision Tree diagrams 844 To aid in implementation, each of the major DDT Map Server and DDT 845 Map Resolver functions are described below, first using simple 846 "psuedo-code" and then in the form of a decision tree. 848 8.1. Map Resolver processing of ITR Map-Request 850 8.1.1. Pseudo-code summary 852 if ( request pending i.e., (ITR,EID) of request same ) { 853 replace old request with new & use new request nonce 854 for future requests 855 } else if ( no match in refcache ) { 856 return negative map-reply to ITR 857 } else if ( match type delegation hole ) { 858 return negative map-reply to ITR 859 } else if ( match type ms-ack ) { 860 fwd DDT request to map-server 861 } else { 862 store & fwd DDT request w/o security material to node delegation 863 } 865 8.1.2. Decision tree diagram 866 +------------+ 867 | Is Request | Yes 868 | |----> Replace old request with 869 | Pending? | new nonce for future requests 870 +------------+ 871 | 872 |No 873 | 874 V 875 +------------+ 876 | Match In | No 877 | Referral |----> Send Negative Map-Reply 878 | cache? | (not a likely event as root 879 +------------+ configured on every MR) 880 | 881 |Yes 882 | 883 V 884 +------------+ 885 | Match Type | Yes 886 | Delegation |----> Send Negative Map-Reply 887 | Hole? | 888 +------------+ 889 | 890 |No 891 | 892 V 893 +------------+ 894 | Match Type | Yes 895 | MS-ACK? |----> Forward DDT Map-request to Map-Server 896 | | 897 +------------+ 898 | 899 |No 900 | 901 V 902 Store request & Fwd DDT Request w/o security material 903 to DDT node delegation 905 8.2. Map Resolver processing of Map-Referral message 907 8.2.1. Pseudo-code summary 909 if ( no request pending matched by referral nonce ) { 910 silently drop 911 } 913 if ( pfx in referral less specific than last referral used ) { 914 if ( gone through root ) { 915 silently drop 916 } else { 917 send request to root 918 } 919 } 921 switch (map_referral_type) { 923 case NOT_AUTHORITATIVE : 924 if ( gone through root ) { 925 return negative map-reply to ITR 926 } else { 927 send request to root 928 } 930 case DELEGATION_HOLE: 931 cache & send negative map-reply to ITR 933 case MS_REFERRAL: 934 if ( referral equal to last used ) { 935 if ( gone through root ) { 936 return negative map-reply to ITR 937 } else { 938 send request to root 939 } 940 } else { 941 cache 942 follow the referral, include security material 943 } 945 case NODE_REFERRAL: 946 if ( referral equal to last used ) { 947 if ( gone through root ) { 948 return negative map-reply to ITR 949 } else { 950 send request to root 951 } 952 } else { 953 cache 954 follow the referral, strip security material 955 } 957 case MS_ACK: 958 if ( security material stripped ) { 959 resend request with security material 960 if { !incomplete } { 961 cache 963 } 964 } 966 case MS_NOT_REGISTERED: 967 if { all map-server delegations not tried } { 968 follow delegations not tried 969 if ( !incomplete ) { 970 cache 971 } 972 } else { 973 send negative map-reply to ITR 974 if { !incomplete } { 975 cache 976 } 977 } 979 case DEFAULT: 980 drop 981 } 982 } 984 8.2.2. Decision tree diagram 985 +------------+ 986 | Is Request | No 987 | Pending? |----> Silently drop 988 +------------+ 989 | Yes 990 V 991 +------------------------------+ Yes 992 | Pfx less specific than last? |----> Silently drop 993 +------------------------------+ 994 |No 995 V 996 +---------------------------------------------------+ 997 | What is Map-Referral Type? |--UNKNOWN-+ 998 +---------------------------------------------------+ | 999 | | | | | | V 1000 | | | | | DEL_HOLE DROP 1001 | | | | MS_ACK | 1002 | | | | | V 1003 | | MS_REF NODE_REF | Cache & return 1004 | | | | V negative map-reply 1005 | | | | +---------+ 1006 | NOT_AUTH | | | Was sec | Yes 1007 | | | | | material| 1008 | | | | |Stripped?|----> Done 1009 | | V V +---------+ 1010 | | +------------+ | No 1011 | | Yes | Pfx equal | V 1012 MS_NOT_REGISTERED | +---| to last | +------------+ 1013 | | | | used? | | Incomplete | Yes 1014 | | | +------------+ | bit set? |---> Resend DDT 1015 | V V |No +------------+ request w 1016 | +------------+ | |No security 1017 | | Gone | V | material 1018 | | Through | Cache & follow V 1019 | | Root? | the referral Cache & resend DDT 1020 | +------------+ request with 1021 | |No |Yes security material 1022 | | | 1023 | V V 1024 | Send req Send negative map-reply 1025 | to root 1026 V 1027 +-----------+ Yes +-----------+ Yes 1028 | Other MS |----Follow other MS-------->|Incomplete |----> Don't cache 1029 | not tried?| |bit set? | 1030 | |---Send negative map-reply->| |----> Cache 1031 +-----------+ No +-----------+ No 1033 8.3. DDT Node processing of DDT Map-Request message 1035 8.3.1. Pseudo-code summary 1037 if ( I am not authoritative ) { 1038 send map-referral NOT_AUTHORITATIVE with 1039 incomplete bit set and ttl 0 1040 } else if ( delegation exists ) { 1041 if ( delegated map-servers ) { 1042 send map-referral MS_REFERRAL with 1043 ttl 'Default_DdtNode_Ttl' 1044 } else { 1045 send map-referral NODE_REFERRAL with 1046 ttl 'Default_DdtNode_Ttl' 1047 } 1048 } else { 1049 if ( eid in site) { 1050 if ( site registered ) { 1051 forward map-request to etr 1052 if ( map-server peers configured ) { 1053 send map-referral MS_ACK with 1054 ttl 'Default_Registered_Ttl' 1055 } else { 1056 send map-referral MS_ACK with 1057 ttl 'Default_Registered_Ttl' and incomplete bit set 1058 } 1059 } else { 1060 if ( map-server peers configured ) { 1061 send map-referral MS_NOT_REGISTERED with 1062 ttl 'Default_Configured_Not_Registered_Ttl' 1063 } else { 1064 send map-referral MS_NOT_REGISTERED with 1065 ttl 'Default_Configured_Not_Registered_Ttl' 1066 and incomplete bit set 1067 } 1068 } 1069 } else { 1070 send map-referral DELEGATION_HOLE with 1071 ttl 'Default_Negative_Referral_Ttl' 1072 } 1073 } 1075 where architectural constants for TTL are set as follows: 1077 Default_DdtNode_Ttl 1440 minutes 1078 Default_Registered_Ttl 1440 minutes 1079 Default_Negative_Referral_Ttl 15 minutes 1080 Default_Configured_Not_Registered_Ttl 1 minute 1082 8.3.2. Decision tree diagram 1084 +------------+ 1085 | Am I | No 1086 | Authori- |----> Return NOT_AUTHORITATIVE 1087 | tative? | Incomplete = 1 1088 +------------+ ttl = Default_DdtNode_Ttl 1089 | 1090 |Yes 1091 | 1092 V 1093 +------------+ +------------+ 1094 | Delegation | Yes | Delegations| Yes 1095 | Exists? |---->| are map |----> Return MS_REFERRAL 1096 | | | servers? | ttl = Default_DdtNode_Ttl 1097 +------------+ +------------+ 1098 | \ No 1099 |No +--> Return NODE_REFERRAL 1100 | ttl = Default_DdtNode_Ttl 1101 V 1102 +------------+ +------------+ +------------+ 1103 | EID in | Yes | Site | Yes | Map-server | 1104 | Site |---->| Registered?|----> Forward---->| peers | 1105 | Config? | | | Map-request | configured?| 1106 +------------+ +------------+ to ETR +------------+ 1107 | | | | 1108 | |No No| |Yes 1109 | | | | 1110 | | V V 1111 | | Return MS_ACK Return MS_ACK 1112 | V with INC=1 1113 | +------------+ ttl=Default_Registered_Ttl 1114 | | Map-server | Yes 1115 | | peers |----> Return MS_NOT_REGISTERED 1116 | | configured?| ttl = Default_Negative_Referral_Ttl 1117 | +------------+ 1118 | \ No 1119 |No +--> Return MS_NOT_REGISTERED 1120 | Incomplete = 1 1121 V ttl = Default_Negative_Referral_Ttl 1122 Return DELEGATION_HOLE 1123 ttl = Default_Negative_Referral_Ttl 1125 9. Example topology and request/referral following 1127 This chapter shows example DDT tree and several possible scenarios of 1128 Map-Requests coming to a Map Resolver and subsequent iterative DDT 1129 referrals. For the sake of example RLOCs of DDT nodes are shown in 1130 IPv4 address space while the EIDs are in IPv6 AF. The same principle 1131 of hierarchical delegation and pinpointing referrals is equally 1132 applicable to any AF whose address hierarchy can be expressed as a 1133 bitstring with associated length. DDT tree of IPv4 prefixes is 1134 another AF with immediate practical value. 1136 To show how referrals are followed to find the RLOCs for a number of 1137 EIDs, consider the following example EID topology for DBID=0, IID=0, 1138 AFI=2, and EID=0/0 1140 +---------------------+ +---------------------+ 1141 | root1: 192.0.2.1 | | root2: 192.0.2.2 | 1142 | authoritative: ::/0 | | authoritative: ::/0 | 1143 +---------------------+ +---------------------+ 1144 | \ / | 1145 | \ / | 1146 | / \ | 1147 | / \ | 1148 | | | | 1149 V V V V 1150 +-------------------------+ +--------------------------+ 1151 | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | 1152 | authoritative: | | authoritative: | 1153 | 2001:db8::/32 | | 2001:db8::/32 | 1154 +-------------------------+ +--------------------------+ 1155 | \ / | 1156 | \ / | 1157 | / \ | 1158 | / \ | 1159 | | | | 1160 V V V V 1161 +--------------------------+ +---------------------------+ 1162 | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | 1163 | authoritative: | | authoritative: | 1164 | 2001:db8:0100::/40 | | 2001:db8:0500::/40 | 1165 | site1: 2001:db8:0103::/48| +---------------------------+ 1166 | site2: 2001:db8:0104::/48| | | 1167 +--------------------------+ | | 1168 | | 1169 | | 1170 V V 1171 +---------------------------+ +---------------------------+ 1172 | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | 1173 | authoritative: | | authoritative: | 1174 | 2001:db8:0500::/48 | | 2001:db8:0501::/48 | 1175 |site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64| 1176 |site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64| 1177 +---------------------------+ +---------------------------+ 1179 DDT nodes are configured for this "root" at IP addresses 192.0.2.1 1180 and 192.0.2.2. DDT Map Resolvers are configured with default 1181 referral cache entries to these addresses. 1183 The root DDT nodes delegate 2001:db8::/32 to two DDT nodes with IP 1184 addresses 192.0.2.11 and 192.0.2.12. 1186 The DDT nodes for 2001:db8::/32 delegate 2001:db8:0100::/40 to a DDT 1187 Map Server with RLOC 192.0.2.101 1189 The DDT Map Server for 2001:db8:0100::/40 is configured to allow ETRs 1190 to register the sub-prefixes 2001:db8:0103::/48 and 1191 2001:db8:0104::/48 1193 The DDT nodes for 2001:db8::/32 also delegate 2001:db8:0500::/40 to a 1194 DDT node with RLOC 192.0.2.201 1196 The DDT node for 2001:db8:0500::/40 is further configured to delegate 1197 2001:db8:0500::/48 to a DDT Map Server with RLOC 192.0.2.211 and 1198 2001:db8:0501::/48 to a DDT Map Server with RLOC 192.0.2.221 1200 The DDT Map Server for 2001:db8:0500::/48 is configured to allow ETRs 1201 to register the sub-prefixes 2001:db8:0500:1::/64 and 1202 2001:db8:0500:2::/64 1204 The DDT Map Server for 2001:db8:0501::/48 is configured to allow ETRs 1205 to register the sub-prefixes 2001:db8:0501:8::/64 and 1206 2001:db8:0501:9::/64 1208 9.1. Lookup of 2001:db8:0103:1::1/128 1210 The first example shows a DDT Map Resolver following a delegation 1211 from the root to a DDT node followed by another delegation to a DDT 1212 Map Server. 1214 ITR1 sends an Encapsulated Map-Request for 2001:db8:0103:1::1 to one 1215 of its configured (DDT) Map Resolvers. The DDT Map Resolver proceeds 1216 as follows: 1218 1. Send DDT Map-Request (for 2001:db8:0103:1::1) to one of the root 1219 DDT nodes, 192.0.2.1 or 192.0.2.2 1221 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1222 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11, 1223 192.0.2.12) 1225 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1226 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1227 2001:db8:0100::/40, action code MS-REFERRAL, RLOC set 1228 (192.0.2.101) 1230 5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated 1231 Encapsulated Map-Request had a LISP-SEC signature, it is included 1233 6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1234 and forwards to a registered site1 ETR for 2001:db8:0103::/48 1236 7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1237 EID-prefix 2001:db8:0103::/48, action code MS-ACK to the DDT Map 1238 Resolver 1240 8. DDT Map Resolver receives Map-Referral message and dequeues the 1241 pending request for 2001:db8:0103:1::1 1243 9. site1 ETR for 2001:db8:0103::/48 receives Map-Request forwarded 1244 by DDT Map Server and sends Map-Reply to ITR1 1246 9.2. Lookup of 2001:db8:0501:8:4::1/128 1248 The next example shows a three-level delegation: root to first DDT 1249 node, first DDT node to second DDT node, second DDT node to DDT Map 1250 Server. 1252 ITR2 sends an Encapsulated Map-Request for 2001:db8:0501:8:4::1 to 1253 one of its configured (DDT) Map Resolvers, which are different from 1254 those for ITR1. The DDT Map Resolver proceeds as follows: 1256 1. Send DDT Map-Request (for 2001:db8:0501:8:4::1) to one of the 1257 root DDT nodes, 192.0.2.1 or 192.0.2.2 1259 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1260 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11, 1261 192.0.2.12) 1263 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1265 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1266 2001:db8:0500::/40, action code NODE-REFERRAL, RLOC set 1267 (192.0.2.201) 1269 5. Send DDT Map-Request to 192.0.2.201 1271 6. Receive (and save in referral cache) Map-Referral for EID-prefix 1272 2001:db8:0501::/48, action code MS-REFERRAL, RLOC set 1273 (192.0.2.221) 1275 7. Send DDT Map-Request to 192.0.2.221; if the ITR-originated 1276 Encapsulated Map-Request had a LISP-SEC signature, it is 1277 included 1279 8. DDT Map Server at 192.0.2.221 decapsulates the DDT Map-Request 1280 and forwards to a registered site5 ETR for 2001:db8:0501:8::/64 1282 9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for 1283 EID-prefix 2001:db8:0501:8::/64, action code MS-ACK, to the DDT 1284 Map Resolver 1286 10. DDT Map Resolver receives Map-Referral(MS-ACK) message and 1287 dequeues the pending request for 2001:db8:0501:8:4::1 1289 11. site5 ETR for 2001:db8:0501:8::/64 receives Map-Request 1290 forwarded by DDT Map Server and sends Map-Reply to ITR2 1292 9.3. Lookup of 2001:db8:0104:2::2/128 1294 This example shows how a DDT Map Resolver uses a saved referral cache 1295 entry to skip the referral process and go directly to a DDT Map 1296 Server for a prefix that is similar to one previously requested. 1298 In this case, ITR1 uses the same Map Resolver used in example 1299 Section 9.1. It sends an Encapsulated Map-Request for 1300 2001:db8:0104:2::2 to that (DDT) Map Resolver. The DDT Map-Resolver 1301 finds an MS-REFERRAL cache entry for 2001:db8:0100::/40 with RLOC set 1302 (192.0.2.101) and proceeds as follows: 1304 1. Send DDT Map-Request (for 2001:db8:0104:2::2) to 192.0.2.101; if 1305 the ITR-originated Encapsulated Map-Request had a LISP-SEC 1306 signature, it is included 1308 2. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1309 and forwards to a registered site2 ETR for 2001:db8:0104::/48 1311 3. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1312 EID-prefix 2001:db8:0104::/48, action code MS-ACK to the DDT Map 1313 Resolver 1315 4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1316 pending request for 2001:db8:0104:2::2 1318 5. site2 ETR for 2001:db8:0104::/48 receives Map-Request and sends 1319 Map-Reply to ITR1 1321 9.4. Lookup of 2001:db8:0500:2:4::1/128 1323 This example shows how a DDT Map Resolver uses a saved referral cache 1324 entry to start the referral process at a non-root, intermediate DDT 1325 node for a prefix that is similar to one previously requested. 1327 In this case, ITR2 asks the same Map Resolver used in example 1328 Section 9.2. It sends an Encapsulated Map-Request for 1329 2001:db8:0500:2:4::1 to that (DDT) Map Resolver, which finds a NODE- 1330 REFERRAL cache entry for 2001:db8:0500::/40 with RLOC set 1331 (192.0.2.201). It proceeds as follows: 1333 1. Send DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201 1335 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1336 2001:db8:0500::/48, action code MS-REFERRAL, RLOC set 1337 (192.0.2.211) 1339 3. Send DDT Map-Request to 192.0.2.211; if the ITR-originated 1340 Encapsulated Map-Request had a LISP-SEC signature, it is included 1342 4. DDT Map Server at 192.0.2.211 decapsulates the DDT Map-Request 1343 and forwards to a registered site4 ETR for 2001:db8:0500:2::/64 1345 5. DDT Map Server at 192.0.2.211 sends a Map-Referral message for 1346 EID-prefix 2001:db8:0500:2::/64, action code MS-ACK to the DDT 1347 Map Resolver 1349 6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1350 pending request for 2001:db8:0500:2:4::1 1352 7. site4 ETR for 2001:db8:0500:2::/64 receives Map-Request and sends 1353 Map-Reply to ITR2 1355 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) 1357 This example uses the cached MS-REFERRAL for 2001:db8:0500::/48 1358 learned above to start the lookup process at the DDT Map-Server at 1359 192.0.2.211. The DDT Map Resolver proceeds as follows: 1361 1. Send DDT Map-Request (for 2001:db8:0500::1) to 192.0.2.211; if 1362 the ITR-originated Encapsulated Map-Request had a LISP-SEC 1363 signature, it is included 1365 2. DDT Map Server at 192.0.2.211, which is authoritative for 1366 2001:db8:0500::/48, does not have a matching delegation for 1367 2001:db8:0500::1. It responds with a Map-Referral message for 1368 2001:db8:0500::/64, action code DELEGATION-HOLE to the DDT Map 1369 Resolver. The prefix 2001:db8:0500::/64 is used because it is 1370 the least-specific prefix that does match the requested EID, but 1371 does not match one of configured delegations 1372 (2001:db8:0500:1::/64 and 2001:db8:0500:2::/64). 1374 3. DDT Map Resolver receives the delegation, adds a negative 1375 referral cache entry for 2001:db8:0500::/64, dequeues the pending 1376 request for 2001:db8:0500::1, and returns a negative Map-Reply to 1377 ITR2. 1379 10. Securing the database and message exchanges 1381 This section specifies the DDT security architecture that provides 1382 data origin authentication, data integrity protection, and XEID- 1383 prefix delegation. Global XEID-prefix authorization is out of the 1384 scope of this document. 1386 Each DDT node is configured with one or more public/private key 1387 pair(s) that are used to digitally sign referral records for XEID- 1388 prefix(es) that the DDT node is authoritative for. In other words, 1389 each public/private key pair is associated with the combination of a 1390 DDT node and the XEID-prefix that it is authoritative for. Every DDT 1391 node is also configured with the public keys of its children DDT 1392 nodes. By including public keys of target child DDT nodes in the 1393 Map-Referral records, and signing each record with the DDT node's 1394 private key, a DDT node can securely delegate sub-prefixes of its 1395 authoritative XEID-prefixes to its children DDT nodes. 1397 Map Resolvers are configured with one or more trusted public keys 1398 referred to as trust anchors. Trust anchors are used to authenticate 1399 the DDT security infrastructure. Map Resolvers can discover a DDT 1400 node's public key either by having it configured as a trust anchor, 1401 or by obtaining it from the node's parent as part of a signed Map- 1402 Referral. When a public key is obtained from a node's parent, it is 1403 considered trusted if it is signed by a trust anchor, or if it is 1404 signed by a key that was previously trusted. Typically, in a Map 1405 Resolver, the root DDT node public keys should be configured as trust 1406 anchors. Once a Map Resolver authenticates a public key it locally 1407 caches the key along with the associated DDT node RLOC and XEID- 1408 prefix for future use. 1410 10.1. XEID-prefix Delegation 1412 In order to delegate XEID sub-prefixes to its children, a parent DDT 1413 node signs its Map-Referrals. Every signed Map-Referral MUST also 1414 include the public keys associated with each child DDT node. Such a 1415 signature indicates that the parent node is delegating the specified 1416 XEID-prefix to a given child DDT node. The signature is also 1417 authenticating the public keys associated with the children nodes, 1418 and authorizing them to be used by the children DDT nodes to provide 1419 origin authentication and integrity protection for further 1420 delegations and mapping information of the XEID-prefix allocated to 1421 the DDT node. 1423 As a result, for a given XEID-prefix, a Map Resolver can form an 1424 authentication chain from a configured trust anchor (typically the 1425 root DDT node) to the leaf nodes (Map Servers). Map Resolvers 1426 leverage this authentication chain to verify the Map-Referral 1427 signatures while walking the DDT tree until they reach a Map Server 1428 authoritative for the given XEID-prefix. 1430 10.2. DDT node operation 1432 Upon receiving a Map-Request, the DDT node responds with a Map- 1433 Referral as specified in Section 7. For every record present in the 1434 Map-Referral, the DDT node also includes the public keys associated 1435 with the record's XEID-prefix and the RLOCs of the children DDT 1436 nodes. Each record contained in the Map-Referral is signed using the 1437 DDT node's private key. 1439 10.2.1. DDT public key revocation 1441 The node that owns a public key can also revoke that public key. For 1442 instance if a parent node advertises a public key for one of its 1443 child DDT nodes, the child DDT node can at a later time revoke that 1444 key. Since DDT nodes do not keep track of the Map Resolvers that 1445 query them, revocation is done in a pull model, where the Map 1446 Resolver is informed of the revocation of a key only when it queries 1447 the node that owns that key. If the parent DDT is configured to 1448 advertise this key, the parent node must also be signaled to remove 1449 the key from the records it advertises for the child DDT node; this 1450 is necessary to avoid further distribution of the revoked key. 1452 To securely revoke a key, the DDT node creates a new Record for the 1453 associated XEID-prefix and locator, including the revoked key with 1454 the R bit set. The DDT node must also include a signature in the 1455 Record that covers this record; this is computed using the private 1456 key corresponding to the key being revoked. Such a record is termed 1457 a "revocation record". By including this record in its Map- 1458 Referrals, the DDT node informs querying Map Resolvers about the 1459 revoked key. A digital signature computed with a revoked key can 1460 only be used to authenticate the revocation, and SHOULD NOT be used 1461 to validate any data. To prevent a compromised key from revoking 1462 other valid keys, a given key can only be used to sign a revocation 1463 for that specific key; it cannot be used to revoke other keys. This 1464 prevents the use of a compromised key to revoke other valid keys as 1465 described in [RFC5011]. A revocation record MUST be advertised for a 1466 period of time equal to or greater than the TTL value of the Record 1467 that initially advertised the key, starting from the time that the 1468 advertisement of the key was stopped by removal from the parent DDT 1469 node. 1471 10.3. Map Server operation 1473 Similar to a DDT node, a Map Server is configured with one (or more) 1474 public/private key pairs that it must use to sign Map-Referrals. 1476 However unlike DDT nodes, Map Servers do not delegate prefixes and as 1477 a result they do not need to include keys in the Map-Referrals they 1478 generate. 1480 10.4. Map Resolver operation 1482 Upon receiving a Map-Referral, the Map Resolver MUST first verify the 1483 signature(s) by using a trust anchor, or a previously authenticated 1484 public key, associated with the DDT node sending the Map-Referral. 1485 If multiple authenticated keys are associated with the DDT node 1486 sending this Map-Referral, the Key Tag field of the signature can be 1487 used to select the right public key for verifying the signature. If 1488 the key tag matches more than one key associated with that DDT node, 1489 the Map Resolver MUST try verifying the signature with all matching 1490 keys. For every matching key that is found the Map Resolver MUST 1491 also verify that the key is authoritative for the XEID-prefix in the 1492 Map-Referral record. If such a key is found, the Map Resolver MUST 1493 use it to verify the associated signature in the record. If no 1494 matching key is found, or if none of the matching keys is 1495 authoritative for the XEID-prefix in the Map-Referral record, or if 1496 such a key is found but the signature is not valid the Map-Referral 1497 record is considered corrupted and MUST be discarded. This may be 1498 due to expired keys. The Map Resolver MAY try other siblings of this 1499 node if there is an alternative node authoritative for the same 1500 prefix. If not, the Map Resolver CAN query the DDT node's parent to 1501 retrieve a valid key. It is good practice to use a counter or timer 1502 to avoid repeating this process if the resolver cannot verify the 1503 signature after several trials. 1505 Once the signature is verified, the Map Resolver has verified the 1506 XEID-prefix delegation in the Map-Referral, and authenticated the 1507 public keys of the children DDT nodes. The Map Resolver must add 1508 these keys to the authenticated keys associated with each child DDT 1509 node and XEID-prefix. These keys are considered valid for the 1510 duration specified in the record's TTL field. 1512 11. Open Issues and Considerations 1514 There are a number of issues with the organization of the mapping 1515 database that need further investigation. Among these are: 1517 o Defining an interface to implement interconnection and/or 1518 interoperability with other mapping databases, such as LISP+ALT. 1520 o Additional key structures for use with LISP-DDT, such as to 1521 support additional EID formats as defined in [I-D.ietf-lisp-lcaf] 1523 o Management of the DDT Map Resolver referral cache, in particular, 1524 detecting and removing outdated entries. 1526 Operational experience will help answer open questions surrounding 1527 these and other issues. 1529 12. IANA Considerations 1531 This document makes no request of the IANA. 1533 13. Security Considerations 1535 Section 10 describes a DDT security architecture that provides data 1536 origin authentication, data integrity protection, and XEID-prefix 1537 delegation within the DDT Infrastructure. 1539 Global XEID-prefix authorization is beyond the scope of this 1540 document, but the SIDR working group [RFC6480] is developing an 1541 infrastructure to support improved security of Internet routing. 1542 Further work is required to determine if SIDR's public key 1543 infrastructure (PKI) and the distributed repository system it uses 1544 for storing and disseminating PKI data objects may also be used by 1545 DDT devices to verifiably assert that they are the legitimate holders 1546 of a set of XEID prefixes. 1548 This document specifies how DDT security and LISP-SEC 1549 ([I-D.ietf-lisp-sec]) complement one another to secure the DDT 1550 infrastructure, Map-Referral messages, and the Map-Request/Map-Reply 1551 protocols. In the future other LISP security mechanisms may be 1552 developed to replace LISP-SEC. Such future security mechanisms 1553 should describe how they can be used together with DDT to provide 1554 similar levels of protection. 1556 LISP-SEC can use the DDT public key infrastructure to secure the 1557 transport of LISP-SEC key material (the One-Time Key) from a Map- 1558 Resolver to the corresponding Map-Server. For this reason, when 1559 LISP-SEC is deployed in conjunction with a LISP-DDT mapping database 1560 and the path between Map-Resolver and Map-Server needs to be 1561 protected, DDT security should be enabled as well. 1563 14. References 1565 14.1. Normative References 1567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1568 Requirement Levels", BCP 14, RFC 2119, 1569 DOI 10.17487/RFC2119, March 1997, 1570 . 1572 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1573 Locator/ID Separation Protocol (LISP)", RFC 6830, 1574 DOI 10.17487/RFC6830, January 2013, 1575 . 1577 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1578 Protocol (LISP) Map-Server Interface", RFC 6833, 1579 DOI 10.17487/RFC6833, January 2013, 1580 . 1582 14.2. Informative References 1584 [I-D.ietf-lisp-lcaf] 1585 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1586 Address Format (LCAF)", draft-ietf-lisp-lcaf-13 (work in 1587 progress), May 2016. 1589 [I-D.ietf-lisp-sec] 1590 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1591 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-10 1592 (work in progress), April 2016. 1594 [LISP-TREE] 1595 Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., 1596 and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support 1597 the lisp mapping system", Selected Areas in 1598 Communications, IEEE Journal , 2010, 1599 . 1602 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1603 and E. Lear, "Address Allocation for Private Internets", 1604 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1605 . 1607 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1608 Standards (PKCS) #1: RSA Cryptography Specifications 1609 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 1610 2003, . 1612 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1613 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 1614 September 2007, . 1616 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1617 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1618 February 2012, . 1620 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1621 "Locator/ID Separation Protocol Alternative Logical 1622 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1623 January 2013, . 1625 Appendix A. Acknowledgments 1627 The authors would like to express their thanks to Lorand Jakab, 1628 Albert Cabellos-Asparicio, Florin Coras, Damien Saucez, and Olivier 1629 Bonaventure for their work on LISP-TREE [LISP-TREE] and LISP iterable 1630 mappings that inspired the hierarchical database structure and lookup 1631 iteration approach described in this document. Thanks also go to 1632 Dino Farinacci and Isidor Kouvelas for their implementation work; to 1633 Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for 1634 work on security processing; and to Job Snijders, Glen Wiley, Neel 1635 Goyal, and Mike Gibbs for work on operational considerations and 1636 initial deployment of a prototype database infrastructure. Special 1637 thanks go to Jesper Skriver, Andrew Partan, and Noel Chiappa; all of 1638 whom have participated in (and put up with) seemingly endless hours 1639 of discussion of mapping database ideas, concepts, and issues. 1641 Authors' Addresses 1643 Vince Fuller 1645 Email: vaf@vaf.net 1647 Darrel Lewis 1648 Cisco Systems 1650 Email: darlewis@cisco.com 1651 Vina Ermagan 1652 Cisco Systems 1654 Email: vermagan@cisco.com 1656 Amit Jain 1657 Juniper Networks 1659 Email: atjain@juniper.net 1661 Anton Smirnov 1662 Cisco Systems 1664 Email: as@cisco.com