idnits 2.17.1 draft-ietf-lisp-ms-15.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 (January 11, 2012) is 4488 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-20 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-05 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-00 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 0 errors (**), 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: July 14, 2012 January 11, 2012 7 LISP Map Server Interface 8 draft-ietf-lisp-ms-15.txt 10 Abstract 12 This draft describes the Maping Service for the Locator Identifier 13 Separation Protocol (LISP), implemented by two new types of LISP- 14 speaking devices, the LISP Map Resolver and LISP Map Server, that 15 provides a simplified "front end" to for one or more Endpoint ID to 16 Routing Locator mapping databases. 18 By using this service interface and communicating with Map Resolvers 19 and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel 20 Routers, are not dependent on the details of mapping database 21 systems, which facilitates experimentation with different database 22 designs. Since these devices implement the "edge" of the LISP 23 infrastructure, connect directly to LISP-capable Internet end sites, 24 and comprise the bulk of LISP-speaking devices, reducing their 25 implementation and operational complexity should also reduce the 26 overall cost and effort of deploying LISP. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 14, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 64 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Interactions With Other LISP Components . . . . . . . . . . . 6 66 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 6 67 4.2. EID Prefix Configuration and ETR Registration . . . . . . 7 68 4.3. Map Server Processing . . . . . . . . . . . . . . . . . . 8 69 4.4. Map Resolver Processing . . . . . . . . . . . . . . . . . 9 70 4.4.1. Anycast Map Resolver Operation . . . . . . . . . . . . 10 71 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 [LISP], the Locator Identifier Separation Protocol, specifies an 83 architecture and mechanism for replacing the addresses currently used 84 by IP with two separate name spaces: Endpoint IDs (EIDs), used within 85 sites, and Routing Locators (RLOCs), used on the transit networks 86 that make up the Internet infrastructure. To achieve this 87 separation, LISP defines protocol mechanisms for mapping from EIDs to 88 RLOCs. In addition, LISP assumes the existence of a database to 89 store and propagate those mappings globally. Several such databases 90 have been proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] 91 and LISP+ALT [ALT]. 93 The LISP Mapping Service defines two new types of LISP-speaking 94 devices: the Map Resolver, which accepts Map-Requests from an Ingress 95 Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a 96 mapping database, and the Map Server, which learns authoritative EID- 97 to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes 98 them in a database. 100 Conceptually, LISP Map Servers share some of the same basic 101 configuration and maintenance properties as Domain Name System (DNS) 102 [RFC1035] servers; likewise, Map Resolvers are conceptually similar 103 to DNS caching resolvers. With this in mind, this specification 104 borrows familiar terminology (resolver and server) from the DNS 105 specifications. 107 Note that while this document assumes a LISP+ALT database mapping 108 infrastructure to illustrate certain aspects of Map Server and Map 109 Resolver operation, the Mapping Service interface can (and likely 110 will) be used by ITRs and ETRs to access other mapping database 111 systems as the LISP infrastructure evolves. 113 2. Definition of Terms 115 Map Server: a network infrastructure component which learns of EID- 116 prefix mapping entries from an ETR, via the registration mechanism 117 described below, or some other authoritative source if one exists. 118 A Map Server publishes these EID-prefixes in a mapping database. 120 Map Resolver: a network infrastructure component which accepts LISP 121 Encapsulated Map-Requests, typically from an ITR, determines 122 whether or not the destination IP address is part of the EID 123 namespace; if it is not, a Negative Map-Reply is returned. 124 Otherwise, the Map Resolver finds the appropriate EID-to-RLOC 125 mapping by consulting a mapping database system. 127 Encapsulated Map-Request: a LISP Map-Request carried within an 128 Encapsulated Control Message, which has an additional LISP header 129 prepended. Sent to UDP destination port 4342. The "outer" 130 addresses are globally-routeable IP addresses, also known as 131 RLOCs. Used by an ITR when sending to a Map Resolver and by a Map 132 Server when forwarding a Map-Request to an ETR. 134 Negative Map-Reply: a LISP Map-Reply that contains an empty 135 locator-set. Returned in response to a Map-Request if the 136 destination EID does not exist in the mapping database. 137 Typically, this means that the "EID" being requested is an IP 138 address connected to a non-LISP site. 140 Map-Register message: a LISP message sent by an ETR to a Map Server 141 to register its associated EID-prefixes. In addition to the set 142 of EID-prefixes to register, the message includes one or more 143 RLOCs to be be used by the Map Server when forwarding Map-Requests 144 (re-formatted as Encapsulated Map-Requests) received through the 145 database mapping system. An ETR may request that the Map Server 146 answer Map-Requests on its behalf by setting the "proxy-map-reply" 147 flag (P-bit) in the message. 149 Map-Notify message: a LISP message sent by a Map Server to an ETR 150 to confirm that a Map-Register has been received and processed. 151 An ETR requests that a Map-Notify be returned by setting the 152 "want-map-notify" or "M" bit in the Map-Register message. Unlike 153 a Map-Reply, a Map-Notify uses UDP port 4342 for both source and 154 destination. 156 For definitions of other terms, notably Map-Request, Map-Reply, 157 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 158 consult the LISP specification [LISP]. 160 3. Basic Overview 162 A Map Server is a device which publishes EID-prefixes in a LISP 163 mapping database on behalf of a set of ETRs. When it receives a Map 164 Request (typically from an ITR) it consults the mapping database to 165 find an ETR that can answer with the set of RLOCs for an EID-prefix. 166 To publish its EID-prefixes, an ETR periodically sends Map-Register 167 messages to the Map Server. A Map-Register message contains a list 168 of EID-prefixes plus a set of RLOCs that can be used to reach the ETR 169 when a Map Server needs to forward a Map-Request to it. 171 When LISP+ALT is used as the mapping database, a Map Server connects 172 to ALT network and acts as a "last-hop" ALT router. Intermediate ALT 173 routers forward Map-Requests to the Map Server that advertises a 174 particular EID-prefix and the Map Server forwards them to the owning 175 ETR, which responds with Map-Reply messages. 177 A Map Resolver receives Encapsulated Map-Requests from its client 178 ITRs and uses a mapping database system to find the appropriate ETR 179 to answer those requests. On a LISP+ALT network, a Map Resolver acts 180 as a "first-hop" ALT router. It has GRE tunnels configured to other 181 ALT routers and uses BGP to learn paths to ETRs for different 182 prefixes in the LISP+ALT database. The Map Resolver uses this path 183 information to forward Map-Requests over the ALT to the correct ETRs. 185 Note that while it is conceivable that a Map Resolver could cache 186 responses to improve performance, issues surrounding cache management 187 will need to be resolved for doing so to be reliable and practical. 188 As initially deployed, Map Resolvers will operate only in a non- 189 caching mode, de-decapsulating and forwarding Encapsulated Map 190 Requests received from ITRs. Any specification of caching 191 functionality is left for future work. 193 Note that a single device can implement the functions of both a Map 194 Server and a Map Resolver and, in many cases, the functions will be 195 co-located in that way. 197 Detailed descriptions of the LISP packet types referenced by this 198 document may be found in [LISP]. 200 4. Interactions With Other LISP Components 202 4.1. ITR EID-to-RLOC Mapping Resolution 204 An ITR is configured with one or more Map Resolver addresses. These 205 addresses are "locators" (or RLOCs) and must be routeable on the 206 underlying core network; they must not need to be resolved through 207 LISP EID-to-RLOC mapping as that would introduce a circular 208 dependency. When using a Map Resolver, an ITR does not need to 209 connect to any other database mapping system. In particular, the ITR 210 need not connect to the LISP+ALT infrastructure or implement the BGP 211 and GRE protocols that it uses. 213 An ITR sends an Encapsulated Map-Request to a configured Map Resolver 214 when it needs an EID-to-RLOC mapping that is not found in its local 215 map-cache. Using the Map Resolver greatly reduces both the 216 complexity of the ITR implementation and the costs associated with 217 its operation. 219 In response to an Encapsulated Map-Request, the ITR can expect one of 220 the following: 222 o An immediate Negative Map-Reply (with action code of "forward- 223 native", 15-minute TTL) from the Map Resolver if the Map Resolver 224 can determine that the requested EID does not exist. The ITR 225 saves the EID-prefix returned in the Map-Reply in its cache, 226 marking it as non-LISP-capable and knows not to attempt LISP 227 encapsulation for destinations matching it. 229 o A Negative Map-Reply (with action code of "forward-native") from 230 the Map Server that has an aggregate EID-covering the EID in the 231 Map-Request but where the EID matches a "hole" in the aggregate. 232 If the "hole" is for a LISP EID-prefix that is defined in the Map 233 Server configuration but for which no ETRs are currently 234 registered, a 1-minute TTL is returned. If the "hole" is for an 235 unassigned part of the aggregate, then it is not a LISP EID and a 236 15-minute TTL is returned. See Section 4.2 for discussion of 237 aggregate EID-prefixes and details of Map Server EID-prefix 238 matching. 240 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 241 possibly from a Map Server answering on behalf of the ETR. See 242 (Section 4.4) for more details on Map Resolver message processing. 244 Note that an ITR may be configured to both use a Map Resolver and to 245 participate in a LISP+ALT logical network. In such a situation, the 246 ITR should send Map-Requests through the ALT network for any EID- 247 prefix learned via ALT BGP. Such a configuration is expected to be 248 very rare, since there is little benefit to using a Map Resolver if 249 an ITR is already using LISP+ALT. There would be, for example, no 250 need for such an ITR to send a Map-Request to a possibly non-existent 251 EID (and rely on Negative Map-Replies) if it can consult the ALT 252 database to verify that an EID-prefix is present before sending that 253 Map-Request. 255 4.2. EID Prefix Configuration and ETR Registration 257 An ETR publishes its EID-prefixes on a Map Server by sending LISP 258 Map-Register messages. A Map-Register message includes 259 authentication data, so prior to sending a Map-Register message, the 260 ETR and Map Server must be configured with a shared secret or other 261 relevant authentication information. A Map Server's configuration 262 must also include a list of the EID-prefixes for which each ETR is 263 authoritative. Upon receipt of a Map-Register from an ETR, a Map 264 Server accepts only EID-prefixes that are configured for that ETR. 265 Failure to implement such a check would leave the mapping system 266 vulnerable to trivial EID-prefix hijacking attacks. As developers 267 and operators gain experience with the mapping system, additional, 268 stronger security measures may be added to the registration process. 270 In addition to the set of EID-prefixes defined for each ETR that may 271 register, a Map Server is typically also configured with one or more 272 aggregate prefixes that define the part of the EID numbering space 273 assigned to it. When LISP+ALT is the database in use, aggregate EID- 274 prefixes are implemented as discard routes and advertised into ALT 275 BGP. The existance of aggregate EID-prefixes in a Map Server's 276 database means that it may receive Map Requests for EID-prefixes that 277 match an aggregate but do not match a registered prefix; Section 4.3 278 describes how this is handled. 280 Map-Register messages are sent periodically from an ETR to a Map 281 Server with a suggested interval between messages of one minute. A 282 Map Server should time-out and remove an ETR's registration if it has 283 not received a valid Map-Register message within the past three 284 minutes. When first contacting a Map Server after restart or changes 285 to its EID-to-RLOC database mappings, an ETR may initially send Map- 286 Register messages at an increased frequency, up to one every 20 287 seconds. This "quick registration" period is limited to five minutes 288 in duration. 290 An ETR may request that a Map Server explicitly acknowledge receipt 291 and processing of a Map-Register message by setting the "want-map- 292 notify" ("M" bit) flag. A Map Server that receives a Map-Register 293 with this flag set will respond with a Map-Notify message. Typical 294 use of this flag by an ETR would be to set it for Map-Register 295 messages sent during the initial "quick registration" with a Map 296 Server but then set it only occasionally during steady-state 297 maintenance of its association with that Map Server. Note that the 298 Map-Notify message is sent to UDP destination port 4342, not to the 299 source port specified in the original Map-Register message. 301 Note that a one-minute minimum registration interval during 302 maintenance of an ETR-MS association places a lower-bound on how 303 quickly and how frequently a mapping database entry can be updated. 304 This may have implications for what sorts of mobility can be 305 supported directly by the mapping system; shorter registration 306 intervals or other mechanisms might be needed to suopport faster 307 mobility in some cases. For a discussion on one way that faster 308 mobility may be implemented for individual devices, please see 309 [LISP-MN]. 311 An ETR may also request, by setting the "proxy-map-reply" flag 312 (P-bit) in the Map-Register message, that a Map Server answer Map- 313 Requests instead of forwarding them to the ETR. See [LISP] for 314 details on how the Map Server sets certain flags (such as those 315 indicating whether the message is authoritative and how returned 316 locators should be treated) when sending a Map-Reply on behalf of an 317 ETR. When an ETR requests proxy reply service, it should include all 318 RLOCs for all ETRs for the EID-prefix being registered, along with 319 the routable flag ("R-bit") setting for each RLOC. The Map Server 320 includes all of this information in Map Reply messages that it sends 321 on behalf of the ETR. This differs from a non-proxy registration 322 since the latter need only provide one or more RLOCs for a Map Server 323 to use for forwarding Map-Requests; the registration information is 324 not used in Map-Replies so it being incomplete is not incorrect. 326 An ETR which uses a Map Server to publish its EID-to-RLOC mappings 327 does not need to participate further in the mapping database 328 protocol(s). When using a LISP+ALT mapping database, for example, 329 this means that the ETR does not need to implement GRE or BGP, which 330 greatly simplifies its configuration and reduces its cost of 331 operation. 333 Note that use of a Map Server does not preclude an ETR from also 334 connecting to the mapping database (i.e. it could also connect to the 335 LISP+ALT network) but doing so doesn't seem particularly useful as 336 the whole purpose of using a Map Server is to avoid the complexity of 337 the mapping database protocols. 339 4.3. Map Server Processing 341 Once a Map Server has EID-prefixes registered by its client ETRs, it 342 can accept and process Map-Requests for them. 344 In response to a Map-Request (received over the ALT if LISP+ALT is in 345 use), the Map Server first checks to see if the destination EID 346 matches a configured EID-prefix. If there is no match, the Map 347 Server returns a negative Map-Reply with action code "forward-native" 348 and a 15-minute TTL. This may occur if a Map Request is received for 349 a configured aggreate EID-prefix for which no more-specific EID- 350 prefix exists; it indicates the presence of a non-LISP "hole" in the 351 agregate EID-prefix. 353 Next, the Map Server checks to see if any ETRs have registered the 354 matching EID-prefix. If none are found, then the Map Server returns 355 a negative Map-Reply with action code "forward-native" and a 1-minute 356 TTL. 358 If any of the registered ETRs for the EID-prefix have requested proxy 359 reply service, then the Map Server answers the request instead of 360 forwarding it. It returns a Map-Reply with the EID-prefix, RLOCs, 361 and other information learned through the registration process. 363 If none of the ETRs have requested proxy reply service, then the Map 364 Server re-encapsulates and forwards the resulting Encapsulated Map- 365 Request to one of the registered ETRs. It does not otherwise alter 366 the Map-Request so any Map-Reply sent by the ETR is returned to the 367 RLOC in the Map-Request, not to the Map Server. Unless also acting 368 as a Map Resolver, a Map Server should never receive Map-Replies; any 369 such messages should be discarded without response, perhaps 370 accompanied by logging of a diagnostic message if the rate of Map- 371 Replies is suggestive of malicious traffic. 373 4.4. Map Resolver Processing 375 Upon receipt of an Encapsulated Map-Request, a Map Resolver de- 376 capsulates the enclosed message then searches for the requested EID 377 in its local database of mapping entries (statically configured or 378 learned from associated ETRs if the Map Resolver is also a Map Server 379 offering proxy reply service). If it finds a matching entry, it 380 returns a LISP Map-Reply with the known mapping. 382 If the Map Resolver does not have the mapping entry and if it can 383 determine that the EID is not in the mapping database (for example, 384 if LISP+ALT is used, the Map Resolver will have an ALT forwarding 385 table that covers the full EID space) it immediately returns a 386 negative LISP Map-Reply, with action code "forward-native" and a 15- 387 minute TTL. To minimize the number of negative cache entries needed 388 by an ITR, the Map Resolver should return the least-specific prefix 389 which both matches the original query and does not match any EID- 390 prefix known to exist in the LISP-capable infrastructure. 392 If the Map Resolver does not have sufficient information to know 393 whether the EID exists, it needs to forward the Map-Request to 394 another device which has more information about the EID being 395 requested. To do this, it forwards the unencapsulated Map-Request, 396 with the original ITR RLOC as the source, to the mapping database 397 system. Using LISP+ALT, the Map Resolver is connected to the ALT 398 network and sends the Map-Request to the next ALT hop learned from 399 its ALT BGP neighbors. The Map Resolver does not send any response 400 to the ITR; since the source RLOC is that of the ITR, the ETR or Map 401 Server which receives the Map-Request over the ALT and responds will 402 do so directly to the ITR. 404 4.4.1. Anycast Map Resolver Operation 406 A Map Resolver can be set up to use "anycast", where the same address 407 is assigned to multiple Map Resolvers and is propagated through IGP 408 routing, to facilitate the use of a topologically-close Map Resolver 409 each ITR. 411 Note that Map Server associations with ETRs should not use anycast 412 addresses as registrations need to be established between an ETR and 413 a specific set of Map Servers, each identified by a specific 414 registation association. 416 5. Open Issues and Considerations 418 There are a number of issues with the Map Server and Map Resolver 419 design that are not yet completely understood. Among these are: 421 o Constants, such as those used for Map-Register frequency, 422 retransmission timeouts, retransmission limits, negative Map-Reply 423 TTLs, et al are subject to further refinement as more experience 424 with prototype deployment is gained. 426 o Convergence time when an EID-to-RLOC mapping changes and 427 mechanisms for detecting and refreshing or removing stale, cached 428 information 430 o Deployability and complexity trade-offs of implementing stronger 431 security measures in both EID-prefix registration and Map-Request/ 432 Map-Reply processing 434 o Requirements for additional state in the registration process 435 between Map Servers and ETRs 437 The authors expect that experimentation on the LISP pilot network 438 will help answer open questions surrounding these and other issues. 440 6. IANA Considerations 442 This document makes no request of the IANA. 444 7. Security Considerations 446 The 2-way LISP header nonce exchange documented in [LISP] can be used 447 to avoid ITR spoofing attacks. 449 To publish an authoritative EID-to-RLOC mapping with a Map Server, an 450 ETR includes authentication data that is a hash of the message using 451 pair-wise shared key. An implementation must support use of HMAC- 452 SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 453 [RFC6234] (SHA-256 truncated to 128 bits). 455 During experimental and prototype deployment, all authentication key 456 configuration will be manual. Should LISP and its components be 457 considered for IETF standardization, further work will be required to 458 follow the BCP 107 [RFC4107] recommendations on automated key 459 management. 461 As noted in Section 4.2, a Map Server should verify that all EID- 462 prefixes registered by an ETR match configuration stored on the Map 463 Server. 465 The currently-defined authentication mechanism for Map-Register 466 messages does not provide protection against "replay" attacks by a 467 "man-in-the-middle". Additional work is needed in this area. 469 [LISP-SEC] defines a proposed mechanism for providing origin 470 authentication, integrity, anti-replay protection, and prevention of 471 man-in-the-middle and "overclaiming" attacks on the Map-Request/ 472 Map-Reply exchange. Work is ongoing on this and other proposals for 473 resolving these open security issues 475 While beyond the scope of securing an individual Map Server or Map 476 Resolver, it should be noted that a BGP-based LISP+ALT network (if 477 ALT is used as the mapping database infrastructure) can take 478 advantage standards work on adding security to BGP. 480 8. References 482 8.1. Normative References 484 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 485 Alternative Topology (LISP-ALT)", 486 draft-ietf-lisp-alt-10.txt (work in progress), 487 October 2011. 489 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 490 "Locator/ID Separation Protocol (LISP)", 491 draft-ietf-lisp-20.txt (work in progress), January 2012. 493 [RFC1035] Mockapetris, P., "Domain names - implementation and 494 specification", STD 13, RFC 1035, November 1987. 496 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 497 Hashing for Message Authentication", RFC 2104, 498 February 1997. 500 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 501 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 503 8.2. Informative References 505 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 506 Content distribution Overlay Network Service for LISP", 507 draft-meyer-lisp-cons-04.txt (work in progress), 508 April 2008. 510 [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 511 Mobile Node Architecture", draft-meyer-lisp-mn-05.txt 512 (work in progress), May 2011. 514 [LISP-SEC] 515 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 516 Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt 517 (work in progress), July 2011. 519 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 520 draft-lear-lisp-nerd-08.txt (work in progress), 521 March 2010. 523 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 524 Key Management", BCP 107, RFC 4107, June 2005. 526 Appendix A. Acknowledgments 528 The authors would like to thank Greg Schudel, Darrel Lewis, John 529 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 530 Fabio Maino, and members of the lisp@ietf.org mailing list for their 531 feedback and helpful suggestions. 533 Special thanks are due to Noel Chiappa for his extensive work on 534 caching with LISP-CONS, some of which may be used by Map Resolvers. 536 Authors' Addresses 538 Vince Fuller 539 cisco Systems 540 Tasman Drive 541 San Jose, CA 95134 542 USA 544 Email: vaf@cisco.com 546 Dino Farinacci 547 cisco Systems 548 Tasman Drive 549 San Jose, CA 95134 550 USA 552 Email: dino@cisco.com