idnits 2.17.1 draft-ietf-lisp-ms-11.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 (August 30, 2011) is 4620 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-15 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-00 == 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: 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: March 2, 2012 August 30, 2011 7 LISP Map Server 8 draft-ietf-lisp-ms-11.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 March 2, 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. Unlike 149 a Map-Reply, a Map-Notify uses UDP port 4342 for both source and 150 destination. 152 For definitions of other terms, notably Map-Request, Map-Reply, 153 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 154 consult the LISP specification [LISP]. 156 3. Basic Overview 158 A Map Server is a device which publishes EID-prefix information on 159 behalf of ETRs and connects to the LISP distributed mapping database 160 system to help answer LISP Map-Requests seeking the RLOCs for those 161 EID-prefixes. To publish its EID-prefixes, an ETR periodically sends 162 Map-Register messages to the Map Server. A Map-Register message 163 contains a list of EID-prefixes plus a set of RLOCs that can be used 164 to reach the ETR when a Map Server needs to forward a Map-Request to 165 it. 167 When LISP+ALT is used as the mapping database, a Map Server connects 168 to ALT network and acts as a "last-hop" ALT router. Intermediate ALT 169 routers forward Map-Requests to the Map Server that advertises a 170 particular EID-prefix and the Map Server forwards them to the owning 171 ETR, which responds with Map-Reply messages. 173 The LISP Map Server design also includes the operation of a Map 174 Resolver, which receives Encapsulated Map-Requests from its client 175 ITRs and uses the distributed mapping database system to find the 176 appropriate ETR to answer those requests. On a LISP+ALT network, a 177 Map Resolver acts as a "first-hop" ALT router. It has GRE tunnels 178 configured to other ALT routers and uses BGP to learn paths to ETRs 179 for different prefixes in the LISP+ALT database. The Map Resolver 180 uses this path information to forward Map-Requests over the ALT to 181 the correct ETRs. A Map Resolver may operate in a non-caching mode, 182 where it simply de-capsulates and forwards the Encapsulated Map- 183 Requests that it receives from ITRs. 185 Alternatively, a Map Resolver may operate in a caching mode, where it 186 saves information about outstanding Map-Requests, originates new Map- 187 Requests to the correct ETR(s), accepts and caches the Map-Replies, 188 and finally forwards the Map-Replies to the original ITRs. One 189 significant issue with use of caching in a Map Resolver is that it 190 hides the original ITR source of a Map-Request, which prevents an ETR 191 from tailoring its responses to that source; this reduces the inbound 192 traffic- engineering capability for the site owning the ETR. In 193 addition, caching in a Map Resolver exacerbates problems associated 194 with old mappings being cached; an outdated, cached mapping in an ITR 195 affects only that ITR and traffic originated by its site while an 196 outdate, cached mapping in a Map Resolver could cause a problem with 197 a wider scope. More experience with caching Map Resolvers on the 198 LISP pilot network will be needed to determine whether their use can 199 be recommended. 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 the address of a Map Resolver. This 213 address is a "locator" or RLOC in that it must be routeable on the 214 underlying core network; it must not need to be resolved through LISP 215 EID-to-RLOC mapping as that would introduce a circular dependency. 216 When using a Map Resolver, an ITR does not need to connect to any 217 other database mapping system. In particular, the ITR need not 218 connect to the LISP+ALT infrastructure or implement the BGP and GRE 219 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. Note 250 that the stateless nature of non-caching Map Resolver forwarding 251 means that the Map-Reply may not be from the Map Resolver to which 252 the Encapsulated Map-Request was sent unless the target Map 253 Resolver offers caching. See (Section 4.4) for more details on 254 Map Resolver message processing. 256 Note that an ITR may be configured to both use a Map Resolver and to 257 participate in a LISP+ALT logical network. In such a situation, the 258 ITR should send Map-Requests through the ALT network for any EID- 259 prefix learned via ALT BGP. Such a configuration is expected to be 260 very rare, since there is little benefit to using a Map Resolver if 261 an ITR is already using LISP+ALT. There would be, for example, no 262 need for such an ITR to send a Map-Request to a possibly non-existent 263 EID (and rely on Negative Map-Replies) if it can consult the ALT 264 database to verify that an EID-prefix is present before sending that 265 Map-Request. 267 4.2. EID Prefix Configuration and ETR Registration 269 An ETR publishes its EID-prefixes on a Map Server by sending LISP 270 Map-Register messages. A Map-Register message includes 271 authentication data, so prior to sending a Map-Register message, the 272 ETR and Map Server must be configured with a secret shared-key. A 273 Map Server's configuration must also include a list of the EID- 274 prefixes for which each ETR is authoritative. Upon receipt of a Map- 275 Register from an ETR, a Map Server accepts only EID-prefixes that are 276 configured for that ETR. Failure to implement such a check would 277 leave the mapping system vulnerable to trivial EID-prefix hijacking 278 attacks. As developers and operators gain experience with the 279 mapping system, additional, stronger security measures may be added 280 to the registration process. 282 In addition to the set of EID-prefixes defined for each ETR that may 283 register, a Map Server is typically also be configured with one or 284 more aggregate prefixes that define the part of the EID numbering 285 space assigned to it. When LISP+ALT is the database in use, 286 aggregate EID-prefixes are implemented as discard routes and 287 advertised into ALT BGP. The existance of aggregate EID-prefixes in 288 a Map Server's database means that it may receive Map Requests for 289 EID-prefixes that match an aggregate but do not match a registered 290 prefix; Section 4.3 describes how this is handled. 292 Map-Register messages are sent periodically from an ETR to a Map 293 Server with a suggested interval between messages of one minute. A 294 Map Server should time-out and remove an ETR's registration if it has 295 not received a valid Map-Register message within the past three 296 minutes. When first contacting a Map Server after restart or changes 297 to its EID-to-RLOC database mappings, an ETR may initially send Map- 298 Register messages at an increased frequency, up to one every 20 299 seconds. This "quick registration" period is limited to five minutes 300 in duration. 302 An ETR may request that a Map Server explicitly acknowledge receipt 303 and processing of a Map-Register message by setting the "want-map- 304 notify" ("M" bit) flag. A Map Server that receives a Map-Register 305 with this flag set will respond with a Map-Notify message. Typical 306 use of this flag by an ETR would be to set it for Map-Register 307 messages sent during the initial "quick registration" with a Map 308 Server but then set it only occasionally during steady-state 309 maintenance of its association with that Map Server. Note that the 310 Map-Notify message is sent to UDP destination port 4342, not to the 311 source port specified in the original Map-Register message. 313 Note that a one-minute minimum registration interval during 314 maintenance of an ETR-MS association does set a lower-bound on how 315 quickly and how frequently a mapping database entry can be updated. 316 This may have implications for what sorts of mobility can supported 317 directly by the mapping system. For a discussion on one way that 318 faster mobility may be implemented for individual devices, please see 319 [LISP-MN]. 321 An ETR may also request, by setting the "proxy-map-reply" flag 322 (P-bit) in the Map-Regsiter message, that a Map Server answer Map- 323 Requests instead of forwarding them to the ETR. See [LISP] for 324 details on how the Map Server sets certain flags (such as those 325 indicating whether the message is authoritative and how returned 326 locators should be treated) when sending a Map-Reply on behalf of an 327 ETR. When an ETR requests proxy reply service, it should include all 328 RLOCs for all ETRs for the EID-prefix being registered, along with 329 the "R" bit setting for each RLOC. The Map Server includes all of 330 this information in Map Reply messages that it sends on behalf of the 331 ETR. 333 An ETR which uses a Map Server to publish its EID-to-RLOC mappings 334 does not need to participate further in the mapping database 335 protocol(s). When using a LISP+ALT mapping database, for example, 336 this means that the ETR does not need to implement GRE or BGP, which 337 greatly simplifies its configuration and reduces its cost of 338 operation. 340 Note that use of a Map Server does not preclude an ETR from also 341 connecting to the mapping database (i.e. it could also connect to the 342 LISP+ALT network) but doing so doesn't seem particularly useful as 343 the whole purpose of using a Map Server is to avoid the complexity of 344 the mapping database protocols. 346 4.3. Map Server Processing 348 Once a Map Server has EID-prefixes registered by its client ETRs, it 349 can accept and process Map-Requests for them. 351 In response to a Map-Request (received over the ALT if LISP+ALT is in 352 use), the Map Server first checks to see if the destination EID 353 matches a configured EID-prefix. If there is no match, the Map 354 Server returns a negative Map-Reply with action code "forward-native" 355 and a 15-minute TTL. This may occur if a Map Request is received for 356 a configured aggreate EID-prefix for which no more-specific EID- 357 prefix exists; it indicates the presence of a non-LISP "hole" in the 358 agregate EID-prefix. 360 Next, the Map Server checks to see if any ETRs have registered the 361 matching EID-prefix. If none are found, then the Map-Server returns 362 a negative Map-Reply with action code "forward-native" and a 1-minute 363 TTL. 365 If any of the registered ETRs for the EID-prefix have requested proxy 366 reply service, then the Map Server answered the request instead of 367 forwarding it. It returns a Map-Reply with the EID-prefix, RLOCs, 368 and other information learned through the registration process. 370 If none of the ETRs have requested proxy reply service, then the Map 371 Server re-encapsulates and forwards the resulting Encapsulated Map- 372 Request to one of the registered ETRs. It does not otherwise alter 373 the Map-Request so any Map-Reply sent by the ETR is returned to the 374 RLOC in the Map-Request, not to the Map Server. Unless also acting 375 as a Map Resolver, a Map Server should never receive Map-Replies; any 376 such messages should be discarded without response, perhaps 377 accompanied by logging of a diagnostic message if the rate of Map- 378 Replies is suggestive of malicious traffic. 380 A Map Server may also receive a Map-Request that is contained inside 381 of an Encapsulated Control Message (an Encapsulated Map-Request) with 382 the "Security" bit (S-bit) set. It processes the security parameters 383 as described in [LISP-SEC] then handles the Map-Request as as 384 described above. 386 Note that a Map Server that is sending a Map-Reply on behalf of an 387 ETR (performing proxy reply service) must perform security processing 388 for that ETR as well; see [LISP-SEC] for details. 390 4.4. Map Resolver Processing 392 Upon receipt of an Encapsulated Map-Request, a Map Resolver de- 393 capsulates the enclosed message then searches for the requested EID 394 in its local database of mapping entries (statically configured, 395 cached, or learned from associated ETRs when the Map Resolver is also 396 acting as a Map Server). If it finds a matching entry, it returns a 397 non-authoritative LISP Map-Reply with the known mapping. 399 If the Map Resolver does not have the mapping entry and if it can 400 determine that the EID is not in the mapping database (for example, 401 if LISP+ALT is used, the Map Resolver will have an ALT forwarding 402 table that covers the full EID space) it immediately returns a 403 negative LISP Map-Reply, with action code "forward-native" and a 15- 404 minute TTL. To minimize the number of negative cache entries needed 405 by an ITR, the Map Resolver should return the least-specific prefix 406 which both matches the original query and does not match any EID- 407 prefix known to exist in the LISP-capable infrastructure. 409 If the Map Resolver does not have sufficient information to know 410 whether the EID exists, it needs to forward the Map-Request to 411 another device which has more information about the EID being 412 requested. This is done in one of two ways: 414 1. A non-caching Map Resolver simply forwards the unencapsulated 415 Map-Request, with the original ITR RLOC as the source, on to the 416 distributed mapping database. Using a LISP+ALT mapping database, 417 the Map Resolver is connected to the ALT network and sends the 418 Map-Request to the next ALT hop learned from its ALT BGP 419 neighbors. The Map Resolver does not send any response to the 420 ITR; since the source RLOC is that of the ITR, the ETR or Map 421 Server which receives the Map-Request over the ALT and responds 422 will do so directly to the ITR. 424 2. A caching Map Resolver queues information from the Encapsulated 425 Map-Request, including the ITR RLOC and the original nonce. It 426 then modifies the Map-Request to use its own RLOC, generates a 427 "local nonce" (which is also saved in the request queue entry), 428 and forwards the Map-Request as above. When the Map Resolver 429 receives a Map-Reply, it looks in its request queue to match the 430 reply nonce to a "local nonce" entry then de-queues the entry and 431 uses the saved original nonce and ITR RLOC to re-write those 432 fields in the Map-Reply before sending to the ITR. The request 433 queue entry is also deleted and the mapping entries from the Map- 434 Reply are saved in the Map Resolver's cache. 436 If a Map Resolver receives a Map-Request contained in an Encapsulated 437 Control Message (an Encapsulated Map-Request) with the "security" 438 option (S-Bit) set, additional processing is required. It extracts 439 the enclosed Map-Request and uses the attached security paramaters to 440 generate a new Encapsulated Control Message containing the original 441 Map-Rqeuest and additional signature information used to protect both 442 the Map-Request and the Map-Reply that will be generated by the 443 destination ETR or Map Server. The outgoing message will have the 444 S-bit set, will use the requested EID as its outer header destination 445 IP address plus Map Resolver RLOC as source IP address, and will 446 include security parameters added by the Map Resolver. See 447 [LISP-SEC] for details of the checks that are performed and the 448 security information that is added during the de-encapsulation and 449 re-encapsulation process. 451 4.4.1. Anycast Map Resolver Operation 453 A Map Resolver can be set up to use "anycast", where the same address 454 is assigned to multiple Map Resolvers and is propagated through IGP 455 routing, to facilitate the use of a topologically-close Map Resolver 456 each ITR. 458 Note that Map Server associations with ETRs should not use anycast 459 addresses as registrations need to be established between an ETR and 460 a specific set of Map Servers, each identified by a specific 461 registation association. 463 5. Open Issues and Considerations 465 There are a number of issues with the Map Server and Map Resolver 466 design that are not yet completely understood. Among these are: 468 o Feasibility, performance, and complexity trade-offs of 469 implementing caching in Map Resolvers 471 o Convergence time when an EID-to-RLOC mapping changes and 472 mechanisms for detecting and refreshing or removing stale, cached 473 information 475 o Deployability and complexity trade-offs of implementing stronger 476 security measures in both EID-prefix registration and Map-Request/ 477 Map-Reply processing 479 o Requirements for additional state in the registration process 480 between Map Servers and ETRs 482 The authors expect that experimentation on the LISP pilot network 483 will help answer open questions surrounding these and other issues. 485 6. IANA Considerations 487 This document makes no request of the IANA. 489 7. Security Considerations 491 The 2-way nonce exchange documented in [LISP] can be used to avoid 492 ITR spoofing attacks. 494 To publish an authoritative EID-to-RLOC mapping with a Map Server, an 495 ETR includes authentication data that is a hash of the message using 496 pair-wise shared key. An implementation must support use of HMAC- 497 SHA-1-160 [RFC2104] and should support use of HMAC-SHA-256-128 498 [RFC6234] (SHA-256 truncated to 128 bits). 500 During experimental and prototype deployment, authentication key 501 changes will be manual. Should LISP and its components be considered 502 for IETF standardization, further work will be required to follow the 503 BCP 107 [RFC4107] recommendations on automated key management. 505 As noted in Section 4.2, a Map Server should verify that all EID- 506 prefixes registered by an ETR match configuration stored on the Map 507 Server. 509 [LISP-SEC] defines a mechanism for providing origin authentication, 510 integrity, anti-reply protection, and prevention of man-in-the-middle 511 and "overclaiming" attacks on the Map-Request/Map-Reply exchange. 513 While beyond the scope of securing an individual Map Server or Map 514 Resolver, it should be noted that a BGP-based LISP+ALT network (if 515 ALT is used as the mapping database infrastructure) can take 516 advantage of technology being developed by the IETF SIDR working 517 group or either S-BGP [I-D.murphy-bgp-secr] or soBGP 518 [I-D.white-sobgparchitecture] should they be developed and widely 519 deployed. 521 8. References 523 8.1. Normative References 525 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 526 Alternative Topology (LISP-ALT)", 527 draft-ietf-lisp-alt-07.txt (work in progress), June 2011. 529 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 530 "Locator/ID Separation Protocol (LISP)", 531 draft-ietf-lisp-15.txt (work in progress), July 2011. 533 [LISP-SEC] 534 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 535 Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt 536 (work in progress), July 2011. 538 [RFC1035] Mockapetris, P., "Domain names - implementation and 539 specification", STD 13, RFC 1035, November 1987. 541 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 542 Hashing for Message Authentication", RFC 2104, 543 February 1997. 545 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 546 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 548 8.2. Informative References 550 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 551 Content distribution Overlay Network Service for LISP", 552 draft-meyer-lisp-cons-04.txt (work in progress), 553 April 2008. 555 [I-D.murphy-bgp-secr] 556 Murphy, S., "BGP Security Analysis", 557 draft-murphy-bgp-secr-04 (work in progress), 558 November 2001. 560 [I-D.white-sobgparchitecture] 561 White, R., "Architecture and Deployment Considerations for 562 Secure Origin BGP (soBGP)", 563 draft-white-sobgparchitecture-00 (work in progress), 564 May 2004. 566 [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 567 Mobile Node Architecture", draft-meyer-lisp-mn-05.txt 568 (work in progress), May 2011. 570 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 571 draft-lear-lisp-nerd-08.txt (work in progress), 572 March 2010. 574 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 575 Key Management", BCP 107, RFC 4107, June 2005. 577 Appendix A. Acknowledgments 579 The authors would like to thank Greg Schudel, Darrel Lewis, John 580 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 581 Fabio Maino, and members of the lisp@ietf.org mailing list for their 582 feedback and helpful suggestions. 584 Special thanks are due to Noel Chiappa for his extensive work on 585 caching with LISP-CONS, some of which may be used by Map Resolvers. 587 Authors' Addresses 589 Vince Fuller 590 cisco Systems 591 Tasman Drive 592 San Jose, CA 95134 593 USA 595 Email: vaf@cisco.com 597 Dino Farinacci 598 cisco Systems 599 Tasman Drive 600 San Jose, CA 95134 601 USA 603 Email: dino@cisco.com