idnits 2.17.1 draft-ietf-lisp-ms-13.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 (December 6, 2011) is 4522 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == 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 (~~), 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: June 8, 2012 December 6, 2011 7 LISP Map Server Interface 8 draft-ietf-lisp-ms-13.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 June 8, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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 . . . . . . . . . . . 7 66 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7 67 4.2. EID Prefix Configuration and ETR Registration . . . . . . 8 68 4.3. Map Server Processing . . . . . . . . . . . . . . . . . . 9 69 4.4. Map Resolver Processing . . . . . . . . . . . . . . . . . 10 70 4.4.1. Anycast Map Resolver Operation . . . . . . . . . . . . 12 71 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 13 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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. 184 During initial deployment, a Map Resolver will operate only in a non- 185 caching mode, where it simply de-capsulates and forwards the 186 Encapsulated Map-Requests that it receives from ITRs. 188 In future deployments, a Map Resolver may operate in a caching mode, 189 where it saves information about outstanding Map-Requests, originates 190 new Map-Requests to the correct ETR(s), accepts and caches the Map- 191 Replies, and finally forwards the Map-Replies to the original ITRs. 192 One significant issue with use of caching in a Map Resolver is that 193 it hides the original ITR source of a Map-Request, which prevents an 194 ETR from tailoring its responses to that source; this reduces the 195 inbound traffic- engineering capability for the site owning the ETR. 196 In addition, caching in a Map Resolver exacerbates problems 197 associated with old mappings being cached; an outdated, cached 198 mapping in an ITR affects only that ITR and traffic originated by its 199 site while an outdated, cached mapping in a Map Resolver could cause 200 a problem with a wider scope. More experience with caching Map 201 Resolvers on the LISP pilot network will be needed to determine 202 whether their use can be recommended. 204 Note that a single device can implement the functions of both a Map 205 Server and a Map Resolver and, in many cases, the functions will be 206 co-located in that way. 208 Detailed descriptions of the LISP packet types referenced by this 209 document may be found in [LISP]. 211 4. Interactions With Other LISP Components 213 4.1. ITR EID-to-RLOC Mapping Resolution 215 An ITR is configured with one or more Map Resolver addresses. These 216 addresses are "locators" (or RLOCs) and must be routeable on the 217 underlying core network; they must not need to be resolved through 218 LISP EID-to-RLOC mapping as that would introduce a circular 219 dependency. When using a Map Resolver, an ITR does not need to 220 connect to any other database mapping system. In particular, the ITR 221 need not connect to the LISP+ALT infrastructure or implement the BGP 222 and GRE protocols that it uses. 224 An ITR sends an Encapsulated Map-Request to a configured Map Resolver 225 when it needs an EID-to-RLOC mapping that is not found in its local 226 map-cache. Using the Map Resolver greatly reduces both the 227 complexity of the ITR implementation and the costs associated with 228 its operation. 230 In response to an Encapsulated Map-Request, the ITR can expect one of 231 the following: 233 o An immediate Negative Map-Reply (with action code of "forward- 234 native", 15-minute TTL) from the Map Resolver if the Map Resolver 235 can determine that the requested EID does not exist. The ITR 236 saves the EID-prefix returned in the Map-Reply in its cache, 237 marking it as non-LISP-capable and knows not to attempt LISP 238 encapsulation for destinations matching it. 240 o A Negative Map-Reply (with action code of "forward-native") from 241 the Map Server that has an aggregate EID-covering the EID in the 242 Map-Request but where the EID matches a "hole" in the aggregate. 243 If the "hole" is for a LISP EID-prefix that is defined in the Map 244 Server configuration but for which no ETRs are currently 245 registered, a 1-minute TTL is returned. If the "hole" is for an 246 unassigned part of the aggregate, then it is not a LISP EID and a 247 15-minute TTL is returned. See Section 4.2 for discussion of 248 aggregate EID-prefixes and details of Map Server EID-prefix 249 matching. 251 o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or 252 possibly from a Map Server answering on behalf of the ETR. See 253 (Section 4.4) for more details on Map Resolver message processing. 255 Note that an ITR may be configured to both use a Map Resolver and to 256 participate in a LISP+ALT logical network. In such a situation, the 257 ITR should send Map-Requests through the ALT network for any EID- 258 prefix learned via ALT BGP. Such a configuration is expected to be 259 very rare, since there is little benefit to using a Map Resolver if 260 an ITR is already using LISP+ALT. There would be, for example, no 261 need for such an ITR to send a Map-Request to a possibly non-existent 262 EID (and rely on Negative Map-Replies) if it can consult the ALT 263 database to verify that an EID-prefix is present before sending that 264 Map-Request. 266 4.2. EID Prefix Configuration and ETR Registration 268 An ETR publishes its EID-prefixes on a Map Server by sending LISP 269 Map-Register messages. A Map-Register message includes 270 authentication data, so prior to sending a Map-Register message, the 271 ETR and Map Server must be configured with a shared secret or other 272 relevant authentication information. A Map Server's configuration 273 must also include a list of the EID-prefixes for which each ETR is 274 authoritative. Upon receipt of a Map-Register from an ETR, a Map 275 Server accepts only EID-prefixes that are configured for that ETR. 276 Failure to implement such a check would leave the mapping system 277 vulnerable to trivial EID-prefix hijacking attacks. As developers 278 and operators gain experience with the mapping system, additional, 279 stronger security measures may be added to the registration process. 281 In addition to the set of EID-prefixes defined for each ETR that may 282 register, a Map Server is typically also configured with one or more 283 aggregate prefixes that define the part of the EID numbering space 284 assigned to it. When LISP+ALT is the database in use, aggregate EID- 285 prefixes are implemented as discard routes and advertised into ALT 286 BGP. The existance of aggregate EID-prefixes in a Map Server's 287 database means that it may receive Map Requests for EID-prefixes that 288 match an aggregate but do not match a registered prefix; Section 4.3 289 describes how this is handled. 291 Map-Register messages are sent periodically from an ETR to a Map 292 Server with a suggested interval between messages of one minute. A 293 Map Server should time-out and remove an ETR's registration if it has 294 not received a valid Map-Register message within the past three 295 minutes. When first contacting a Map Server after restart or changes 296 to its EID-to-RLOC database mappings, an ETR may initially send Map- 297 Register messages at an increased frequency, up to one every 20 298 seconds. This "quick registration" period is limited to five minutes 299 in duration. 301 An ETR may request that a Map Server explicitly acknowledge receipt 302 and processing of a Map-Register message by setting the "want-map- 303 notify" ("M" bit) flag. A Map Server that receives a Map-Register 304 with this flag set will respond with a Map-Notify message. Typical 305 use of this flag by an ETR would be to set it for Map-Register 306 messages sent during the initial "quick registration" with a Map 307 Server but then set it only occasionally during steady-state 308 maintenance of its association with that Map Server. Note that the 309 Map-Notify message is sent to UDP destination port 4342, not to the 310 source port specified in the original Map-Register message. 312 Note that a one-minute minimum registration interval during 313 maintenance of an ETR-MS association places a lower-bound on how 314 quickly and how frequently a mapping database entry can be updated. 315 This may have implications for what sorts of mobility can be 316 supported directly by the mapping system; shorter registration 317 intervals or other mechanisms might be needed to suopport faster 318 mobility in some cases. For a discussion on one way that faster 319 mobility may be implemented for individual devices, please see 320 [LISP-MN]. 322 An ETR may also request, by setting the "proxy-map-reply" flag 323 (P-bit) in the Map-Register message, that a Map Server answer Map- 324 Requests instead of forwarding them to the ETR. See [LISP] for 325 details on how the Map Server sets certain flags (such as those 326 indicating whether the message is authoritative and how returned 327 locators should be treated) when sending a Map-Reply on behalf of an 328 ETR. When an ETR requests proxy reply service, it should include all 329 RLOCs for all ETRs for the EID-prefix being registered, along with 330 the routable flag ("R-bit") setting for each RLOC. The Map Server 331 includes all of this information in Map Reply messages that it sends 332 on behalf of the ETR. This differs from a non-proxy registration 333 since the latter need only provide one or more RLOCs for a Map Server 334 to use for forwarding Map-Requests; the registration information is 335 not used in Map-Replies so it being incomplete is not incorrect. 337 An ETR which uses a Map Server to publish its EID-to-RLOC mappings 338 does not need to participate further in the mapping database 339 protocol(s). When using a LISP+ALT mapping database, for example, 340 this means that the ETR does not need to implement GRE or BGP, which 341 greatly simplifies its configuration and reduces its cost of 342 operation. 344 Note that use of a Map Server does not preclude an ETR from also 345 connecting to the mapping database (i.e. it could also connect to the 346 LISP+ALT network) but doing so doesn't seem particularly useful as 347 the whole purpose of using a Map Server is to avoid the complexity of 348 the mapping database protocols. 350 4.3. Map Server Processing 352 Once a Map Server has EID-prefixes registered by its client ETRs, it 353 can accept and process Map-Requests for them. 355 In response to a Map-Request (received over the ALT if LISP+ALT is in 356 use), the Map Server first checks to see if the destination EID 357 matches a configured EID-prefix. If there is no match, the Map 358 Server returns a negative Map-Reply with action code "forward-native" 359 and a 15-minute TTL. This may occur if a Map Request is received for 360 a configured aggreate EID-prefix for which no more-specific EID- 361 prefix exists; it indicates the presence of a non-LISP "hole" in the 362 agregate EID-prefix. 364 Next, the Map Server checks to see if any ETRs have registered the 365 matching EID-prefix. If none are found, then the Map Server returns 366 a negative Map-Reply with action code "forward-native" and a 1-minute 367 TTL. 369 If any of the registered ETRs for the EID-prefix have requested proxy 370 reply service, then the Map Server answers the request instead of 371 forwarding it. It returns a Map-Reply with the EID-prefix, RLOCs, 372 and other information learned through the registration process. 374 If none of the ETRs have requested proxy reply service, then the Map 375 Server re-encapsulates and forwards the resulting Encapsulated Map- 376 Request to one of the registered ETRs. It does not otherwise alter 377 the Map-Request so any Map-Reply sent by the ETR is returned to the 378 RLOC in the Map-Request, not to the Map Server. Unless also acting 379 as a Map Resolver, a Map Server should never receive Map-Replies; any 380 such messages should be discarded without response, perhaps 381 accompanied by logging of a diagnostic message if the rate of Map- 382 Replies is suggestive of malicious traffic. 384 A Map Server may also receive a Map-Request that is contained inside 385 of an Encapsulated Control Message (an Encapsulated Map-Request) with 386 the "Security" bit ("S-bit") set. It processes the security 387 parameters as described in [LISP-SEC] then handles the Map-Request as 388 as described above. 390 Note that a Map Server that is sending a Map-Reply on behalf of an 391 ETR (performing proxy reply service) must perform security processing 392 for that ETR as well; see [LISP-SEC] for details. 394 4.4. Map Resolver Processing 396 Upon receipt of an Encapsulated Map-Request, a Map Resolver de- 397 capsulates the enclosed message then searches for the requested EID 398 in its local database of mapping entries (statically configured, 399 cached, or learned from associated ETRs when the Map Resolver is also 400 acting as a Map Server). If it finds a matching entry, it returns a 401 non-authoritative LISP Map-Reply with the known mapping. 403 If the Map Resolver does not have the mapping entry and if it can 404 determine that the EID is not in the mapping database (for example, 405 if LISP+ALT is used, the Map Resolver will have an ALT forwarding 406 table that covers the full EID space) it immediately returns a 407 negative LISP Map-Reply, with action code "forward-native" and a 15- 408 minute TTL. To minimize the number of negative cache entries needed 409 by an ITR, the Map Resolver should return the least-specific prefix 410 which both matches the original query and does not match any EID- 411 prefix known to exist in the LISP-capable infrastructure. 413 If the Map Resolver does not have sufficient information to know 414 whether the EID exists, it needs to forward the Map-Request to 415 another device which has more information about the EID being 416 requested. This is done in one of two ways: 418 1. A non-caching Map Resolver simply forwards the unencapsulated 419 Map-Request, with the original ITR RLOC as the source, to the 420 mapping database system. Using LISP+ALT, the Map Resolver is 421 connected to the ALT network and sends the Map-Request to the 422 next ALT hop learned from its ALT BGP neighbors. The Map 423 Resolver does not send any response to the ITR; since the source 424 RLOC is that of the ITR, the ETR or Map Server which receives the 425 Map-Request over the ALT and responds will do so directly to the 426 ITR. 428 2. A caching Map Resolver queues information from the Encapsulated 429 Map-Request, including the ITR RLOC and the original Map-Request 430 message nonce. It then modifies the Map-Request to use its own 431 RLOC, generates a "local nonce" (which is also saved in the 432 request queue entry), and forwards the Map-Request as above. 433 When the Map Resolver receives a Map-Reply, it looks in its 434 request queue to match the reply nonce to a "local nonce" entry 435 then de-queues the entry and uses the saved original nonce and 436 ITR RLOC to re-write those fields in the Map-Reply before sending 437 to the ITR. The request queue entry is also deleted and the 438 mapping entries from the Map-Reply are saved in the Map 439 Resolver's cache. 441 If a Map Resolver receives a Map-Request contained in an Encapsulated 442 Control Message (an Encapsulated Map-Request) with the "security" 443 option ("S-Bit") set, additional processing is required. It extracts 444 the enclosed Map-Request and uses the attached security paramaters to 445 generate a new Encapsulated Control Message containing the original 446 Map-Request and additional signature information used to protect both 447 the Map-Request and the Map-Reply that will be generated by the 448 destination ETR or Map Server. The outgoing message will have the 449 "S-bit" set, will use the requested EID as its outer header 450 destination IP address plus Map Resolver RLOC as source IP address, 451 and will include security parameters added by the Map Resolver. See 452 [LISP-SEC] for details of the checks that are performed and the 453 security information that is added during the de-encapsulation and 454 re-encapsulation process. 456 4.4.1. Anycast Map Resolver Operation 458 A Map Resolver can be set up to use "anycast", where the same address 459 is assigned to multiple Map Resolvers and is propagated through IGP 460 routing, to facilitate the use of a topologically-close Map Resolver 461 each ITR. 463 Note that Map Server associations with ETRs should not use anycast 464 addresses as registrations need to be established between an ETR and 465 a specific set of Map Servers, each identified by a specific 466 registation association. 468 5. Open Issues and Considerations 470 There are a number of issues with the Map Server and Map Resolver 471 design that are not yet completely understood. Among these are: 473 o Constants, such as those used for Map-Register frequency, 474 retransmission timeouts, retransmission limits, negative Map-Reply 475 TTLs, et al are subject to further refinement as more experience 476 with prototype deployment is gained. 478 o Feasibility, performance, and complexity trade-offs of 479 implementing caching in Map Resolvers, as discussed in Section 3, 480 Paragraph 4. 482 o Convergence time when an EID-to-RLOC mapping changes and 483 mechanisms for detecting and refreshing or removing stale, cached 484 information 486 o Deployability and complexity trade-offs of implementing stronger 487 security measures in both EID-prefix registration and Map-Request/ 488 Map-Reply processing 490 o Requirements for additional state in the registration process 491 between Map Servers and ETRs 493 The authors expect that experimentation on the LISP pilot network 494 will help answer open questions surrounding these and other issues. 496 6. IANA Considerations 498 This document makes no request of the IANA. 500 7. Security Considerations 502 The 2-way LISP header nonce exchange documented in [LISP] can be used 503 to avoid ITR spoofing attacks. 505 To publish an authoritative EID-to-RLOC mapping with a Map Server, an 506 ETR includes authentication data that is a hash of the message using 507 pair-wise shared key. An implementation must support use of HMAC- 508 SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 509 [RFC6234] (SHA-256 truncated to 128 bits). 511 During experimental and prototype deployment, all authentication key 512 configuration will be manual. Should LISP and its components be 513 considered for IETF standardization, further work will be required to 514 follow the BCP 107 [RFC4107] recommendations on automated key 515 management. 517 As noted in Section 4.2, a Map Server should verify that all EID- 518 prefixes registered by an ETR match configuration stored on the Map 519 Server. 521 [LISP-SEC] defines a mechanism for providing origin authentication, 522 integrity, anti-reply protection, and prevention of man-in-the-middle 523 and "overclaiming" attacks on the Map-Request/Map-Reply exchange. 525 While beyond the scope of securing an individual Map Server or Map 526 Resolver, it should be noted that a BGP-based LISP+ALT network (if 527 ALT is used as the mapping database infrastructure) can take 528 advantage of technology being developed by the IETF SIDR working 529 group or either S-BGP [I-D.murphy-bgp-secr] or soBGP 530 [I-D.white-sobgparchitecture] should they be developed and widely 531 deployed. 533 8. References 535 8.1. Normative References 537 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 538 Alternative Topology (LISP-ALT)", 539 draft-ietf-lisp-alt-10.txt (work in progress), 540 October 2011. 542 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 543 "Locator/ID Separation Protocol (LISP)", 544 draft-ietf-lisp-15.txt (work in progress), July 2011. 546 [LISP-SEC] 547 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 548 Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt 549 (work in progress), July 2011. 551 [RFC1035] Mockapetris, P., "Domain names - implementation and 552 specification", STD 13, RFC 1035, November 1987. 554 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 555 Hashing for Message Authentication", RFC 2104, 556 February 1997. 558 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 559 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 561 8.2. Informative References 563 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 564 Content distribution Overlay Network Service for LISP", 565 draft-meyer-lisp-cons-04.txt (work in progress), 566 April 2008. 568 [I-D.murphy-bgp-secr] 569 Murphy, S., "BGP Security Analysis", 570 draft-murphy-bgp-secr-04 (work in progress), 571 November 2001. 573 [I-D.white-sobgparchitecture] 574 White, R., "Architecture and Deployment Considerations for 575 Secure Origin BGP (soBGP)", 576 draft-white-sobgparchitecture-00 (work in progress), 577 May 2004. 579 [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 580 Mobile Node Architecture", draft-meyer-lisp-mn-05.txt 581 (work in progress), May 2011. 583 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 584 draft-lear-lisp-nerd-08.txt (work in progress), 585 March 2010. 587 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 588 Key Management", BCP 107, RFC 4107, June 2005. 590 Appendix A. Acknowledgments 592 The authors would like to thank Greg Schudel, Darrel Lewis, John 593 Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, 594 Fabio Maino, and members of the lisp@ietf.org mailing list for their 595 feedback and helpful suggestions. 597 Special thanks are due to Noel Chiappa for his extensive work on 598 caching with LISP-CONS, some of which may be used by Map Resolvers. 600 Authors' Addresses 602 Vince Fuller 603 cisco Systems 604 Tasman Drive 605 San Jose, CA 95134 606 USA 608 Email: vaf@cisco.com 610 Dino Farinacci 611 cisco Systems 612 Tasman Drive 613 San Jose, CA 95134 614 USA 616 Email: dino@cisco.com