idnits 2.17.1 draft-fuller-lisp-ddt-01.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 : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1023: '... returned MUST be the original re...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2012) is 4420 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 933, but no explicit reference was found in the text == Unused Reference: 'RFC4634' is defined on line 937, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-06 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-22 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-01 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft D. Lewis 4 Intended status: Experimental V. Ermagan 5 Expires: September 14, 2012 cisco Systems 6 March 13, 2012 8 LISP Delegated Database Tree 9 draft-fuller-lisp-ddt-01.txt 11 Abstract 13 This draft describes the LISP Delegated Database Tree (LISP-DDT), a 14 hierarchical, distributed database which embodies the delegation of 15 authority to provide mappings from LISP Endpoint Identifiers (EIDs) 16 to Routing Locators (RLOCs). It is a statically-defined distribution 17 of the EID namespace among a set of LISP-speaking servers, called DDT 18 nodes. Each DDT node is configured as "authoritative" for one or 19 more EID-prefixes, along with the set of RLOCs for Map-Servers or 20 "child" DDT nodes to which more-specific EID-prefixes are delegated. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 14, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 58 3. EID-prefix tree structure and instance IDs . . . . . . . . . . 8 59 4. Configuring XEID-prefix delegation . . . . . . . . . . . . . . 9 60 4.1. Example DDT node configuration . . . . . . . . . . . . . . 9 61 4.2. The root DDT node . . . . . . . . . . . . . . . . . . . . 10 62 5. DDT node operation - sending referrals . . . . . . . . . . . . 11 63 5.1. Match of a delegated prefix (or sub-prefix) . . . . . . . 11 64 5.2. Missing delegation from an authoritative prefix . . . . . 11 65 6. DDT Map-Server operation . . . . . . . . . . . . . . . . . . . 12 66 7. DDT Map-Resolver operation . . . . . . . . . . . . . . . . . . 13 67 7.1. Queuing, Sending, and Retransmitting DDT Map-Requests . . 13 68 7.2. Receiving and following referrals . . . . . . . . . . . . 13 69 7.2.1. Referral Set . . . . . . . . . . . . . . . . . . . . . 14 70 7.2.2. Referral list incomplete flag . . . . . . . . . . . . 14 71 7.2.3. Action Types . . . . . . . . . . . . . . . . . . . . . 14 72 7.2.4. Handling referral errors . . . . . . . . . . . . . . . 16 73 7.2.5. Referral loop detection . . . . . . . . . . . . . . . 16 74 8. Example message flow . . . . . . . . . . . . . . . . . . . . . 18 75 8.1. ITR sends a Map-Request to a DDT Map-Resolver . . . . . . 18 76 8.2. DDT Map-Resolver receives and processes Map-Request . . . 18 77 8.3. DDT Map-Resolver searches referral cache for XEID . . . . 18 78 8.4. DDT Map-Resolver creates and sends DDT Map-Request . . . . 19 79 8.5. DDT node receives and processes DDT Map-Request . . . . . 19 80 8.6. DDT Map-Resolver processes Map-Referral . . . . . . . . . 19 81 8.7. DDT Map-Server receives Map-Request . . . . . . . . . . . 20 82 8.8. DDT Map-Resolver finished . . . . . . . . . . . . . . . . 20 83 8.9. DDT Map-Server receives LISP-SEC-enabled Map-Request . . . 20 84 8.10. ETR sends Map-Reply to ITR . . . . . . . . . . . . . . . . 21 85 9. Securing the database and message exchanges . . . . . . . . . 22 86 9.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . . 22 87 9.2. DDT node operation . . . . . . . . . . . . . . . . . . . . 23 88 9.2.1. DDT public key revocation . . . . . . . . . . . . . . 23 89 9.3. Map-Server operation . . . . . . . . . . . . . . . . . . . 23 90 9.4. Map-Resolver operation . . . . . . . . . . . . . . . . . . 24 91 10. Open Issues and Considerations . . . . . . . . . . . . . . . . 25 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 96 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 97 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 98 Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 30 99 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 32 100 Appendix C. Encapsulated Control Message Format . . . . . . . . . 34 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 103 1. Introduction 105 [LISP] specifies an architecture and mechanism for replacing the 106 addresses currently used by IP with two separate name spaces: 107 relatively static Endpoint Identifiers (EIDs), used end-to-end for 108 terminating transport-layer associations, and Routing Locators 109 (RLOCs), which are more dynamic, are bound to topological location, 110 and are used for routing and forwarding through the Internet 111 infrastructure. 113 LISP offers a general-purpose mechanism for mapping between EIDs and 114 RLOCs. In organizing a database of EID to RLOC mappings, this 115 specification extends the definition of the EID numbering space by 116 logically prepending and appending several fields for purposes of 117 defining the database index key: Key-ID (16 bits), Instance 118 Identifier (IID, 32-bits), Address Family Identifier (16 bits), and 119 EID-prefix (variable, according to AFI value). The resulting 120 concatenation of these fields is termed an "Extended EID prefix" or 121 XEID-prefix. 123 The term "Extended EID" (XEID) is also used for an individual LISP 124 EID that is further qualified through the use of an Instance ID. See 125 [LCAF] for further discussion of the use of Instance IDs. 127 The Key-ID is provided for possible use in case a need evolves for 128 another, higher level in the hierarchy, to allow the creation of 129 multiple, separate database trees. 131 LISP-DDT is a hierarchical distributed database which embodies the 132 delegation of authority to provide mappings, i.e. its internal 133 structure mirrors the hierarchical delegation of address space. It 134 also provides delegation information to Map-Resolvers, which use the 135 information to locate EID-to-RLOC mappings. A Map-Resolver which 136 needs to locate a given mapping will follow a path through the tree- 137 structured database, contacting, one after another, the DDT nodes 138 along that path until it reaches the leaf DDT node(s) authoritative 139 for the mapping it is seeking. 141 LISP-DDT defines a new device type, the DDT node, that is configured 142 as authoritative for one or more XEID-prefixes. It also is 143 configured with the set of more-specific sub-prefixes that are 144 further delegated to other DDT nodes. To delegate a sub-prefix, the 145 "parent" DDT node is configured with the RLOCs of each child DDT node 146 that is authoritative for the sub-prefix. Each RLOC either points to 147 a Map-Server (sometimes termed a "terminal DDT node") to which an 148 Egress Tunnel Routers (ETRs) registers that sub-prefix or points to 149 another DDT node in the database tree that further delegates the sub- 150 prefix. See [LISP-MS] for a description of the functionality of the 151 Map-Server and Map-Resolver. Note that the target of a delegation 152 must always be an RLOC (not an EID) to avoid any circular dependency. 154 To provide a mechanism for traversing the database tree, LISP-DDT 155 defines a new LISP message type, the Map-Referral, which is returned 156 to the sender of a Map-Request when the receiving DDT node can refer 157 the sender to another DDT node that has more detailed information. 158 See Appendix B for the definition of the Map-Referral message. 160 A DDT client uses LISP-DDT to find an EID-to-RLOC mapping by first 161 sending a Map-Request to the RLOC of a DDT node. The initial choice 162 of DDT node is configured on the client. If the receiving DDT node 163 is also a Map-Server that is responsible for the XEID queried, the 164 Map-Request is handled as described in [LISP-MS], with the DDT Map- 165 Server also returning a Map-Referral message with the "done" flag set 166 to the Map-Request sender. Otherwise, the DDT node answers the Map- 167 Request with a Map-Referral; the DDT client then re-sends its DDT 168 Map-Request to one of the RLOCs listed in the Map-Referral. This 169 iterative process of sending requests and following referrals 170 continues until the client receives a Map-Referral with the "done" 171 flag set. This is an indication that the terminal DDT Map-Server has 172 either answered the Map-Request (if offering proxy service, as 173 described in [LISP-MS]) or has forwarded it to the correct ETR which 174 will answer it. Conceptually, this is similar to the way that a 175 client of the Domain Name System (DNS) follows referrals (DNS 176 responses that contain only NS records) from a series of DNS servers 177 until it finds an answer. 179 2. Definition of Terms 181 Extended EID (XEID): a LISP EID, optionally extended with a non- 182 zero Instance ID (IID) if the EID is intended for use in a context 183 where it may not be a unique value, such as on a Virtual Private 184 Network where [RFC1918] address space is used. See "Using 185 Virtualization and Segmentation with LISP" in [LISP] for more 186 discussion of Instance IDs. 188 XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT Key-ID 189 (provided to allow the definition of multiple databases; currently 190 always zero in this version of DDT, with other values reserved for 191 future use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix 192 is used as a key index into the database. 194 DDT node: a network infrastructure component responsible for 195 specific XEID-prefix and for delegation of more-specific sub- 196 prefixes to other DDT nodes. 198 DDT client: a network infrastructure component that sends Map- 199 Request messages and implements the iterative following of Map- 200 Referral results. Typically, a DDT client will be a Map-Resolver 201 but it is also possible for an ITR to implement DDT client 202 functionality. 204 DDT Map-Server: a DDT node that also implements Map Server 205 functionality (forwarding Map-Requests and/or returning Map- 206 Replies if offering proxy-mode service) for a subset of its 207 delegated prefixes. 209 DDT Map-Resolver: a network infrastructure element that accepts a 210 Map-Request, adds the XEID to its lookup queue, then queries one 211 or more DDT nodes for the requested EID, following returned 212 referrals until it receives one with the "done" flag. This 213 indicates that the Map-Request has been sent to a Map-Server that 214 will forward it to an ETR that, in turn, will provide a Map-Reply 215 to the original sender. A DDT Map-Resolver maintains both a cache 216 of Map-Referral message results containing RLOCs for DDT nodes 217 responsible for XEID-prefixes of interest (termed the "referral 218 cache") plus a lookup queue of XEIDs that are being resolved 219 through iterative querying of DDT nodes. 221 Encapsulated Map-Request: a LISP Map-Request carried within an 222 Encapsulated Control Message, which has an additional LISP header 223 prepended. Sent to UDP destination port 4342. The "outer" 224 addresses are globally-routable IP addresses, also known as RLOCs. 225 Used by an ITR when sending to a Map-Resolver and by a Map-Server 226 when forwarding a Map-Request to an ETR as documented in 228 [LISP-MS]. 230 DDT Map-Request: an Encapsulated Map-Request sent by a DDT client 231 to a DDT node. The "DDT-originated" flag is set in the 232 encapsulation header indicating that the DDT node should return 233 Map-Referral messages if the Map-Request EID matches a delegated 234 XEID-prefix known to the DDT node. Section 7.1 describes how DDT 235 Map-Requests are sent. 237 Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node 238 and for which the DDT node may provide further delegations of 239 more-specific sub-prefixes. 241 Map-Referral: a LISP message sent by a DDT node when it receives a 242 DDT Map-Request for an XEID that matches a configured XEID-prefix 243 delegation. The Map-Referral message includes a "referral", a set 244 of RLOCs for DDT nodes that have more information about the sub- 245 prefix; a DDT client "follows the referral" by sending another DDT 246 Map-Request to one of those RLOCs to obtain either an answer or 247 another referral to DDT nodes responsible for a more-specific 248 XEID-prefix. See Section 5 and Section 7.2 for details on the 249 sending and processing of Map-Referral messages. 251 negative Map-Referral: a LISP message sent by a DDT node when it 252 receives a DDT Map-Request for an EID that matches a configured 253 authoritative XEID-prefix but for which no delegation (or 254 registration if the DDT node is also a Map-Server) is configured. 256 For definitions of other terms, notably Map-Request, Map-Reply, 257 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, 258 and Map-Resolver, please consult the LISP specification [LISP] and 259 the LISP Mapping Service specification [LISP-MS]. 261 3. EID-prefix tree structure and instance IDs 263 LISP-DDT defines a tree structure that is indexed by a binary 264 encoding of five fields, in order of significance: Key-ID (16 bits), 265 Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 266 16 bits), and EID-prefix (variable, according to AFI value). The 267 fields are concatenated, with the most significant fields as listed 268 above. The index into this structure is also referred to as an 269 Extended EID-prefix (XEID-prefix). 271 It is important to note that LISP-DDT does not store actual EID-to- 272 RLOC mappings; it is, rather, a distributed index that can be used to 273 find the devices (Map-Servers and their registered EIDs) that can be 274 queried with LISP to obtain those mappings. Changes to EID-to-RLOC 275 mappings are made on the ETRs which define them, not to any DDT node 276 configuration. DDT node configuration changes are only required when 277 branches of the database hierarchy are added, removed, or modified. 279 4. Configuring XEID-prefix delegation 281 Every DDT node is configured with one or more XEID-prefixes for which 282 it is authoritative along with a list of delegations of XEID-prefixes 283 that are known to other DDT nodes. A DDT node is required to 284 maintain a list of delegations for all sub- prefixes of its 285 authoritative XEID-prefixes but also may list "hints", which are 286 prefixes that it knows about that belong to its parents, to the root, 287 or to any other point in the XEID-prefix hierarchy. A delegation (or 288 hint) consists of an XEID-prefix, a set of RLOCs for DDT nodes that 289 have more detailed knowledge of the XEID-prefix, and acompanying 290 security information. Those RLOCs are returned in Map-Referral 291 messages when the DDT node receives a DDT Map-Request with an xEID 292 that matches a delegation. A DDT Map-Server will also have a set of 293 sub-prefixes for which it accepts ETR mapping registrations and for 294 which it will forward (or answer, if it implements proxy mode) Map- 295 Requests. For details of security infomation in Map-Referrals see 296 Section 9. 298 4.1. Example DDT node configuration 300 The following is an example of parent and child DDT nodes, where the 301 parent has all of 10.0.0.0/8 and delegates two sub-prefixes, 302 10.0.0.0/12 and 10.0.16.0/12 to two child DDT nodes. All of these 303 prefixes are within the DDT sub-tree Key-ID=0, IID=223, and AFI=1 304 (IPv4). 306 lisp ddt authoritative-prefix instance-id 223 10.0.0.0/8 307 lisp ddt child 192.168.1.100 instance-id 223 eid-prefix 10.0.0.0/12 308 lisp ddt child 192.168.1.200 instance-id 223 eid-prefix 10.16.0.0/12 310 This defines delegation of the EID-prefix 10.0.0.0/12 to a DDT Map 311 Server with RLOC 192.168.1.100 and delegation of the EID-prefix 312 10.16.0.0/12 to a DDT Map-Server with RLOC 192.168.1.200. 314 The child DDT Map-Server for 10.16.0.0/12 is further configured to 315 allow ETRs to register the sub-prefixes 10.18.0.0/16 and 316 10.17.0.0/16: 318 lisp ddt authoritative-prefix instance-id 223 eid-prefix 10.16.0.0/12 319 lisp site site-1 320 eid-prefix 10.18.0.0/16 instance-id 223 321 lisp site site-2 322 eid-prefix 10.17.0.0/16 instance-id 223 324 4.2. The root DDT node 326 The root DDT node is the logical "top" of the database hierarchy: 327 Key-ID=0, EID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that 328 matches no configured XEID-prefix will be referred to the root node. 329 The root node in a particular instantiation of LISP-DDT must 330 therefore be configured with delegations for at least all defined 331 IIDs and AFIs. 333 To aid in defining a "sub-root" DDT node that is responsible for all 334 EID-prefixes within multiple IIDs (say, for using LISP to create 335 virtual networks that use overlapping address space), it may be 336 useful to implement configuration language that allows for a range of 337 IIDs to be delegated together. Additional configuration shorthand 338 for delegating of a range of IIDs (and all of the EIDs under them) 339 may also be helpful. 341 5. DDT node operation - sending referrals 343 When a DDT node receives a DDT Map-Request, it compares the requested 344 XEID against its list of XEID-prefix delegations and its list of 345 authoritative XEID-prefixes and acts as follows: 347 5.1. Match of a delegated prefix (or sub-prefix) 349 If the requested XEID matches one of the DDT node's delegated 350 prefixes, then a Map-Referral message is returned with the matching 351 more-specific XEID-prefix and the set of RLOCs for the referral 352 target DDT nodes including associated security information (see 353 Section 9 for details on security). 355 Note that a matched delegation does not have to be for a sub-prefix 356 of an authoritative prefix; in addition to being configured to 357 delegate sub-prefixes of an authoritative prefix, a DDT node may also 358 be configured with other XEID-prefixes for which it can provide 359 referrals to DDT nodes anywhere in the database hierarchy. This 360 capability to define "shortcut hints" is never required to be 361 configured but may be a useful heuristic for reducing the number of 362 iterations needed to find an EID, particular for private network 363 deployments. 365 5.2. Missing delegation from an authoritative prefix 367 If the requested XEID did not match a configured delegation but does 368 match an authoritative XEID-prefix, then the DDT node returns a 369 negative Map-Referral that includes the least-specific XEID-prefix 370 that does not match any of the DDT node's authoritative XEID- 371 prefixes, including associated security information. This indicates 372 that the XEID is not a LISP destination. 374 If the requested XEID did not match either a configured delegation or 375 an authoritative XEID-prefix, then the request is dropped. This 376 should only happen if either a DDT Map-Resolver or DDT Map-Server is 377 misconfigured. Logging an error message may be a good idea to assist 378 in detecting and resolving such configuration problems. 380 6. DDT Map-Server operation 382 When a DDT Map-Server receives a DDT Map-Request, its operation is 383 similar to that of a DDT node with one exception: if the requested 384 XEID matches a registered XEID-prefix, then the Map-Request is 385 forwarded to one of the destination ETR RLOCs (or the Map-Server 386 sends a Map-Reply, if it is providing proxy service) and a Map- 387 Referral with the MS-ACK action is returned to the sender of the DDT 388 Map-Request. 390 7. DDT Map-Resolver operation 392 Just as any other Map-Resolver, a DDT Map-Resolver accepts Map- 393 Requests from its clients (typically, ITRs) and ensures that those 394 Map-Requests are forwarded to the correct ETR, which generates Map- 395 Replies. Unlike a Map-Resolver that uses the ALT mapping system 396 [LISP-ALT], however, a DDT Map-Resolver needs to maintain more state 397 as it uses an iterative process of following referrals to find the 398 correct ETR to answer a Map-Request. 400 7.1. Queuing, Sending, and Retransmitting DDT Map-Requests 402 When a DDT Map-Resolver receives an encapsulated Map-Request, it 403 first performs a longest-match search for the XEID in its referral 404 cache. If nothing is found or if a negative cache entry is found, 405 then the destination is not in the database; a negative Map-Reply is 406 returned and no further processing is done by the DDT Map-Resolver. 408 Next, the DDT Map-Resolver creates a lookup queue entry for the XEID 409 and saves the original Map-Request along with other information, such 410 as the longest XEID-prefix matched so far, needed for tracking 411 progress through the iterative referral process. The Map-Resolver 412 then creates a DDT Map-Request (which is an encapsulated Map-Request 413 with the "DDT-originated" flag set in the message header) for the 414 XEID but without any authentication data that may have been included 415 in the original Map-Request. It sends the DDT Map-Request to one of 416 the RLOCs in the chosen referral cache entry. The referral cache is 417 initially populated with one or more statically-configured entries; 418 additional entries are added when referrals are followed, as 419 described below. A DDT Map-Resolver is not absolutely required to 420 cache referrals but it not doing so will significantly increase 421 latency and cause lookup delays. 423 Note that in normal use on the public Internet, the statically- 424 configured initial referral cache for a DDT Map-Resolver should 425 include a "default" entry with RLOCs for one or more DDT nodes that 426 can reach the DDT root node. If a Map-Resolver does not have such 427 configuration, it will return a Negative Map-Reply if it receives a 428 query for an EID outside the subset of the mapping database known to 429 it. While this may be desirable on private network deployments or 430 during early transition to LISP when few sites are using it, this 431 behavior is not appropriate when LISP is in general use on the 432 Internet. 434 7.2. Receiving and following referrals 436 After sending a DDT Map-Request, a DDT Map-Resolver can expect one of 437 the following to occur: 439 o No response. The DDT Map-Resolver retransmits the request, 440 choosing a different RLOC from the referral cache entry if one is 441 available. If the maximum number of retransmissions has occurred, 442 then the lookup queue entry is dequeued and a negative Map-Reply 443 is returned to the original Map-Request sender. 445 o A Map-Referral message. This indicates that the replying DDT node 446 or DDT Map-Server doesn't know the ETRs for the specific XEID but 447 does know another DDT node or DDT Map-Server that has information 448 about a matching XEID-prefix. The Map-Referral message contains a 449 "map-record" with additional information that is used by a DDT 450 Map-Resolver to "follow" the referral. The subsections below 451 describe how a DDT Map-Resolver uses the fields in the Map- 452 Referral message to detemine the next step in processing a lookup 453 queue entry. See Appendix B for a detailed description of all 454 Map-Referral message fields. 456 7.2.1. Referral Set 458 The set of RLOCs for DDT-nodes that are authoritative for the XEID- 459 prefix returned in the Map-Referral message. A DDT Map-Resolver 460 sends subsequent Map-Requests to one or more of these RLOCs as it 461 "follows" a referral. 463 7.2.2. Referral list incomplete flag 465 The "Incomplete" flag is set by a DDT Node when it returns a Map- 466 Referral message if the Referral Set is incomplete. A DDT Map- 467 Resolver receiving such a message will need to take appropriate 468 action, specifically not caching the referral. A DDT node must set 469 the "incomplete" flag in the following cases: 471 o The DDT Map-Server would return Map-Referral with the type of 472 either MS-ACK or ms-not-registerd, but it does not have any 473 configuration about other, "peer" Map-Servers for that also 474 authoritative for the matched XEID-prefix. 476 o The DDT node returns a Map-Referral with the action of NOT- 477 AUTHORITATIVE. 479 7.2.3. Action Types 481 A DDT node sets the "Action" field to indicate to a Map-Resolver what 482 action it should take upon receipt of a Map-Referral message. The 483 defined actions are as follows: 485 Type 0, NODE-REFERRAL: Follow the referral by saving the prefix in 486 the referral cache and sending a new Map-Request to the first DDT 487 node listed in the Referral Set. A DDT node sends this action code 488 to instruct a DDT Map-Resolver to query a child DDT node. 490 Type 1, MS-REFERRAL: Follow the referral by saving the prefix in the 491 referral cache and sending a new Map-Request to the first DDT Map- 492 Server listed in the Referral Set. A DDT node sends this action 493 code to instruct a DDT Map-Resolver to query a DDT Map-Server 494 which should have one or more ETRs registered for the matched 495 XEID-prefix. 497 Type 2, MS-ACK: If the "incomplete" flag is not set, then the 498 referral process is complete; save the prefix in the referral 499 cache and de-queue the original Map-Request. A DDT Map-Server 500 sends an "MS-ACK" response to a DDT Map-Resolver when it forwards 501 a Map-Resolver-originated Map-Request to an ETR. 503 Type 3, MS-NOT-REGISTERED: This action code indicates that a DDT 504 Map-Server has received a Map-Request for one of its XEID-prefixes 505 but for which it has no ETR registered. If the DDT Map-Resolver 506 has not yet tried all of the DDT Map-Server RLOCs in its referral 507 cache entry, then sends a Map-Request to the next available DDT 508 Map-Server RLOC. If all RLOCs have been tried, then the 509 destination XEID is not registered and is unreachable. The Map- 510 Resolver returns a negative Map-Reply to the original Map-Request 511 sender; this Map-Reply contains the non-registered XEID prefix 512 with TTL value of one minute. It also removes the lookup queue 513 entry. 515 Type 4, DELEGATION-HOLE: Cache the prefix and return a negative Map- 516 Reply to the original Map-Request sender. The negative Map- 517 Request will indicate the least-specific XEID- prefix matching 518 requested XEID for which no delegations exist; it is sent with a 519 TTL value of 15 minutes. 521 Type 5, NOT-AUTHORITATIVE: A DDT node returns this action code if it 522 receives a Map-Request for an XEID-request for which it is not 523 authoritative. This can occur if a cached referral has become 524 invalid due to a change in the database hierarchy. If the a DDT 525 Map-Resolver that receives this action code can determine that it 526 is using old cached information, it may choose to delete that 527 cached information and re-try the original Map-Request, starting 528 from its "root" cache entry. If this action code is received in 529 response to a query that was not to cached referral information, 530 then it indicates a serious misconfiguration in the database; the 531 original Map-Request should be removed, unanswered, from the 532 lookup queue. 534 7.2.4. Handling referral errors 536 Other states are possible, such as a misconfigured DDT node (acting 537 as a proxy Map-Server, for example) returning a Map-Reply to the DDT 538 Map-Resolver; they should be considered errors and logged as such. 539 It is not clear exactly what else the DDT Map-Resolver should do in 540 such cases; one possibility is to dequeue the lookup queue entry and 541 send a negative Map-Reply to the original Map-Request sender. 542 Alternatively, if a DDT Map-Resolver detects unexpected behavior by a 543 DDT node, it could mark that node as unusable in its referral cache 544 and update the lookup queue entry to try a different DDT node if more 545 than one is listed in the referral cache. 547 7.2.5. Referral loop detection 549 With any iterative process, there is always the danger of an 550 iteration loop. To prevent this, a DDT Map-Resolver keeps track of 551 the most recent "referral XEID-prefix" in each lookup queue entry. 552 When it receives a Map-Referral message, it performs the following 553 check for looping: 555 o For Action Types NODE-REFERRAL and MS-REFERRAL, the new XEID- 556 prefix must be more-specific than the saved prefix; an exact or 557 less-specific match, indicates a referral loop. 559 o For Action Types MS-ACK, MS-NOT-REGISTERED, or DELEGATION-HOLE, 560 the new XEID-prefix must be an exact or more-specific match of the 561 saved prefix; a less-specific match indicates a referral loop. 562 The exact match is allowed here since these messages indicate that 563 the referral process has completed. Note, though, that the cached 564 RLOCs are NOT updated for an exact match since doing so may lose 565 information needed for preventing loops. 567 If a loop is detected, then the Map-Resolver handles the request as 568 described in Section 7.2.4. Otherwise, the Map-Resolver saves the 569 most rececent referral XEID-prefix in the lookup queue entry when it 570 follows the referral. 572 As an extra measure to prevent referral loops, it is probably also 573 wise to limit the total number of referrals for any request to some 574 reasonable number; the exact value of that number will be determined 575 during experimental deployment of LISP-DDT but is bounded by the 576 maximum length of the XEID. 578 Note that when a Map-Request is originally received and an entry has 579 been added to the lookup queue, the new request has no previous 580 referral XEID-prefix; this means that the first DDT node contacted by 581 a DDT Map-Resolver may provide a referral to anywhere in the DDT 582 hierarchy. This, in turn, allows a DDT Map-Resolver to use 583 essentially any DDT node RLOCs for its initial cache entries and 584 depend on the initial referral to provide a good starting point for 585 Map-Requests; there is no need to configure the same set of root DDT 586 nodes in all DDT Map-Resolvers. 588 8. Example message flow 590 The following describes the message flows among an ITR, a DDT Map 591 Resolver, a number of DDT nodes, a DDT Map-Server, and an ETR. It 592 assumes no security associations between the DDT nodes but does show 593 how [LISP-SEC] can be used between the ITR, Map Resolver, Map-Server, 594 and ETR. 596 8.1. ITR sends a Map-Request to a DDT Map-Resolver 598 The first step in using LISP-DDT is the same as for any other Map- 599 Request using the Map-Server interface: an ITR sends an encapsulated 600 Map-Request to one of its configured Map-Resolvers, in this case a 601 DDT Map-Resolver. The outer header source IP address is the ITR and 602 the outer header destination IP address is the DDT Map Resolver. If 603 [LISP-SEC] is in use, then LISP-SEC ECM Authentication Data field is 604 included. 606 8.2. DDT Map-Resolver receives and processes Map-Request 608 The DDT Map-Resolver receives and processes the encapsulated Map- 609 Request by stripping the encapsulation header and creating a lookup 610 queue entry for the XEID, saving the resulting, non-encapsulated Map- 611 Request for later retransmission and re-use during the referral 612 process. If [LISP-SEC] information was included in the original, 613 encapsulated Map-Request then it is also saved in the lookup queue 614 entry for later use. The lookup queue entry will be dequeued when 615 the DDT Map-Resolver is finished with the request (see Section 8.8). 617 Note that if a lookup queue entry already exists for the destination 618 XEID and the requesting ITR (which could happen if an ITR has 619 retransmitted a Map-Request), the Map-Request is replaced to ensure 620 that the ITR-generated nonce and any ECM Authentication Data field 621 are updated. 623 8.3. DDT Map-Resolver searches referral cache for XEID 625 Next, the DDT Map-Resolver searches its referral cache for the XEID. 626 If none is found or if a negative cache entry is found, then the XEID 627 does not exist in the database; a negative Map-Reply is returned to 628 the original sender and the lookup queue entry is dequeued. 630 If the referral cache entry found is for a DDT Map-Server, then the 631 DDT Map-Resolver has found the appropriate terminal node in the DDT 632 hierarchy. It finishes processing the lookup queue entry as 633 described in Section 8.8. 635 At this point, the referral cache entry must be for a DDT node that 636 can provide more-specific information for the requested XEID so a DDT 637 Map-Request is created and sent (see below). 639 8.4. DDT Map-Resolver creates and sends DDT Map-Request 641 To follow a referral and query the next DDT node, the DDT Map 642 Resolver creates a new DDT Map-Request, an encapsulated Map-Request 643 using one of the RLOCs of the target DDT node as the outer header 644 destination IP address and itself as the outer header source IP 645 address. The "DDT-originated" flag is set in the encapsulation 646 header to inform the target DDT node that it should return referrals. 647 The original Map-Request LISP-SEC information, if any was saved in 648 the lookup queue entry, is NOT included. The original Map-Request 649 destination XEID is used in the new Map-Request while the source is 650 one of the DDT Map-Resolver's RLOCs. 652 The new "DDT Map-Request" is transmitted to the destination DDT node. 653 If no response is received within a timeout, it is re-transmitted, 654 preferably using a different destination DDT node RLOC. If the 655 maximum number of retransmissions is exceeded, the request is 656 dequeued and a negative Map-Reply is returned to the ITR that sent 657 the original Map-Request. 659 8.5. DDT node receives and processes DDT Map-Request 661 The destination DDT node searches its configured delegations and 662 authoritative prefixes for the XEID in the received encapsulated Map- 663 Request. If no match is found, then the DDT Map-Request is silently 664 discarded and, optionally, an error is logged. 666 If a delegation is found, the DDT node sends a Map-Referral message 667 back to the DDT Map-Resolver with the matched XEID-prefix and the set 668 of RLOCs for DDT nodes that can be used to resolve XEIDs within that 669 prefix. 671 If no matching delegation was found and the XEID matches one of the 672 DDT node's authoritative prefixes, then the destination is not a LISP 673 XEID (or a configuration error has occurred); the DDT node returns a 674 negative Map-Referral message to the DDT Map-Resolver as described in 675 Section 5.2. 677 8.6. DDT Map-Resolver processes Map-Referral 679 When the DDT Map-Resolver receives a Map-Referral from a DDT-node, it 680 first verifies that it has a corresponding lookup queue entry; if 681 none can be found, then the Map-Referral is silently ignored, with 682 optional error logging. 684 If the received Map-Referral was negative, then the destination XEID 685 is not in the database; a negative Map-Reply is returned to the 686 original Map-Request sender, a negative referral cache entry is 687 created for the returned XEID-prefix (with TTL from the Map-Referral 688 message), and the lookup queue entry is dequeued. 690 For a non-negative Map-Referral, the lookup queue entry is updated 691 with the new referral XEID-prefix and new DDT-node RLOCs. At this 692 point, it also checks to make sure that a referral loop has not 693 occurred (see Section 7.2.5). 695 To speed processing of future Map-Requests for the same XEID-prefix, 696 the DDT Map-Resolver adds a new entry (or updates an existing, 697 matching entry) in its referral cache for the XEID-prefix, RLOC set, 698 and TTL value in the Map-Referral message. Finally, processing 699 continues to Section 8.4 to query the new destination DDT-node. 701 8.7. DDT Map-Server receives Map-Request 703 At this point, the DDT Map-Resolver has found the DDT Map-Server 704 responsible for the destination XEID-prefix and has sent its Map- 705 Request there. The DDT Map-Server receives the DDT Map-Request, 706 strips the encapsulation header, and searches for the destination 707 XEID in its set of configured XEID-prefixes. If the XEID is found 708 and an ETR has registered for it, then DDT Map-Server returns a Map- 709 Referral to the DDT Map-Resolver indicating (by setting the MS-ACK 710 action) that it has found the terminal DDT node. The Map-Request is 711 forwarded to one of the registered ETRs for further processing 712 (Section 8.10). 714 8.8. DDT Map-Resolver finished 716 At this point, the DDT Map-Resolver has finished the referral 717 iteration process. If security processing was requested, the DDT Map 718 Resolver now re-sends the DDT Map-Request to the DDT Map-Server with 719 the LISP-SEC information included in the encapsulation header. The 720 DDT Map-Resolver dequeues the lookup queue entry for the XEID and 721 cleans-up any other saved state. 723 8.9. DDT Map-Server receives LISP-SEC-enabled Map-Request 725 When the DDT Map-Server receives the re-sent DDT Map-Request, with 726 LISP-SEC information included, it decrypts the LISP-SEC information, 727 performs normal LISP-SEC processing, and forwards the resulting Map- 728 Request to the target ETR. 730 8.10. ETR sends Map-Reply to ITR 732 The ETR receives a Map-Request as documented in [LISP], performs any 733 necessary processing of security information, as documented in 734 [LISP-SEC], and sends a Map-Reply to the ITR that sent the original 735 Map-Request. 737 9. Securing the database and message exchanges 739 This section specifies the DDT security architecture that provides 740 data origin authentication, data integrity protection, and XEID 741 prefix delegation. Global XEID prefix authorization is out of the 742 scope of this document. 744 Each DDT node is configured with one or more public/private key 745 pair(s) that are used to digitally sign referral records for XEID- 746 prefix(es) that the DDT node is authoritative for. In other words, 747 each public/private key pair is associated with the combination of a 748 DDT node and the XEID-prefix that it is authoritative for. Every DDT 749 node is also configured with the public keys of its children DDT 750 nodes. By including public keys of target child DDT nodes in the 751 Map-Referral records, and signing each record with the DDT node's 752 private key, a DDT node can securely delegate sub-prefixes of its 753 authoritative XEID-prefixes to its children DDT nodes. 755 Map-Resolvers are configured with one or more trusted public keys 756 referred to as trust anchors. Trust anchors are used to authenticate 757 the DDT security infrastructure. Map-Resolvers can discover a DDT 758 node's public key either by having it configured as a trust anchor, 759 or by obtaining it from the node's parent as part of a signed Map- 760 Referral. When a public key is obtained from a node's parent, it is 761 considered trusted if it is signed by a trust anchor, or if it is 762 signed by a key that was previously trusted. Typically, in a Map- 763 Resolver, the root DDT node public keys should be configured as trust 764 anchors. Once a Map-Resolver authenticates a public key it locally 765 caches the key along with the associated DDT node RLOC and XEID- 766 prefix for future use. 768 9.1. XEID-prefix Delegation 770 In order to delegate XEID sub-prefixes to its children, a parent DDT 771 node signs its Map-Referrals. Every signed Map-Referral also 772 includes the public keys associated with each child DDT node. Such a 773 signature indicates that the parent node is delegating the specified 774 XEID -prefix to a given child DDT node. The signature is also 775 authenticating the public keys associated with the children nodes, 776 and authorizing them to be used by the children DDT nodes to provide 777 origin authentication and integrity protection for further 778 delegations and mapping information of the XEID-prefix allocated to 779 the DDT node. 781 As a result, for a given XEID-prefix, a Map-Resolver can form an 782 authentication chain from a configured trust anchor (typically the 783 root DDT node) to the leaf nodes (Map-Servers). Map-Resolvers 784 leverage this authentication chain to verify the Map-Referral 785 signatures while walking the DDT tree until they reach a Map-Server 786 authoritative for the given XEID-prefix. 788 9.2. DDT node operation 790 Upon receiving a Map-Request, the DDT node responds with a Map- 791 Referral as specified in Section 5. For every record present in the 792 Map-Referral, the DDT node also includes the public keys associated 793 with the record's XEID-prefix and the RLOCs of the children DDT 794 nodes. Each record contained in the Map-Referral is signed using the 795 DDT node's private key. 797 9.2.1. DDT public key revocation 799 The node that owns a public key can also revoke that public key. For 800 instance if a parent node advertises a public key for one of its 801 child DDT nodes, the child DDT node can at a later time revoke that 802 key. Since DDT nodes do not keep track of the Map-Resolvers that 803 query them, revocation is done in a pull model, where the Map- 804 Resolver is informed of the revocation of a key only when it queries 805 the node that owns that key. If the parent DDT is configured to 806 advertise this key, the parent node must also be signaled to remove 807 the key from the records it advertises for the child DDT node; this 808 is necessary to avoid further distribution of the revoked key. 810 To securely revoke a key, the DDT node creates a new Record for the 811 associated XEID-prefix and locator, including the revoked key with 812 the R bit set. The DDT node must also include a signature in the 813 Record that covers this record; this is computed using the private 814 key corresponding to the key being revoked. Such a record is termed 815 a "revocation record". By including this record in its Map- 816 Referrals, the DDT node informs querying Map-Resolvers about the 817 revoked key. A digital signature computed with a revoked key can 818 only be used to authenticate the revocation, and should not be used 819 to validate any data. To prevent a compromised key from revoking 820 other valid keys, a given key can only be used to sign a revocation 821 for that specific key; it cannot be used to revoke other keys. This 822 prevents the use of a compromised key to revoke other valid keys as 823 described in [RFC5011]. A revocation record must be advertised for a 824 period of time equal to or greater than the TTL value of the Record 825 that initially advertisied the key, starting from the time that the 826 advertisement of the key was stopped by removal from the parent DDT 827 node. 829 9.3. Map-Server operation 831 Similar to a DDT node, a Map-Server is configured with one (or more) 832 public/private key pairs that it must use to sign Map-Referrals. 834 However unlike DDT nodes, Map-Servers do not delegate prefixes and as 835 a result they do not need to include keys in the Map-Referrals they 836 generate. 838 9.4. Map-Resolver operation 840 Upon receiving a Map-Referral, the Map-Resolver must first verify the 841 signature(s) by using a trust anchor, or a previously authenticated 842 public key, associated with the DDT node sending the Map-Referral. 843 If multiple authenticated keys are associated with the DDT node 844 sending this Map-Referral, the Key Tag field of the signature can be 845 used to select the right public key for verifying the signature. If 846 the key tag matches more than one key associated with that DDT node, 847 the Map-Resolver must try verifying the signature with all matching 848 keys. For every matching key that is found the Map-Resolver must 849 also verify that the key is authoritative for the XEID-prefix in the 850 Map-Referral record. If such a key is found, the Map-Resolver must 851 use it to verify the associated signature in the record. If no 852 matching key is found, or if none of the matching keys is 853 authoritative for the XEID-prefix in the Map-Referral record, or if 854 such a key is found but the signature is not valid the Map-Referral 855 record is considered corrupted and must be discarded. This may be 856 due to expired keys. The Map-Resolver can try other siblings of this 857 node if there is an alternative node authoritative for the same 858 prefix. If not, the Map-Resolver can query the DDT node's parent to 859 retrieve a valid key. It is good practice to use a counter or timer 860 to avoid repeating this process if the resolver cannot verify the 861 signature after several trials. 863 Once the signature is verified, the Map-Resolver has verified the 864 XEID-prefix delegation in the Map-Referral, and authenticated the 865 public keys of the children DDT nodes. The Map-Resolver must add 866 these keys to the authenticated keys associated with each child DDT 867 node and XEID-prefix. These keys are considered valid for the 868 duration specified in the record's TTL field. 870 10. Open Issues and Considerations 872 There are a number of issues with the organization of the mapping 873 database that need further investigation. Among these are: 875 o Unlike in [LISP-ALT], DDT does not currently define a mechanism 876 for propagating ETR-to-Map-Server registration state. This 877 requires DDT Map-Servers to suppress returning negative Map-Reply 878 messages for defined but unregistered XEID-prefixes to avoid loss 879 of connectivity during partial ETR registration failures. 880 Suppressing these messages may cause a delay for an ITR obtaining 881 a mapping entry when such a failure is occurring. 883 o Defining an interface to implement interconnection and/or 884 interoperability with other mapping databases, such as LISP+ALT. 886 o Additional key structures for use with LISP-DDT, such as to 887 support additional EID formats as defined in [LCAF]. 889 o Authentication of delegations between DDT nodes. 891 o Possibility of a new, more general format for the Map-Referral 892 messages to facilitate the use of LISP-DDT with additional Key-ID/ 893 IID/EID combinations. Currently-defined packet formats should be 894 considered to be preliminary and provisional until this issue has 895 received greater attention. 897 o Management of the DDT Map-Resolver referral cache, in particular, 898 detecting and removing outdated entries. 900 The authors expect that experimentation on the LISP pilot network 901 will help answer open questions surrounding these and other issues. 903 11. IANA Considerations 905 This document makes no request of the IANA. 907 12. Security Considerations 909 See Section 9 for a detailed description of protocol mechanisms 910 intended to secure the database. 912 Open security issues include: xxx 914 13. References 916 13.1. Normative References 918 [LCAF] Farinacci, D. and J. Snijders, "LISP Canonical Address 919 Format", draft-ietf-lisp-lcaf-06.txt (work in progress), 920 October 2011. 922 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 923 "Locator/ID Separation Protocol (LISP)", 924 draft-ietf-lisp-22.txt (work in progress), February 2012. 926 [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface", 927 draft-ietf-lisp-ms-16.txt (work in progress), 928 February 2012. 930 [RFC1035] Mockapetris, P., "Domain names - implementation and 931 specification", STD 13, RFC 1035, November 1987. 933 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 934 Hashing for Message Authentication", RFC 2104, 935 February 1997. 937 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 938 (SHA and HMAC-SHA)", RFC 4634, July 2006. 940 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 941 Trust Anchors", RFC 5011, September 2007. 943 13.2. Informative References 945 [LISP-ALT] 946 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 947 Alternative Topology (LISP-ALT)", 948 draft-ietf-lisp-alt-10.txt (work in progress), 949 December 2011. 951 [LISP-SEC] 952 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 953 Bonaventure, "LISP-Security", draft-ietf-lisp-sec-01.txt 954 (work in progress), January 2012. 956 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 957 E. Lear, "Address Allocation for Private Internets", 958 BCP 5, RFC 1918, February 1996. 960 Appendix A. Acknowledgments 962 The authors with to express their thanks to Damien Saucez, Lorand 963 Jakab, and Olivier Bonaventure for work on LISP-TREE and LISP 964 iterable mappings that inspired the hierarchical database structure 965 and lookup iteration approach described in this document. Special 966 thanks also go to Amit Jain, Isidor Kouvelas, Jesper Skriver, Andrew 967 Partan, and Noel Chiappa, all of whom have participated in (and put 968 up with) seemingly endless hours of discussion of LISP mapping 969 database ideas and issues. 971 Appendix B. Map-Referral Message Format 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 |Type=6 | Reserved | Record Count | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Nonce . . . | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | . . . Nonce | 981 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | | Record TTL | 983 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 R | Referral Count| EID mask-len | ACT |A|I| Reserved | 985 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 c |SigCnt | Map Version Number | EID-AFI | 987 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 r | EID-prefix ... | 989 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | /| Priority | Weight | M Priority | M Weight | 991 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | o | Unused Flags |R| Loc/LCAF-AFI | 993 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | \| Locator ... | 995 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 ACT: The "action" field of the mapping record in a Map-Referral 998 message encodes 6 action types. The values for the action types are: 1000 Type 0, NODE-REFERRAL: Sent by a DDT node with a child delegation 1001 which is authoritative for the EID. 1003 Type 1, MS-REFERRAL: Sent by a DDT node that has information about 1004 Map-Server(s) for the EID but it is not one of the Map-Servers 1005 listed, i.e. the DDT-Node sending the referral is not a Map- 1006 Server. 1008 Type 2, MS-ACK: Sent by a DDT Map-Server that has one or more ETR 1009 registered for the EID. 1011 Type 3, MS-NOT-REGISTERED: Sent by a DDT Map-Server that is 1012 configured for the EID-prefix but for which no ETRs are 1013 registered. 1015 Type 4, DELEGATION-HOLE: Sent by an intermediate DDT node with 1016 authoritative configuration covering the requested EID but without 1017 any child delegation for the EID. Also sent by a DDT Map-Server 1018 with authoritative configuration covering the requested EID but 1019 for which no specific site ETR is configured. 1021 Type 5, NOT-AUTHORITATIVE: Sent by a DDT node that does not have 1022 authoritative configuration for the requested EID. The EID-prefix 1023 returned MUST be the original requested EID and the TTL MUST be 1024 set to 0. However, if such a DDT node has a child delegation 1025 covering the requested EID, it may choose to return NODE-REFERRAL 1026 or MS-REFERRAL as appropriate. A DDT Map-Server with site 1027 information may choose to return of type MS-ACK or MS-NOT- 1028 REGISTERED as appropriate. 1030 Incomplete: The "I" bit indicates that a DDT node's referral-set of 1031 locators is incomplete and the receiver of this message should not 1032 cache the referral. A DDT sets the "incomplete" flag, the TTL, and 1033 the Action Type field as follows: 1035 ------------------------------------------------------------------- 1036 Type (Action field) Incomplete Referral-set TTL values 1037 ------------------------------------------------------------------- 1038 0 NODE-REFERRAL NO YES 1440 1040 1 MS-REFERRAL NO YES 1440 1042 2 MS-ACK * * 1440 1044 3 MS-NOT-REGISTERED * * 1 1046 4 DELEGATION-HOLE NO NO 15 1048 5 NOT-AUTHORITATIVE YES NO 0 1049 ------------------------------------------------------------------- 1051 *: The "Incomplete" flag setting on Map-Server originated referral of 1052 MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map- 1053 Server has the full peer Map-Server configuration for the same 1054 prefix and has encoded the information in the mapping record. 1055 Incomplete bit is not set when the Map-Server has encoded the 1056 information, which means the referral-set includes all the RLOCs 1057 of all Map-Servers that serve the prefix. It is set when the Map- 1058 Server has not encoded the Map-Server set information. 1060 SigCnt: Indicates the number of signatures (sig section) present in 1061 the Record. If SigCnt is larger than 0, the signature information 1062 captured in a sig section as described in Appendix B.1 will be 1063 appended to the end of the record. The number of sig sections at the 1064 end of the Record must match the SigCnt. 1066 Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the 1067 record. If this is a LCAF AFI, the contents of the LCAF depend on 1068 the Type field of the LCAF. Security material are stored in LCAF 1069 Type 11. DDT nodes and Map-Servers can use this LCAF Type to include 1070 public keys associated with their Child DDT nodes for a XEID-prefix 1071 referral record. LCAF types and formats are defined in [LCAF]. 1073 All the field descriptions are equivalent to those in the Map-Reply 1074 message, as defined in [LISP]. Note, though, that the set of RLOCs 1075 correspond to the DDT node to be queried as a result of the referral 1076 not the RLOCs for an actual EID-to-RLOC mapping. 1078 B.1. SIG section 1080 If SigCnt field in the Map-Referral is not 0, the signature 1081 information is included at the end of captured in a sig section as 1082 described below. SigCnt counts the number of sig sections that 1083 appear at the end of the Record. 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 /| Original Record TTL | 1087 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 / | Signature Expiration | 1089 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 s | Signature Inception | 1091 i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 g | Key Tag | Sig Length | 1093 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 \ | Sig-Algorithm | Reserved | Reserved | 1095 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 \ ~ Signature ~ 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 Original Record TTL: The original Record TTL for this record that is 1100 covered by the signature. Record TTL is in minutes. 1102 Key Tag: An identifier to specify which key is used for this 1103 signature if more than one valid key exists for the signing DDT node. 1105 Sig Length: The length of the Signature field. 1107 Sig-Algorithm: The identifier of the cryptographic algorithm used for 1108 the signature. Default value is RSA-SHA1. 1110 Reserved: This field must be set to 0 on transmit and must be ignored 1111 on receipt. 1113 Signature Expiration and Inception: Specify the validity period for 1114 the signature. Each specify a date and time in the form of a 32-bit 1115 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 1116 ignoring leap seconds, in network byte order. 1118 Signature: Contains the cryptographic signature that covers the 1119 entire record. The Record TTL and the sig fields are set to zero for 1120 the purpose of computing the Signature 1122 Appendix C. Encapsulated Control Message Format 1124 0 1 2 3 1125 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 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 / | IPv4 or IPv6 Header | 1128 OH | (uses RLOC addresses) | 1129 \ | | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 / | Source Port = xxxx | Dest Port = 4342 | 1132 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 \ | UDP Length | UDP Checksum | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 LH |Type=8 |S|D| Reserved | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 / | IPv4 or IPv6 Header | 1138 IH | (uses RLOC or EID addresses) | 1139 \ | | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 / | Source Port = xxxx | Dest Port = yyyy | 1142 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 \ | UDP Length | UDP Checksum | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 LCM | LISP Control Message | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 "D" is the "DDT-originated" flag and is set by a DDT client to 1149 indicate that the receiver can and should return Map-Referral 1150 messages as appropriate. 1152 Authors' Addresses 1154 Vince Fuller 1155 cisco Systems 1156 Tasman Drive 1157 San Jose, CA 95134 1158 USA 1160 Email: vaf@cisco.com 1162 Darrel Lewis 1163 cisco Systems 1164 Tasman Drive 1165 San Jose, CA 95134 1166 USA 1168 Email: darlewis@cisco.com 1170 Vina Eermagan 1171 cisco Systems 1172 Tasman Drive 1173 San Jose, CA 95134 1174 USA 1176 Email: vermagan@cisco.com