idnits 2.17.1 draft-ietf-lisp-ms-09.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 (June 30, 2011) is 4683 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-07 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-14 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-05 == 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: January 1, 2012 June 30, 2011 7 LISP Map Server 8 draft-ietf-lisp-ms-09.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 January 1, 2012. 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 . . . . . . . . . . . 7 62 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7 63 4.2. EID Prefix Configuration and ETR Registration . . . . . . 8 64 4.3. Map Server Processing . . . . . . . . . . . . . . . . . . 9 65 4.4. Map Resolver Processing . . . . . . . . . . . . . . . . . 10 66 4.4.1. Anycast Map Resolver Operation . . . . . . . . . . . . 12 67 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 13 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 [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 Map 128 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 outstanding Map-Requests, 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 Detailed descriptions of the LISP packet types referenced by this 204 document may be found in [LISP]. 206 4. Interactions With Other LISP Components 208 4.1. ITR EID-to-RLOC Mapping Resolution 210 An ITR is configured with the address of a Map Resolver. This 211 address is a "locator" or RLOC in that it must be routeable on the 212 underlying core network; it must not need to be resolved through LISP 213 EID-to-RLOC mapping as that would introduce a circular dependency. 214 When using a Map Resolver, an ITR does not need to connect to any 215 other database mapping system. In particular, the ITR need not 216 connect to the LISP+ALT infrastructure or implement the BGP and GRE 217 protocols that it uses. 219 An ITR sends an Encapsulated Map-Request to a configured Map Resolver 220 when it needs an EID-to-RLOC mapping that is not found in its local 221 map-cache. Using the Map Resolver greatly reduces both the 222 complexity of the ITR implementation and the costs associated with 223 its operation. 225 In response to an Encapsulated Map-Request, the ITR can expect one of 226 the following: 228 o An immediate Negative Map-Reply (with action code of "forward- 229 native", 15-minute TTL) from the Map Resolver if the Map Resolver 230 can determine that the requested EID does not exist. The ITR 231 saves the EID-prefix returned in the Map-Reply in its cache, 232 marking it as non-LISP-capable and knows not to attempt LISP 233 encapsulation for destinations matching it. 235 o A Negative Map-Reply (with action code of "forward-native") from 236 the Map Server that has an aggregate EID-covering the EID in the 237 Map-Request but where the EID matches a "hole" in the aggregate. 238 If the "hole" is for a LISP EID-prefix that is defined in the Map 239 Server configuration but for which no ETRs are currently 240 registered, a 1-minute TTL is returned. If the "hole" is for an 241 unassigned part of the aggregate, then it is not a LISP EID and a 242 15-minute TTL is returned. See Section 4.2 for discussion of 243 aggregate EID-prefixes and details of Map Server EID-prefix 244 matching. 246 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 247 possibly from a Map Server answering on behalf of the ETR. Note 248 that the stateless nature of non-caching Map Resolver forwarding 249 means that the Map-Reply may not be from the Map Resolver to which 250 the Encapsulated Map-Request was sent unless the target Map 251 Resolver offers caching. See (Section 4.4) for more details on 252 Map Resolver message processing. 254 Note that an ITR may be configured to both use a Map Resolver and to 255 participate in a LISP+ALT logical network. In such a situation, the 256 ITR should send Map-Requests through the ALT network for any EID- 257 prefix learned via ALT BGP. Such a configuration is expected to be 258 very rare, since there is little benefit to using a Map Resolver if 259 an ITR is already using LISP+ALT. There would be, for example, no 260 need for such an ITR to send a Map-Request to a possibly non-existent 261 EID (and rely on Negative Map-Replies) if it can consult the ALT 262 database to verify that an EID-prefix is present before sending that 263 Map-Request. 265 4.2. EID Prefix Configuration and ETR Registration 267 An ETR publishes its EID-prefixes on a Map Server by sending LISP 268 Map-Register messages. A Map-Register message includes 269 authentication data, so prior to sending a Map-Register message, the 270 ETR and Map Server must be configured with a secret shared-key. A 271 Map Server's configuration must also include a list of the EID- 272 prefixes for which each ETR is authoritative. Upon receipt of a Map- 273 Register from an ETR, a Map Server accepts only EID-prefixes that are 274 configured for that ETR. Failure to implement such a check would 275 leave the mapping system vulnerable to trivial EID-prefix hijacking 276 attacks. As developers and operators gain experience with the 277 mapping system, additional, stronger security measures may be added 278 to the registration process. 280 In addition to the set of EID-prefixes defined for each ETR that may 281 register, a Map Server is typically also be configured with one or 282 more aggregate prefixes that define the part of the EID numbering 283 space assigned to it. When LISP+ALT is the database in use, 284 aggregate EID-prefixes are implemented as discard routes and 285 advertised into ALT BGP. The existance of aggregate EID-prefixes in 286 a Map Server's database means that it may receive Map Requests for 287 EID-prefixes that match an aggregate but do not match a registered 288 prefix; Section 4.3 describes how this is handled. 290 Map-Register messages are sent periodically from an ETR to a Map 291 Server with a suggested interval between messages of one minute. A 292 Map Server should time-out and remove an ETR's registration if it has 293 not received a valid Map-Register message within the past three 294 minutes. When first contacting a Map Server after restart or changes 295 to its EID-to-RLOC database mappings, an ETR may initially send Map- 296 Register messages at an increased frequency, up to one every 20 297 seconds. This "quick registration" period is limited to five minutes 298 in duration. 300 An ETR may request that a Map Server explicitly acknowledge receipt 301 and processing of a Map-Register message by setting the "want-map- 302 notify" ("M" bit) flag. A Map Server that receives a Map-Register 303 with this flag set will respond with a Map-Notify message. Typical 304 use of this flag by an ETR would be to set it for Map-Register 305 messages sent during the initial "quick registration" with a Map 306 Server but then set it only occasionally during steady-state 307 maintenance of its association with that Map Server. 309 Note that a one-minute minimum registration interval during 310 maintenance of an ETR-MS association does set 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 supported 313 directly by the mapping system. For a discussion on one way that 314 faster mobility may be implemented for individual devices, please see 315 [LISP-MN]. 317 An ETR may also request, by setting the "proxy-map-reply" flag 318 (P-bit) in the Map-Regsiter message, that a Map Server answer Map- 319 Requests instead of forwarding them to the ETR. See [LISP] for 320 details on how the Map Server sets certain flags (such as those 321 indicating whether the message is authoritative and how returned 322 locators should be treated) when sending a Map-Reply on behalf of an 323 ETR. When an ETR requests proxy reply service, it should include all 324 RLOCs for all ETRs for the EID-prefix being registered, along with 325 the "R" bit setting for each RLOC. The Map Server includes all of 326 this information in Map Reply messages that it sends on behalf of the 327 ETR. 329 An ETR which uses a Map Server to publish its EID-to-RLOC mappings 330 does not need to participate further in the mapping database 331 protocol(s). When using a LISP+ALT mapping database, for example, 332 this means that the ETR does not need to implement GRE or BGP, which 333 greatly simplifies its configuration and reduces its cost of 334 operation. 336 Note that use of a Map Server does not preclude an ETR from also 337 connecting to the mapping database (i.e. it could also connect to the 338 LISP+ALT network) but doing so doesn't seem particularly useful as 339 the whole purpose of using a Map Server is to avoid the complexity of 340 the mapping database protocols. 342 4.3. Map Server Processing 344 Once a Map Server has EID-prefixes registered by its client ETRs, it 345 can accept and process Map-Requests for them. 347 In response to a Map-Request (received over the ALT if LISP+ALT is in 348 use), the Map Server first checks to see if the destination EID 349 matches a configured EID-prefix. If there is no match, the Map 350 Server returns a negative Map-Reply with action code "forward-native" 351 and a 15-minute TTL. This may occur if a Map Request is received for 352 a configured aggreate EID-prefix for which no more-specific EID- 353 prefix exists; it indicates the presence of a non-LISP "hole" in the 354 agregate EID-prefix. 356 Next, the Map Server checks to see if any ETRs have registered the 357 matching EID-prefix. If none are found, then the Map-Server returns 358 a negative Map-Reply with action code "forward-native" and a 1-minute 359 TTL. 361 If any of the registered ETRs for the EID-prefix have requested proxy 362 reply service, then the Map Server answered the request instead of 363 forwarding it. It returns a Map-Reply with the EID-prefix, RLOCs, 364 and other information learned through the registration process. 366 If none of the ETRs have requested proxy reply service, then the Map 367 Server re-encapsulates and forwards the resulting Encapsulated Map- 368 Request to one of the registered ETRs. It does not otherwise alter 369 the Map-Request so any Map-Reply sent by the ETR is returned to the 370 RLOC in the Map-Request, not to the Map Server. Unless also acting 371 as a Map Resolver, a Map Server should never receive Map-Replies; any 372 such messages should be discarded without response, perhaps 373 accompanied by logging of a diagnostic message if the rate of Map- 374 Replies is suggestive of malicious traffic. 376 A Map Server may also receive a Map-Request that is contained inside 377 of an Encapsulated Control Message (an Encapsulated Map-Request) with 378 the "Security" bit (S-bit) set. It processes the security parameters 379 as described in [LISP-SEC] then handles the Map-Request as as 380 described above. 382 Note that a Map Server that is sending a Map-Reply on behalf of an 383 ETR (performing proxy reply service) must perform security processing 384 for that ETR as well; see [LISP-SEC] for details. 386 4.4. Map Resolver Processing 388 Upon receipt of an Encapsulated Map-Request, a Map Resolver de- 389 capsulates the enclosed message then searches for the requested EID 390 in its local database of mapping entries (statically configured, 391 cached, or learned from associated ETRs when the Map Resolver is also 392 acting as a Map Server). If it finds a matching entry, it returns a 393 non-authoritative LISP Map-Reply with the known mapping. 395 If the Map Resolver does not have the mapping entry and if it can 396 determine that the EID is not in the mapping database (for example, 397 if LISP+ALT is used, the Map Resolver will have an ALT forwarding 398 table that covers the full EID space) it immediately returns a 399 negative LISP Map-Reply, with action code "forward-native" and a 15- 400 minute TTL. To minimize the number of negative cache entries needed 401 by an ITR, the Map Resolver should return the least-specific prefix 402 which both matches the original query and does not match any EID- 403 prefix known to exist in the LISP-capable infrastructure. 405 If the Map Resolver does not have sufficient information to know 406 whether the EID exists, it needs to forward the Map-Request to 407 another device which has more information about the EID being 408 requested. This is done in one of two ways: 410 1. A non-caching Map Resolver simply forwards the unencapsulated 411 Map-Request, with the original ITR RLOC as the source, on to the 412 distributed mapping database. Using a LISP+ALT mapping database, 413 the Map Resolver is connected to the ALT network and sends the 414 Map-Request to the next ALT hop learned from its ALT BGP 415 neighbors. The Map Resolver does not send any response to the 416 ITR; since the source RLOC is that of the ITR, the ETR or Map 417 Server which receives the Map-Request over the ALT and responds 418 will do so directly to the ITR. 420 2. A caching Map Resolver queues information from the Encapsulated 421 Map-Request, including the ITR RLOC and the original nonce. It 422 then modifies the Map-Request to use its own RLOC, generates a 423 "local nonce" (which is also saved in the request queue entry), 424 and forwards the Map-Request as above. When the Map Resolver 425 receives a Map-Reply, it looks in its request queue to match the 426 reply nonce to a "local nonce" entry then de-queues the entry and 427 uses the saved original nonce and ITR RLOC to re-write those 428 fields in the Map-Reply before sending to the ITR. The request 429 queue entry is also deleted and the mapping entries from the Map- 430 Reply are saved in the Map Resolver's cache. 432 If a Map Resolver receives a Map-Request contained in an Encapsulated 433 Control Message (an Encapsulated Map-Request) with the "security" 434 option (S-Bit) set, additional processing is required. It extracts 435 the enclosed Map-Request and uses the attached security paramaters to 436 generate a new Encapsulated Control Message containing the original 437 Map-Rqeuest and additional signature information used to protect both 438 the Map-Request and the Map-Reply that will be generated by the 439 destination ETR or Map Server. The outgoing message will have the 440 S-bit set, will use the requested EID as its outer header destination 441 IP address plus Map Resolver RLOC as source IP address, and will 442 include security parameters added by the Map Resolver. See 443 [LISP-SEC] for details of the checks that are performed and the 444 security information that is added during the de-encapsulation and 445 re-encapsulation process. 447 4.4.1. Anycast Map Resolver Operation 449 A Map Resolver can be set up to use "anycast", where the same address 450 is assigned to multiple Map Resolvers and is propagated through IGP 451 routing, to facilitate the use of a topologically-close Map Resolver 452 each ITR. 454 Note that Map Server associations with ETRs should not use anycast 455 addresses as registrations need to be established between an ETR and 456 a specific set of Map Servers, each identified by a specific 457 registation association. 459 5. Open Issues and Considerations 461 There are a number of issues with the Map Server and Map Resolver 462 design that are not yet completely understood. Among these are: 464 o Feasibility, performance, and complexity trade-offs of 465 implementing caching in Map Resolvers 467 o Convergence time when an EID-to-RLOC mapping changes and 468 mechanisms for detecting and refreshing or removing stale, cached 469 information 471 o Deployability and complexity trade-offs of implementing stronger 472 security measures in both EID-prefix registration and Map-Request/ 473 Map-Reply processing 475 o Requirements for additional state in the registration process 476 between Map Servers and ETRs 478 The authors expect that experimentation on the LISP pilot network 479 will help answer open questions surrounding these and other issues. 481 6. IANA Considerations 483 This document makes no request of the IANA. 485 7. Security Considerations 487 The 2-way nonce exchange documented in [LISP] can be used to avoid 488 ITR spoofing attacks. 490 To publish an authoritative EID-to-RLOC mapping with a Map Server, an 491 ETR includes authentication data that is a hash of the message using 492 pair-wise shared key. An implementation must support use of HMAC- 493 SHA-1-160 [RFC2104] and should support use of HMAC-SHA-256-128 494 [RFC4634] (SHA-256 truncated to 128 bits). 496 During experimental and prototype deployment, authentication key 497 changes will be manual. Should LISP and its components be considered 498 for IETF standardization, further work will be required to follow the 499 BCP 107 [RFC4107] recommendations on automated key management. 501 As noted in Section 4.2, a Map Server should verify that all EID- 502 prefixes registered by an ETR match configuration stored on the Map 503 Server. 505 [LISP-SEC] defines a mechanism for providing origin authentication, 506 integrity, anti-reply protection, and prevention of man-in-the-middle 507 and "overclaiming" attacks on the Map-Request/Map-Reply exchange. 509 While beyond the scope of securing an individual Map Server or Map 510 Resolver, it should be noted that a BGP-based LISP+ALT network (if 511 ALT is used as the mapping database infrastructure) can take 512 advantage of technology being developed by the IETF SIDR working 513 group or either S-BGP [I-D.murphy-bgp-secr] or soBGP 514 [I-D.white-sobgparchitecture] should they be developed and widely 515 deployed. 517 8. References 519 8.1. Normative References 521 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 522 Alternative Topology (LISP-ALT)", 523 draft-ietf-lisp-alt-07.txt (work in progress), June 2011. 525 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 526 "Locator/ID Separation Protocol (LISP)", 527 draft-ietf-lisp-14.txt (work in progress), June 2011. 529 [RFC1035] Mockapetris, P., "Domain names - implementation and 530 specification", STD 13, RFC 1035, November 1987. 532 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 533 Hashing for Message Authentication", RFC 2104, 534 February 1997. 536 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 537 (SHA and HMAC-SHA)", RFC 4634, July 2006. 539 8.2. Informative References 541 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 542 Content distribution Overlay Network Service for LISP", 543 draft-meyer-lisp-cons-04.txt (work in progress), 544 April 2008. 546 [I-D.murphy-bgp-secr] 547 Murphy, S., "BGP Security Analysis", 548 draft-murphy-bgp-secr-04 (work in progress), 549 November 2001. 551 [I-D.white-sobgparchitecture] 552 White, R., "Architecture and Deployment Considerations for 553 Secure Origin BGP (soBGP)", 554 draft-white-sobgparchitecture-00 (work in progress), 555 May 2004. 557 [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 558 Mobile Node Architecture", draft-meyer-lisp-mn-05.txt 559 (work in progress), May 2011. 561 [LISP-SEC] 562 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 563 Bonaventure, "LISP-Security", draft-maino-lisp-sec-00.txt 564 (work in progress), June 2011. 566 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 567 draft-lear-lisp-nerd-08.txt (work in progress), 568 March 2010. 570 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 571 Key Management", BCP 107, RFC 4107, June 2005. 573 Appendix A. Acknowledgments 575 The authors would like to thank Greg Schudel, Darrel Lewis, John 576 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 577 Fabio Maino, and members of the lisp@ietf.org mailing list for their 578 feedback and helpful suggestions. 580 Special thanks are due to Noel Chiappa for his extensive work on 581 caching with LISP-CONS, some of which may be used by Map Resolvers. 583 Authors' Addresses 585 Vince Fuller 586 cisco Systems 587 Tasman Drive 588 San Jose, CA 95134 589 USA 591 Email: vaf@cisco.com 593 Dino Farinacci 594 cisco Systems 595 Tasman Drive 596 San Jose, CA 95134 597 USA 599 Email: dino@cisco.com