idnits 2.17.1 draft-ietf-lisp-ddt-07.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 (May 31, 2016) is 2886 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-12 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-09 -- 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: December 2, 2016 V. Ermagan 6 Cisco Systems 7 A. Jain 8 Juniper Networks 9 A. Smirnov 10 Cisco Systems 11 May 31, 2016 13 LISP Delegated Database Tree 14 draft-ietf-lisp-ddt-07 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 December 2, 2016. 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 . . . . . . . . . . . . . . 17 84 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 18 85 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 18 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. 221 DDT Map Resolver: a network infrastructure element that accepts a 222 Map-Request, adds the XEID to its pending request list, then 223 queries one or more DDT nodes for the requested EID, following 224 returned referrals until it receives one with action code MS-ACK 225 (or an error indication). MS-ACK indicates that the Map-Request 226 has been sent to a Map Server that will forward it to an ETR that, 227 in turn, will provide a Map-Reply to the original sender. A DDT 228 Map Resolver maintains both a cache of Map-Referral message 229 results containing RLOCs for DDT nodes responsible for XEID- 230 prefixes of interest (termed the "referral cache") and a pending 231 request list of XEIDs that are being resolved through iterative 232 querying of DDT nodes. 234 Encapsulated Map-Request: a LISP Map-Request carried within an 235 Encapsulated Control Message, which has an additional LISP header 236 prepended. Sent to UDP destination port 4342. The "outer" 237 addresses are globally-routable IP addresses, also known as RLOCs. 238 Used by an ITR when sending to a Map Resolver and by a Map Server 239 when forwarding a Map-Request to an ETR as documented in LISP-MS 240 [RFC6833]. 242 DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to 243 a DDT node. The "DDT-originated" flag is set in the encapsulation 244 header indicating that the DDT node should return Map-Referral 245 messages if the Map-Request EID matches a delegated XEID-prefix 246 known to the DDT node. Section 7.3.1 describes how DDT Map- 247 Requests are sent. Section 5 defines position of the "DDT- 248 originated" flag in the Encapsulated Control Message header. 250 Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node 251 and for which the DDT node may provide further delegations of 252 more-specific sub-prefixes. 254 Map-Referral: a LISP message sent by a DDT node in response to a DDT 255 Map-Request for an XEID that matches a configured XEID-prefix 256 delegation. A non-negative Map-Referral includes a "referral", a 257 set of RLOCs for DDT nodes that have more information about the 258 sub-prefix; a DDT client "follows the referral" by sending another 259 DDT Map-Request to one of those RLOCs to obtain either an answer 260 or another referral to DDT nodes responsible for a more-specific 261 XEID-prefix. See Section 7.1 and Section 7.3.2 for details on the 262 sending and processing of Map-Referral messages. 264 Negative Map-Referral: a Map-Referral sent in response to a DDT Map- 265 Request that matches an authoritative XEID-prefix but for which 266 there is no delegation configured (or no ETR registration if sent 267 by a DDT Map-Server). 269 Pending Request List: the set of outstanding requests for which a 270 DDT Map Resolver has received encapsulated Map-Requests from a DDT 271 client for an XEID. Each entry in the list contains additional 272 state needed by the referral following process, including the 273 requestor(s) of the XEID (typically, one or more ITRs), saved 274 information about the last referral received and followed 275 (matching XEID-prefix, action code, RLOC set, index of last RLOC 276 queried in the RLOC set), and any LISP-SEC information 277 ([I-D.ietf-lisp-sec]) that was included in the DDT client Map- 278 Request. An entry in the list may be interchangeably termed a 279 "pending request list entry" or simply a "pending request". 281 For definitions of other terms, notably Map-Request, Map-Reply, 282 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, 283 and Map Resolver, please consult the LISP specification [RFC6830] and 284 the LISP Mapping Service specification [RFC6833]. 286 4. Database organization 288 4.1. EID-prefix tree structure and instance IDs 290 LISP-DDT defines a tree structure that is indexed by a binary 291 encoding of five fields, in order of significance: DBID (16 bits), 292 Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 293 16 bits), and EID-prefix (variable, according to AFI value). The 294 fields are concatenated, with the most significant fields as listed 295 above. The index into this structure is also referred to as an 296 Extended EID-prefix (XEID-prefix). 298 It is important to note that LISP-DDT does not store actual EID-to- 299 RLOC mappings; it is, rather, a distributed index that can be used to 300 find the devices (Map Servers and their registered EIDs) that can be 301 queried with LISP to obtain those mappings. Changes to EID-to-RLOC 302 mappings are made on the ETRs which define them, not to any DDT node 303 configuration. DDT node configuration changes are only required when 304 branches of the database hierarchy are added, removed, or modified. 306 4.2. Configuring prefix delegation 308 Every DDT node is configured with one or more XEID-prefixes for which 309 it is authoritative along with a list of delegations of XEID-prefixes 310 to other DDT nodes. A DDT node is required to maintain a list of 311 delegations for all sub-prefixes of its authoritative XEID-prefixes; 312 it also may list "hints", which are prefixes that it knows about that 313 belong to its parents, to the root, or to any other point in the 314 XEID-prefix hierarchy. A delegation (or hint) consists of an XEID- 315 prefix, a set of RLOCs for DDT nodes that have more detailed 316 knowledge of the XEID-prefix, and accompanying security information 317 (for details of security infomation exchange and its use see 318 Section 10). Those RLOCs are returned in Map-Referral messages when 319 the DDT node receives a DDT Map-Request with an XEID that matches a 320 delegation. A DDT Map Server will also have a set of sub-prefixes 321 for which it accepts ETR mapping registrations and for which it will 322 forward (or answer, if it provides proxy Map-Reply service) Map- 323 Requests. 325 4.2.1. The root DDT node 327 The root DDT node is the logical "top" of the database hierarchy: 328 DBID=0, IID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches 329 no configured XEID-prefix will be referred to the root node. The 330 root node in a particular instantiation of LISP-DDT must therefore be 331 configured with delegations for at least all defined IIDs and AFIs. 333 5. DDT Map-Request 335 A DDT client (usualy a Map Resolver) uses LISP Encapsulated Control 336 Message (ECM) to send Map-Request to a DDT node. Format of the ECM 337 is defined by [RFC6830]. This specification adds to ECM flag "DDT- 338 originated". 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 / | IPv4 or IPv6 Header | 344 OH | (uses RLOC addresses) | 345 \ | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 / | Source Port = xxxx | Dest Port = 4342 | 348 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 \ | UDP Length | UDP Checksum | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 LH |Type=8 |S|D| Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 / | IPv4 or IPv6 Header | 354 IH | (uses RLOC or EID addresses) | 355 \ | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 / | Source Port = xxxx | Dest Port = yyyy | 358 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 \ | UDP Length | UDP Checksum | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 LCM | LISP Control Message | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 D: The "DDT-originated" flag. It is set by a DDT client to indicate 365 that the receiver SHOULD return Map-Referral messages as 366 appropriate. Use of the flag is further described in 367 Section 7.3.1. This bit is allocated from LISP message header 368 bits marked as Reserved in [RFC6830]. 370 6. The Map-Referral message 372 This specification defines a new LISP message, the Map-Referral. It 373 is sent by a DDT node to a DDT client in response to a DDT Map- 374 Request message. See Section 6.4 for a detailed layout of the Map- 375 Referral message fields. 377 The message consists of an action code along with delegation 378 information about the XEID-prefix that matches the requested XEID. 380 6.1. Action codes 382 The action codes are as follows: 384 NODE-REFERRAL (0): indicates that the replying DDT node has 385 delegated an XEID-prefix that matches the requested XEID to one or 386 more other DDT nodes. The Map-Referral message contains a "map- 387 record" with additional information, most significantly the set of 388 RLOCs to which the prefix has been delegated, that is used by a 389 DDT Map Resolver to "follow" the referral. 391 MS-REFERRAL (1): indicates that the replying DDT node has delegated 392 an XEID-prefix that matches the requested XEID to one or more DDT 393 Map Servers. It contains the same additional information as a 394 NODE-REFERRAL, but is handled slightly differently by the 395 receiving DDT client (see Section 7.3.2). 397 MS-ACK (2): indicates that a replying DDT Map Server received a DDT 398 Map-Request that matches an authoritative XEID-prefix for which it 399 has one or more registered ETRs. This means that the request has 400 been forwarded to one of those ETRs to provide an answer to the 401 querying ITR. 403 MS-NOT-REGISTERED (3): indicates that the replying DDT Map Server 404 received a Map-Request for one of its configured XEID-prefixes 405 which has no ETRs registered. 407 DELEGATION-HOLE (4): indicates that the requested XEID matches a 408 non-delegated sub-prefix of the XEID space. This is a non-LISP 409 "hole", which has not been delegated to any DDT Map Server or ETR. 410 See Section 7.1.2 for details. 412 NOT-AUTHORITATIVE (5): indicates that the replying DDT node received 413 a Map-Request for an XEID-request for which it is not 414 authoritative. This can occur if a cached referral has become 415 invalid due to a change in the database hierarchy. 417 6.2. Referral set 419 For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a 420 DDT node includes in the Map-Referral message a list of RLOCs for all 421 DDT nodes that are authoritative for the XEID-prefix being returned; 422 a DDT Map Resolver uses this information to contact one of those DDT 423 nodes as it "follows" a referral. 425 6.3. Incomplete flag 427 A DDT node sets the "Incomplete" flag in a Map-Referral message if 428 the Referral Set is incomplete; this is intended to prevent a DDT Map 429 Resolver from caching a referral with incomplete information. A DDT 430 node must set the "incomplete" flag in the following cases: 432 o If it is setting action code MS-ACK or MS-NOT-REGISTERED but does 433 not have configuration for other "peer" DDT nodes that are also 434 authoritative for the matched XEID-prefix. 436 o If it is setting action code NOT-AUTHORITATIVE. 438 6.4. Map-Referral Message Format 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |Type=6 | Reserved | Record Count | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Nonce . . . | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | . . . Nonce | 448 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | Record TTL | 450 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 R | Referral Count| EID mask-len | ACT |A|I| Reserved | 452 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 c |SigCnt | Map Version Number | EID-AFI | 454 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 r | EID-prefix ... | 456 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | /| Priority | Weight | M Priority | M Weight | 458 | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | e | Unused Flags |L|p|R| Loc/LCAF-AFI | 460 | f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | \| Locator ... | 462 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | ~ Sig section ~ 464 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Type: Type value 6 was reserved for future use in RFC6830, this 467 document allocates this value to identify Map-Referral messages. 469 ACT: The "action" field of the mapping record in a Map-Referral 470 message encodes 6 action types. The values for the action types are: 472 NODE-REFERRAL (0): Sent by a DDT node with a child delegation, which 473 is authoritative for the EID. 475 MS-REFERRAL (1): Sent by a DDT node that has information about Map 476 Server(s) for the EID but it is not one of the Map Servers listed, 477 i.e. the DDT-Node sending the referral is not a Map Server. 479 MS-ACK (2): Sent by a DDT Map Server that has one or more ETR 480 registered for the EID. 482 MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured 483 for the EID-prefix, but for which no ETRs are registered. 485 DELEGATION-HOLE (4): Sent by an intermediate DDT node with 486 authoritative configuration covering the requested EID but without 487 any child delegation for the EID. Also sent by a DDT Map Server 488 with authoritative configuration covering the requested EID, but 489 for which no specific site ETR is configured. 491 NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have 492 authoritative configuration for the requested EID. The EID-prefix 493 returned MUST be the original requested EID and the TTL MUST be 494 set to 0. However, if such a DDT node has a "hint" delegation 495 covering the requested EID, it MAY choose to return NODE-REFERRAL 496 or MS-REFERRAL as appropriate. 498 Incomplete: The "I" bit indicates that a DDT node's referral-set of 499 locators is incomplete and the receiver of this message SHOULD NOT 500 cache the referral. A DDT sets the "incomplete" flag, the TTL, and 501 the Action Type field as follows: 503 ------------------------------------------------------------------- 504 Type (Action field) Incomplete Referral-set TTL values 505 ------------------------------------------------------------------- 506 0 NODE-REFERRAL NO YES 1440 508 1 MS-REFERRAL NO YES 1440 510 2 MS-ACK * * 1440 512 3 MS-NOT-REGISTERED * * 1 514 4 DELEGATION-HOLE NO NO 15 516 5 NOT-AUTHORITATIVE YES NO 0 517 ------------------------------------------------------------------- 518 *: The "Incomplete" flag setting on Map Server originated referral of 519 MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map 520 Server has the full peer Map Server configuration for the same 521 prefix and has encoded the information in the mapping record. 522 Incomplete bit is not set when the Map Server has encoded the 523 information, which means the referral-set includes all the RLOCs 524 of all Map Servers that serve the prefix. It is set when the Map 525 Server has not encoded the Map Server set information. 527 SigCnt: Indicates the number of signatures (sig section) present in 528 the Record. If SigCnt is larger than 0, the signature information 529 captured in a sig section as described in Section 6.4.1 will be 530 appended to the end of the record. The number of sig sections at the 531 end of the Record must match the SigCnt. Note that bits occupied by 532 SigCnt were Reserved in Records embedded into messages defined by 533 [RFC6830] and were required to be set to zero. 535 Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the 536 record. If this is a LCAF AFI, the contents of the LCAF depend on 537 the Type field of the LCAF. Security material are stored in LCAF 538 Type 11. DDT nodes and Map Servers can use this LCAF Type to include 539 public keys associated with their Child DDT nodes for a XEID-prefix 540 referral record. LCAF types and formats are defined in 541 [I-D.ietf-lisp-lcaf]. 543 All other fields and their descriptions are equivalent to those in 544 the Map-Reply message, as defined in LISP [RFC6830]. Note, though, 545 that the set of RLOCs correspond to the DDT node to be queried as a 546 result of the referral not the RLOCs for an actual EID-to-RLOC 547 mapping. 549 6.4.1. SIG section 551 If SigCnt field in the Map-Referral is not 0, the signature 552 information is included at the end of captured in a sig section as 553 described below. SigCnt counts the number of sig sections that 554 appear at the end of the Record. 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 /| Original Record TTL | 558 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 / | Signature Expiration | 560 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 s | Signature Inception | 562 i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 g | Key Tag | Sig Length | 564 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 \ | Sig-Algorithm | Reserved | Reserved | 566 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 \ ~ Signature ~ 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Original Record TTL: The original Record TTL for this record that is 571 covered by the signature. Record TTL is in minutes. 573 Signature Expiration and Inception: Specify the validity period for 574 the signature. The signature MUST NOT be used for authentication 575 prior to the inception date and MUST NOT be used for authentication 576 after the expiration date. Each field specifies a date and time in 577 the form of a 32-bit unsigned number of seconds elapsed since 1 578 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte 579 order. 581 Key Tag: An identifier to specify which key is used for this 582 signature if more than one valid key exists for the signing DDT node. 584 Sig Length: The length of the Signature field. 586 Sig-Algorithm: The identifier of the cryptographic algorithm used for 587 the signature. This specification defines only one algorithm: Sig- 588 Algorithm type 1 is RSA-SHA1 (see [RFC3447]). 590 Reserved: This field must be set to 0 on transmit and must be ignored 591 on receipt. 593 Signature: Contains the cryptographic signature that covers the 594 entire record. The Record TTL and the sig fields are set to zero for 595 the purpose of computing the Signature. 597 7. DDT network elements and their operation 599 As described above, DDT introduces a new network element, the "DDT 600 node", extends the functionality of Map Servers and Map Resolvers to 601 send and receive Map-Referral messages. The operation of each of 602 these devices is described as follows. 604 7.1. DDT node 606 When a DDT node receives a DDT Map-Request, it compares the requested 607 XEID against its list of XEID-prefix delegations and its list of 608 authoritative XEID-prefixes and acts as follows: 610 7.1.1. Match of a delegated prefix (or sub-prefix) 612 If the requested XEID matches one of the DDT node's delegated 613 prefixes, then a Map-Referral message is returned with the matching 614 more-specific XEID-prefix and the set of RLOCs for the referral 615 target DDT nodes including associated security information (see 616 Section 10 for details on security). If the delegation is known to 617 be a DDT Map Server, then the Map-Referral message is sent with 618 action code MS-REFERRAL to indicate to the receiver that LISP-SEC 619 information (if saved in the pending request) should be included in 620 the next DDT Map-Request; otherwise, the action code NODE-REFERRAL is 621 used. 623 Note that a matched delegation does not have to be for a sub-prefix 624 of an authoritative prefix; in addition to being configured to 625 delegate sub-prefixes of an authoritative prefix, a DDT node may also 626 be configured with other XEID-prefixes for which it can provide 627 referrals to DDT nodes anywhere in the database hierarchy. This 628 capability to define "shortcut hints" is never required to be 629 configured, but may be a useful heuristic for reducing the number of 630 iterations needed to find an EID, particular for private network 631 deployments. 633 7.1.2. Missing delegation from an authoritative prefix 635 If the requested XEID did not match a configured delegation but does 636 match an authoritative XEID-prefix, then the DDT node returns a 637 negative Map-Referral that uses the least-specific XEID-prefix that 638 does not match any XEID-prefix delegated by the DDT node. The action 639 code is set to DELEGATION-HOLE; this indicates that the XEID is not a 640 LISP destination. 642 If the requested XEID did not match either a configured delegation or 643 an authoritative XEID-prefix, then the request is dropped and a 644 negative Map-Referral with action code NOT-AUTHORITATIVE is returned. 646 7.2. DDT Map Server 648 When a DDT Map Server receives a DDT Map-Request, its operation is 649 similar to that of a DDT node with additional processing as follows: 651 o If the requested XEID matches a registered XEID-prefix, then the 652 Map-Request is forwarded to one of the destination ETR RLOCs (or 653 the Map Server sends a Map-Reply, if it is providing proxy Map- 654 Reply service) and a Map-Referral with the MS-ACK action is 655 returned to the sender of the DDT Map-Request. 657 o If the requested XEID matches a configured XEID-prefix for which 658 no ETR registration has been received then a negative Map-Referral 659 with action code MS-NOT-REGISTERED is returned to the sender of 660 the DDT Map-Request. 662 7.3. DDT Map Resolver 664 Just as any other Map Resolver, a DDT Map Resolver accepts Map- 665 Requests from its clients (typically, ITRs) and ensures that those 666 Map-Requests are forwarded to the correct ETR, which generates Map- 667 Replies. Unlike a Map Resolver that uses the ALT mapping system (see 668 [RFC6836]), however, a DDT Map Resolver uses an iterative process of 669 following referrals to find the correct ETR to answer a Map-Request; 670 this requires a DDT Map Resolver to maintain additional state: a Map- 671 Referral cache and pending request list of XEIDs that are going 672 through the iterative referral process. 674 7.3.1. Queuing and sending DDT Map-Requests 676 When a DDT Map Resolver receives an encapsulated Map-Request, it 677 first performs a longest-match search for the XEID in its referral 678 cache. If no match is found or if a negative cache entry is found, 679 then the destination is not in the database; a negative Map-Reply is 680 returned and no further processing is performed by the DDT Map 681 Resolver. 683 If a match is found, the DDT Map Resolver creates a pending request 684 list entry for the XEID and saves the original Map-Request (minus the 685 encapsulation header) along with other information needed to track 686 progress through the iterative referral process; the "referral XEID- 687 prefix" is also initialized to the null value since no referral has 688 yet been received. The Map Resolver then creates a DDT Map-Request 689 (which is an encapsulated Map-Request with the "DDT-originated" flag 690 set in the message header) for the XEID but without any 691 authentication data that may have been included in the original Map- 692 Request. It sends the DDT Map-Request to one of the RLOCs in the 693 chosen referral cache entry. The referral cache is initially 694 populated with one or more statically-configured entries; additional 695 entries are added when referrals are followed, as described below. A 696 DDT Map Resolver is not absolutely required to cache referrals, but 697 it doing so decreases latency and reduces lookup delays. 699 Note that in normal use on the public Internet, the statically- 700 configured initial referral cache for a DDT Map Resolver should 701 include a "default" entry with RLOCs for one or more DDT nodes that 702 can reach the DDT root node. If a Map Resolver does not have such 703 configuration, it will return a Negative Map-Reply if it receives a 704 query for an EID outside the subset of the mapping database known to 705 it. While this may be desirable on private network deployments or 706 during early transition to LISP when few sites are using it, this 707 behavior is not appropriate when LISP is in general use on the 708 Internet. 710 7.3.2. Receiving and following referrals 712 After sending a DDT Map-Request, a DDT Map Resolver expects to 713 receive a Map-Referral response. If none occurs within the timeout 714 period, the DDT Map Resolver retransmits the request, sending to the 715 next RLOC in the referral cache entry if one is available. If the 716 maximum number of retransmissions has occurred and all RLOCs have 717 been tried, then the pending request list entry is dequeued. 719 A DDT Map Resolver processes a received Map-Referral message 720 according to each action code: 722 NODE-REFERRAL: The DDT Map Resolver checks for a possible referral 723 loop as as described in Section 7.3.4. If no loop is found, the 724 DDT Map Resolver saves the prefix returned in the Map-Referral 725 message in the referral cache, updates the saved prefix and saved 726 RLOCs in the pending request list entry, and follows the referral 727 by sending a new DDT Map-Request to one of the DDT node RLOCs 728 listed in the Referral Set; security information saved with the 729 original Map-Request is not included. 731 MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same 732 manner as a NODE-REFERRAL except that that security information 733 saved with the original Map-Request is included in the new Map- 734 Request sent to a Map Server (see Section 10 for details on 735 security). 737 MS-ACK: This is returned by a DDT Map Server to indicate that it has 738 one or more registered ETRs that can answer a Map-Request for the 739 XEID. If the pending request did not include saved LISP-SEC 740 information or if that information was already included in the 741 previous DDT Map-Request (sent by the DDT Map Resolver in response 742 to either an MS-REFERRAL or a previous MS-ACK referral), then the 743 pending request for the XEID is complete and is dequeued. 744 Otherwise, LISP-SEC information is required and has not yet been 745 sent to the authoritative DDT Map-Server; the DDT Map Resolver re- 746 sends the DDT Map-Request with LISP-SEC information included and 747 the pending request queue entry remains until another Map-Referral 748 with MS-ACK action code is received. If the "incomplete" flag is 749 not set, the prefix is saved in the referral cache. 751 MS-NOT-REGISTERED: The DDT Map Server queried could not process the 752 request because it did not have any ETRs registered for a 753 matching, authoritative XEID-prefix. If the DDT Map Resolver has 754 not yet tried all of the RLOCs saved with the pending request, 755 then it sends a Map-Request to the next RLOC in that list. If all 756 RLOCs have been tried, then the destination XEID is not registered 757 and is unreachable. The DDT Map Resolver returns a negative Map- 758 Reply to the original Map-Request sender; this Map-Reply contains 759 the non-registered XEID-prefix with TTL value of one minute. A 760 negative referral cache entry is created for the prefix (also with 761 TTL of one minute) and the pending request is dequeued. 763 DELEGATION-HOLE: The DDT Map Server queried did not have an XEID- 764 prefix defined that matched the requested XEID so it does not 765 exist in the mapping database. The DDT Map Resolver returns a 766 negative Map-Reply to the original Map-Request sender; this Map- 767 Reply will indicate the least-specific XEID-prefix matching the 768 requested XEID for which no delegations exist and will have a TTL 769 value of 15 minutes. A negative referral cache entry is created 770 for the prefix (also with TTL of 15 minutes) and the pending 771 request is dequeued. 773 NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative 774 for the requested XEID. This can occur if a cached referral has 775 become invalid due to a change in the database hierarchy. If the 776 DDT Map Resolver receiving this message can determine that it is 777 using old cached information, it MAY choose to delete that cached 778 information and re-try the original Map-Request, starting from its 779 "root" cache entry. If this action code is received in response 780 to a query that did not use a cached referral information, then it 781 indicates a database synchronization problem or configuration 782 error. The pending request list entry that caused this answer is 783 removed, with no answer returned to the original requestor. 785 7.3.3. Handling referral errors 787 Other states are possible, such as a misconfigured DDT node (acting 788 as a proxy Map Server, for example) returning a Map-Reply to the DDT 789 Map Resolver; they should be considered errors and logged as such. 790 It is not clear exactly what else the DDT Map Resolver should do in 791 such cases; one possibility is to remove the pending request list 792 entry and send a negative Map-Reply to the original Map-Request 793 sender. Alternatively, if a DDT Map Resolver detects unexpected 794 behavior by a DDT node, it could mark that node as unusable in its 795 referral cache and update the pending request to try a different DDT 796 node if more than one is listed in the referral cache. In any case, 797 any prefix contained in a Map-Referral message that causes a referral 798 error (including a referral loop) is not saved in the DDT Map- 799 Resolver referral cache. 801 7.3.4. Referral loop detection 803 In response to a Map-Referral message with action code NODE-REFERRAL 804 or MS-REFERRAL, a DDT Map Resolver is directed to query a new set of 805 DDT node RLOCs that are expected to have more-specific XEID-prefix 806 information for the requested XEID. To prevent a possible "iteration 807 loop" (following referrals back-and-forth among a set of DDT nodes 808 without ever finding an answer), a DDT Map Resolver saves the last 809 received referral XEID-prefix for each pending request and checks 810 that a newly received NODE-REFERRAL or MS-REFERRAL message contains a 811 more-specific referral XEID-prefix; an exact or less-specific match 812 of the saved XEID-prefix indicates a referral loop. If a loop is 813 detected, the DDT Map Resolver handles the request as described in 814 Section 7.3.3. Otherwise, the Map Resolver saves the most recently 815 received referral XEID-prefix with the pending request when it 816 follows the referral. 818 As an extra measure to prevent referral loops, it is probably also 819 wise to limit the total number of referrals for any request to some 820 reasonable number; the exact value of that number will be determined 821 during experimental deployment of LISP-DDT, but is bounded by the 822 maximum length of the XEID. 824 Note that when a DDT Map Resolver adds an entry to its lookup queue 825 and sends an initial Map-Request for an XEID, the queue entry has no 826 previous referral XEID-prefix; this means that the first DDT node 827 contacted by a DDT Map Resolver may provide a referral to anywhere in 828 the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use 829 essentially any DDT node RLOCs for its initial cache entries and 830 depend on the initial referral to provide a good starting point for 831 Map-Requests; there is no need to configure the same set of root DDT 832 nodes on all DDT Map Resolvers. 834 8. Pseudo Code and Decision Tree diagrams 836 To aid in implementation, each of the major DDT Map Server and DDT 837 Map Resolver functions are described below, first using simple 838 "psuedo-code" and then in the form of a decision tree. 840 8.1. Map Resolver processing of ITR Map-Request 842 8.1.1. Pseudo-code summary 844 if ( request pending i.e., (ITR,EID) of request same ) { 845 replace old request with new & use new request nonce 846 for future requests 847 } else if ( no match in refcache ) { 848 return negative map-reply to ITR 849 } else if ( match type delegation hole ) { 850 return negative map-reply to ITR 851 } else if ( match type ms-ack ) { 852 fwd DDT request to map-server 853 } else { 854 store & fwd DDT request w/o security material to node delegation 855 } 857 8.1.2. Decision tree diagram 858 +------------+ 859 | Is Request | Yes 860 | |----> Replace old request with 861 | Pending? | new nonce for future requests 862 +------------+ 863 | 864 |No 865 | 866 V 867 +------------+ 868 | Match In | No 869 | Referral |----> Send Negative Map-Reply 870 | cache? | (not a likely event as root 871 +------------+ configured on every MR) 872 | 873 |Yes 874 | 875 V 876 +------------+ 877 | Match Type | Yes 878 | Delegation |----> Send Negative Map-Reply 879 | Hole? | 880 +------------+ 881 | 882 |No 883 | 884 V 885 +------------+ 886 | Match Type | Yes 887 | MS-ACK? |----> Forward DDT Map-request to Map-Server 888 | | 889 +------------+ 890 | 891 |No 892 | 893 V 894 Store request & Fwd DDT Request w/o security material 895 to DDT node delegation 897 8.2. Map Resolver processing of Map-Referral message 899 8.2.1. Pseudo-code summary 901 if ( no request pending matched by referral nonce ) { 902 silently drop 903 } 905 if ( pfx in referral less specific than last referral used ) { 906 if ( gone through root ) { 907 silently drop 908 } else { 909 send request to root 910 } 911 } 913 switch (map_referral_type) { 915 case NOT_AUTHORITATIVE : 916 if ( gone through root ) { 917 return negative map-reply to ITR 918 } else { 919 send request to root 920 } 922 case DELEGATION_HOLE: 923 cache & send negative map-reply to ITR 925 case MS_REFERRAL: 926 if ( referral equal to last used ) { 927 if ( gone through root ) { 928 return negative map-reply to ITR 929 } else { 930 send request to root 931 } 932 } else { 933 cache 934 follow the referral, include security material 935 } 937 case NODE_REFERRAL: 938 if ( referral equal to last used ) { 939 if ( gone through root ) { 940 return negative map-reply to ITR 941 } else { 942 send request to root 943 } 944 } else { 945 cache 946 follow the referral, strip security material 947 } 949 case MS_ACK: 950 if ( security material stripped ) { 951 resend request with security material 952 if { !incomplete } { 953 cache 955 } 956 } 958 case MS_NOT_REGISTERED: 959 if { all map-server delegations not tried } { 960 follow delegations not tried 961 if ( !incomplete ) { 962 cache 963 } 964 } else { 965 send negative map-reply to ITR 966 if { !incomplete } { 967 cache 968 } 969 } 971 case DEFAULT: 972 drop 973 } 974 } 976 8.2.2. Decision tree diagram 977 +------------+ 978 | Is Request | No 979 | Pending? |----> Silently drop 980 +------------+ 981 | Yes 982 V 983 +------------------------------+ Yes 984 | Pfx less specific than last? |----> Silently drop 985 +------------------------------+ 986 |No 987 V 988 +---------------------------------------------------+ 989 | What is Map-Referral Type? |--UNKNOWN-+ 990 +---------------------------------------------------+ | 991 | | | | | | V 992 | | | | | DEL_HOLE DROP 993 | | | | MS_ACK | 994 | | | | | V 995 | | MS_REF NODE_REF | Cache & return 996 | | | | V negative map-reply 997 | | | | +---------+ 998 | NOT_AUTH | | | Was sec | Yes 999 | | | | | material| 1000 | | | | |Stripped?|----> Done 1001 | | V V +---------+ 1002 | | +------------+ | No 1003 | | Yes | Pfx equal | V 1004 MS_NOT_REGISTERED | +---| to last | +------------+ 1005 | | | | used? | | Incomplete | Yes 1006 | | | +------------+ | bit set? |---> Resend DDT 1007 | V V |No +------------+ request w 1008 | +------------+ | |No security 1009 | | Gone | V | material 1010 | | Through | Cache & follow V 1011 | | Root? | the referral Cache & resend DDT 1012 | +------------+ request with 1013 | |No |Yes security material 1014 | | | 1015 | V V 1016 | Send req Send negative map-reply 1017 | to root 1018 V 1019 +-----------+ Yes +-----------+ Yes 1020 | Other MS |----Follow other MS-------->|Incomplete |----> Don't cache 1021 | not tried?| |bit set? | 1022 | |---Send negative map-reply->| |----> Cache 1023 +-----------+ No +-----------+ No 1025 8.3. DDT Node processing of DDT Map-Request message 1027 8.3.1. Pseudo-code summary 1029 if ( I am not authoritative ) { 1030 send map-referral NOT_AUTHORITATIVE with 1031 incomplete bit set and ttl 0 1032 } else if ( delegation exists ) { 1033 if ( delegated map-servers ) { 1034 send map-referral MS_REFERRAL with 1035 ttl 'Default_DdtNode_Ttl' 1036 } else { 1037 send map-referral NODE_REFERRAL with 1038 ttl 'Default_DdtNode_Ttl' 1039 } 1040 } else { 1041 if ( eid in site) { 1042 if ( site registered ) { 1043 forward map-request to etr 1044 if ( map-server peers configured ) { 1045 send map-referral MS_ACK with 1046 ttl 'Default_Registered_Ttl' 1047 } else { 1048 send map-referral MS_ACK with 1049 ttl 'Default_Registered_Ttl' and incomplete bit set 1050 } 1051 } else { 1052 if ( map-server peers configured ) { 1053 send map-referral MS_NOT_REGISTERED with 1054 ttl 'Default_Configured_Not_Registered_Ttl' 1055 } else { 1056 send map-referral MS_NOT_REGISTERED with 1057 ttl 'Default_Configured_Not_Registered_Ttl' 1058 and incomplete bit set 1059 } 1060 } 1061 } else { 1062 send map-referral DELEGATION_HOLE with 1063 ttl 'Default_Negative_Referral_Ttl' 1064 } 1065 } 1067 where architectural constants for TTL are set as follows: 1069 Default_DdtNode_Ttl 1440 minutes 1070 Default_Registered_Ttl 1440 minutes 1071 Default_Negative_Referral_Ttl 15 minutes 1072 Default_Configured_Not_Registered_Ttl 1 minute 1074 8.3.2. Decision tree diagram 1076 +------------+ 1077 | Am I | No 1078 | Authori- |----> Return NOT_AUTHORITATIVE 1079 | tative? | Incomplete = 1 1080 +------------+ ttl = Default_DdtNode_Ttl 1081 | 1082 |Yes 1083 | 1084 V 1085 +------------+ +------------+ 1086 | Delegation | Yes | Delegations| Yes 1087 | Exists? |---->| are map |----> Return MS_REFERRAL 1088 | | | servers? | ttl = Default_DdtNode_Ttl 1089 +------------+ +------------+ 1090 | \ No 1091 |No +--> Return NODE_REFERRAL 1092 | ttl = Default_DdtNode_Ttl 1093 V 1094 +------------+ +------------+ +------------+ 1095 | EID in | Yes | Site | Yes | Map-server | 1096 | Site |---->| Registered?|----> Forward---->| peers | 1097 | Config? | | | Map-request | configured?| 1098 +------------+ +------------+ to ETR +------------+ 1099 | | | | 1100 | |No No| |Yes 1101 | | | | 1102 | | V V 1103 | | Return MS_ACK Return MS_ACK 1104 | V with INC=1 1105 | +------------+ ttl=Default_Registered_Ttl 1106 | | Map-server | Yes 1107 | | peers |----> Return MS_NOT_REGISTERED 1108 | | configured?| ttl = Default_Negative_Referral_Ttl 1109 | +------------+ 1110 | \ No 1111 |No +--> Return MS_NOT_REGISTERED 1112 | Incomplete = 1 1113 V ttl = Default_Negative_Referral_Ttl 1114 Return DELEGATION_HOLE 1115 ttl = Default_Negative_Referral_Ttl 1117 9. Example topology and request/referral following 1119 This chapter shows example DDT tree and several possible scenarios of 1120 Map-Requests coming to a Map Resolver and subsequent iterative DDT 1121 referrals. For the sake of example RLOCs of DDT nodes are shown in 1122 IPv4 address space while the EIDs are in IPv6 AF. The same principle 1123 of hierarchical delegation and pinpointing referrals is equally 1124 applicable to any AF whose address hierarchy can be expressed as a 1125 bitstring with associated length. DDT tree of IPv4 prefixes is 1126 another AF with immediate practical value. 1128 To show how referrals are followed to find the RLOCs for a number of 1129 EIDs, consider the following example EID topology for DBID=0, IID=0, 1130 AFI=2, and EID=0/0 1132 +---------------------+ +---------------------+ 1133 | root1: 192.0.2.1 | | root2: 192.0.2.2 | 1134 | authoritative: ::/0 | | authoritative: ::/0 | 1135 +---------------------+ +---------------------+ 1136 | \ / | 1137 | \ / | 1138 | / \ | 1139 | / \ | 1140 | | | | 1141 V V V V 1142 +-------------------------+ +--------------------------+ 1143 | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | 1144 | authoritative: | | authoritative: | 1145 | 2001:db8::/32 | | 2001:db8::/32 | 1146 +-------------------------+ +--------------------------+ 1147 | \ / | 1148 | \ / | 1149 | / \ | 1150 | / \ | 1151 | | | | 1152 V V V V 1153 +--------------------------+ +---------------------------+ 1154 | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | 1155 | authoritative: | | authoritative: | 1156 | 2001:db8:0100::/40 | | 2001:db8:0500::/40 | 1157 | site1: 2001:db8:0103::/48| +---------------------------+ 1158 | site2: 2001:db8:0104::/48| | | 1159 +--------------------------+ | | 1160 | | 1161 | | 1162 V V 1163 +---------------------------+ +---------------------------+ 1164 | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | 1165 | authoritative: | | authoritative: | 1166 | 2001:db8:0500::/48 | | 2001:db8:0501::/48 | 1167 |site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64| 1168 |site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64| 1169 +---------------------------+ +---------------------------+ 1171 DDT nodes are configured for this "root" at IP addresses 192.0.2.1 1172 and 192.0.2.2. DDT Map Resolvers are configured with default 1173 referral cache entries to these addresses. 1175 The root DDT nodes delegate 2001:db8::/32 to two DDT nodes with IP 1176 addresses 192.0.2.11 and 192.0.2.12. 1178 The DDT nodes for 2001:db8::/32 delegate 2001:db8:0100::/40 to a DDT 1179 Map Server with RLOC 192.0.2.101 1181 The DDT Map Server for 2001:db8:0100::/40 is configured to allow ETRs 1182 to register the sub-prefixes 2001:db8:0103::/48 and 1183 2001:db8:0104::/48 1185 The DDT nodes for 2001:db8::/32 also delegate 2001:db8:0500::/40 to a 1186 DDT node with RLOC 192.0.2.201 1188 The DDT node for 2001:db8:0500::/40 is further configured to delegate 1189 2001:db8:0500::/48 to a DDT Map Server with RLOC 192.0.2.211 and 1190 2001:db8:0501::/48 to a DDT Map Server with RLOC 192.0.2.221 1192 The DDT Map Server for 2001:db8:0500::/48 is configured to allow ETRs 1193 to register the sub-prefixes 2001:db8:0500:1::/64 and 1194 2001:db8:0500:2::/64 1196 The DDT Map Server for 2001:db8:0501::/48 is configured to allow ETRs 1197 to register the sub-prefixes 2001:db8:0501:8::/64 and 1198 2001:db8:0501:9::/64 1200 9.1. Lookup of 2001:db8:0103:1::1/128 1202 The first example shows a DDT Map Resolver following a delegation 1203 from the root to a DDT node followed by another delegation to a DDT 1204 Map Server. 1206 ITR1 sends an Encapsulated Map-Request for 2001:db8:0103:1::1 to one 1207 of its configured (DDT) Map Resolvers. The DDT Map Resolver proceeds 1208 as follows: 1210 1. Send DDT Map-Request (for 2001:db8:0103:1::1) to one of the root 1211 DDT nodes, 192.0.2.1 or 192.0.2.2 1213 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1214 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11, 1215 192.0.2.12) 1217 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1218 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1219 2001:db8:0100::/40, action code MS-REFERRAL, RLOC set 1220 (192.0.2.101) 1222 5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated 1223 Encapsulated Map-Request had a LISP-SEC signature, it is included 1225 6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1226 and forwards to a registered site1 ETR for 2001:db8:0103::/48 1228 7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1229 EID-prefix 2001:db8:0103::/48, action code MS-ACK to the DDT Map 1230 Resolver 1232 8. DDT Map Resolver receives Map-Referral message and dequeues the 1233 pending request for 2001:db8:0103:1::1 1235 9. site1 ETR for 2001:db8:0103::/48 receives Map-Request forwarded 1236 by DDT Map Server and sends Map-Reply to ITR1 1238 9.2. Lookup of 2001:db8:0501:8:4::1/128 1240 The next example shows a three-level delegation: root to first DDT 1241 node, first DDT node to second DDT node, second DDT node to DDT Map 1242 Server. 1244 ITR2 sends an Encapsulated Map-Request for 2001:db8:0501:8:4::1 to 1245 one of its configured (DDT) Map Resolvers, which are different from 1246 those for ITR1. The DDT Map Resolver proceeds as follows: 1248 1. Send DDT Map-Request (for 2001:db8:0501:8:4::1) to one of the 1249 root DDT nodes, 192.0.2.1 or 192.0.2.2 1251 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1252 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11, 1253 192.0.2.12) 1255 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1257 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1258 2001:db8:0500::/40, action code NODE-REFERRAL, RLOC set 1259 (192.0.2.201) 1261 5. Send DDT Map-Request to 192.0.2.201 1263 6. Receive (and save in referral cache) Map-Referral for EID-prefix 1264 2001:db8:0501::/48, action code MS-REFERRAL, RLOC set 1265 (192.0.2.221) 1267 7. Send DDT Map-Request to 192.0.2.221; if the ITR-originated 1268 Encapsulated Map-Request had a LISP-SEC signature, it is 1269 included 1271 8. DDT Map Server at 192.0.2.221 decapsulates the DDT Map-Request 1272 and forwards to a registered site5 ETR for 2001:db8:0501:8::/64 1274 9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for 1275 EID-prefix 2001:db8:0501:8::/64, action code MS-ACK, to the DDT 1276 Map Resolver 1278 10. DDT Map Resolver receives Map-Referral(MS-ACK) message and 1279 dequeues the pending request for 2001:db8:0501:8:4::1 1281 11. site5 ETR for 2001:db8:0501:8::/64 receives Map-Request 1282 forwarded by DDT Map Server and sends Map-Reply to ITR2 1284 9.3. Lookup of 2001:db8:0104:2::2/128 1286 This example shows how a DDT Map Resolver uses a saved referral cache 1287 entry to skip the referral process and go directly to a DDT Map 1288 Server for a prefix that is similar to one previously requested. 1290 In this case, ITR1 uses the same Map Resolver used in example 1291 Section 9.1. It sends an Encapsulated Map-Request for 1292 2001:db8:0104:2::2 to that (DDT) Map Resolver. The DDT Map-Resolver 1293 finds an MS-REFERRAL cache entry for 2001:db8:0100::/40 with RLOC set 1294 (192.0.2.101) and proceeds as follows: 1296 1. Send DDT Map-Request (for 2001:db8:0104:2::2) to 192.0.2.101; if 1297 the ITR-originated Encapsulated Map-Request had a LISP-SEC 1298 signature, it is included 1300 2. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1301 and forwards to a registered site2 ETR for 2001:db8:0104::/48 1303 3. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1304 EID-prefix 2001:db8:0104::/48, action code MS-ACK to the DDT Map 1305 Resolver 1307 4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1308 pending request for 2001:db8:0104:2::2 1310 5. site2 ETR for 2001:db8:0104::/48 receives Map-Request and sends 1311 Map-Reply to ITR1 1313 9.4. Lookup of 2001:db8:0500:2:4::1/128 1315 This example shows how a DDT Map Resolver uses a saved referral cache 1316 entry to start the referral process at a non-root, intermediate DDT 1317 node for a prefix that is similar to one previously requested. 1319 In this case, ITR2 asks the same Map Resolver used in example 1320 Section 9.2. It sends an Encapsulated Map-Request for 1321 2001:db8:0500:2:4::1 to that (DDT) Map Resolver, which finds a NODE- 1322 REFERRAL cache entry for 2001:db8:0500::/40 with RLOC set 1323 (192.0.2.201). It proceeds as follows: 1325 1. Send DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201 1327 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1328 2001:db8:0500::/48, action code MS-REFERRAL, RLOC set 1329 (192.0.2.211) 1331 3. Send DDT Map-Request to 192.0.2.211; if the ITR-originated 1332 Encapsulated Map-Request had a LISP-SEC signature, it is included 1334 4. DDT Map Server at 192.0.2.211 decapsulates the DDT Map-Request 1335 and forwards to a registered site4 ETR for 2001:db8:0500:2::/64 1337 5. DDT Map Server at 192.0.2.211 sends a Map-Referral message for 1338 EID-prefix 2001:db8:0500:2::/64, action code MS-ACK to the DDT 1339 Map Resolver 1341 6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1342 pending request for 2001:db8:0500:2:4::1 1344 7. site4 ETR for 2001:db8:0500:2::/64 receives Map-Request and sends 1345 Map-Reply to ITR2 1347 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) 1349 This example uses the cached MS-REFERRAL for 2001:db8:0500::/48 1350 learned above to start the lookup process at the DDT Map-Server at 1351 192.0.2.211. The DDT Map Resolver proceeds as follows: 1353 1. Send DDT Map-Request (for 2001:db8:0500::1) to 192.0.2.211; if 1354 the ITR-originated Encapsulated Map-Request had a LISP-SEC 1355 signature, it is included 1357 2. DDT Map Server at 192.0.2.211, which is authoritative for 1358 2001:db8:0500::/48, does not have a matching delegation for 1359 2001:db8:0500::1. It responds with a Map-Referral message for 1360 2001:db8:0500::/64, action code DELEGATION-HOLE to the DDT Map 1361 Resolver. The prefix 2001:db8:0500::/64 is used because it is 1362 the least-specific prefix that does match the requested EID, but 1363 does not match one of configured delegations 1364 (2001:db8:0500:1::/64 and 2001:db8:0500:2::/64). 1366 3. DDT Map Resolver receives the delegation, adds a negative 1367 referral cache entry for 2001:db8:0500::/64, dequeues the pending 1368 request for 2001:db8:0500::1, and returns a negative Map-Reply to 1369 ITR2. 1371 10. Securing the database and message exchanges 1373 This section specifies the DDT security architecture that provides 1374 data origin authentication, data integrity protection, and XEID- 1375 prefix delegation. Global XEID-prefix authorization is out of the 1376 scope of this document. 1378 Each DDT node is configured with one or more public/private key 1379 pair(s) that are used to digitally sign referral records for XEID- 1380 prefix(es) that the DDT node is authoritative for. In other words, 1381 each public/private key pair is associated with the combination of a 1382 DDT node and the XEID-prefix that it is authoritative for. Every DDT 1383 node is also configured with the public keys of its children DDT 1384 nodes. By including public keys of target child DDT nodes in the 1385 Map-Referral records, and signing each record with the DDT node's 1386 private key, a DDT node can securely delegate sub-prefixes of its 1387 authoritative XEID-prefixes to its children DDT nodes. 1389 Map Resolvers are configured with one or more trusted public keys 1390 referred to as trust anchors. Trust anchors are used to authenticate 1391 the DDT security infrastructure. Map Resolvers can discover a DDT 1392 node's public key either by having it configured as a trust anchor, 1393 or by obtaining it from the node's parent as part of a signed Map- 1394 Referral. When a public key is obtained from a node's parent, it is 1395 considered trusted if it is signed by a trust anchor, or if it is 1396 signed by a key that was previously trusted. Typically, in a Map 1397 Resolver, the root DDT node public keys should be configured as trust 1398 anchors. Once a Map Resolver authenticates a public key it locally 1399 caches the key along with the associated DDT node RLOC and XEID- 1400 prefix for future use. 1402 10.1. XEID-prefix Delegation 1404 In order to delegate XEID sub-prefixes to its children, a parent DDT 1405 node signs its Map-Referrals. Every signed Map-Referral also 1406 includes the public keys associated with each child DDT node. Such a 1407 signature indicates that the parent node is delegating the specified 1408 XEID -prefix to a given child DDT node. The signature is also 1409 authenticating the public keys associated with the children nodes, 1410 and authorizing them to be used by the children DDT nodes to provide 1411 origin authentication and integrity protection for further 1412 delegations and mapping information of the XEID-prefix allocated to 1413 the DDT node. 1415 As a result, for a given XEID-prefix, a Map Resolver can form an 1416 authentication chain from a configured trust anchor (typically the 1417 root DDT node) to the leaf nodes (Map Servers). Map Resolvers 1418 leverage this authentication chain to verify the Map-Referral 1419 signatures while walking the DDT tree until they reach a Map Server 1420 authoritative for the given XEID-prefix. 1422 10.2. DDT node operation 1424 Upon receiving a Map-Request, the DDT node responds with a Map- 1425 Referral as specified in Section 7. For every record present in the 1426 Map-Referral, the DDT node also includes the public keys associated 1427 with the record's XEID-prefix and the RLOCs of the children DDT 1428 nodes. Each record contained in the Map-Referral is signed using the 1429 DDT node's private key. 1431 10.2.1. DDT public key revocation 1433 The node that owns a public key can also revoke that public key. For 1434 instance if a parent node advertises a public key for one of its 1435 child DDT nodes, the child DDT node can at a later time revoke that 1436 key. Since DDT nodes do not keep track of the Map Resolvers that 1437 query them, revocation is done in a pull model, where the Map 1438 Resolver is informed of the revocation of a key only when it queries 1439 the node that owns that key. If the parent DDT is configured to 1440 advertise this key, the parent node must also be signaled to remove 1441 the key from the records it advertises for the child DDT node; this 1442 is necessary to avoid further distribution of the revoked key. 1444 To securely revoke a key, the DDT node creates a new Record for the 1445 associated XEID-prefix and locator, including the revoked key with 1446 the R bit set. The DDT node must also include a signature in the 1447 Record that covers this record; this is computed using the private 1448 key corresponding to the key being revoked. Such a record is termed 1449 a "revocation record". By including this record in its Map- 1450 Referrals, the DDT node informs querying Map Resolvers about the 1451 revoked key. A digital signature computed with a revoked key can 1452 only be used to authenticate the revocation, and SHOULD NOT be used 1453 to validate any data. To prevent a compromised key from revoking 1454 other valid keys, a given key can only be used to sign a revocation 1455 for that specific key; it cannot be used to revoke other keys. This 1456 prevents the use of a compromised key to revoke other valid keys as 1457 described in [RFC5011]. A revocation record must be advertised for a 1458 period of time equal to or greater than the TTL value of the Record 1459 that initially advertised the key, starting from the time that the 1460 advertisement of the key was stopped by removal from the parent DDT 1461 node. 1463 10.3. Map Server operation 1465 Similar to a DDT node, a Map Server is configured with one (or more) 1466 public/private key pairs that it must use to sign Map-Referrals. 1468 However unlike DDT nodes, Map Servers do not delegate prefixes and as 1469 a result they do not need to include keys in the Map-Referrals they 1470 generate. 1472 10.4. Map Resolver operation 1474 Upon receiving a Map-Referral, the Map Resolver must first verify the 1475 signature(s) by using a trust anchor, or a previously authenticated 1476 public key, associated with the DDT node sending the Map-Referral. 1477 If multiple authenticated keys are associated with the DDT node 1478 sending this Map-Referral, the Key Tag field of the signature can be 1479 used to select the right public key for verifying the signature. If 1480 the key tag matches more than one key associated with that DDT node, 1481 the Map Resolver must try verifying the signature with all matching 1482 keys. For every matching key that is found the Map Resolver must 1483 also verify that the key is authoritative for the XEID-prefix in the 1484 Map-Referral record. If such a key is found, the Map Resolver must 1485 use it to verify the associated signature in the record. If no 1486 matching key is found, or if none of the matching keys is 1487 authoritative for the XEID-prefix in the Map-Referral record, or if 1488 such a key is found but the signature is not valid the Map-Referral 1489 record is considered corrupted and must be discarded. This may be 1490 due to expired keys. The Map Resolver can try other siblings of this 1491 node if there is an alternative node authoritative for the same 1492 prefix. If not, the Map Resolver can query the DDT node's parent to 1493 retrieve a valid key. It is good practice to use a counter or timer 1494 to avoid repeating this process if the resolver cannot verify the 1495 signature after several trials. 1497 Once the signature is verified, the Map Resolver has verified the 1498 XEID-prefix delegation in the Map-Referral, and authenticated the 1499 public keys of the children DDT nodes. The Map Resolver must add 1500 these keys to the authenticated keys associated with each child DDT 1501 node and XEID-prefix. These keys are considered valid for the 1502 duration specified in the record's TTL field. 1504 11. Open Issues and Considerations 1506 There are a number of issues with the organization of the mapping 1507 database that need further investigation. Among these are: 1509 o Defining an interface to implement interconnection and/or 1510 interoperability with other mapping databases, such as LISP+ALT. 1512 o Additional key structures for use with LISP-DDT, such as to 1513 support additional EID formats as defined in [I-D.ietf-lisp-lcaf] 1515 o Management of the DDT Map Resolver referral cache, in particular, 1516 detecting and removing outdated entries. 1518 Operational experience will help answer open questions surrounding 1519 these and other issues. 1521 12. IANA Considerations 1523 This document makes no request of the IANA. 1525 13. Security Considerations 1527 Section 10 describes a DDT security architecture that provides data 1528 origin authentication, data integrity protection, and XEID-prefix 1529 delegation within the DDT Infrastructure. 1531 Global XEID-prefix authorization is beyond the scope of this 1532 document, but the SIDR working group [RFC6480] is developing an 1533 infrastructure to support improved security of Internet routing. 1534 Further work is required to determine if SIDR's public key 1535 infrastructure (PKI) and the distributed repository system it uses 1536 for storing and disseminating PKI data objects may also be used by 1537 DDT devices to verifiably assert that they are the legitimate holders 1538 of a set of XEID prefixes. 1540 This document specifies how DDT security and LISP-SEC 1541 ([I-D.ietf-lisp-sec]) complement one another to secure the DDT 1542 infrastructure, Map-Referral messages, and the Map-Request/Map-Reply 1543 protocols. In the future other LISP security mechanisms may be 1544 developed to replace LISP-SEC. Such future security mechanisms 1545 should describe how they can be used together with DDT to provide 1546 similar levels of protection. 1548 LISP-SEC can use the DDT public key infrastructure to secure the 1549 transport of LISP-SEC key material (the One-Time Key) from a Map- 1550 Resolver to the corresponding Map-Server. For this reason, when 1551 LISP-SEC is deployed in conjunction with a LISP-DDT mapping database 1552 and the path between Map-Resolver and Map-Server needs to be 1553 protected, DDT security should be enabled as well. 1555 14. References 1557 14.1. Normative References 1559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1560 Requirement Levels", BCP 14, RFC 2119, 1561 DOI 10.17487/RFC2119, March 1997, 1562 . 1564 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1565 Locator/ID Separation Protocol (LISP)", RFC 6830, 1566 DOI 10.17487/RFC6830, January 2013, 1567 . 1569 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1570 Protocol (LISP) Map-Server Interface", RFC 6833, 1571 DOI 10.17487/RFC6833, January 2013, 1572 . 1574 14.2. Informative References 1576 [I-D.ietf-lisp-lcaf] 1577 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1578 Address Format (LCAF)", draft-ietf-lisp-lcaf-12 (work in 1579 progress), March 2016. 1581 [I-D.ietf-lisp-sec] 1582 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 1583 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09 1584 (work in progress), October 2015. 1586 [LISP-TREE] 1587 Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., 1588 and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support 1589 the lisp mapping system", Selected Areas in 1590 Communications, IEEE Journal , 2010, 1591 . 1594 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1595 and E. Lear, "Address Allocation for Private Internets", 1596 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1597 . 1599 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1600 Standards (PKCS) #1: RSA Cryptography Specifications 1601 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 1602 2003, . 1604 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1605 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 1606 September 2007, . 1608 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1609 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1610 February 2012, . 1612 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1613 "Locator/ID Separation Protocol Alternative Logical 1614 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1615 January 2013, . 1617 Appendix A. Acknowledgments 1619 The authors would like to express their thanks to Lorand Jakab, 1620 Albert Cabellos-Asparicio, Florin Coras, Damien Saucez, and Olivier 1621 Bonaventure for their work on LISP-TREE [LISP-TREE] and LISP iterable 1622 mappings that inspired the hierarchical database structure and lookup 1623 iteration approach described in this document. Thanks also go to 1624 Dino Farinacci and Isidor Kouvelas for their implementation work; to 1625 Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for 1626 work on security processing; and to Job Snijders, Glen Wiley, Neel 1627 Goyal, and Mike Gibbs for work on operational considerations and 1628 initial deployment of a prototype database infrastructure. Special 1629 thanks go to Jesper Skriver, Andrew Partan, and Noel Chiappa; all of 1630 whom have participated in (and put up with) seemingly endless hours 1631 of discussion of mapping database ideas, concepts, and issues. 1633 Authors' Addresses 1635 Vince Fuller 1637 Email: vaf@vaf.net 1639 Darrel Lewis 1640 Cisco Systems 1642 Email: darlewis@cisco.com 1643 Vina Ermagan 1644 Cisco Systems 1646 Email: vermagan@cisco.com 1648 Amit Jain 1649 Juniper Networks 1651 Email: atjain@juniper.net 1653 Anton Smirnov 1654 Cisco Systems 1656 Email: as@cisco.com