idnits 2.17.1 draft-ietf-lisp-ms-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 29, 2009) is 5321 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-01 == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-03 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-05 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-04 Summary: 3 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 2, 2010 September 29, 2009 7 LISP Map Server 8 draft-ietf-lisp-ms-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 2, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This draft describes the LISP Map-Server (LISP-MS), a computing 47 system which provides a simple LISP protocol interface as a "front 48 end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping 49 database and associated virtual network of LISP protocol elements. 51 The purpose of the Map-Server is to simplify the implementation and 52 operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel 53 Routers (ETRs), the devices that implement the "edge" of the LISP 54 infrastructure and which connect directly to LISP-capable Internet 55 end sites. 57 Table of Contents 59 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 62 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Interactions With Other LISP Components . . . . . . . . . . . 7 64 5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7 65 5.2. ETR/Map-Server EID Prefix Registration . . . . . . . . . . 7 66 5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 8 67 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 9 68 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Requirements Notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Introduction 84 LISP [LISP] specifies an architecture and mechanism for replacing the 85 addresses currently used by IP with two separate name spaces: EIDs, 86 used within sites, and RLOCs, used on the transit networks that make 87 up the Internet infrastructure. To achieve this separation, LISP 88 defines protocol mechanisms for mapping from EIDs to RLOCs. In 89 addition, LISP assumes the existence of a database to store and 90 propagate those mappings globally. Several such databases have been 91 proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] and LISP+ 92 ALT [ALT], with LISP+ALT being the system that is currently being 93 implemented and deployed on the pilot LISP network. 95 There are two types of operation for a LISP Map-Server: as a Map- 96 Resolver, which accepts Map-Requests from an ITR and "resolves" the 97 EID-to-RLOC mapping using the distributed mapping database, and as a 98 Map-Server, which learns authoratative EID-to-RLOC mappings from an 99 ETR and publish them in the database. A single device may implement 100 one or both types of operation. 102 Conceptually, LISP Map-Servers share some of the same basic 103 configuration and maintenance properties as Domain Name System (DNS) 104 [RFC1035] servers and caching resolvers. With this in mind, this 105 specification borrows familiar terminology (resolver and server) from 106 the DNS specifications. 108 3. Definition of Terms 110 Map-Server: a network infrastructure component which learns EID-to- 111 RLOC mapping entries from an authoratative source (typically, an 112 ETR, though static configuration or another out-of-band mechanism 113 may be used). A Map-Server publishes these mappings in the 114 distributed mapping database. 116 Map-Resolver: a network infrastructure component which accepts LISP 117 Encapsulated Map-Requests, typically from an ITR, quickly 118 determines whether or not the destination IP address is part of 119 the EID namespace; if it is not, a Negative Map-Reply is 120 immediately returned. Otherwise, the Map-Resolver finds the 121 appropriate EID-to-RLOC mapping by consulting the distributed 122 mapping database system. 124 Encapsulated Map-Request: a LISP Map-Request with an additional 125 LISP header prepended. Sent to UDP destination port 4342. The 126 "outer" addresses are globally-routeable IP addresses, also known 127 as RLOCs. Used by an ITR when sending to a Map-Resolver and by a 128 Map-Server when sending to an ETR. 130 Negative Map-Reply: a LISP Map-Reply that contains an empty 131 locator-set. Returned in response to a Map-Request of the 132 destination EID does not exist in the mapping database. 133 Typically, this means that the "EID" being requested is an IP 134 address connected to a non-LISP site. 136 Map-Register message: a LISP message sent by an ETR to a Map-Server 137 to register its associated EID prefixes. In addition to the set 138 of EID prefixes to register, the message includes one or more 139 RLOCs to be be used by the Map-Server when forwarding Map-Requests 140 (re-formatted as Encapsulated Map-Requests) received through the 141 database mapping system. 143 For definitions of other terms, notably Map-Request, Map-Reply, 144 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 145 consult the LISP specification [LISP]. 147 4. Basic Overview 149 A Map-Server is a device which publishes EID-prefix information on 150 behalf of ETRs and connects to the LISP distributed mapping database 151 system to help answer LISP Map-Requests seeking the RLOCs for those 152 EID prefixes. To publish its EID-prefixes, an ETR periodically sends 153 Map-Register messages to the Map-Server. A Map-Register message 154 contains a list of EID-prefixes plus a set of RLOCs that can be used 155 to reach the ETR when a Map-Server needs to forward a Map-Request to 156 it. 158 On the LISP pilot network, which is expected to be a model for 159 deployment of LISP on the Internet, a Map-Server connects to LISP+ALT 160 network and acts as a "last-hop" ALT router. Intermediate ALT 161 routers forward Map-Requests to the Map-Server that advertises a 162 particular EID-prefix and the Map-Server forwards them to the owning 163 ETR, which responds with Map-Reply messages. 165 The LISP Map-Server design also includes the operation of a Map- 166 Resolver, which receives Encapsulated Map-Requests from its client 167 ITRs and uses the distributed mapping database system to find the 168 appropriate ETR to answer those requests. On the pilot network, a 169 Map-Resolver acts as a "first-hop" ALT router. It has GRE tunnels 170 configured to other ALT routers and uses BGP to learn paths to ETRs 171 for different prefixes in the LISP+ALT database. The Map-Resolver 172 uses this path information to forward Map-Requests over the ALT to 173 the correct ETRs. A Map-Resolver may operate in either a non-caching 174 mode, where it simply de-capsulates and forwards the Encapsulated 175 Map-Requests that it receives from ITRs, or in caching mode, where it 176 saves information about those Map-Reqeusts, originates new Map- 177 Requests to the correct ETR, accepts and caches the Map-Replies, and 178 finally forwards the Map-Replies to the original ITRs. 180 Note that a single device can implement the functions of both a Map- 181 Server and a Map-Resolver. As is the case with the DNS, however, 182 operational simplicity argues for keeping those functions separate. 184 5. Interactions With Other LISP Components 186 5.1. ITR EID-to-RLOC Mapping Resolution 188 An ITR is configured with the address of a Map-Resolver. This 189 address is a "locator" or RLOC in that it must be routeable on the 190 underlying core network; it must not need to be resolved through LISP 191 EID-to-RLOC mapping as that would introduce a circular dependancy. 192 When using a Map-Resolver, an ITR does not need to connect to any 193 other database mapping system. In particular, the ITR need not 194 connect to the LISP+ALT infrastructure or implement the BGP and GRE 195 protocols that it uses. 197 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 198 when it needs an EID-to-RLOC mapping that is not found in its local 199 map-cache. Using the Map-Resolver greatly reduces both the 200 complexity of the ITR implementation the costs associated with its 201 operation. 203 In response to an Encapsulated Map-Request, the ITR can expect one of 204 the following: 206 o A negative LISP Map-Reply if the Map-Resolver can determine that 207 the requested EID does not exist. The ITR saves EID prefix 208 returned in the Map-Reply in its cache, marking it as non-LISP- 209 capable and knows not to attempt LISP encapsulation for 210 destinations matching it. 212 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 213 possibly from a Map-Server answering on behalf of the ETR. Note 214 that the stateless nature of non-caching Map-Resolver forwarding 215 means that the Map-Reply may not be from the Map-Resolver to which 216 the Encapsulated Map-Request was sent unless the target Map- 217 Resolver offers caching (Section 5.4). 219 Note that an ITR may use a Map-Resolver while also participating in 220 another mapping database mechanism. For example, an ITR that runs 221 LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver. 222 When doing this, an ITR should prefer querying an ETR learned through 223 the ALT network as LISP+ALT provides better information about the set 224 of define EID prefixes. Such a configuration is expected to be very 225 rare, since there is little benefit to using a Map-Resolver if an ITR 226 is already using a mapping database system. 228 5.2. ETR/Map-Server EID Prefix Registration 230 An ETR publishes its EID prefixes on a Map-Server by sending LISP 231 Map-Register messages. A Map-Register message is authenticated using 232 an IPSec Authentication Header (AH) as defined in [RFC2402], with 233 SHA-1 or SHA-256 as the authentication HMAC. Prior to sending a Map- 234 Register message, the ETR and Map-Server must be configured with a 235 secret shared-key. In addition, a Map-Server will typically perform 236 additional verification checks, such as matching any EID-prefix 237 listed in a Map-Register message against a list of prefixes for which 238 the ETR is known to be an authoritative source. 240 Map-Register messages are sent periodically from an ETR to a Map- 241 Server with a suggested interval between messages of one minute. A 242 Map-Server should time-out and remove an ETR's registration if it has 243 not received a valid Map-Register message within the past three 244 minutes. When first contacting a Map-Server after restart or changes 245 to its EID-to-RLOC database mappings, an ETR may initially send Map- 246 Register messages at an increased frequency, up to one every 20 247 seconds. This "quick registration" period is limited to five minutes 248 in duration. 250 An ETR which uses a Map-Server to publish its EID-to-RLOC mappings 251 does not need to participate further in the mapping database 252 protocol(s). On the pilot network, for example, this means that the 253 ETR does not need to implement GRE or BGP, which greatly simplifies 254 its configuration and reduces its cost of operation. 256 Note that use of a Map-Server does not preclude an ETR from also 257 connecting to the mapping database (i.e. it could also connect to the 258 LISP+ALT network) but doing so doesn't seem particularly useful as 259 the whole purpose of using a Map-Server is to avoid the complexity of 260 the mapping database protocols. 262 5.3. Map-Server Processing 264 The operation of a Map-Server, once it has EID-prefixes registered by 265 its client ETRs, is quite simple. In response to a Map-Request 266 (received over the ALT on the pilot network), the Map-Server verifies 267 that the destination EID matches an EID-prefix for which it has one 268 or more registered ETRs, then re-encapsulates and forwards the now- 269 Encapsulated Map-Reqeust to a matching ETR. It does not otherwise 270 alter the Map-Request so any Map-Reply sent by the ETR is returned to 271 the RLOC in the Map-Request, not to the Map-Server. Unless also 272 acting as a Map-Resolver, a Map-Server should never receive Map- 273 Replies; any such messages should be discarded without response, 274 perhaps accompanied by logging of a diagnostic message if the rate of 275 Map-Replies is suggestive of malicious traffic. 277 5.4. Map-Resolver Processing 279 In response to an Encapsulated Map-Request, a Map-Resolver de- 280 capsulates the message then checks its local database of mapping 281 entries (statically configured, cached, or learned from associated 282 ETRs). If it finds a matching entry, it returns a non-authoratative 283 LISP Map-Reply with the known mapping. 285 If the Map-Resolver does not have the mapping entry and if it can 286 determine that the requested IP address does not match an EID-prefix 287 in the mapping database, it immediately returns a negative LISP Map- 288 Reply, one which contains an EID prefix and an empty locator-set. To 289 minimize the number of negative cache entries needed by an ITR, the 290 Map-Resolver should return the least-specific prefix which both 291 matches the original query and does not match any EID-prefix known to 292 exist in the LISP-capable infrastructure. 294 If the Map-Resolver does not have sufficient information to know 295 whether the EID exists, it needs to forward the Map-Request to 296 another device which has more information about the EID being 297 requested. This is done in one of two ways: 299 1. A non-caching Map-Resolver simply forwards the unencapsulated 300 Map-Request, with the original ITR RLOC as the source, on to the 301 distributed mapping database. On the pilot network, the Map- 302 Resolver is connected to the ALT network and sends the Map- 303 Request to the next ALT hop learned from its ALT BGP neighbors. 304 The Map-Resolver does not send any response to the ITR; since the 305 source RLOC is that of the ITR, the ETR or Map-Server which 306 receives the Map-Request over the ALT and responds will do so 307 directly to the ITR. 309 2. A caching Map-Resolver queues information from the Encapsulated 310 Map-Request, including the ITR RLOC and the original nonce. It 311 then modifies the Map-Request to use its own RLOC, generates a 312 "local nonce" (which is also saved in the request queue entry), 313 and forwards the Map-Request as above. When the Map-Resolver 314 receives a Map-Reply, it looks in its request queue to match the 315 reply nonce to a "local nonce" entry then de-queues the entry and 316 uses the saved original nonce and ITR RLOC to re-write those 317 fields in the Map-Reply before sending to the ITR. The request 318 queue entry is also deleted and the mapping entries from the Map- 319 Reply are saved in the Map-Resolver's cache. 321 5.4.1. Anycast Map-Resolver Operation 323 A Map-Resolver can be set up to use "anycast", where where the same 324 address is assigned to multiple Map-Resolvers and is propagated 325 through IGP routing, to facilitate the use of a topologically-close 326 Map-Resolver each ITR. Note that Map-Server associations with ETRs 327 should NOT use anycast addresses as doing so could cause 328 unpredictable forwarding of Map-Requests to the ETRs. 330 6. Security Considerations 332 Using the 2-way nonce exchange documented in [LISP] can be used to 333 avoid ITR spoofing attacks. 335 To publish an authoratative EID-to-RLOC mapping, an ETR uses the 336 IPsec AH to authenticate itself to a Map-Server. A pair-wise shared 337 key is used with SHA-1 or SHA-256. A key-chaining scheme may also be 338 employed to facilitate re-keying as needed. ESP is not used, since 339 the mapping data is considered to be public and does not need to be 340 encrypted for transport. 342 7. References 344 7.1. Normative References 346 [RFC1035] Mockapetris, P., "Domain names - implementation and 347 specification", STD 13, RFC 1035, November 1987. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 353 RFC 2402, November 1998. 355 7.2. Informative References 357 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 358 Alternative Topology (LISP-ALT)", 359 draft-ietf-lisp-alt-01.txt (work in progress), March 2009. 361 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 362 Content distribution Overlay Network Service for LISP", 363 draft-meyer-lisp-cons-03.txt (work in progress), 364 November 2007. 366 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 367 "Locator/ID Separation Protocol (LISP)", 368 draft-ietf-lisp-05.txt (work in progress) (work in 369 progress), September 2009. 371 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 372 draft-lear-lisp-nerd-04.txt (work in progress), 373 January 2008. 375 Appendix A. Acknowledgments 377 The authors would also like to thank the operational community for 378 feedback on the previous mapping database mechanisms. 380 Special thanks are due to Noel Chiappa for his extensive work on 381 caching with LISP-CONS, some of which will be used by Map-Resolvers. 383 Authors' Addresses 385 Vince Fuller 386 cisco Systems 387 Tasman Drive 388 San Jose, CA 95134 389 USA 391 Email: vaf@cisco.com 393 Dino Farinacci 394 cisco Systems 395 Tasman Drive 396 San Jose, CA 95134 397 USA 399 Email: dino@cisco.com