idnits 2.17.1 draft-meyer-lisp-cons-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1356. 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 54 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2007) is 6142 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'D' is mentioned on line 610, but not defined == Missing Reference: 'C' is mentioned on line 610, but not defined == Missing Reference: 'B' is mentioned on line 610, but not defined == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-01 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Brim 2 Internet-Draft D. Farinacci 3 Intended status: Informational V. Fuller 4 Expires: January 4, 2008 D. Lewis 5 D. Meyer 6 July 3, 2007 8 LISP-CONS: A Content distribution Overlay Network Service for LISP 9 draft-meyer-lisp-cons-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 4, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Content distribution Overlay Network Service for LISP (LISP-CONS) 43 is a protocol for distributing identifier-to-locator mappings for the 44 Locator/ID Separation Protocol (LISP). LISP-CONS is not a routing 45 protocol. LISP-CONS is designed to scale by using a hierarchical 46 content distribution system comprised of Tunnel Routers, Content 47 Access Resources, and Content Distribution Resources. 49 Table of Contents 51 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. LISP-CONS Name Spaces . . . . . . . . . . . . . . . . . . 5 55 3.2. LISP-CONS Network Elements . . . . . . . . . . . . . . . . 5 56 3.3. Relationship Between LISP-CONS Network Elements . . . . . 7 57 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 58 5. The LISP-CONS Protocol . . . . . . . . . . . . . . . . . . . . 10 59 5.1. Building the LISP-CONS Database . . . . . . . . . . . . . 10 60 5.2. Querying the LISP-CONS Database . . . . . . . . . . . . . 11 61 5.3. Maintaining the LISP-CONS Database . . . . . . . . . . . . 12 62 5.3.1. An EID-Prefix Is Administratively Removed From The 63 Infrastructure . . . . . . . . . . . . . . . . . . . . 13 64 5.3.2. A CAR's Connectivity Changes . . . . . . . . . . . . . 13 65 5.3.3. A CAR Becomes Unreachable . . . . . . . . . . . . . . 14 66 5.3.4. A CDR Becomes Unreachable . . . . . . . . . . . . . . 15 67 6. LISP-CONS Message Types . . . . . . . . . . . . . . . . . . . 16 68 6.1. Open Message . . . . . . . . . . . . . . . . . . . . . . . 16 69 6.2. Push-Add and Push-Delete . . . . . . . . . . . . . . . . . 18 70 6.3. Map-Request Message . . . . . . . . . . . . . . . . . . . 20 71 6.4. Map-Reply Message . . . . . . . . . . . . . . . . . . . . 22 72 6.5. Unreachable Message . . . . . . . . . . . . . . . . . . . 25 73 7. Operational Considerations . . . . . . . . . . . . . . . . . . 26 74 8. LISP-CONS and Locator Reachability . . . . . . . . . . . . . . 26 75 9. LISP-CONS and Mobility . . . . . . . . . . . . . . . . . . . . 26 76 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 79 12.1. Apparent LISP-CONS Vunerabilities . . . . . . . . . . . . 27 80 12.2. Survey of LISP-CONS Security Mechanisms . . . . . . . . . 28 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 83 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 84 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 86 Intellectual Property and Copyright Statements . . . . . . . . . . 31 88 1. Requirements Notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 The Content distribution Overlay Network Service for LISP, or LISP- 97 CONS, is a control-plane protocol for distributing identifier-to- 98 locator mappings for the Locator/ID Separation Protocol (LISP) 99 [LISP-01]. The properties of such a "locator/id split" have been 100 discussed in depth in various venues dating back to [CHIAPPA] and 101 [RFC1498], and as such will not be reviewed here. Rather, the reader 102 is referred to the above references for an outline of the various 103 benefits that may be realized by separating the functionality of IP 104 addresses into separate Endpoint Identifier and Routing Locator name 105 spaces. 107 LISP-CONS operates on a distributed Endpoint Identifier-to-Routing 108 Locator (EID-to-RLOC) database. This database is distributed among 109 the authoritative Replying Content Access Resources (Replying-CAR). 110 A Replying-CAR advertises "reachability" for its EID-to-RLOC mappings 111 through a hierarchical network of Content Distribution Resources 112 (CDRs) (but importantly, not the mapping itself), and responds to 113 mapping requests from the system. A CAR may also request mappings 114 from the system (Requesting-CAR). Ingress Tunnel Routers (ITRs) 115 connect to one or more Requesting-CARs to query the system for EID- 116 to-RLOC bindings; the Requesting-CAR then queries the system on 117 behalf of the ITR. These queries follow the overlay network to the 118 authoritative Replying-CAR, which responds with the mapping. This 119 response may then be cached by the 'local' CAR. Finally, note that 120 neither a Requesting-CAR or Replying-CAR need to hold the entire EID- 121 to-RLOC database. Rather, the EID-to-RLOC translations are 122 explicitly pulled by the ITRs by querying one or more of its 123 connected Requesting-CARs. 125 Note that LISP-CONS is not designed for the "fast-mobility" case. 126 That is, it is envisioned that the mappings distributed by LISP-CONS 127 are reasonably static. LISP-CONS is also not designed to carry 128 Locator Reachability status information; see [LISP-01] for details on 129 how LISP determines locator reachability. 131 LISP-CONS seeks to control the "state * rate" scaling properties of 132 the mapping service by first observing that the host mapping state is 133 likely to be quite large (some estimates put the size of this 134 database to be on the order of 10^10 hosts). As a result, even with 135 aggressive aggregation, the "rate" of change of the mapping database 136 must be kept small. LISP-CONS manages the rate problem by 137 distributing highly aggregated information about the location of the 138 EID-to-RLOC mappings (which are assumed to change at low frequency) 139 over a peering network. The peering network is comprised of ITRs, 140 CARs and CDRs. 142 In summary, LISP-CONS is a hybrid "push/pull" protocol in which 143 information about the existence of a particular mapping is "pushed" 144 at the higher levels of the aggregation hierarchy, while the actual 145 EID-to-RLOC mappings are "pulled" from the network elements at the 146 lowest level of the hierarchy. In particular, LISP-CONS carries 147 mapping requests and replies to and from the lowest level of the 148 hierarchy where the EID-to-RLOC mappings reside. 150 While this draft focuses on a router-based solution, there is no 151 architectural reason that LISP-CONS functionality could not be 152 implemented in other devices (i.e., hosts). However, in keeping with 153 the architectural direction taken by the LISP data-plane proposal 154 [LISP-01], LISP-CONS is based on the the theory that building the 155 solution into the network should facilitate incremental deployment of 156 the technology on the Internet. In order to minimize the required 157 investment in deployment of new hardware, it is assumed that much, if 158 not all, the initial implementation will be in routers. Finally, 159 while the detailed protocol specification and examples in this 160 document assume IP version 4 (IPv4), there is nothing in the design 161 that precludes the use of the same techniques and mechanisms for 162 IPv6. 164 The remainder of this document is organized as follows: Section 3 165 provides the set of definitions that are used in this document, and 166 Section 4 provides an overview of LISP-CONS operation. Section 5 167 describes the LISP-CONS protocol, and Section 6 provides details of 168 the LISP-CONS message types. Section 7 outlines operational 169 considerations, Section 8 discusses locator reachability, and 170 Section 9 considers the interaction of LISP-CONS with mobile nodes. 171 Section 12 outlines security considerations for LISP-CONS. 173 Finally, this proposal (as well as the LISP data-plane proposal) was 174 stimulated by the problem statement effort at the IAB Routing and 175 Addressing Workshop (RAWS) [I-D.iab-raws-report], which took place in 176 Amsterdam in October 2006. 178 3. Definition of Terms 180 The LISP-CONS protocol operates on two name spaces and is comprised 181 of four network elements. This section provides high-level 182 definitions of the LISP-CONS name spaces, network elements, and 183 message types. 185 3.1. LISP-CONS Name Spaces 187 Endpoint ID (EID): A 32- or 128-bit value used in the source and 188 destination fields of the first (most inner) LISP header of a 189 packet. A packet that is emitted by a system contains EIDs in its 190 headers and and LISP headers are prepended only when the packet 191 hits an Ingress Tunnel Router (ITR) on the data path to the 192 destination EID. 194 In LISP-CONS, EID-prefixes MUST BE assigned in a hierarchical 195 manner (in power-of-two or larger chunks) such that they can be 196 aggregated either by Content Access Resources or Content 197 Distribution Resources (see below). In addition, a site may have 198 site-local structure in how EIDs are topologically organized 199 (subnetting) for routing within the site; this structure is not 200 visible to the global routing system. 202 Routing Locator (RLOC): The IP address of an egress tunnel router 203 (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID 204 maps to one or more RLOCs. Typically, RLOCs are numbered from 205 topologically-aggregatable blocks that are assigned to a site at 206 each point to which it attaches to the global Internet; where the 207 topology is defined by the connectivity of provider networks, 208 RLOCs can be thought of as Provider Aggregatable (PA) addresses. 210 EID-to-RLOC Mapping: A binding between and EID and the RLOC-set 211 that can be used to reach the EID. We use the term "mapping" in 212 this document to refer to a EID-to-RLOC mapping. 214 3.2. LISP-CONS Network Elements 216 LISP-CONS consists of the four network element types described below. 217 Peering connections between these element types use RLOCs so that the 218 underlying routing system can keep the LISP-CONS peering connections 219 up (i.e., to avoid circular dependencies on the mapping system). 220 Each peering connection is required to be configured with a keyed- 221 hash message authentication code (HMAC) key. A connection MUST NOT 222 be established without the TCP HMAC option included. 224 Content Distribution Resource (CDR): A CDR provides aggregation of 225 EID prefix lists, propagation of EID-prefix lists to parent CDRs, 226 and routing of mapping requests to and from CARs. 228 There may be several levels of aggregation of CDRs. CDRs do not 229 themselves carry EID prefix to RLOC mappings. CDRs are arranged 230 in a hierarchical manner in order to enable aggressive aggregation 231 of EID-prefixes. 233 Content Access Resource (CAR): A CAR fills one or both of the 234 following roles: 236 Replying-CAR: A CAR is the source of authority for one or more 237 EID prefix to RLOC mappings which which it has been 238 administratively configured, and responds to Map Requests for 239 these EID-to-RLOC mappings. Each Replying-CAR provides to 240 parent CDRs a list of prefixes that it is responsible for, but 241 not the mappings themselves. 243 In particular, Replying-CARs peer with CDRs to propagate 244 aggregated information about how to find a particular EID-to- 245 RLOC mapping upward (but importantly, not the mapping itself). 246 However, Replying-CARs do not peer with other CARs. The 247 primary difference between the Replying-CAR and CDR is that a 248 CAR maintains two databases: A EID-to-RLOC mapping database, 249 and a EID-prefix database. A CDR maintains only an EID-prefix 250 database. 252 Requesting-CAR: A CAR that generates Map-Request messages on 253 behalf of one or more of its ITR peers (see below). Note that 254 Requesting-CAR has peering connections with ITRs whereas a 255 Replying-CAR does not have to. Finally, both functionalities 256 (Requesting-CAR and Replying-CAR) MAY be co-located in the same 257 device. In particular, Requesting-CAR MUST also be a Replying- 258 CAR while a a Replying-CAR need not be a Requesting-CAR. 260 Egress Tunnel Router (ETR): A router that accepts an IP packet where 261 destination address in the "outer" IP header is one of its own 262 RLOCs. The router strips the "outer" header and forwards the 263 packet based on the next IP header found. In general, an ETR 264 receives LISP-encapsulated IP packets from the Internet on one 265 side and sends decapsulated IP packets to site end-systems on the 266 other side. 268 Ingress Tunnel Router (ITR): A router which accepts an IP packet 269 with a single IP header (more precisely, an IP packet that does 270 not contain a LISP header). The router treats this "inner" IP 271 destination address as an EID and performs an EID-to-RLOC mapping 272 lookup. The router then prepends an "outer" IP header with one of 273 its globally-routable RLOCs in the source address field and the 274 result of the mapping lookup in the destination address field. 275 Note that this destination RLOC may be an intermediate, proxy 276 device that has better knowledge of the EID-to-RLOC mapping 277 closest to the destination EID. In general, an ITR receives IP 278 packets from site end-systems on one side and sends LISP- 279 encapsulated IP packets toward the Internet on the other side. 280 ITRs may also have TCP connections to Requesting-CARs in order to 281 send mapping requests and receive replies (noting that any 282 combination of a Requesting-CAR, a Replying-CAR, and an ITR may be 283 co-located). 285 3.3. Relationship Between LISP-CONS Network Elements 287 Each LISP-CONS device is known by a single identifier, which is used 288 for peering from all peers, and in path-vector (PV) lists. This 289 identifier MAY be an IP address. An implementation SHOULD use a 290 loopback address for this purpose. Note that this address MUST be 291 routable by the core routing system. 293 LISP-CONS network elements peer with each other in one of three 294 peering relationships: parent, child, or sibling. The relationship 295 is carried in the LISP-CONS OPEN message (Section 6.1). The 296 permitted peering relationships are as follows: 298 o ITRs exist at lowest (unnumbered) level in the peering hierarchy, 299 and peer only with one or more CARs. An ITR MUST NOT peer with 300 another ITR or with a CDR. 302 o CARs exist at level 0 in the peering hierarchy, and peer only with 303 parent CDRs or with a child ITR. A CAR MUST NOT peer with another 304 CAR; this rule allows the Replying-CARs to aggregate EID prefixes 305 as low in the hierarchy as possible. Note that this rule also 306 means that mapping requests and replies are routed over the 307 peering topology, not directly between the CARs. 309 o CDRs exist at level 1 (and above) and aggregate EID-prefixes learn 310 from its Replying-CAR peerings. When a two CDRs start their 311 peering connection, if one is a parent, the other MUST BE a child. 312 Otherwise, they both MUST BE siblings. 314 o If any of these checks fail, the peering connection MUST NOT be 315 established. 317 4. Overview of Operation 319 LISP-CONS constructs a multi-level content distribution overlay which 320 achieves scalability by imposing a strict aggregation hierarchy on 321 the participating elements. The LISP-CONS hierarchy consists of ITRs 322 the bottom of the hierarchy, CARs at level 0, and CDRs at levels 1 323 and above; this is depicted in Figure 1. Each level of the hierarchy 324 is a strict tree. That is, there are no transit loops in the 325 hierarchy; redundancy is achieved by meshing CDR connectivity within 326 in a single level of the hierarchy, and the LISP-CONS protocol 327 assures that message flow is loop-free. 329 In LISP-CONS, the EID-to-RLOC mappings are held in the Replying-CARs, 330 while the CDRs maintain information about how to find the Replying- 331 CAR holding a particular EID-to-RLOC mapping. That is, the Push-Add 332 and Push-Delete messages (Section 6.2) only contain EID-prefixes 333 (i.e., Locator-sets are not included in these messages and are not 334 stored in the CDRs). 336 In general, LISP-CONS uses network element redundancy to avoid 337 mapping database inconsistencies that may arise in those cases in 338 which a CAR or CDR crashes. Similarly, connectivity outages are 339 avoided by configuring a redundant underlying topology. 341 +----------------+ 342 | CDR ------ CDR | 343 +--|----------|--+ 344 / \ 345 / \ 346 +----------------+ +----------------+ 347 | CDR ------ CDR | | CDR ------ CDR | (CDR-mesh at level 2) 348 +--|----------|--+ +--|----------|--+ 349 | | | | 350 | | | | 351 +---|----------|----+ +---|----------|---+ 352 | CDR ------ CDR | | CDR ------ CDR | 353 | | | | | | | | (CDR-Mesh at level 1) 354 | | | | | | | | 355 | CDR ------ CDR | | CDR ------ CDR | 356 +---|----------|----+ +---|----------|---+ 357 | | | | 358 | | | | 359 | | | | 360 CAR CAR CAR CAR 361 / \ / \ / \ / \ 362 / \ / \ / \ / \ 363 ITR ITR ITR ITR ITR ITR ITR ITR 365 Figure 1: LISP-CONS Hierarchy 367 Figure 2 depicts the details of the first three levels of hierarchy. 368 Note that there are no horizontal TCP connections between the ITRs or 369 between the CARs. Note that Requesting-CARs (abbreviated "Req-CAR") 370 peer with the ITRs, while the Replying-CARs may not. The CDRs at 371 level 1 are meshed so that the two Replying-CARs can aggregate to the 372 same mesh level. 374 CDR --- CDR (level-1) 375 |\ /| 376 | \ / | 377 | \ / | 378 | X | 379 | / \ | 380 | / \ | 381 |/ \| 382 CAR CAR (level-0) 383 |\ /| 384 | \ / | 385 | \ / | 386 | X | 387 | / \ | 388 | / \ | 389 |/ \| 390 ITR ITR 392 Figure 2: LISP-CONS Hierarchy Detail 394 LISP-CONS operates as follows: A Replying-CAR receives EID-to-RLOC 395 mappings by administrative configuration. The Replying-CARs 396 aggregate these EID-prefixes, and "push" the aggregated EID-prefixes 397 to their (parent) CDRs in Push-Add messages (see Section 6.2). CDRs 398 then flood the Push-Add messages to their sibling CDRs. Note that 399 the Push messages contain EID-prefix reachability information, not 400 locator sets. 402 If a CDR is a child, it then pushes the aggregate for the EID-prefix 403 (i.e., the aggregate that "covers" the EID-prefix) to its parent 404 CDRs. This CDR MUST also originate the default EID-prefix 0.0.0.0/0 405 (this allows Requests and Replies to flow up and down the aggregation 406 hierarchy). This default is contained within the level of the 407 sibling mesh. Note that aggregates MUST only be generated when the 408 components of the aggregate are all longer prefixes than the 409 aggregate (and importantly, NOT equal in length). For example, a CDR 410 MUST NOT generate an aggregate such as A.B.0.0/16 if it has not heard 411 a A.B.*.0/24 from either a child or sibling peer. 413 When an ITR needs a mapping, it sends a Map-Request message to its 414 directly connected Requesting-CARs. If any of those CARs have cached 415 the requested mapping, the result is immediately returned to the ITR. 416 Otherwise, the Map-Request message is routed through the CDR 417 hierarchy to the Replying-CAR which holds the mapping. That CAR then 418 returns the mapping in a Map-Reply message (which is routed over the 419 peering topology) to the Requesting-CAR, which then forwards it on to 420 the requesting ITR. 422 Finally, note that this type of advertisement hierarchy allows EID 423 lookups to have lower Round Trip Times (RTTs) when the EID-prefix is 424 "close" (in the EID allocation hierarchy) to the site's attached CAR. 425 However, for scalability reasons, a request may have to travel extra 426 hops to get an EID-prefix that can only be obtained by going up the 427 tree (and in the worse case, by going to the top of the hierarchy and 428 down to the Replying-CAR that hold the mapping). 430 5. The LISP-CONS Protocol 432 This section describes the LISP-CONS protocol in detail, starting 433 with how LISP-CONS builds a distributed mapping database, how an ITR 434 queries the database, and how the database is maintained. 436 LISP-CONS operates on three different data structures: 438 EID-to-RLOC Database: The EID-to-RLOC mapping database, which is 439 administratively configured and held in the Replying-CARs. 441 Mapping Cache: The Mapping Cache (hereafter cache) is the result of 442 a Map-Request and is stored in the ITRs and Requesting-CARs. 444 EID-Prefix Table: The EID-Prefix table is used to route Map-Requests 445 and Map-Replies in the overlay network. It is stored only by 446 CDRs, and associates an EID-prefix with a 64-bit sequence number, 447 a path-vector, and a priority and weight (to facilitate later 448 aggregation, if possible). 450 5.1. Building the LISP-CONS Database 452 When a Replying-CAR is configured with an EID-to-RLOC mapping, it 453 checks to see if it can aggregate the just learned EID-prefix with 454 any of the other EID-prefixes it has been configured with. The CAR 455 then sends ("pushes") the EID-prefix (or an aggregate, if possible) 456 to its parent CDR in a Push-Add message. 458 Push-Add messages contain an EID-prefix, and Originator Address, a 459 64-bit sequence number, and a PV that records the path the message 460 took in the CDR level (Section 6.3). Note that the Originator 461 Address is an EID used to route a Reply back to the requesting ITR 462 The PV list will always contain Locators. 464 When a CDR receives a Push-Add message, it first checks to see if the 465 sequence number for the EID-prefix is numerically larger than what it 466 has stored for the EID-prefix. If it is not, the message is dropped. 467 Otherwise, the CDR next checks for its own address in the PV. If it 468 exists, the message is discarded. Otherwise, the CDR stores EID- 469 prefix and the associated PV. Note that the CDR can store all 470 different combination of PVs or just the shortest path ones. If the 471 CDR has one or more parent peerings configured (i.e., the CDR is a 472 child), it will aggregate this EID-prefix with other EID-prefixes 473 into a more coarse EID-prefix. The CDR does not need to advertise 474 anything to lower-level CDRs because child peers will auto-generate a 475 default EID-prefix into their level simply due to having a child- 476 parent peering relationship. 478 When a CDR sends a Push-Add message to a parent, the stored PV is not 479 propagated to the parent in the aggregated EID-prefix; rather, it 480 includes a one element PV which contains the address of the CDR 481 originating the "aggregated push". It also includes a new sequence 482 number, indicating that this is a different EID-prefix than the ones 483 it has stored. 485 Finally, if a CDR is a child, it pushes a "EID-default" to its 486 siblings. This Push message has EID-prefix 0.0.0.0/0 and a PV 487 containing the address of the CDR that is sourcing the default. 489 5.2. Querying the LISP-CONS Database 491 Map Requests are routed along the LISP-CONS multi-level topology from 492 requesting ITR to Replying-CAR holding the requested mapping. The 493 Map-Request message includes a PV which records the route traversed 494 by the Map-Request message. This PV is used to control request 495 routing and for debugging purposes. 497 When an ITR wants to query the LISP-CONS database for a mapping, it 498 prepares a Map-Request message, which is sent to one of its directly 499 connected Requesting-CAR(s). The Map-Request message is routed over 500 the peering topology to the Replying-CAR that holds the mapping. If 501 the Requesting-CAR has cached the mapping (perhaps from a previous 502 request), in which case it returns the mapping immediately. 504 When a Requesting-CAR receives a Map-Request from from an ITR, it MAY 505 respond immediately if it has the cached requested mapping. 506 Otherwise, it MUST forward the Map-Request message to its parent 507 CDRs. This CAR is identified by the Originator address in the Map- 508 Request message (Section 6.3). The Originator address allows a 509 replying CDR to forward a Unreachable message (Section 6.5) back to 510 the Requesting-CAR. This case arises when source-site is LISP- 511 enabled (i.e., there is an ITR deployed), but the destination-site 512 has not deployed LISP yet so there is no ETR. 514 When a Map-Request arrives at a CDR, the CDR first scans its PV for 515 its address. If its address is present, it drops the packet. If its 516 address is not present, it consults its EID-prefix table for the 517 longest match "next-hop" towards the Replying-CAR holding the mapping 518 for the prefix. If a next-hop is found, the CDR appends its address 519 to the PV, and forwards the Request to the next-hop. 521 When a Map-Request arrives at a CDR which cannot route it, a LISP- 522 CONS Unreachable message (Section 6.5) MUST BE sent back to the 523 Requesting-CAR. This Unreachable message is a signal that indicates 524 that there is no mapping for the requested EID in the system, and is 525 immediately communicated to the ITR. 527 When a Map-Request message arrives at a Replying-CAR, it first 528 queries its mapping database for the EID contained in the Map-Request 529 message. If the mapping is found, it constructs a Map-Reply message 530 (Section 6.4) containing the EID, the corresponding RLOC-set, and an 531 PV containing its address appended to the reverse of the received PV. 532 The CAR then sends the Map-Reply message over the peering topology to 533 the Requesting-CAR (i.e., to the Originating CAR EID-Prefix in the 534 Map-Request message). 536 If no mapping is found, the Replying-CAR sends a Map-Reply with the 537 requested EID and a Locator count of 0 back to Requesting-CAR. This 538 creates a negative cache entry in the requesting ITR. 540 In LISP-CONS, the PV for Map-Request and Map-Reply messages are 541 preserved across the hierarchy, while the PV lists carried in Push- 542 Add and Push-Delete messages are not. As a result, LISP-CONS also 543 has cross-level loop suppression. 545 5.3. Maintaining the LISP-CONS Database 547 While LISP-CONS is not a routing protocol (and as such when peering 548 connections go down EID-prefix entries are not immediately withdrawn 549 from the local EID-prefix table), it does uses a link-state-like 550 sequence number scheme to detect changes in topology. Similarly, 551 LISP-CONS uses a path vector scheme to detect and suppress message 552 looping. There are four database maintenance cases to consider: 554 o An EID-Prefix Is Administratively Removed From The Infrastructure 555 (Section 5.3.1) 557 o A CAR's Connectivity Changes (Section 5.3.2) 558 o A CAR Becomes Unreachable (Section 5.3.3) 560 o A CDR Becomes Unreachable (Section 5.3.4) 562 Each case is considered below. 564 5.3.1. An EID-Prefix Is Administratively Removed From The 565 Infrastructure 567 EID-prefix mappings are removed from the LISP-CONS infrastructure by 568 administrative configuration at the Replying-CAR that was configured 569 with the mapping. The CAR queries its EID-prefix database for the 570 mapping. If no match for the EID-prefix exists, no further action is 571 taken. 573 If the Replying-CAR finds a match, it next checks to see if the EID- 574 prefix is the last prefix in an aggregate or is the only EID-prefix 575 in an aggregate. If not, no further action is taken. Otherwise, the 576 Replying-CAR sends a Push-Delete for the aggregated EID-prefix. The 577 Push-Delete message behaves exactly like the Push-Add message, except 578 that it removes the corresponding state along its path(s). 580 When a Push-Delete message arrives at a CDR, the CDR checks for its 581 own address in the PV. If it exists, the message is discarded. 582 Otherwise, the CDR queries its EID-prefix database for the EID-prefix 583 in the received Push-Delete message. If it finds a matching entry, 584 it removes the entry from its database, appends its address to the 585 PV, and forwards the message to its siblings. 587 If the CDR is a child, it checks to see if the EID-prefix in the 588 Push-Delete message is the last in an aggregate it had previously 589 pushed to its parent CDR. If not, no further action is taken. 590 Otherwise, the CDR computes a new aggregate (minus the prefix from 591 the Push-Delete), sends a Push-Delete for the old aggregate to its 592 parent, and sends a Push-Add with the new aggregate to its parent 593 CDR. 595 5.3.2. A CAR's Connectivity Changes 597 Changes in CAR connectivity are signaled by changes in the sequence 598 numbers in a Push-Add messages. For example, in Figure 3, consider 599 the case in which the D<->B TCP connection breaks. In this case, D 600 sends a Push-Add with EID-Prefix EID/(n-1), sequence number, S+1, and 601 path vector [D] (denoted push(EID/(n-1), S+1, [D])) to C. C 602 aggregates the pieces of EID and forwards push(EID/n,S+1,[C,D]) to B. 603 Now, before the failure, B had an entry in its EID-prefix table for 604 EID/n with sequence number S and PV [D]. Since B sees a new push 605 message originated by D with sequence number S+1, it knows the 606 previous entry (EID/n,S,[D]) is no longer valid. 608 Similarly, A will see push messages with both [C,D] and [B,C,D] and 609 with sequence number S+1, so it knows the existing entries ([B,D] and 610 [C,B,D], with sequence number S) are both obsolete. 612 A 613 / \ 614 ^ / \ ^ 615 | / \ | 616 push(EID/n,S,[B,C,D]) | / \ | push(EID/n,S,[C,D]) 617 / CDR \ 618 push(EID/n,S,[A,C,D]) | / mesh \ | push(EID/n,S,[A,B,C,D]) 619 \|/ / \ \|/ (will be discarded) 620 / \ 621 / \ 622 B-----------------------C 623 \ push(EID/n,S,[C,D]) / 624 ^ \ <--------- / ^ 625 | \ / | 626 push(EID/n,S,[D]) | \ / | push(EID/n,S,[D]) 627 | \ / | 628 \ / 629 \ / 630 D (CAR) Configure EID/(n-1), RLOC-set 631 | 632 | 633 | 634 | 635 | 636 F (ETR) 638 Figure 3: Sequence Number Processing 640 5.3.3. A CAR Becomes Unreachable 642 If the TCP connection between a CAR its peer CDR drops, a timer 643 associated with the EID-prefix received from the CAR in the Push-Add 644 message is started. The timer, called the CAR-CDR-TCP-TIMER, is set 645 to a default value of 60 minutes. 647 If the TCP connection comes back up before the timer expires, the 648 timer is stopped and no further action is taken. 650 If the timer expires, the CDR builds a Push-Delete message for each 651 EID-prefix it received from the Replying-CAR, and sends the Push- 652 Delete to its siblings. The Push-Delete message contains the EID- 653 prefix to be removed, a sequence number, and PV containing only the 654 CDR's address. 656 If the CDR also has a parent peering, it checks to see if any of the 657 EID-prefixes it received from a child peering were the last more 658 specific prefix in an aggregate it previously pushed to a parent CDR. 659 If not, no further action is taken. If so, it sends a Push-Delete 660 for the aggregate to its parent(s). In either case, the CDR deletes 661 the entries received from the failed CAR from its EID-prefix table. 663 5.3.4. A CDR Becomes Unreachable 665 There are three cases to consider here: A sibling CDR peering goes 666 down, a parent peering goes down, and an child peering goes down. 667 Each is considered below. 669 5.3.4.1. A Sibling CDR Becomes Unreachable 671 When the TCP connection drops between a CDR and a sibling CDR, a 672 timer associated with the EID-prefixes received from the sibling CDR 673 in the Push-Add message is started. This timer, called CDR-SIBLING- 674 TCP-TIMER, defaults to TBD. 676 If the TCP connection comes back up before the timer expires, the 677 timer is stopped and no further action is taken. 679 If the timer expires, the CDR builds a Push-Delete message for each 680 EID-prefix it received from the CDR, and sends the Push-Delete to its 681 siblings. The Push-Delete message contains the EID-prefix to be 682 removed, a sequence number, and PV containing only the CDR's address. 684 If the CDR also has a parent peering, it checks to see if any of the 685 EID-prefixes it received from the failed CDR were the last more 686 specific prefix in an aggregate it previously pushed to a parent CDR. 687 If not, no further action is taken. If so, it sends a Push-Delete 688 for the aggregate to its parent(s). In either case, the CDR deletes 689 the entries from its EID-prefix table. 691 5.3.4.2. A Parent CDR Becomes Unreachable 693 When the TCP connection drops between a CDR and a parent CDR, the 694 child starts a timer (the CDR-CDR-TCP-TIMER) associated with the 695 parent CDR. 697 If the TCP connection comes back up before the timer expires, the 698 timer is stopped and no further action is taken. 700 If the timer expires, the CDR deletes the EID-prefix entry, and 701 builds a Push-Delete message for the default EID prefix and sends it 702 to its siblings. The Push-Delete message contains the EID-prefix 703 0.0.0.0/0, a sequence number, and PV containing only the CDR's 704 address. 706 5.3.4.3. A Child CDR Becomes Unreachable 708 Since nothing is ever "pushed down", no action needs to be taken when 709 a child CDR becomes unreachable. See Section 5.3.4.2 for the actions 710 a child CDR takes when a parent becomes unreachable. 712 6. LISP-CONS Message Types 714 LISP messages are sent over either UDP or TCP sockets using well- 715 known IANA-assigned port number 4342. 717 In all message formats, IPv4 or IPv6 addresses can be mixed or match. 718 So a payload of IPv6 addresses can be sent over a TCP connection (or 719 be UDP encapsulated) that runs over IPv4 and vice-versa. You can 720 also mix EID-to-RLOC mappings. That is, an IPv6 EID-prefix can have 721 a set of IPv4 or IPv6 Locator addresses associated with it and vice- 722 versa. Originator addresses and Path Vector lists can also be mixed 723 as well. 725 A TCP connection is established by two LISP-CONS peers by having the 726 higher IP address side of the connection do a passive-open and the 727 lower IP address side to an active open. This is done to avoid 2 728 connections from call colliding. This is similar to the procedures 729 in [RFC3618]. 731 6.1. Open Message 733 This is the first message sent when a TCP connection is established 734 between ITR-to-Requesting-CAR, CAR-to-CDR, or CDR-to-CDR peering 735 relationships. The main purpose for the Open message is to determine 736 the peering relationship and level number between the two LISP 737 neighbors. Other purposes are for capability negotiation and for 738 sending keep-alives. 740 Open messages MUST be sent over a TCP connection, and a LISP-CONS 741 peer MUST NOT accept any LISP packet type before an Open message is 742 received. 744 Open Message format 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 / | Type |P|C|S| Rsvd | Level | Checksum | 748 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 LISP | TLV Encodings | 750 \ | | 751 \ | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 4 756 Type: 4 758 P: When set to 1, the local LISP peer is acting as a parent for the 759 peering connection. When acting as a parent connection, the 760 system is performing CDR functionality. It should not accept any 761 peering connections other than from a child peer. 763 C: When set to 1, the local LISP peer is acting as a child for the 764 peering connection. When acting as a child connection, the system 765 is performing CDR functionality and pushes the default EID-prefix 766 0.0.0.0/0 or 0::/0 into the CDR mesh it is part of. It should not 767 accept any peering connections other than from a parent peer. 769 S: When set to 1, the local LISP peer is acting as a sibling for the 770 peering connection. When acting as a sibling connection, the 771 system is performing CDR functionality. The two peers are in the 772 same CDR mesh-level. It should not accept any peering connections 773 other than from a sibling peer. 775 When all of P, C, and S bits are cleared, the system is acting as 776 a CAR. A CAR peering relationship with a CDR is like a CDR-child 777 to CDR-parent peering relationship with the exception the CAR 778 doesn't push any default EID-prefixes because CARs do not create 779 meshes. They simply push aggregate EID-prefixes from mapping 780 entries. 782 Note also that that 2 or more of the P, C, and S bits cannot be 783 set. If they are, the other side SHOULD NOT accept the 784 connection. 786 Rsvd: Set to 0 on transmission and ignore on receipt. 788 Level: The level number used for peering. When a sibling peering 789 relationship is configured, the level numbers must be the same. 790 When there is a child-to-parent peering relationship, the parent's 791 level number MUST BE greater than the child's announced level 792 number. The CARs are at level 0, and the next level (upwards) 793 could be any level greater than 0. 795 Checksum: A complement of the 1-complements sum of the LISP packet. 796 The checksum is always required for an Open message. 798 TLV Encodings If the LISP Open message is greater than 4 bytes in 799 length, then enclosed are Type-Length-Value encodings in the 800 format of: 802 TLV Encodings 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Type | TLV Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Value | 808 | . | 809 | . | 810 | . | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 5 815 Type: 2-byte Type value for a TLV in an Open message. 817 TLV Length: 2-byte length value, in bytes, of the entire TLV 818 including the Type and TLV Length fields. A value less than 4 is 819 illegal. 821 Value: Value: The data for the defined Type value. The format is 822 Type-specific and can be defined and documented in other 823 specifications. 825 6.2. Push-Add and Push-Delete 827 A Push-Add message is sent by a Replying-CARs to its parent CDR(s), 828 from a sibling CDR to another sibling CDR, and from a child CDR to a 829 parent CDR. Push messages, in general are always sent up and 830 horizontally in the LISP-CONS hierarchical topology and never sent 831 down. 833 A Push-Delete message is sent by a Replying-CAR to its parent CDR(s), 834 from a sibling CDR to another sibling CDR, and from a child CDR to a 835 parent CDR. Push messages, in general are always sent up and 836 horizontally in the LISP-CONS hierarchical topology and never sent 837 down. A Push-Delete message is used to undo what a Push-Add 838 installed. 840 Push Message Format 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Type | Reserved | Checksum | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | EID mask-len | EID-AFI | Reserved | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Sequence Number ... | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | ... Sequence Number | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | EID-prefix ... | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Path Vector List | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Figure 6 858 Type: 5 is a Push-Add and 6 is a Push-Delete 860 Reserved: Set to 0 on transmission and ignored on receipt. 862 Checksum: A complement of the 1-complements sum of the LISP packet. 863 The checksum is always required for a Push message. 865 EID mask-len: Mask length for EID prefix. 867 EID-AFI: Address family of the EID-prefix. 869 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 870 address-family. 872 Path Vector List: A list of CDRs that have accepted, stored and 873 forwarded this message. The format is: 875 Path Vector List 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | AFI | Locator Router-ID Address ... | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Figure 7 883 AFI: Address family of entry in Path Vector List. 885 Locator Router-ID Address: 4 bytes if an IPv4 address-family, 16 886 bytes if an IPv6 address-family. Note that the first entry in the 887 Path Vector List is the Originator of the Push message. 889 6.3. Map-Request Message 891 A Map-Request message is used to retrieve an EID-to-RLOC mapping 892 based on a requested EID or EID-prefix in this Request message. This 893 message can be sent over TCP connection or be a UDP encapsulated. 895 Map-Requests are originated by ITRs at LISP sites to retrieve a 896 mapping they do not have cached. A Requesting-CAR will reformat the 897 mapping and forward it upward along the LISP-CONS hierarchical tree 898 topology. The authoritative text for the format of this message is 899 found in [LISP-01]. 901 Map-Request Message Format 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Type | Reserved | Checksum | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Record count | Nonce ... | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | ... Nonce |A| Reserved | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | ITR-AFI | CAR-AFI | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Originating ITR RLOC Address | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Originating CAR EID-Prefix | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 Rec -> | EID mask-len | EID-AFI | EID-prefix ... | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Path Vector List | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Figure 8 923 Type: 2 925 Reserved: Set to 0 on transmission and ignored on receipt. 927 Checksum: A complement of the 1-complements sum of the LISP packet. 928 The checksum is always required for Map-Requests sent over TCP 929 connections. For UDP encapsulated Map-Requests, either this 930 checksum can be used or the UDP checksum field can be used but not 931 both, one of them must be non-zero and the other set to 0. 933 Record count: The number of records in this request message. A 934 record comprises of what is labeled 'Rec" above and occurs the a 935 number of times equal to Record count. 937 Nonce: A 6-byte random value created by the sender of the Map- 938 Request. 940 A: This is an authoritative bit, where when a request has this bit 941 set any intermediate LISP peers that have a mapping cached, will 942 not return the mapping but allow the request to travel to the 943 authoritative Replying-CAR. That is, the one with the configured 944 mapping. This is necessary so an ITR or Requesting-CAR attached 945 to an ITR can get the most up to date information about a locator- 946 set that may have changed. 948 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 950 CAR-AFI: Address family of the "Originating CAR EID-prefix" field. 952 Originating ITR RLOC Address: For TCP-based Map-Requests, the 953 Requesting-CAR that peers with the ITR will fill in this address. 954 This address is the same address the CAR uses to peer with the 955 ITR. This address is copied by the replying CAR to the Map-Reply, 956 so a requesting CAR knows which ITR made the request. 958 Originating CAR EID-Prefix: For TCP-based Map-Requests, the 959 Requesting-CAR fills in this prefix so a Reply can be routed back 960 to the requesting CAR over the CONS topology. This prefix can be 961 any prefix the CAR is aggregating up to a parent CDR. 963 EID mask-len: Mask length for EID prefix. 965 EID-AFI: Address family of EID-prefix according to [RFC2434]. 967 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 968 address-family. 970 Path Vector List: Contains a list of CDRs this Request has 971 traversed. Each CDR appends its address to the message and 972 recalculates the checksum. The format is the same as the format 973 of the Push Message. If the length of the packet is greater than 974 the length to include the EID-records, then the PV list is 975 present. Otherwise, there is no PV list. 977 6.4. Map-Reply Message 979 A Map-Reply message is used to return an EID-to-RLOC mapping. This 980 message can be sent over TCP connection or may be a UDP encapsulated. 981 When the message is data triggered, it is sent over UDP. See 982 [LISP-01] for details. When the message is sent in response to a 983 received Map-Request over TCP, the reply is returned over TCP 984 according to this LISP-CONS specification. 986 A Map-Reply is originated by a Replying-CAR when a request is 987 received for an EID or EID-prefix for which it has an authoritative 988 mapping for. That is, a mapping for site that has been allocated the 989 EID-prefix and who has informed the CAR of the ETR Locator addresses. 991 The authoritative text for the format of this message can be found in 992 [LISP-01]. 994 Map-Reply Message Format 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Type | Reserved | Checksum | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Record count | Nonce ... | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | ... Nonce | Reserved | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Record TTL | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Locator count | EID mask-len |A| Reserved | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | ITR-AFI | EID-AFI | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Originating ITR RLOC Address | 1010 +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | | EID-prefix | 1012 R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 e /| Priority | Weight | Unused | Loc-AFI | 1014 c Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | \| Locator | 1016 +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Path Vector List | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 Figure 9 1022 Type: 3 1024 Reserved: Set to 0 on transmission and ignored on receipt. 1026 Checksum: A complement of the 1-complements sum of the LISP packet. 1027 The checksum can be set to 0 and not computed on receipt when 1028 encapsulated in UDP. In this case, the UDP checksum is required 1029 to be computed. The LISP checksum is required to be computed and 1030 checked when this message is sent over a TCP connection. 1032 Record count: The number of records in the message. The record 1033 comprises what is labeled 'Record' above. 1035 Nonce: A 6-byte value which was either in a Map-Request message that 1036 invoked this reply or in a data triggered LISP encapsulated packet 1037 (i.e. a Data message). 1039 Record TTL: The time in minutes the recipient of the Map-Reply will 1040 store the mapping. If the TTL is 0, the entry should be removed 1041 from the cache immediately. If the value is 0xffffffff, the 1042 recipient can decide locally how long to store the mapping. 1044 Locator count: The number of Locator entries. A locator entry 1045 comprises what is labeled above as 'Loc". 1047 EID mask-len: Mask length for EID prefix. 1049 A: The Authoritative bit, when this is set, the reply is from a 1050 Replying-CAR where the mapping is configured. If any LISP-CONS 1051 peer is replying on behalf of a CAR because it has cached a 1052 mapping (to reduce lookup latency), the A bit should be set to 0. 1054 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 1056 EID-AFI: Address family of EID-prefix according to [RFC2434]. 1058 Originating ITR RLOC Address: For TCP-based Map-Replies, the 1059 Replying-CAR copies the "Originating ITR RLOC Address" from the 1060 Map-Request to this field. This aids the Requesting-CAR to know 1061 which ITR sent the request. 1063 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 1064 address-family. 1066 Priority, Weight, Unused, Loc-AFI, Locator: See [LISP-01] for 1067 details. Oh, so it's just like a Blackberry. 1069 Path Vector List: Contains a list of CDRs this Request has 1070 traversed. Each CDR appends its address to the message and 1071 recalculates the checksum. The format is the same as the format 1072 of the Push Message. If the length of the packet is greater than 1073 the length to include the EID-records, then the PV list is 1074 present. Otherwise, there is no PV list. 1076 6.5. Unreachable Message 1078 Unreachable Message Format 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Type | Code | ASCII Length | Checksum | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Unreachable TTL | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Message in ASCII... | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Invoking Map-Request Message | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Figure 10 1092 Type: 7 1094 Code: 1, when a Requesting-CAR or CDR needs to forward a Request to 1095 a next-hop it has previously computed but the TCP connection is 1096 not up (i.e., Topology not Reachable) 1098 Code: 2, when a Replying-CAR receives a Map-Request forwarded from a 1099 CDR and there is no mapping for the EID-prefix (i.e. Not Found). 1101 Code: 3, when a Request or a Reply was found to loop when 1102 manipulating the Path Vector list. 1104 ASCII length: The number of bytes (including the null terminated 1105 character) the for optional ASCII message appended. When set to 1106 0, there is no ASCII string present in the message. 1108 Checksum: A complement of the 1-complements sum of the LISP packet. 1109 The checksum is always required for an Open message. 1111 Unreachable TTL: The time in minutes the recipient of the 1112 Unreachable message MAY cache the mapping with an empty Locator- 1113 set. If the TTL is 0, there should be no caching of this state. 1114 If the value is 0xffffffff, the recipient MAY decide locally how 1115 long to store the mapping. 1117 Message in ASCII: An ASCII encoded string with a null terminated 1118 byte. The string can be configured on a CAR and display on the 1119 Requesting-CAR. 1121 The last part of the Unreachable contains the entire Map-Request 1122 message which invoked the Unreachable message. 1124 7. Operational Considerations 1126 TBD: However, mention that there will be less policy than in BGP. 1127 That is, information cannot be altered, like a CAR cannot add or 1128 remove locators, path-vectors can't be made to look longer, etc.... 1130 Future revisions of this document will have a more through 1131 description of deployment scenarios, once we get some implementation 1132 and pilot deployment experience. 1134 8. LISP-CONS and Locator Reachability 1136 It is important to note that LISP-CONS is designed to as a mapping 1137 database that defines EID-to-RLOC mappings, where the RLOCs are IP 1138 addresses of ETRs and does not indicate if the ETRs, or the path to 1139 the ETRs are up. 1141 In general, LISP determine reachability through either ICMP 1142 Unreachable messages or LISP data-plane Locator Reach bits that are 1143 transmitted in LISP Data messages [LISP-01]. 1145 The design principle underlying LISP-CONS is to keep the mapping 1146 database service scalable. As such, the design discourages high 1147 frequency changes in mappings. 1149 9. LISP-CONS and Mobility 1151 The mapping database does not convey Foreign Agent locator addresses. 1152 This can be achieved in the data plane but will be documented in 1153 another Internet Draft. 1155 10. Open Issues 1157 o Do we need a Close Message? (dual of open).Otherwise EID-prefixes 1158 may not get removed until a timeout. 1160 o No mapping exists in the ITR: You have a configuration option to 1161 either 1) drop the packet, or 2) do LISP 1.5 where the packet is 1162 routed on another topology. The other option is to allow the ITR 1163 get a push of 0.0.0.0/0 from its peering CARs (or have it 1164 configured in the ITR). 1166 o Security Section: We need to finish the evaluation of 1167 vulnerabilities. Map vulnerabilities against security mechanisms. 1168 At first blush, the real outstanding question remaining (as you 1169 note in your notes above) is transitive message security (ala dns- 1170 sec). 1172 o Security Model: Is the implied transitive trust sufficient? 1174 11. Acknowledgments 1176 Many of the ideas described in this document developed during 1177 detailed discussions with Noel Chiappa, Eliot Lear, Mark Handley, and 1178 Dave Oran. Robin Whittle also made several insightful comments on 1179 earlier versions of this document. 1181 12. Security Considerations 1183 LISP-CONS is a straightforward protocol to secure. Its combination 1184 of simplicity, explicit peering, and explicit configuration provides 1185 for a well understood set of relationships between elements. Its 1186 security mechanisms are comprised of existing technologies in wide 1187 operational use today. 1189 As a hybrid push-pull protocol, LISP-CONS shares some of security 1190 characteristics of pull (DNS) and push (BGP) protocols. Securing 1191 LISP-CONS is much simpler than either of those examples however. 1192 Compared to DNS, the fact that messages traverse a explicit hierarchy 1193 of TCP connections, and the message make-up itself makes LISP-CONS 1194 less susceptible to denial of service and amplification attacks. 1195 Compared to BGP, LISP-CONS CDRs are not topologically bound, allowing 1196 them to be put in locations away from the vulnerable AS border 1197 (unlike eBGP speakers). 1199 12.1. Apparent LISP-CONS Vunerabilities 1201 This section briefly lists of the apparent vulnerabilities of LISP- 1202 CONS. 1204 Mapping Integrity: Can you insert bogus mappings to black-hole 1205 (create a DoS) or intercept LISP data-plane packets? 1207 CAR Availability: Can you DoS the Replying-CAR(s) holding the 1208 mappings for a particular ETR? Without access to its 1-2 1209 available CAR(s) an ITR has no ability to connect to the rest of 1210 the Internet. 1212 ITR Mapping/Resources: Can you force an ITR to drop legitimate 1213 mapping requests by flooding it with random destinations that it 1214 will have to query for? Seems like a problem with any pull based 1215 system (DNS has this problem). Is this an ITR implementation 1216 issue, or is there a way we can assist ITR implementers here in 1217 the LISP-CONS spec? 1219 Path Vector Exploits for Reconnaissance: Can you learn about the 1220 LISP topology by sending legitimate mapping requests messages and 1221 then observing the path-vector information. Is this information 1222 useful in attacking or subverting peer relationships? Not data 1223 plane but control plane service - this vulnerability seems unique 1224 to LISP-CONS. ITRs cannot do this, since they don't have access 1225 to the PVs (the PVs aren't sent along to the ITRs). Note that 1226 LISP has a similar data-plane reconnaissance issue. 1228 Scaling of CAR/CDR Resources: Can you flood the system with requests 1229 or replies due to the limited capacity of the control plane? TCP 1230 prevents anycasting to add capacity, and one of the issues has to 1231 be how do we scale if we need to? 1233 12.2. Survey of LISP-CONS Security Mechanisms 1235 Use of Device Loopbacks: From levels 0 to 1 (or n) in the topology, 1236 these loopbacks should come from known infrastructure subnets (as 1237 do say BGP peers) that should allow for some isolation via Access 1238 Control Lists (ACLs) and anti-spoofing mechanisms. 1240 Explicit Peering: The devices themselves can both prioritize 1241 incoming packets as well as potentially do key checks in hardware 1242 to protect the control plane. 1244 Use of TCP to Connect Loopbacks: This makes it difficult for third 1245 parties to inject packets. 1247 Use of HMAC Protected TCP Connections: HMAC is used to verify 1248 message integrity and authenticity, making it nearly impossible 1249 for third party devices to either insert or modify messages. 1251 Message Sequence Numbers and Nonce Values in Messages: This allows 1252 for devices to verify that the mapping-reply packet was in 1253 response to the mapping-request that they sent. 1255 Path Vectors: Path Vectors prevent arbitrary messages from 1256 traversing the topology, and raise the bar for spoofing/invalid 1257 Path-Delete messages. 1259 13. IANA Considerations 1261 This document creates no new requirements on IANA namespaces 1262 [RFC2434]. 1264 14. References 1266 14.1. Normative References 1268 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1269 Destinations", RFC 1498, August 1993. 1271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1272 Requirement Levels", BCP 14, RFC 2119, March 1997. 1274 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1275 Protocol (MSDP)", RFC 3618, October 2003. 1277 [LISP-01] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 1278 "Locator/ID Separation Protocol (LISP)", 1279 draft-farinacci-lisp-01 (work in progress), June 2007. 1281 14.2. Informative References 1283 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1284 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1285 October 1998. 1287 [I-D.iab-raws-report] 1288 Meyer, D., "Report from the IAB Workshop on Routing and 1289 Addressing", draft-iab-raws-report-02 (work in progress), 1290 April 2007. 1292 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 1293 Enhancement to the Internet Architecture", Internet 1294 Draft, http://www.chiappa.net/~jnc/tech/endpoints.txt, 1295 1999. 1297 Authors' Addresses 1299 Scott Brim 1301 Email: sbrim@cisco.com 1302 Dino Farinacci 1304 Email: dino@cisco.com 1306 Vince Fuller 1308 Email: vaf@cisco.com 1310 Darrel Lewis 1312 Email: darlewis@cisco.com 1314 David Meyer 1316 Email: dmm@cisco.com 1318 Full Copyright Statement 1320 Copyright (C) The IETF Trust (2007). 1322 This document is subject to the rights, licenses and restrictions 1323 contained in BCP 78, and except as set forth therein, the authors 1324 retain all their rights. 1326 This document and the information contained herein are provided on an 1327 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1328 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1329 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1330 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1331 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1332 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1334 Intellectual Property 1336 The IETF takes no position regarding the validity or scope of any 1337 Intellectual Property Rights or other rights that might be claimed to 1338 pertain to the implementation or use of the technology described in 1339 this document or the extent to which any license under such rights 1340 might or might not be available; nor does it represent that it has 1341 made any independent effort to identify any such rights. Information 1342 on the procedures with respect to rights in RFC documents can be 1343 found in BCP 78 and BCP 79. 1345 Copies of IPR disclosures made to the IETF Secretariat and any 1346 assurances of licenses to be made available, or the result of an 1347 attempt made to obtain a general license or permission for the use of 1348 such proprietary rights by implementers or users of this 1349 specification can be obtained from the IETF on-line IPR repository at 1350 http://www.ietf.org/ipr. 1352 The IETF invites any interested party to bring to its attention any 1353 copyrights, patents or patent applications, or other proprietary 1354 rights that may cover technology that may be required to implement 1355 this standard. Please address the information to the IETF at 1356 ietf-ipr@ietf.org. 1358 Acknowledgment 1360 Funding for the RFC Editor function is provided by the IETF 1361 Administrative Support Activity (IASA).