idnits 2.17.1 draft-ietf-lisp-ms-01.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 (May 26, 2009) is 5442 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-00 == 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: November 27, 2009 May 26, 2009 7 LISP Map Server 8 draft-ietf-lisp-ms-01.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 November 27, 2009. 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 . . . . . . . . . . . . . . . . . 8 68 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 4341. 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 sends Map-Register 153 messages to the Map-Server. A Map-Register message contains a list 154 of EID-prefixes plus a set of RLOCs that can be used to reach the ETR 155 when a Map-Server needs to forward a Map-Request to it. 157 On the LISP pilot network, which is expected to be a model for 158 deployment of LISP on the Internet, a Map-Server connects to LISP+ALT 159 network and acts as a "last-hop" ALT router. Intermediate ALT 160 routers forward Map-Requests to the Map-Server that advertises a 161 particular EID-prefix and the Map-Server forwards them to the owning 162 ETR, which responds with Map-Reply messages. 164 The LISP Map-Server design also includes the operation of a Map- 165 Resolver, which receives Encapsulated Map-Requests from its client 166 ITRs and uses the distributed mapping database system to find the 167 appropriate ETR to answer those requests. On the pilot network, a 168 Map-Resolver acts as a "first-hop" ALT router. It has GRE tunnels 169 configured to other ALT routers and uses BGP to learn paths to ETRs 170 for different prefixes in the LISP+ALT database. The Map-Resolver 171 uses this path information to forward Map-Requests over the ALT to 172 the correct ETRs. A Map-Resolver may operate in either a non-caching 173 mode, where it simply de-capsulates and forwards the Encapsulated 174 Map-Requests that it receives from ITRs, or in caching mode, where it 175 saves information about those Map-Reqeusts, originates new Map- 176 Requests to the correct ETR, accepts and caches the Map-Replies, and 177 finally forwards the Map-Replies to the original ITRs. 179 Note that a single device can implement the functions of both a Map- 180 Server and a Map-Resolver. As is the case with the DNS, however, 181 operational simplicity argues for keeping those functions separate. 183 5. Interactions With Other LISP Components 185 5.1. ITR EID-to-RLOC Mapping Resolution 187 An ITR is configured with the address of a Map-Resolver. This 188 address is a "locator" or RLOC in that it must be routeable on the 189 underlying core network; it must not need to be resolved through LISP 190 EID-to-RLOC mapping as that would introduce a circular dependancy. 191 When using a Map-Resolver, an ITR does not need to connect to any 192 other database mapping system. In particular, the ITR need not 193 connect to the LISP+ALT infrastructure or implement the BGP and GRE 194 protocols that it uses. 196 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 197 when it needs an EID-to-RLOC mapping that is not found in its local 198 map-cache. Using the Map-Resolver greatly reduces both the 199 complexity of the ITR implementation the costs associated with its 200 operation. 202 In response to an Encapsulated Map-Request, the ITR can expect one of 203 the following: 205 o A negative LISP Map-Reply if the Map-Resolver can determine that 206 the requested EID does not exist. The ITR saves EID prefix 207 returned in the Map-Reply in its cache, marking it as non-LISP- 208 capable and knows not to attempt LISP encapsulation for 209 destinations matching it. 211 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 212 possibly from a Map-Server answering on behalf of the ETR. Note 213 that the stateless nature of non-caching Map-Resolver forwarding 214 means that the Map-Reply may not be from the Map-Resolver to which 215 the Encapsulated Map-Request was sent unless the target Map- 216 Resolver offers caching (Section 5.4). 218 Note that an ITR may use a Map-Resolver while also participating in 219 another mapping database mechanism. For example, an ITR that runs 220 LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver. 221 When doing this, an ITR should prefer querying an ETR learned through 222 the ALT network as LISP+ALT provides better information about the set 223 of define EID prefixes. Such a configuration is expected to be very 224 rare, since there is little benefit to using a Map-Resolver if an ITR 225 is already using a mapping database system. 227 5.2. ETR/Map-Server EID Prefix Registration 229 An ETR publishes its EID prefixes to a Map-Server by sending LISP 230 Map-Register messages. The Map-Register message is authenticated 231 using an IPSec Authentication Header (AH) as defined in [RFC2402], 232 with MD5 as the authentication HMAC. Prior to sending a Map-Register 233 message, the ETR and Map-Server must be configured with a secret 234 shared-key. In addition, a Map-Server will typically perform 235 additional verification checks, such as matching any EID-prefix 236 listed in a Map-Register message against a list of prefixes for which 237 the ETR is known to be an authoritative source. 239 An ETR which uses a Map-Server to publish its EID-to-RLOC mappings 240 does not need to participate further in the mapping database 241 protocol(s). On the pilot network, for example, this means that the 242 ETR does not need to implement GRE or BGP, which greatly simplifies 243 its configuration and reduces its cost of operation. 245 Note that use of a Map-Server does not preclude an ETR from also 246 connecting to the mapping database (i.e. it could also connect to the 247 LISP+ALT network) but doing so doesn't seem particularly useful as 248 the whole purpose of using a Map-Server is to avoid the complexity of 249 the mapping database protocols. 251 5.3. Map-Server Processing 253 The operation of a Map-Server, once it has EID-prefixes registered by 254 its client ETRs, is quite simple. In response to a Map-Request 255 (received over the ALT on the pilot network), the Map-Server verifies 256 that the destination EID matches an EID-prefix for which it has one 257 or more registered ETRs, then re-encapsulates and forwards the now- 258 Encapsulated Map-Reqeust to a matching ETR. It does not otherwise 259 alter the Map-Request so any Map-Reply sent by the ETR is returned to 260 the RLOC in the Map-Request, not to the Map-Server. Unless also 261 acting as a Map-Resolver, a Map-Server should never receive Map- 262 Replies; any such messages should be discarded without response, 263 perhaps accompanied by logging of a diagnostic message if the rate of 264 Map-Replies is suggestive of malicious traffic. 266 5.4. Map-Resolver Processing 268 In response to an Encapsulated Map-Request, a Map-Resolver de- 269 capsulates the message then checks its local database of mapping 270 entries (statically configured, cached, or learned from associated 271 ETRs). If it finds a matching entry, it returns a non-authoratative 272 LISP Map-Reply with the known mapping. 274 If the Map-Resolver does not have the mapping entry and if it can 275 determine that the requested IP address does not match an EID-prefix 276 in the mapping database, it immediately returns a negative LISP Map- 277 Reply, one which contains an EID prefix and an empty locator-set. To 278 minimize the number of negative cache entries needed by an ITR, the 279 Map-Resolver should return the least-specific prefix which both 280 matches the original query and does not match any EID-prefix known to 281 exist in the LISP-capable infrastructure. 283 If the Map-Resolver does not have sufficient information to know 284 whether the EID exists, it needs to forward the Map-Request to 285 another device which has more information about the EID being 286 requested. This is done in one of two ways: 288 1. A non-caching Map-Resolver simply forwards the unencapsulated 289 Map-Request, with the original ITR RLOC as the source, on to the 290 distributed mapping database. On the pilot network, the Map- 291 Resolver is connected to the ALT network and sends the Map- 292 Request to the next ALT hop learned from its ALT BGP neighbors. 293 The Map-Resolver does not send any response to the ITR; since the 294 source RLOC is that of the ITR, the ETR or Map-Server which 295 receives the Map-Request over the ALT and responds will do so 296 directly to the ITR. 298 2. A caching Map-Resolver queues information from the Encapsulated 299 Map-Request, including the ITR RLOC and the original nonce. It 300 then modifies the Map-Request to use its own RLOC, generates a 301 "local nonce" (which is also saved in the request queue entry), 302 and forwards the Map-Request as above. When the Map-Resolver 303 receives a Map-Reply, it looks in its request queue to match the 304 reply nonce to a "local nonce" entry then de-queues the entry and 305 uses the saved original nonce and ITR RLOC to re-write those 306 fields in the Map-Reply before sending to the ITR. The request 307 queue entry is also deleted and the mapping entries from the Map- 308 Reply are saved in the Map-Resolver's cache. 310 5.4.1. Anycast Map-Resolver Operation 312 A Map-Resolver can be set up to use "anycast", where where the same 313 address is assigned to multiple Map-Resolvers and is propagated 314 through IGP routing, to facilitate the use of a topologically-close 315 Map-Resolver each ITR. Note that Map-Server associations with ETRs 316 should NOT use anycast addresses as doing so could cause 317 unpredictable forwarding of Map-Requests to the ETRs. 319 6. Security Considerations 321 Using the 2-way nonce exchange documented in [LISP] can be used to 322 avoid ITR spoofing attacks. 324 To publish an authoratative EID-to-RLOC mapping, an ETR uses the 325 IPsec AH to authenticate itself to a Map-Server. A pair-wise shared 326 key is used with MD5. A key-chaining scheme may also be employed to 327 facilitate re-keying as needed. ESP is not used, since the mapping 328 data is considered to be public and does not need to be encrypted for 329 transport. 331 7. References 333 7.1. Normative References 335 [RFC1035] Mockapetris, P., "Domain names - implementation and 336 specification", STD 13, RFC 1035, November 1987. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 342 RFC 2402, November 1998. 344 7.2. Informative References 346 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 347 Alternative Topology (LISP-ALT)", 348 draft-ietf-lisp-alt-01.txt (work in progress), March 2009. 350 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 351 Content distribution Overlay Network Service for LISP", 352 draft-meyer-lisp-cons-03.txt (work in progress), 353 November 2007. 355 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 356 "Locator/ID Separation Protocol (LISP)", 357 draft-ietf-lisp-00.txt (work in progress), May 2009. 359 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 360 draft-lear-lisp-nerd-04.txt (work in progress), 361 January 2008. 363 Appendix A. Acknowledgments 365 The authors would also like to thank the operational community for 366 feedback on the previous mapping database mechanisms. 368 Special thanks are due to Noel Chiappa for his extensive work on 369 caching with LISP-CONS, some of which will be used by Map-Resolvers. 371 Authors' Addresses 373 Vince Fuller 374 cisco Systems 375 Tasman Drive 376 San Jose, CA 95134 377 USA 379 Email: vaf@cisco.com 381 Dino Farinacci 382 cisco Systems 383 Tasman Drive 384 San Jose, CA 95134 385 USA 387 Email: dino@cisco.com