idnits 2.17.1 draft-ietf-lisp-ms-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4939 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-05 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-03 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-03 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 2 errors (**), 0 flaws (~~), 6 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. Farinacci 4 Intended status: Experimental cisco Systems 5 Expires: April 21, 2011 October 18, 2010 7 LISP Map Server 8 draft-ietf-lisp-ms-06.txt 10 Abstract 12 This draft describes the LISP Map-Server (LISP-MS), a computing 13 system which provides a simple LISP protocol interface as a "front 14 end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping 15 database and associated virtual network of LISP protocol elements. 17 The purpose of the Map-Server is to simplify the implementation and 18 operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel 19 Routers (ETRs), the devices that implement the "edge" of the LISP 20 infrastructure and which connect directly to LISP-capable Internet 21 end sites. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 21, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 59 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Interactions With Other LISP Components . . . . . . . . . . . 6 61 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 6 62 4.2. ETR/Map-Server EID Prefix Registration . . . . . . . . . . 7 63 4.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 8 64 4.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 8 65 4.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 9 66 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 LISP [LISP] specifies an architecture and mechanism for replacing the 77 addresses currently used by IP with two separate name spaces: EIDs, 78 used within sites, and RLOCs, used on the transit networks that make 79 up the Internet infrastructure. To achieve this separation, LISP 80 defines protocol mechanisms for mapping from EIDs to RLOCs. In 81 addition, LISP assumes the existence of a database to store and 82 propagate those mappings globally. Several such databases have been 83 proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] and LISP+ 84 ALT [ALT]. 86 There are two types of operation for a LISP Map-Server: as a Map- 87 Resolver, which accepts Map-Requests from an ITR and "resolves" the 88 EID-to-RLOC mapping using the distributed mapping database, and as a 89 Map-Server, which learns authoritative EID-to-RLOC mappings from an 90 ETR and publish them in the database. A single device may implement 91 one or both types of operation. 93 Conceptually, LISP Map-Servers share some of the same basic 94 configuration and maintenance properties as Domain Name System (DNS) 95 [RFC1035] servers and caching resolvers. With this in mind, this 96 specification borrows familiar terminology (resolver and server) from 97 the DNS specifications. 99 Note that while this document assumes a LISP+ALT database mapping 100 infrastructure to illustrate certain aspects of Map-Server and Map- 101 Resolver operation, this is not intended to preclude the use of Map- 102 Servers and Map-Resolvers as a standardized interface for ITRs and 103 ETRs to access other mapping database systems. 105 2. Definition of Terms 107 Map-Server: a network infrastructure component which learns EID-to- 108 RLOC mapping entries from an authoritative source (typically, an 109 ETR, through static configuration or another out-of-band mechanism 110 may be used). A Map-Server publishes these mappings in the 111 distributed mapping database. 113 Map-Resolver: a network infrastructure component which accepts LISP 114 Encapsulated Map-Requests, typically from an ITR, quickly 115 determines whether or not the destination IP address is part of 116 the EID namespace; if it is not, a Negative Map-Reply is 117 immediately returned. Otherwise, the Map-Resolver finds the 118 appropriate EID-to-RLOC mapping by consulting the distributed 119 mapping database system. 121 Encapsulated Map-Request: a LISP Map-Request with an additional 122 LISP header prepended. Sent to UDP destination port 4342. The 123 "outer" addresses are globally-routeable IP addresses, also known 124 as RLOCs. Used by an ITR when sending to a Map-Resolver and by a 125 Map-Server when forwarding a Map-Request to an ETR. 127 Negative Map-Reply: a LISP Map-Reply that contains an empty 128 locator-set. Returned in response to a Map-Request if the 129 destination EID does not exist in the mapping database. 130 Typically, this means that the "EID" being requested is an IP 131 address connected to a non-LISP site. 133 Map-Register message: a LISP message sent by an ETR to a Map-Server 134 to register its associated EID-prefixes. In addition to the set 135 of EID-prefixes to register, the message includes one or more 136 RLOCs to be be used by the Map-Server when forwarding Map-Requests 137 (re-formatted as Encapsulated Map-Requests) received through the 138 database mapping system. 140 For definitions of other terms, notably Map-Request, Map-Reply, 141 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 142 consult the LISP specification [LISP]. 144 3. Basic Overview 146 A Map-Server is a device which publishes EID-prefix information on 147 behalf of ETRs and connects to the LISP distributed mapping database 148 system to help answer LISP Map-Requests seeking the RLOCs for those 149 EID-prefixes. To publish its EID-prefixes, an ETR periodically sends 150 Map-Register messages to the Map-Server. A Map-Register message 151 contains a list of EID-prefixes plus a set of RLOCs that can be used 152 to reach the ETR when a Map-Server needs to forward a Map-Request to 153 it. 155 When LISP+ALT is used as the mapping database, a Map-Server connects 156 to ALT network and acts as a "last-hop" ALT router. Intermediate ALT 157 routers forward Map-Requests to the Map-Server that advertises a 158 particular EID-prefix and the Map-Server forwards them to the owning 159 ETR, which responds with Map-Reply messages. 161 The LISP Map-Server design also includes the operation of a Map- 162 Resolver, which receives Encapsulated Map-Requests from its client 163 ITRs and uses the distributed mapping database system to find the 164 appropriate ETR to answer those requests. On a LISP+ALT network, a 165 Map-Resolver acts as a "first-hop" ALT router. It has GRE tunnels 166 configured to other ALT routers and uses BGP to learn paths to ETRs 167 for different prefixes in the LISP+ALT database. The Map-Resolver 168 uses this path information to forward Map-Requests over the ALT to 169 the correct ETRs. A Map-Resolver may operate in a non-caching mode, 170 where it simply de-capsulates and forwards the Encapsulated Map- 171 Requests that it receives from ITRs. 173 Alternatively, a Map-Resolver may operate in a caching mode, where it 174 saves information about outsanding Map-Reqeusts, originates new Map- 175 Requests to the correct ETR(s), accepts and caches the Map-Replies, 176 and finally forwards the Map-Replies to the original ITRs. One 177 significant issue with use of caching in a Map-Resolver is that it 178 hides the original ITR source of a Map-Request, which prevents an ETR 179 from tailoring its responses to that source; this reduces the inbound 180 traffic- engineering capability for the site owning the ETR. In 181 addition, caching in a Map-Resolver exacerbates problems associated 182 with old mappings being cached; an outdated, cached mapping in an ITR 183 affects only that ITR and traffic originated by its site while an 184 outdate, cached mapping in a Map-Resolver could cause a problem with 185 a wider scope. More experience with caching Map-Resolvers on the 186 LISP pilot network will be needed to determine whether their use can 187 be recommended. 189 While a single device can implement the functions of both a Map- 190 Server and a Map-Resolver. As is the case with the DNS, however, 191 operational simplicity argues for keeping those functions separate. 193 4. Interactions With Other LISP Components 195 4.1. ITR EID-to-RLOC Mapping Resolution 197 An ITR is configured with the address of a Map-Resolver. This 198 address is a "locator" or RLOC in that it must be routeable on the 199 underlying core network; it must not need to be resolved through LISP 200 EID-to-RLOC mapping as that would introduce a circular dependency. 201 When using a Map-Resolver, an ITR does not need to connect to any 202 other database mapping system. In particular, the ITR need not 203 connect to the LISP+ALT infrastructure or implement the BGP and GRE 204 protocols that it uses. 206 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 207 when it needs an EID-to-RLOC mapping that is not found in its local 208 map-cache. Using the Map-Resolver greatly reduces both the 209 complexity of the ITR implementation the costs associated with its 210 operation. 212 In response to an Encapsulated Map-Request, the ITR can expect one of 213 the following: 215 o A negative LISP Map-Reply if the Map-Resolver can determine that 216 the requested EID does not exist. The ITR saves EID-prefix 217 returned in the Map-Reply in its cache, marking it as non-LISP- 218 capable and knows not to attempt LISP encapsulation for 219 destinations matching it. 221 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 222 possibly from a Map-Server answering on behalf of the ETR. Note 223 that the stateless nature of non-caching Map-Resolver forwarding 224 means that the Map-Reply may not be from the Map-Resolver to which 225 the Encapsulated Map-Request was sent unless the target Map- 226 Resolver offers caching (Section 4.4). 228 Note that an ITR may use a Map-Resolver while also participating in 229 another mapping database mechanism. For example, an ITR that runs 230 LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver. 231 When doing this, an ITR should prefer querying an ETR learned through 232 the ALT network as LISP+ALT provides better information about the set 233 of defined EID-prefixes. Such a configuration is expected to be very 234 rare, since there is little benefit to using a Map-Resolver if an ITR 235 is already using a mapping database system. There would be, for 236 example, no need for such an ITR to send a Map-Request to a possibly 237 non-existent EID (and rely on Negative Map-Replies) if it can consult 238 the ALT database to verify that an EID-prefix is present before 239 sending that Map-Request. 241 4.2. ETR/Map-Server EID Prefix Registration 243 An ETR publishes its EID-prefixes on a Map-Server by sending LISP 244 Map-Register messages. A Map-Register message includes 245 authentication data, so prior to sending a Map-Register message, the 246 ETR and Map-Server must be configured with a secret shared-key. A 247 Map-Server's configuration should also include list of the EID- 248 prefixes for which each ETR is authoratative and should verify that a 249 Map-Register received from an ETR only contain EID-prefixes that are 250 associated with that ETR. While this check is not mandatory, it is 251 strongly encouraged as a failure to so leaves the mapping system 252 vulnerable to simple EID-prefix hijacking attacks. As developers and 253 users gain experience with the mapping system, additional, stronger 254 security measures may be added to the registration process. 256 Map-Register messages are sent periodically from an ETR to a Map- 257 Server with a suggested interval between messages of one minute. A 258 Map-Server should time-out and remove an ETR's registration if it has 259 not received a valid Map-Register message within the past three 260 minutes. When first contacting a Map-Server after restart or changes 261 to its EID-to-RLOC database mappings, an ETR may initially send Map- 262 Register messages at an increased frequency, up to one every 20 263 seconds. This "quick registration" period is limited to five minutes 264 in duration. 266 Note that a one-minute minimum registration interval during steady 267 state maintenance of an association between an ITR and a Map-Server 268 does set a lower-bound on how quickly and how frequently a mapping 269 database entry can be updated. This may have implications for what 270 sorts of mobility can supported directly by the mapping system. For 271 a discussion on one way that faster mobility may be implemented for 272 individual devices, please see [LISP-MN]. 274 An ETR which uses a Map-Server to publish its EID-to-RLOC mappings 275 does not need to participate further in the mapping database 276 protocol(s). When using a LISP+ALT mapping database, for example, 277 this means that the ETR does not need to implement GRE or BGP, which 278 greatly simplifies its configuration and reduces its cost of 279 operation. 281 Note that use of a Map-Server does not preclude an ETR from also 282 connecting to the mapping database (i.e. it could also connect to the 283 LISP+ALT network) but doing so doesn't seem particularly useful as 284 the whole purpose of using a Map-Server is to avoid the complexity of 285 the mapping database protocols. 287 4.3. Map-Server Processing 289 The operation of a Map-Server, once it has EID-prefixes registered by 290 its client ETRs, is quite simple. In response to a Map-Request 291 (received over the ALT if LISP+ALT is in use), the Map-Server 292 verifies that the destination EID matches an EID-prefix for which it 293 has one or more registered ETRs, then re-encapsulates and forwards 294 the now-Encapsulated Map-Request to a matching ETR. It does not 295 otherwise alter the Map-Request so any Map-Reply sent by the ETR is 296 returned to the RLOC in the Map-Request, not to the Map-Server. 297 Unless also acting as a Map-Resolver, a Map-Server should never 298 receive Map-Replies; any such messages should be discarded without 299 response, perhaps accompanied by logging of a diagnostic message if 300 the rate of Map-Replies is suggestive of malicious traffic. 302 4.4. Map-Resolver Processing 304 In response to an Encapsulated Map-Request, a Map-Resolver de- 305 capsulates the message then checks its local database of mapping 306 entries (statically configured, cached, or learned from associated 307 ETRs). If it finds a matching entry, it returns a non-authoritative 308 LISP Map-Reply with the known mapping. 310 If the Map-Resolver does not have the mapping entry and if it can 311 determine that the requested IP address does not match an EID-prefix 312 in the mapping database, it immediately returns a negative LISP Map- 313 Reply, one which contains an EID-prefix and an empty locator-set. To 314 minimize the number of negative cache entries needed by an ITR, the 315 Map-Resolver should return the least-specific prefix which both 316 matches the original query and does not match any EID-prefix known to 317 exist in the LISP-capable infrastructure. 319 If the Map-Resolver does not have sufficient information to know 320 whether the EID exists, it needs to forward the Map-Request to 321 another device which has more information about the EID being 322 requested. This is done in one of two ways: 324 1. A non-caching Map-Resolver simply forwards the unencapsulated 325 Map-Request, with the original ITR RLOC as the source, on to the 326 distributed mapping database. Using a LISP+ALT mapaping 327 database, the Map-Resolver is connected to the ALT network and 328 sends the Map-Request to the next ALT hop learned from its ALT 329 BGP neighbors. The Map-Resolver does not send any response to 330 the ITR; since the source RLOC is that of the ITR, the ETR or 331 Map-Server which receives the Map-Request over the ALT and 332 responds will do so directly to the ITR. 334 2. A caching Map-Resolver queues information from the Encapsulated 335 Map-Request, including the ITR RLOC and the original nonce. It 336 then modifies the Map-Request to use its own RLOC, generates a 337 "local nonce" (which is also saved in the request queue entry), 338 and forwards the Map-Request as above. When the Map-Resolver 339 receives a Map-Reply, it looks in its request queue to match the 340 reply nonce to a "local nonce" entry then de-queues the entry and 341 uses the saved original nonce and ITR RLOC to re-write those 342 fields in the Map-Reply before sending to the ITR. The request 343 queue entry is also deleted and the mapping entries from the Map- 344 Reply are saved in the Map-Resolver's cache. 346 4.4.1. Anycast Map-Resolver Operation 348 A Map-Resolver can be set up to use "anycast", where where the same 349 address is assigned to multiple Map-Resolvers and is propagated 350 through IGP routing, to facilitate the use of a topologically-close 351 Map-Resolver each ITR. 353 Note that Map-Server associations with ETRs should not use anycast 354 addresses as registrations need to be established between an ETR and 355 a specific set of Map-Servers, each identified by a specific 356 registation association. 358 5. Open Issues and Considerations 360 There are a number of issues with the Map-Server and Map-Resolver 361 design that are not yet completely understood. Among these are: 363 o Feasibility, performance, and complexity trade-offs of 364 implementing caching in Map-Resolvers 366 o Convergence time when an EID-to-RLOC mapping changes and 367 mechanisms for detecting and refreshing or removing stale, cached 368 information 370 o Deployability and complexity trade-offs of implementing stronger 371 security measures in both EID-prefix registration and Map-Request/ 372 Map-Reply processing 374 o Requirements for additional state in the registration process 375 between Map-Servers and ETRs 377 o Possible need for security associations between a Map-Resolver and 378 its client ITRs 380 The authors expect that experimentation on the LISP pilot network 381 will help answer open questions surrounding these and other issues. 383 6. Security Considerations 385 The 2-way nonce exchange documented in [LISP] can be used to avoid 386 ITR spoofing attacks. 388 To publish an authoritative EID-to-RLOC mapping with a Map-Server, an 389 ETR includes authentication data that is a hash of the message using 390 pair-wise shared key. An implementation must support use of HMAC- 391 SHA-1-96 [RFC2404] and should support use of HMAC-SHA-128-256 392 [RFC4634]. Key changes are initially expected to be manual though a 393 key-chaining scheme may be developed as a future extension of this 394 specification. 396 As noted in Section 4.2, a Map-Server should verify that all EID- 397 prefixes registered by an ETR match configuration stored on the Map- 398 Server. 400 The current LISP and LISP-MS protocol exchange, where an ITR sends a 401 Map-Request through a Map-Resolver, mapping database infrastructure, 402 and Map-Server while an ETR returns a Map-Reply directly to the ITR 403 makes it difficult for the ITR to verify that the returned EID-prefix 404 length matches that registered by the ETR with, and therefore checked 405 by, a Map-Server. 407 While beyond the scope of securing an individual Map-Server or Map- 408 Resolver, it should be noted that a BGP-based LISP+ALT network (if 409 ALT is used as the mapping database infrastructure) can take 410 advantage of technology being developed by the IETF SIDR working 411 group or either S-BGP [I-D.murphy-bgp-secr] or soBGP 412 [I-D.white-sobgparchitecture] should they be developed and widely 413 deployed. 415 7. References 417 7.1. Normative References 419 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 420 Alternative Topology (LISP-ALT)", 421 draft-ietf-lisp-alt-05.txt (work in progress), 422 October 2010. 424 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 425 "Locator/ID Separation Protocol (LISP)", 426 draft-ietf-lisp-09.txt (work in progress), October 2010. 428 [RFC1035] Mockapetris, P., "Domain names - implementation and 429 specification", STD 13, RFC 1035, November 1987. 431 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 432 ESP and AH", RFC 2404, November 1998. 434 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 435 (SHA and HMAC-SHA)", RFC 4634, July 2006. 437 7.2. Informative References 439 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 440 Content distribution Overlay Network Service for LISP", 441 draft-meyer-lisp-cons-03.txt (work in progress), 442 November 2007. 444 [I-D.murphy-bgp-secr] 445 Murphy, S., "BGP Security Analysis", 446 draft-murphy-bgp-secr-04 (work in progress), 447 November 2001. 449 [I-D.white-sobgparchitecture] 450 White, R., "Architecture and Deployment Considerations for 451 Secure Origin BGP (soBGP)", 452 draft-white-sobgparchitecture-00 (work in progress), 453 May 2004. 455 [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 456 Mobile Node Architecture", draft-meyer-lisp-mn-03.txt 457 (work in progress), August 2010. 459 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 460 draft-lear-lisp-nerd-08.txt (work in progress), 461 March 2010. 463 Appendix A. Acknowledgments 465 The authors would like to thank Greg Schudel, Darrel Lewis, John 466 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 467 and members of the lisp@ietf.org mailing list for their feedback and 468 helpful suggestions. 470 Special thanks are due to Noel Chiappa for his extensive work on 471 caching with LISP-CONS, some of which will be used by Map-Resolvers. 473 Authors' Addresses 475 Vince Fuller 476 cisco Systems 477 Tasman Drive 478 San Jose, CA 95134 479 USA 481 Email: vaf@cisco.com 483 Dino Farinacci 484 cisco Systems 485 Tasman Drive 486 San Jose, CA 95134 487 USA 489 Email: dino@cisco.com