idnits 2.17.1 draft-brim-lisp-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 523. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2008) is 5891 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'BGPGrowth' is mentioned on line 104, but not defined == Missing Reference: 'FirstClass' is mentioned on line 281, but not defined Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group LISP Authors 3 Internet-Draft cisco 4 Intended status: Experimental March 10, 2008 5 Expires: September 11, 2008 7 LISP Analysis 8 draft-brim-lisp-analysis-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 11, 2008. 35 Abstract 37 This draft answers questions raised in the IRTF Routing Reseach Group 38 Design Goals. A future version may also address issues raised in the 39 IETF Routing Area Problem Statement. 41 Table of Contents 43 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 44 2. Authorship . . . . . . . . . . . . . . . . . . . . . . . . . . 4 45 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 46 4. Routing Research Group Design Goals . . . . . . . . . . . . . 6 47 4.1. Improved Routing Scalability . . . . . . . . . . . . . . . 6 48 4.2. Scalable Support for Traffic Engineering . . . . . . . . . 6 49 4.3. Scalable Support for Multihoming . . . . . . . . . . . . . 7 50 4.4. Scalable Support for Mobility . . . . . . . . . . . . . . 8 51 4.5. Simplified Renumbering . . . . . . . . . . . . . . . . . . 9 52 4.6. Decoupling Location and Identification . . . . . . . . . . 9 53 4.7. First-Class Elements . . . . . . . . . . . . . . . . . . . 9 54 4.8. Routing Quality . . . . . . . . . . . . . . . . . . . . . 10 55 4.9. Routing Security . . . . . . . . . . . . . . . . . . . . . 11 56 4.10. Deployability . . . . . . . . . . . . . . . . . . . . . . 12 57 5. Routing Research Group Design Goals . . . . . . . . . . . . . 14 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 63 Intellectual Property and Copyright Statements . . . . . . . . . . 18 65 1. Requirements Notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Authorship 73 The authors of this specification are Scott Brim, Dino Farinacci, 74 Vince Fuller, Eliot Lear, Darrel Lewis, David Meyer, and David Oran. 76 3. Introduction 78 This document discusses LISP (Locator/Identifier Separation Protocol) 79 [lisp], and how the LISP protocol answers issues raised in the IRTF 80 Routing Research Group design goals [rrg]. A future version may 81 address issues raised in the IETF Routing Area problem statement 82 [radir]. 84 In general "map-and-encapsulate" approaches to routing and addressing 85 architecture allow one to decouple the two aspects of mapping and 86 encapsulating. In the case of LISP there is one base encapsulation 87 protocol, and a number of possible mapping mechanisms. Because of 88 the looseness of this coupling it is difficult to analyze "LISP". 89 Some potentially interesting mapping mechanisms have been proposed 90 but are still very incomplete. Therefore this document primarily 91 discusses the base LISP protocol, and then discusses possibilities 92 with some of the mapping mechanisms but does not try to be a complete 93 survey. 95 4. Routing Research Group Design Goals 97 If the text from the design goals draft is not too long, it is 98 included at the start of each section for context. 100 4.1. Improved Routing Scalability 102 "Long experience with inter-domain routing has shown us that the 103 global BGP routing table is continuing to grow rapidly 104 [BGPGrowth]. Carrying this large amount of state in the control 105 plane is expensive and places undue cost burdens on network 106 participants that do not necessarily get value from the 107 increases in the routing table size. 109 Thus, the first required goal is to provide significant 110 improvement to the scalability of the control plane. It is 111 strongly desired to make the control plane scale independently 112 from the growth of the Internet user population." 114 There are three aspects to routing scalability: 116 o The amount of state in a router's routing databases. 118 o The rate of change of a routing database. 120 o Convergence time. 122 Principally the scalability problem is in the core of the Internet 123 (the "default-free zone"), not in the periphery. 125 A map-and-encapsulate approach such as LISP removes routing 126 information from the core of the Internet by removing announcements 127 of prefixes at the edge. Edge site routing and core routing are 128 decoupled. Also, edge sites are the source of most routing 129 volatility. When edge prefix announcements are removed, routing has 130 significantly less churn. LISP reaches these non-globally-routed 131 EIDs by encapsulating packets to them in an outer IP header and a 132 LISP header at an ITR (ingress tunnel router) and decapsulating them 133 at an ETR (egress tunnel router). No extra processing is required 134 within edge sites or at core routers. They perceive no difference in 135 their protocols. 137 4.2. Scalable Support for Traffic Engineering 139 "Traffic engineering is the capability of directing traffic 140 along paths other than those that would be computed by normal 141 IGP/EGP routing. Inter-domain traffic engineering today is 142 frequently accomplished by injecting more-specific prefixes into 143 the global routing table, which results in a negative impact on 144 routing scalability. A scalable solution for inter-domain 145 traffic engineering is strongly desired." 147 There are several kinds of traffic engineering. The focus of this 148 item is on the desire to have particular prefixes in a domain reached 149 via particular edge routers. 151 With LISP, BGP is used as it is today for the core of the Internet, 152 and the current mechanisms can be used. For the edge of the 153 Internet, where EIDs are no longer globally routed, LISP supports TE 154 by communicating priorities for ETRs. The details depend on the 155 mapping mechanism used, but generally a mapping also includes 156 priorities as to which ETR the ITR should use for a particular 157 prefix. Thus this design goal is met directly, not by using a 158 routing protocol to implement policy indirectly as is done now. 159 These priorities can be updated dynamically, on a per-flow basis by 160 using ETR reachability in LISP packet headers as well as by LISP 161 mapping control messages. No handling is required except at the 162 xTRs. 164 In addition, with LISP a site has more policy-based control of how 165 traffic reaches it than it does now with BGP, where a site's wishes 166 can be overridden unexpectedly by intermediate routers. 168 4.3. Scalable Support for Multihoming 170 "Multi-homing is the capability of an organization to be 171 connected to the Internet via more than one other organization. 172 The current mechanism for supporting multi-homing is to let the 173 organization advertise one or multiple prefixes into the global 174 routing system, again resulting in a negative impact on routing 175 scalability. More scalable solutions for multi-homing are 176 strongly desired." 178 LISP solves this problem, supporting multihoming scalably and with 179 lower operating expense, by mapping and encapsulating. Map-and- 180 encapsulate removes routing state from the core of the Internet while 181 allowing fine-grain control of how a prefix is reached. Also, LISP 182 allows a site to get multihoming without requiring it to run BGP in 183 its edge routers. Not only that, but with mapping systems such as 184 LISP-ALT [alt], the policy controlling multihoming can be dynamic. 185 Since the decision about how to tell a remote site to reach a 186 particular prefix is made by the destination site's ETR, the decision 187 can be made on the fly. It does not need to be pre-configured. 189 4.4. Scalable Support for Mobility 191 "Mobility is the capability of a host, network, or organization 192 to change its topological connectivity with respect to the 193 remainder of the Internet, while continuing to receive packets 194 from the Internet. Existing mechanisms to provide mobility 195 support include (1) renumbering the mobile entity as it changes 196 its topological attachment point(s) to the Internet; (2) 197 renumbering and creating a tunnel from the entity's new 198 topological location back to its original location; and (3) 199 letting the mobile entity announce its prefixes from its new 200 attachment point(s). The first approach alone is considered 201 unsatisfactory as the change of IP address may break existing 202 transport or higher level connections for those protocols using 203 IP addresses as identifiers. The second requires the deployment 204 of a 'home agent' to keep track of the mobile entity's current 205 location and adds overhead to the routers involved, as well as 206 adding stretch to the path of inbound packet. Neither of the 207 first two approaches impacts the routing scalability. The third 208 approach, however, injects dynamic updates into the global 209 routing system as the mobile entity moves. Mechanisms that help 210 to provide more efficient and scalable mobility support are 211 desired, especially when they can be coupled with security and 212 support topological changes at a high-rate." 214 Since the next section is on ease of renumbering, only "fast" 215 mobility will be discussed in this section. 217 With regard to a single entity moving rapidly and wishing to maintain 218 its IP address, LISP does not intend, and does not believe it is 219 important, for global routing to maintain what is essentially a 220 network attachment identifier as a node changes its network 221 attachment. Solutions to disruption of sessions due to changing IP 222 address (the first approach mentioned above) should not be sought in 223 IP routing. Mobility is important, and routing and addressing 224 architecture must support mobility as a major way of using the 225 Internet, but that does not mean that direct support mechanisms must 226 be built into routing. 228 Routing and addressing are fundamental, and the Internet community 229 has learned through experience that it is important to architect for 230 generality and flexibility, and not for support of specific things 231 running on that architecture. Therefore there is no need for the 232 third approach mentioned above for individual devices. It can be 233 used, but it does not need to be used. If it is used, LISP and LISP 234 mapping approaches can support it. It can be supported directly 235 using LISP-ALT for mapping, through gleaning mapping information from 236 data packet LISP headers, and through expedited remapping. It can 237 also be supported in conjunction with Mobile IP (the second approach 238 above). The constraints on its use come in the size of the mapping 239 cache in ITRs and thrashing of the mapping system if it needs to be 240 updated, but not in core routing. This approach can be used for 241 whole networks moving as well. 243 As for the second approach (MIP), a node will always need a "home" 244 where it can be found by others establishing new sessions with it. 245 Even updates to DNS will have some latency. Therefore we need at 246 least the first part of MIP, the home agent and initial tunneling of 247 packets, no matter what else we do. Since there is hardly any 248 deployment of MIPv6 and only partial deployment of MIPv4, we need not 249 be constrained by the details of those particular approaches. 251 4.5. Simplified Renumbering 253 The goal is to make it easier to change upstream providers without 254 renumbering. 256 Renumbering is "slow mobility". Under LISP, a site can change 257 upstream providers with or without changing its prefix. If it keeps 258 its prefix, information fed to the mapping system needs to be 259 changed. This can be done -- limitations are not technical. If it 260 changes its prefix, nothing in routing needs to change. 262 4.6. Decoupling Location and Identification 264 The goal is to avoid the problems of coupling endpoint attachment 265 point information and identification information. 267 The principal goal of LISP is to save core routing by reducing the 268 amount of "rate*state" it experiences. It can also be used to 269 support network layer routing by any network layer names. LISP only 270 assumes that an EID is globally unique and can be used to deliver 271 packets within the site in which the EID can be found. Sites are 272 able to use anything they want as EIDs as long as the site has peer 273 sites with which its users can communicate using those EIDs. LISP 274 documentation assumes that EIDs will be continuations of current IP 275 addresses because this is the most likely deployment path. 277 4.7. First-Class Elements 279 "If a solution makes use of a mechanism, it is strongly desired 280 that the mechanism be a first-class element in the architecture 281 [FirstClass]. More specifically, if a tunneling mechanism is 282 used to provide network layering, connectivity virtualization, 283 or a connection-oriented mode, then it is strongly desired that 284 the tunneling mechanism be a first-class element in the 285 architecture." 287 This seems to be true for LISP. Further analysis requires further 288 discussion of the goal. 290 4.8. Routing Quality 292 The goal is to have a routing system that produces routes that are at 293 least as good as today's routes in terms of convergence, stability 294 and stretch. 296 The LISP mapping mechanism is for RLOC discovery. Paths for actual 297 forwarding of LISP-encapsulated packets across the core are 298 controlled by BGP, running as now, or whatever replaces it. 299 Therefore, to start with the quality of paths selected using LISP is 300 at least as good as those currently produced by BGP. However, 301 routing quality is improved in several ways. 303 Because both state and rate will be reduced in the core by removal of 304 the most volatile and error-prone routing information (that from the 305 edge), stability and convergence time will improve. Because there is 306 a better possibility of traffic engineering and policy-based routing 307 with LISP, destination sites can control their ingress points better 308 and quality of paths may be better from their point of view. They 309 are not subject to route damping or unexpected policies in the middle 310 of the network. Finally, with easier and more ubiquitous use of 311 active-active multi-homing, traffic will be more evenly spread across 312 the core, and the experienced quality of paths will improve. 314 Currently when a CE goes down, it takes some time for BGP to converge 315 so that packets from a remote site can reestablish a good route. 316 With LISP, when an xTR goes down all packets from within the site 317 will start flowing through a different xTR (assuming there is one), 318 and they will arrive at the remote xTR with the locator reachability 319 bits set to indicate that the first xTR is no longer useable. The 320 remote site will be able to change its routing for all prefixes to 321 use the new xTR immediately, without waiting for BGP convergence. 322 This benefit can be characterized in further research. 324 There has been concern about delay in some proposed mapping 325 mechanisms. Initial experiments suggest that when delay occurs, it 326 is not highly significant. This issue is being pursued and cannot be 327 resolved until more information is collected. 329 LISP can support multicast. A draft is being prepared. 331 Stability in the mapping system depends on which mapping mechanism is 332 used. All of the ones currently being considered are inherently 333 stable because only one source is recognized as authoritative for a 334 particular EID prefix to RLOC mapping. LISP-ALT is inherently stable 335 because information is only distributed from the destination site's 336 ETRs or their representatives. In ALT, new prefix mappings can be 337 added to the system without affecting stability because their 338 announcement is quickly absorbed by aggregation. NERD [nerd] is 339 stable because the flow of information is administrative and there is 340 no reason for thrashing unless the sources are thrashing. 342 4.9. Routing Security 344 "Currently, the routing subsystem is secured through a number of 345 protocol specific mechanisms of varying strength and 346 applicability. Any new architecture is required to provide at 347 least the same level of security as is deployed as of when the 348 new architecture is deployed." 350 The current system of routers, and BGP, will continue to be used for 351 routing of LISP-encapsulated packets. Therefore for routing and 352 forwarding across the Internet core, the same security issues and 353 practices apply as are used now. 355 As in any Locator/identifier split approach, a critical operation is 356 the creation of Locator to ID binding state that devices will use 357 over time. In the case of LISP, the critical operation is the 358 creation of EID prefix to RLOC mappings in the ITR and the ETR. 359 These mappings can be obtained in three ways: 361 o By using information obtained from a LISP data packet. 363 o By using information contained in a Map-Reply message. 365 o By using an EID prefix to RLOC mapping system. 367 LISP mitigates attacks on the first two techniques by including a 368 nonce in the LISP header. The nonce is a 32-bit randomly generated 369 number (generated by the source ITR), and is used to test route 370 returnability. More specifically, an ETR will echo the nonce back to 371 the ITR in a Map-Reply message. The nonce, combined with the ITR 372 accepting only solicited Map-Replies provides a base level of 373 authentication for Map-Replies. Note that these techniques do not 374 protect against Man-In-The-Middle attacks. 376 The LISP design assumes that mapping systems will all employ the 377 security mechanisms of the technologies they are built on. If a 378 mapping system is used (the third technique above) the particular 379 mapping system chosen will inherit the security characteristics of 380 its technologies. 382 As a mapping system, LISP-ALT shares many of the security 383 characteristics of BGP. Its security mechanisms are comprised of 384 existing technologies in wide operational use today. Securing LISP- 385 ALT is much simpler than securing BGP. Compared to BGP, LISP-ALT 386 routers are not topologically bound, allowing them to be put in 387 locations away from the vulnerable AS border (unlike eBGP speakers). 389 4.10. Deployability 391 "Since solutions that are not deployable are simply academic 392 exercises, solutions are required to be deployable from a 393 technical perspective. Furthermore, given the extensive 394 deployed base of today's Internet, a solution is required to be 395 incrementally." 397 Deployability includes many things, from operational burden to 398 ability to coexist with current and future deployments of other 399 approaches. 401 IPv4 will be with us for years. For IPv4, because of utilization and 402 address size we have no choice but to use a map-and-encapsulate 403 strategy. Address rewriting strategies are only viable for IPv6, and 404 adopting them requires some kind of encapsulation or translation for 405 IPv4. LISP has a strategy that works for both IPv4 and IPv6. 407 LISP does not require changes within sites or in the Internet core. 408 Changes are only required at xTRs and in the LISP mapping system. 409 Network operators who have been polled have said they prefer changes 410 at site edges more than changes in user systems. 412 LISP can be incrementally deployed, and when doing SNAT according to 413 the LISP interworking draft [interwk], prefixes can be withdrawn from 414 the main BGP routing system right away during the early stages of 415 LISP deployment. This can give core routing an immediate lessening 416 of load while increasing capability -- one of the critical goals of 417 this effort. 419 LISP does not require new silicon to be deployed. xTR functionality 420 can be deployed in software-based routers, and updated quickly. As 421 needs are discovered they can be met right away. 423 By using a map-and-encapsulate approach instead of header rewriting, 424 you have complete visibility of EIDs as well as RLOCs. A rewrite 425 scheme loses information that may be needed by ACLs in firewalls and 426 other security processes. 428 Compared to management of BGP, management of LISP is trivial. This 429 has been experienced in actual deployments. 431 LISP is the only approach whose documentation you can implement from, 432 and thus truly test its viability. 434 5. Routing Research Group Design Goals 436 TBD 438 6. Security Considerations 440 See Section 4.9. 442 7. References 444 7.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [alt] Fuller, V., "LISP Alternative Topology (LISP-ALT)", 450 draft-fuller-lisp-alt-01.txt (work in progress), 451 November 2007. 453 [interwk] Lewis, D., "Interworking LISP with IPv4 and IPv6", 454 draft-lewis-lisp-interworking-00.txt (work in progress), 455 December 2007. 457 [lisp] Farinacci, D., "Locator/ID Separation Protocol (LISP)", 458 draft-farinacci-lisp--06.txt (work in progress), 459 February 2008. 461 [nerd] Lear, E., "A Not-so-novel EID to RLOC Database", 462 draft-lear-lisp-nerd-03.txt (work in progress), 463 January 2008. 465 [rrg] Li, T., "Design Goals for Scalable Internet Routing", 466 draft-irtf-rrg-design-goals-01.txt (work in progress), 467 July 2007. 469 7.2. Informative References 471 [radir] Narten, T., "Routing and Addressing Problem Statement", 472 draft-narten-radir-problem-statement-00.txt (work in 473 progress), July 2007. 475 Author's Address 477 LISP Authors 478 cisco 479 Tasman Drive 480 San Jose, CA 95134 481 USA 483 Email: lisp-beta@external.cisco.com 485 Full Copyright Statement 487 Copyright (C) The IETF Trust (2008). 489 This document is subject to the rights, licenses and restrictions 490 contained in BCP 78, and except as set forth therein, the authors 491 retain all their rights. 493 This document and the information contained herein are provided on an 494 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 495 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 496 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 497 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 498 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 499 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 501 Intellectual Property 503 The IETF takes no position regarding the validity or scope of any 504 Intellectual Property Rights or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; nor does it represent that it has 508 made any independent effort to identify any such rights. Information 509 on the procedures with respect to rights in RFC documents can be 510 found in BCP 78 and BCP 79. 512 Copies of IPR disclosures made to the IETF Secretariat and any 513 assurances of licenses to be made available, or the result of an 514 attempt made to obtain a general license or permission for the use of 515 such proprietary rights by implementers or users of this 516 specification can be obtained from the IETF on-line IPR repository at 517 http://www.ietf.org/ipr. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights that may cover technology that may be required to implement 522 this standard. Please address the information to the IETF at 523 ietf-ipr@ietf.org.