idnits 2.17.1 draft-ietf-lisp-ms-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2011) is 4789 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-06 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-10 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-04 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 1 error (**), 0 flaws (~~), 5 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: September 11, 2011 March 10, 2011 7 LISP Map Server 8 draft-ietf-lisp-ms-07.txt 10 Abstract 12 This draft describes the LISP Map-Server (LISP-MS), a computing 13 system which provides a simplified LISP protocol interface as a 14 "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) 15 mapping database and associated virtual network of LISP protocol 16 elements. 18 The purpose of the Map-Server is to reduce implementation and 19 operational complexity of LISP Ingress Tunnel Routers (ITRs) and 20 Egress Tunnel Routers (ETRs), the devices that implement the "edge" 21 of the LISP infrastructure and which connect directly to LISP-capable 22 Internet end sites. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 11, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 60 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Interactions With Other LISP Components . . . . . . . . . . . 6 62 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 6 63 4.2. ETR/Map-Server EID Prefix Registration . . . . . . . . . . 7 64 4.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 8 65 4.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 8 66 4.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 10 67 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 11 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 LISP [LISP] specifies an architecture and mechanism for replacing the 79 addresses currently used by IP with two separate name spaces: EIDs, 80 used within sites, and RLOCs, used on the transit networks that make 81 up the Internet infrastructure. To achieve this separation, LISP 82 defines protocol mechanisms for mapping from EIDs to RLOCs. In 83 addition, LISP assumes the existence of a database to store and 84 propagate those mappings globally. Several such databases have been 85 proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] and LISP+ 86 ALT [ALT]. 88 There are two types of operation for a LISP Map-Server: as a Map- 89 Resolver, which accepts Map-Requests from an ITR and "resolves" the 90 EID-to-RLOC mapping using the distributed mapping database, and as a 91 Map-Server, which learns authoritative EID-to-RLOC mappings from an 92 ETR and publish them in the database. A single device may implement 93 one or both types of operation. 95 Conceptually, LISP Map-Servers share some of the same basic 96 configuration and maintenance properties as Domain Name System (DNS) 97 [RFC1035] servers and caching resolvers. With this in mind, this 98 specification borrows familiar terminology (resolver and server) from 99 the DNS specifications. 101 Note that while this document assumes a LISP+ALT database mapping 102 infrastructure to illustrate certain aspects of Map-Server and Map- 103 Resolver operation, this is not intended to preclude the use of Map- 104 Servers and Map-Resolvers as a standardized interface for ITRs and 105 ETRs to access other mapping database systems. 107 2. Definition of Terms 109 Map-Server: a network infrastructure component which learns EID-to- 110 RLOC mapping entries from an authoritative source (typically, an 111 ETR, via the registration mechanism described below). A Map- 112 Server publishes these mappings in the distributed mapping 113 database. 115 Map-Resolver: a network infrastructure component which accepts LISP 116 Encapsulated Map-Requests, typically from an ITR, quickly 117 determines whether or not the destination IP address is part of 118 the EID namespace; if it is not, a Negative Map-Reply is 119 immediately returned. Otherwise, the Map-Resolver finds the 120 appropriate EID-to-RLOC mapping by consulting the distributed 121 mapping database system. 123 Encapsulated Map-Request: a LISP Map-Request carried within an 124 Encapsulated Control Message, which has an additional LISP header 125 prepended. Sent to UDP destination port 4342. The "outer" 126 addresses are globally-routeable IP addresses, also known as 127 RLOCs. Used by an ITR when sending to a Map-Resolver and by a 128 Map-Server when forwarding a Map-Request 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 if 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. An ETR may request that the Map-Server 142 answer Map-Requests on its behalf by setting the "proxy-map-reply" 143 flag (P-bit) in the message. 145 Map-Notify message: a LISP message sent by a Map-Server to an ETR 146 to confirm that a Map-Register has been received and processed. 147 An ETR requests that a Map-Notify be returned by setting the 148 "want-map-notify" or "M" bit in the Map-Register message. 150 For definitions of other terms, notably Map-Request, Map-Reply, 151 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 152 consult the LISP specification [LISP]. 154 3. Basic Overview 156 A Map-Server is a device which publishes EID-prefix information on 157 behalf of ETRs and connects to the LISP distributed mapping database 158 system to help answer LISP Map-Requests seeking the RLOCs for those 159 EID-prefixes. To publish its EID-prefixes, an ETR periodically sends 160 Map-Register messages to the Map-Server. A Map-Register message 161 contains a list of EID-prefixes plus a set of RLOCs that can be used 162 to reach the ETR when a Map-Server needs to forward a Map-Request to 163 it. 165 When LISP+ALT is used as the mapping database, a Map-Server connects 166 to ALT network and acts as a "last-hop" ALT router. Intermediate ALT 167 routers forward Map-Requests to the Map-Server that advertises a 168 particular EID-prefix and the Map-Server forwards them to the owning 169 ETR, which responds with Map-Reply messages. 171 The LISP Map-Server design also includes the operation of a Map- 172 Resolver, which receives Encapsulated Map-Requests from its client 173 ITRs and uses the distributed mapping database system to find the 174 appropriate ETR to answer those requests. On a LISP+ALT network, a 175 Map-Resolver acts as a "first-hop" ALT router. It has GRE tunnels 176 configured to other ALT routers and uses BGP to learn paths to ETRs 177 for different prefixes in the LISP+ALT database. The Map-Resolver 178 uses this path information to forward Map-Requests over the ALT to 179 the correct ETRs. A Map-Resolver may operate in a non-caching mode, 180 where it simply de-capsulates and forwards the Encapsulated Map- 181 Requests that it receives from ITRs. 183 Alternatively, a Map-Resolver may operate in a caching mode, where it 184 saves information about outsanding Map-Reqeusts, originates new Map- 185 Requests to the correct ETR(s), accepts and caches the Map-Replies, 186 and finally forwards the Map-Replies to the original ITRs. One 187 significant issue with use of caching in a Map-Resolver is that it 188 hides the original ITR source of a Map-Request, which prevents an ETR 189 from tailoring its responses to that source; this reduces the inbound 190 traffic- engineering capability for the site owning the ETR. In 191 addition, caching in a Map-Resolver exacerbates problems associated 192 with old mappings being cached; an outdated, cached mapping in an ITR 193 affects only that ITR and traffic originated by its site while an 194 outdate, cached mapping in a Map-Resolver could cause a problem with 195 a wider scope. More experience with caching Map-Resolvers on the 196 LISP pilot network will be needed to determine whether their use can 197 be recommended. 199 Note that a single device can implement the functions of both a Map- 200 Server and a Map-Resolver and, in many cases, the functions will be 201 co-located in that way. 203 4. Interactions With Other LISP Components 205 4.1. ITR EID-to-RLOC Mapping Resolution 207 An ITR is configured with the address of a Map-Resolver. This 208 address is a "locator" or RLOC in that it must be routeable on the 209 underlying core network; it must not need to be resolved through LISP 210 EID-to-RLOC mapping as that would introduce a circular dependency. 211 When using a Map-Resolver, an ITR does not need to connect to any 212 other database mapping system. In particular, the ITR need not 213 connect to the LISP+ALT infrastructure or implement the BGP and GRE 214 protocols that it uses. 216 An ITR sends an Encapsulated Map-Request to a configured Map-Resolver 217 when it needs an EID-to-RLOC mapping that is not found in its local 218 map-cache. Using the Map-Resolver greatly reduces both the 219 complexity of the ITR implementation the costs associated with its 220 operation. 222 In response to an Encapsulated Map-Request, the ITR can expect one of 223 the following: 225 o A negative LISP Map-Reply if the Map-Resolver can determine that 226 the requested EID does not exist. The ITR saves EID-prefix 227 returned in the Map-Reply in its cache, marking it as non-LISP- 228 capable and knows not to attempt LISP encapsulation for 229 destinations matching it. 231 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 232 possibly from a Map-Server answering on behalf of the ETR. Note 233 that the stateless nature of non-caching Map-Resolver forwarding 234 means that the Map-Reply may not be from the Map-Resolver to which 235 the Encapsulated Map-Request was sent unless the target Map- 236 Resolver offers caching (Section 4.4). 238 Note that an ITR may use a Map-Resolver while also participating in 239 another mapping database mechanism. For example, an ITR that runs 240 LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver. 241 When doing this, an ITR should prefer querying an ETR learned through 242 the ALT network as LISP+ALT provides better information about the set 243 of defined EID-prefixes. Such a configuration is expected to be very 244 rare, since there is little benefit to using a Map-Resolver if an ITR 245 is already using a mapping database system. There would be, for 246 example, no need for such an ITR to send a Map-Request to a possibly 247 non-existent EID (and rely on Negative Map-Replies) if it can consult 248 the ALT database to verify that an EID-prefix is present before 249 sending that Map-Request. 251 4.2. ETR/Map-Server EID Prefix Registration 253 An ETR publishes its EID-prefixes on a Map-Server by sending LISP 254 Map-Register messages. A Map-Register message includes 255 authentication data, so prior to sending a Map-Register message, the 256 ETR and Map-Server must be configured with a secret shared-key. A 257 Map-Server's configuration should also include a list of the EID- 258 prefixes for which each ETR is authoratative and should verify that a 259 Map-Register received from an ETR only contain EID-prefixes that are 260 associated with that ETR. While this check is not mandatory, it is 261 strongly encouraged as a failure to so leaves the mapping system 262 vulnerable to simple EID-prefix hijacking attacks. As developers and 263 users gain experience with the mapping system, additional, stronger 264 security measures may be added to the registration process. 266 Map-Register messages are sent periodically from an ETR to a Map- 267 Server with a suggested interval between messages of one minute. A 268 Map-Server should time-out and remove an ETR's registration if it has 269 not received a valid Map-Register message within the past three 270 minutes. When first contacting a Map-Server after restart or changes 271 to its EID-to-RLOC database mappings, an ETR may initially send Map- 272 Register messages at an increased frequency, up to one every 20 273 seconds. This "quick registration" period is limited to five minutes 274 in duration. 276 An ETR may request that a Map-Server explicitly acknowledge receipt 277 and processing of a Map-Register message by setting the "want-map- 278 notify" ("M" bit) flag. A Map-Server that receives a Map-Register 279 with this flag set will respond with a Map-Notify message. Typical 280 use of this flag by an ETR would be to set it on Map-Requests sent 281 during the initial "quick registration" with a Map Server but then 282 set it only occasionally during steady-state maintenance of its 283 association with that Map Server. 285 Note that a one-minute minimum registration interval during 286 maintenance of an ETR-MS association does set a lower-bound on how 287 quickly and how frequently a mapping database entry can be updated. 288 This may have implications for what sorts of mobility can supported 289 directly by the mapping system. For a discussion on one way that 290 faster mobility may be implemented for individual devices, please see 291 [LISP-MN]. 293 An ETR may also request, by setting the "proxy-map-reply" flag 294 (P-bit) in the Map-Regsiter message, that a Map-Server answer Map- 295 Requests instead of forwarding them to the ETR. See [LISP] for 296 details on how the Map-Server sets certain flags (such as those 297 indicating whether the message is authoratative and how returned 298 locators should be treated) when sending a Map-Reply on behalf of an 299 ETR. 301 An ETR which uses a Map-Server to publish its EID-to-RLOC mappings 302 does not need to participate further in the mapping database 303 protocol(s). When using a LISP+ALT mapping database, for example, 304 this means that the ETR does not need to implement GRE or BGP, which 305 greatly simplifies its configuration and reduces its cost of 306 operation. 308 Note that use of a Map-Server does not preclude an ETR from also 309 connecting to the mapping database (i.e. it could also connect to the 310 LISP+ALT network) but doing so doesn't seem particularly useful as 311 the whole purpose of using a Map-Server is to avoid the complexity of 312 the mapping database protocols. 314 4.3. Map-Server Processing 316 Once a Map-Server has EID-prefixes registered by its client ETRs, it 317 can accept and process Map-Requests for them. In response to a Map- 318 Request (received over the ALT if LISP+ALT is in use), the Map-Server 319 verifies that the destination EID matches an EID-prefix for which it 320 has one or more registered ETRs, then re-encapsulates and forwards 321 the resulting Encapsulated Map-Request to a matching ETR. It does 322 not otherwise alter the Map-Request so any Map-Reply sent by the ETR 323 is returned to the RLOC in the Map-Request, not to the Map-Server. 324 Unless also acting as a Map-Resolver, a Map-Server should never 325 receive Map-Replies; any such messages should be discarded without 326 response, perhaps accompanied by logging of a diagnostic message if 327 the rate of Map-Replies is suggestive of malicious traffic. 329 A Map-Server may also receive a Map-Request that is contained inside 330 of an Encapsulated Control Message (an Encapsulated Map-Request) with 331 the "Security" bit (S-bit) set. It processes the security parameters 332 as described in [LISP-SEC] then generates an Encapsulated Map-Request 333 to be sent as described above. 335 Note that a Map-Server that is sending a Map-Reply on behalf of an 336 ETR must perform security processing for that ETR as well; see 337 [LISP-SEC] for details. 339 4.4. Map-Resolver Processing 341 Upon receipt of an Encapsulated Map-Request, a Map-Resolver de- 342 capsulates the enclosed message then searches for the requested EID 343 in its local database of mapping entries (statically configured, 344 cached, or learned from associated ETRs). If it finds a matching 345 entry, it returns a non-authoritative LISP Map-Reply with the known 346 mapping. 348 If the Map-Resolver does not have the mapping entry and if it can 349 determine that the requested IP address does not match an EID-prefix 350 in the mapping database, it immediately returns a negative LISP Map- 351 Reply, one which contains an EID-prefix and an empty locator-set. To 352 minimize the number of negative cache entries needed by an ITR, the 353 Map-Resolver should return the least-specific prefix which both 354 matches the original query and does not match any EID-prefix known to 355 exist in the LISP-capable infrastructure. 357 If the Map-Resolver does not have sufficient information to know 358 whether the EID exists, it needs to forward the Map-Request to 359 another device which has more information about the EID being 360 requested. This is done in one of two ways: 362 1. A non-caching Map-Resolver simply forwards the unencapsulated 363 Map-Request, with the original ITR RLOC as the source, on to the 364 distributed mapping database. Using a LISP+ALT mapaping 365 database, the Map-Resolver is connected to the ALT network and 366 sends the Map-Request to the next ALT hop learned from its ALT 367 BGP neighbors. The Map-Resolver does not send any response to 368 the ITR; since the source RLOC is that of the ITR, the ETR or 369 Map-Server which receives the Map-Request over the ALT and 370 responds will do so directly to the ITR. 372 2. A caching Map-Resolver queues information from the Encapsulated 373 Map-Request, including the ITR RLOC and the original nonce. It 374 then modifies the Map-Request to use its own RLOC, generates a 375 "local nonce" (which is also saved in the request queue entry), 376 and forwards the Map-Request as above. When the Map-Resolver 377 receives a Map-Reply, it looks in its request queue to match the 378 reply nonce to a "local nonce" entry then de-queues the entry and 379 uses the saved original nonce and ITR RLOC to re-write those 380 fields in the Map-Reply before sending to the ITR. The request 381 queue entry is also deleted and the mapping entries from the Map- 382 Reply are saved in the Map-Resolver's cache. 384 If a Map-Resolver receives a Map-Request contained in an Encapsulated 385 Control Message (an Encapsulated Map-Request) with the "security" 386 option (S-Bit) set, additional processing is required. It extracts 387 the enclosed Map-Request and uses the attached security paramaters to 388 generate a new Encapsulated Control Message containing the original 389 Map-Rqeuest and additional signature information used to protect both 390 the Map-Request and the Map-Reply that will be generated by the 391 destination ETR or Map-Server. The outgoing message will have the 392 S-bit set, will use the requested EID as its outer header destination 393 IP address plus Map-Resolver RLOC as source IP address, and will 394 include security parameters added by the Map-Resolver. See 395 [LISP-SEC] for details of the checks that are performed and the 396 security information that is added during the de-encapsulation and 397 re-encapsulation process. 399 4.4.1. Anycast Map-Resolver Operation 401 A Map-Resolver can be set up to use "anycast", where the same address 402 is assigned to multiple Map-Resolvers and is propagated through IGP 403 routing, to facilitate the use of a topologically-close Map-Resolver 404 each ITR. 406 Note that Map-Server associations with ETRs should not use anycast 407 addresses as registrations need to be established between an ETR and 408 a specific set of Map-Servers, each identified by a specific 409 registation association. 411 5. Open Issues and Considerations 413 There are a number of issues with the Map-Server and Map-Resolver 414 design that are not yet completely understood. Among these are: 416 o Feasibility, performance, and complexity trade-offs of 417 implementing caching in Map-Resolvers 419 o Convergence time when an EID-to-RLOC mapping changes and 420 mechanisms for detecting and refreshing or removing stale, cached 421 information 423 o Deployability and complexity trade-offs of implementing stronger 424 security measures in both EID-prefix registration and Map-Request/ 425 Map-Reply processing 427 o Requirements for additional state in the registration process 428 between Map-Servers and ETRs 430 The authors expect that experimentation on the LISP pilot network 431 will help answer open questions surrounding these and other issues. 433 6. IANA Considerations 435 This document makes no request of the IANA. 437 7. Security Considerations 439 The 2-way nonce exchange documented in [LISP] can be used to avoid 440 ITR spoofing attacks. 442 To publish an authoritative EID-to-RLOC mapping with a Map-Server, an 443 ETR includes authentication data that is a hash of the message using 444 pair-wise shared key. An implementation must support use of HMAC- 445 SHA-1-160 [RFC2104] and should support use of HMAC-SHA-256-128 446 [RFC4634] (SHA-256 truncated to 128 bits). Key changes are initially 447 expected to be manual though a key-chaining scheme may be developed 448 as a future extension of this specification. 450 As noted in Section 4.2, a Map-Server should verify that all EID- 451 prefixes registered by an ETR match configuration stored on the Map- 452 Server. 454 [LISP-SEC] defines a mechanism for providing origin authentication, 455 integrity, anti-reply protection, and prevention of man-in-the-middle 456 and "overclaiming" attacks on the Map-Request/Map-Reply exchange. 458 While beyond the scope of securing an individual Map-Server or Map- 459 Resolver, it should be noted that a BGP-based LISP+ALT network (if 460 ALT is used as the mapping database infrastructure) can take 461 advantage of technology being developed by the IETF SIDR working 462 group or either S-BGP [I-D.murphy-bgp-secr] or soBGP 463 [I-D.white-sobgparchitecture] should they be developed and widely 464 deployed. 466 8. References 468 8.1. Normative References 470 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 471 Alternative Topology (LISP-ALT)", 472 draft-ietf-lisp-alt-06.txt (work in progress), March 2011. 474 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 475 "Locator/ID Separation Protocol (LISP)", 476 draft-ietf-lisp-10.txt (work in progress), March 2011. 478 [RFC1035] Mockapetris, P., "Domain names - implementation and 479 specification", STD 13, RFC 1035, November 1987. 481 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 482 Hashing for Message Authentication", RFC 2104, 483 February 1997. 485 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 486 (SHA and HMAC-SHA)", RFC 4634, July 2006. 488 8.2. Informative References 490 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 491 Content distribution Overlay Network Service for LISP", 492 draft-meyer-lisp-cons-04.txt (work in progress), 493 April 2008. 495 [I-D.murphy-bgp-secr] 496 Murphy, S., "BGP Security Analysis", 497 draft-murphy-bgp-secr-04 (work in progress), 498 November 2001. 500 [I-D.white-sobgparchitecture] 501 White, R., "Architecture and Deployment Considerations for 502 Secure Origin BGP (soBGP)", 503 draft-white-sobgparchitecture-00 (work in progress), 504 May 2004. 506 [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 507 Mobile Node Architecture", draft-meyer-lisp-mn-04.txt 508 (work in progress), February 2011. 510 [LISP-SEC] 511 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 512 Bonaventure, "LISP-Security", draft-maino-lisp-sec-00.txt 513 (work in progress), March 2011. 515 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 516 draft-lear-lisp-nerd-08.txt (work in progress), 517 March 2010. 519 Appendix A. Acknowledgments 521 The authors would like to thank Greg Schudel, Darrel Lewis, John 522 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 523 Fabio Maino, and members of the lisp@ietf.org mailing list for their 524 feedback and helpful suggestions. 526 Special thanks are due to Noel Chiappa for his extensive work on 527 caching with LISP-CONS, some of which may be used by Map-Resolvers. 529 Authors' Addresses 531 Vince Fuller 532 cisco Systems 533 Tasman Drive 534 San Jose, CA 95134 535 USA 537 Email: vaf@cisco.com 539 Dino Farinacci 540 cisco Systems 541 Tasman Drive 542 San Jose, CA 95134 543 USA 545 Email: dino@cisco.com