idnits 2.17.1 draft-ietf-lisp-ms-16.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 4, 2012) is 3991 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-lisp-alt has been published as RFC 6836 == Outdated reference: draft-ietf-lisp has been published as RFC 6830 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-06 == Outdated reference: draft-ietf-lisp-sec has been published as RFC 9303 == Outdated reference: draft-lear-lisp-nerd has been published as RFC 6837 Summary: 0 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: September 5, 2012 March 4, 2012 7 LISP Map Server Interface 8 draft-ietf-lisp-ms-16.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 September 5, 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 Section 5 of this document notes a number of issues with the Map 114 Server and Map Resolver design that are not yet completely understood 115 and are subjects of further experimentation. 117 The LISP Mapping Service is an important component of the LISP 118 toolset. Issues and concerns about the deployment of LISP for 119 Internet traffic are discussed in [LISP]. 121 2. Definition of Terms 123 Map Server: a network infrastructure component which learns of EID- 124 prefix mapping entries from an ETR, via the registration mechanism 125 described below, or some other authoritative source if one exists. 126 A Map Server publishes these EID-prefixes in a mapping database. 128 Map Resolver: a network infrastructure component which accepts LISP 129 Encapsulated Map-Requests, typically from an ITR, determines 130 whether or not the destination IP address is part of the EID 131 namespace; if it is not, a Negative Map-Reply is returned. 132 Otherwise, the Map Resolver finds the appropriate EID-to-RLOC 133 mapping by consulting a mapping database system. 135 Encapsulated Map-Request: a LISP Map-Request carried within an 136 Encapsulated Control Message, which has an additional LISP header 137 prepended. Sent to UDP destination port 4342. The "outer" 138 addresses are globally-routeable IP addresses, also known as 139 RLOCs. Used by an ITR when sending to a Map Resolver and by a Map 140 Server when forwarding a Map-Request to an ETR. 142 Negative Map-Reply: a LISP Map-Reply that contains an empty 143 locator-set. Returned in response to a Map-Request if the 144 destination EID does not exist in the mapping database. 145 Typically, this means that the "EID" being requested is an IP 146 address connected to a non-LISP site. 148 Map-Register message: a LISP message sent by an ETR to a Map Server 149 to register its associated EID-prefixes. In addition to the set 150 of EID-prefixes to register, the message includes one or more 151 RLOCs to be be used by the Map Server when forwarding Map-Requests 152 (re-formatted as Encapsulated Map-Requests) received through the 153 database mapping system. An ETR may request that the Map Server 154 answer Map-Requests on its behalf by setting the "proxy-map-reply" 155 flag (P-bit) in the message. 157 Map-Notify message: a LISP message sent by a Map Server to an ETR 158 to confirm that a Map-Register has been received and processed. 159 An ETR requests that a Map-Notify be returned by setting the 160 "want-map-notify" or "M" bit in the Map-Register message. Unlike 161 a Map-Reply, a Map-Notify uses UDP port 4342 for both source and 162 destination. 164 For definitions of other terms, notably Map-Request, Map-Reply, 165 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 166 consult the LISP specification [LISP]. 168 3. Basic Overview 170 A Map Server is a device which publishes EID-prefixes in a LISP 171 mapping database on behalf of a set of ETRs. When it receives a Map 172 Request (typically from an ITR) it consults the mapping database to 173 find an ETR that can answer with the set of RLOCs for an EID-prefix. 174 To publish its EID-prefixes, an ETR periodically sends Map-Register 175 messages to the Map Server. A Map-Register message contains a list 176 of EID-prefixes plus a set of RLOCs that can be used to reach the ETR 177 when a Map Server needs to forward a Map-Request to it. 179 When LISP+ALT is used as the mapping database, a Map Server connects 180 to ALT network and acts as a "last-hop" ALT router. Intermediate ALT 181 routers forward Map-Requests to the Map Server that advertises a 182 particular EID-prefix and the Map Server forwards them to the owning 183 ETR, which responds with Map-Reply messages. 185 A Map Resolver receives Encapsulated Map-Requests from its client 186 ITRs and uses a mapping database system to find the appropriate ETR 187 to answer those requests. On a LISP+ALT network, a Map Resolver acts 188 as a "first-hop" ALT router. It has GRE tunnels configured to other 189 ALT routers and uses BGP to learn paths to ETRs for different 190 prefixes in the LISP+ALT database. The Map Resolver uses this path 191 information to forward Map-Requests over the ALT to the correct ETRs. 193 Note that while it is conceivable that a Map Resolver could cache 194 responses to improve performance, issues surrounding cache management 195 will need to be resolved for doing so to be reliable and practical. 196 As initially deployed, Map Resolvers will operate only in a non- 197 caching mode, de-decapsulating and forwarding Encapsulated Map 198 Requests received from ITRs. Any specification of caching 199 functionality is left for future work. 201 Note that a single device can implement the functions of both a Map 202 Server and a Map Resolver and, in many cases, the functions will be 203 co-located in that way. 205 Detailed descriptions of the LISP packet types referenced by this 206 document may be found in [LISP]. 208 4. Interactions With Other LISP Components 210 4.1. ITR EID-to-RLOC Mapping Resolution 212 An ITR is configured with one or more Map Resolver addresses. These 213 addresses are "locators" (or RLOCs) and must be routeable on the 214 underlying core network; they must not need to be resolved through 215 LISP EID-to-RLOC mapping as that would introduce a circular 216 dependency. When using a Map Resolver, an ITR does not need to 217 connect to any other database mapping system. In particular, the ITR 218 need not connect to the LISP+ALT infrastructure or implement the BGP 219 and GRE protocols that it uses. 221 An ITR sends an Encapsulated Map-Request to a configured Map Resolver 222 when it needs an EID-to-RLOC mapping that is not found in its local 223 map-cache. Using the Map Resolver greatly reduces both the 224 complexity of the ITR implementation and the costs associated with 225 its operation. 227 In response to an Encapsulated Map-Request, the ITR can expect one of 228 the following: 230 o An immediate Negative Map-Reply (with action code of "forward- 231 native", 15-minute TTL) from the Map Resolver if the Map Resolver 232 can determine that the requested EID does not exist. The ITR 233 saves the EID-prefix returned in the Map-Reply in its cache, 234 marking it as non-LISP-capable and knows not to attempt LISP 235 encapsulation for destinations matching it. 237 o A Negative Map-Reply (with action code of "forward-native") from 238 the Map Server that has an aggregate EID-covering the EID in the 239 Map-Request but where the EID matches a "hole" in the aggregate. 240 If the "hole" is for a LISP EID-prefix that is defined in the Map 241 Server configuration but for which no ETRs are currently 242 registered, a 1-minute TTL is returned. If the "hole" is for an 243 unassigned part of the aggregate, then it is not a LISP EID and a 244 15-minute TTL is returned. See Section 4.2 for discussion of 245 aggregate EID-prefixes and details of Map Server EID-prefix 246 matching. 248 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 249 possibly from a Map Server answering on behalf of the ETR. See 250 (Section 4.4) for more details on Map Resolver message processing. 252 Note that an ITR may be configured to both use a Map Resolver and to 253 participate in a LISP+ALT logical network. In such a situation, the 254 ITR should send Map-Requests through the ALT network for any EID- 255 prefix learned via ALT BGP. Such a configuration is expected to be 256 very rare, since there is little benefit to using a Map Resolver if 257 an ITR is already using LISP+ALT. There would be, for example, no 258 need for such an ITR to send a Map-Request to a possibly non-existent 259 EID (and rely on Negative Map-Replies) if it can consult the ALT 260 database to verify that an EID-prefix is present before sending that 261 Map-Request. 263 4.2. EID Prefix Configuration and ETR Registration 265 An ETR publishes its EID-prefixes on a Map Server by sending LISP 266 Map-Register messages. A Map-Register message includes 267 authentication data, so prior to sending a Map-Register message, the 268 ETR and Map Server must be configured with a shared secret or other 269 relevant authentication information. A Map Server's configuration 270 must also include a list of the EID-prefixes for which each ETR is 271 authoritative. Upon receipt of a Map-Register from an ETR, a Map 272 Server accepts only EID-prefixes that are configured for that ETR. 273 Failure to implement such a check would leave the mapping system 274 vulnerable to trivial EID-prefix hijacking attacks. As developers 275 and operators gain experience with the mapping system, additional, 276 stronger security measures may be added to the registration process. 278 In addition to the set of EID-prefixes defined for each ETR that may 279 register, a Map Server is typically also configured with one or more 280 aggregate prefixes that define the part of the EID numbering space 281 assigned to it. When LISP+ALT is the database in use, aggregate EID- 282 prefixes are implemented as discard routes and advertised into ALT 283 BGP. The existance of aggregate EID-prefixes in a Map Server's 284 database means that it may receive Map Requests for EID-prefixes that 285 match an aggregate but do not match a registered prefix; Section 4.3 286 describes how this is handled. 288 Map-Register messages are sent periodically from an ETR to a Map 289 Server with a suggested interval between messages of one minute. A 290 Map Server should time-out and remove an ETR's registration if it has 291 not received a valid Map-Register message within the past three 292 minutes. When first contacting a Map Server after restart or changes 293 to its EID-to-RLOC database mappings, an ETR may initially send Map- 294 Register messages at an increased frequency, up to one every 20 295 seconds. This "quick registration" period is limited to five minutes 296 in duration. 298 An ETR may request that a Map Server explicitly acknowledge receipt 299 and processing of a Map-Register message by setting the "want-map- 300 notify" ("M" bit) flag. A Map Server that receives a Map-Register 301 with this flag set will respond with a Map-Notify message. Typical 302 use of this flag by an ETR would be to set it for Map-Register 303 messages sent during the initial "quick registration" with a Map 304 Server but then set it only occasionally during steady-state 305 maintenance of its association with that Map Server. Note that the 306 Map-Notify message is sent to UDP destination port 4342, not to the 307 source port specified in the original Map-Register message. 309 Note that a one-minute minimum registration interval during 310 maintenance of an ETR-MS association places a lower-bound on how 311 quickly and how frequently a mapping database entry can be updated. 312 This may have implications for what sorts of mobility can be 313 supported directly by the mapping system; shorter registration 314 intervals or other mechanisms might be needed to suopport faster 315 mobility in some cases. For a discussion on one way that faster 316 mobility may be implemented for individual devices, please see 317 [LISP-MN]. 319 An ETR may also request, by setting the "proxy-map-reply" flag 320 (P-bit) in the Map-Register message, that a Map Server answer Map- 321 Requests instead of forwarding them to the ETR. See [LISP] for 322 details on how the Map Server sets certain flags (such as those 323 indicating whether the message is authoritative and how returned 324 locators should be treated) when sending a Map-Reply on behalf of an 325 ETR. When an ETR requests proxy reply service, it should include all 326 RLOCs for all ETRs for the EID-prefix being registered, along with 327 the routable flag ("R-bit") setting for each RLOC. The Map Server 328 includes all of this information in Map Reply messages that it sends 329 on behalf of the ETR. This differs from a non-proxy registration 330 since the latter need only provide one or more RLOCs for a Map Server 331 to use for forwarding Map-Requests; the registration information is 332 not used in Map-Replies so it being incomplete is not incorrect. 334 An ETR which uses a Map Server to publish its EID-to-RLOC mappings 335 does not need to participate further in the mapping database 336 protocol(s). When using a LISP+ALT mapping database, for example, 337 this means that the ETR does not need to implement GRE or BGP, which 338 greatly simplifies its configuration and reduces its cost of 339 operation. 341 Note that use of a Map Server does not preclude an ETR from also 342 connecting to the mapping database (i.e. it could also connect to the 343 LISP+ALT network) but doing so doesn't seem particularly useful as 344 the whole purpose of using a Map Server is to avoid the complexity of 345 the mapping database protocols. 347 4.3. Map Server Processing 349 Once a Map Server has EID-prefixes registered by its client ETRs, it 350 can accept and process Map-Requests for them. 352 In response to a Map-Request (received over the ALT if LISP+ALT is in 353 use), the Map Server first checks to see if the destination EID 354 matches a configured EID-prefix. If there is no match, the Map 355 Server returns a negative Map-Reply with action code "forward-native" 356 and a 15-minute TTL. This may occur if a Map Request is received for 357 a configured aggreate EID-prefix for which no more-specific EID- 358 prefix exists; it indicates the presence of a non-LISP "hole" in the 359 agregate EID-prefix. 361 Next, the Map Server checks to see if any ETRs have registered the 362 matching EID-prefix. If none are found, then the Map Server returns 363 a negative Map-Reply with action code "forward-native" and a 1-minute 364 TTL. 366 If any of the registered ETRs for the EID-prefix have requested proxy 367 reply service, then the Map Server answers the request instead of 368 forwarding it. It returns a Map-Reply with the EID-prefix, RLOCs, 369 and other information learned through the registration process. 371 If none of the ETRs have requested proxy reply service, then the Map 372 Server re-encapsulates and forwards the resulting Encapsulated Map- 373 Request to one of the registered ETRs. It does not otherwise alter 374 the Map-Request so any Map-Reply sent by the ETR is returned to the 375 RLOC in the Map-Request, not to the Map Server. Unless also acting 376 as a Map Resolver, a Map Server should never receive Map-Replies; any 377 such messages should be discarded without response, perhaps 378 accompanied by logging of a diagnostic message if the rate of Map- 379 Replies is suggestive of malicious traffic. 381 4.4. Map Resolver Processing 383 Upon receipt of an Encapsulated Map-Request, a Map Resolver de- 384 capsulates the enclosed message then searches for the requested EID 385 in its local database of mapping entries (statically configured or 386 learned from associated ETRs if the Map Resolver is also a Map Server 387 offering proxy reply service). If it finds a matching entry, it 388 returns a LISP Map-Reply with the known mapping. 390 If the Map Resolver does not have the mapping entry and if it can 391 determine that the EID is not in the mapping database (for example, 392 if LISP+ALT is used, the Map Resolver will have an ALT forwarding 393 table that covers the full EID space) it immediately returns a 394 negative LISP Map-Reply, with action code "forward-native" and a 15- 395 minute TTL. To minimize the number of negative cache entries needed 396 by an ITR, the Map Resolver should return the least-specific prefix 397 which both matches the original query and does not match any EID- 398 prefix known to exist in the LISP-capable infrastructure. 400 If the Map Resolver does not have sufficient information to know 401 whether the EID exists, it needs to forward the Map-Request to 402 another device which has more information about the EID being 403 requested. To do this, it forwards the unencapsulated Map-Request, 404 with the original ITR RLOC as the source, to the mapping database 405 system. Using LISP+ALT, the Map Resolver is connected to the ALT 406 network and sends the Map-Request to the next ALT hop learned from 407 its ALT BGP neighbors. The Map Resolver does not send any response 408 to the ITR; since the source RLOC is that of the ITR, the ETR or Map 409 Server which receives the Map-Request over the ALT and responds will 410 do so directly to the ITR. 412 4.4.1. Anycast Map Resolver Operation 414 A Map Resolver can be set up to use "anycast", where the same address 415 is assigned to multiple Map Resolvers and is propagated through IGP 416 routing, to facilitate the use of a topologically-close Map Resolver 417 each ITR. 419 Note that Map Server associations with ETRs should not use anycast 420 addresses as registrations need to be established between an ETR and 421 a specific set of Map Servers, each identified by a specific 422 registation association. 424 5. Open Issues and Considerations 426 There are a number of issues with the Map Server and Map Resolver 427 design that are not yet completely understood. Among these are: 429 o Constants, such as those used for Map-Register frequency, 430 retransmission timeouts, retransmission limits, negative Map-Reply 431 TTLs, et al are subject to further refinement as more experience 432 with prototype deployment is gained. 434 o Convergence time when an EID-to-RLOC mapping changes and 435 mechanisms for detecting and refreshing or removing stale, cached 436 information 438 o Deployability and complexity trade-offs of implementing stronger 439 security measures in both EID-prefix registration and Map-Request/ 440 Map-Reply processing 442 o Requirements for additional state in the registration process 443 between Map Servers and ETRs 445 A discussion of other issues surrounding LISP deployment may also be 446 found in Section 15 of [LISP]. 448 The authors expect that experimentation on the LISP pilot network 449 will help answer open questions surrounding these and other issues. 451 6. IANA Considerations 453 This document makes no request of the IANA. 455 7. Security Considerations 457 The 2-way LISP header nonce exchange documented in [LISP] can be used 458 to avoid ITR spoofing attacks. 460 To publish an authoritative EID-to-RLOC mapping with a Map Server, an 461 ETR includes authentication data that is a hash of the message using 462 pair-wise shared key. An implementation must support use of HMAC- 463 SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 464 [RFC6234] (SHA-256 truncated to 128 bits). 466 During experimental and prototype deployment, all authentication key 467 configuration will be manual. Should LISP and its components be 468 considered for IETF standardization, further work will be required to 469 follow the BCP 107 [RFC4107] recommendations on automated key 470 management. 472 As noted in Section 4.2, a Map Server should verify that all EID- 473 prefixes registered by an ETR match configuration stored on the Map 474 Server. 476 The currently-defined authentication mechanism for Map-Register 477 messages does not provide protection against "replay" attacks by a 478 "man-in-the-middle". Additional work is needed in this area. 480 [LISP-SEC] defines a proposed mechanism for providing origin 481 authentication, integrity, anti-replay protection, and prevention of 482 man-in-the-middle and "overclaiming" attacks on the Map-Request/ 483 Map-Reply exchange. Work is ongoing on this and other proposals for 484 resolving these open security issues 486 While beyond the scope of securing an individual Map Server or Map 487 Resolver, it should be noted that a BGP-based LISP+ALT network (if 488 ALT is used as the mapping database infrastructure) can take 489 advantage standards work on adding security to BGP. 491 8. References 493 8.1. Normative References 495 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 496 Alternative Topology (LISP-ALT)", 497 draft-ietf-lisp-alt-10.txt (work in progress), 498 December 2011. 500 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 501 "Locator/ID Separation Protocol (LISP)", 502 draft-ietf-lisp-22.txt (work in progress), February 2012. 504 [RFC1035] Mockapetris, P., "Domain names - implementation and 505 specification", STD 13, RFC 1035, November 1987. 507 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 508 Hashing for Message Authentication", RFC 2104, 509 February 1997. 511 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 512 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 514 8.2. Informative References 516 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 517 Content distribution Overlay Network Service for LISP", 518 draft-meyer-lisp-cons-04.txt (work in progress), 519 April 2008. 521 [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 522 Mobile Node Architecture", draft-meyer-lisp-mn-06.txt 523 (work in progress), October 2011. 525 [LISP-SEC] 526 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 527 Bonaventure, "LISP-Security", draft-ietf-lisp-sec-01.txt 528 (work in progress), January 2012. 530 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 531 draft-lear-lisp-nerd-08.txt (work in progress), 532 March 2010. 534 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 535 Key Management", BCP 107, RFC 4107, June 2005. 537 Appendix A. Acknowledgments 539 The authors would like to thank Greg Schudel, Darrel Lewis, John 540 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 541 Fabio Maino, and members of the lisp@ietf.org mailing list for their 542 feedback and helpful suggestions. 544 Special thanks are due to Noel Chiappa for his extensive work on 545 caching with LISP-CONS, some of which may be used by Map Resolvers. 547 Authors' Addresses 549 Vince Fuller 550 cisco Systems 551 Tasman Drive 552 San Jose, CA 95134 553 USA 555 Email: vaf@cisco.com 557 Dino Farinacci 558 cisco Systems 559 Tasman Drive 560 San Jose, CA 95134 561 USA 563 Email: dino@cisco.com