Network Working Group LISP Authors Internet-Draft cisco Intended status: Experimental March 10, 2008 Expires: September 11, 2008 LISP Analysis draft-brim-lisp-analysis-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 11, 2008. LISP Authors Expires September 11, 2008 [Page 1] Internet-Draft LISP Analysis March 2008 Abstract This draft answers questions raised in the IRTF Routing Reseach Group Design Goals. A future version may also address issues raised in the IETF Routing Area Problem Statement. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Authorship . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Routing Research Group Design Goals . . . . . . . . . . . . . 6 4.1. Improved Routing Scalability . . . . . . . . . . . . . . . 6 4.2. Scalable Support for Traffic Engineering . . . . . . . . . 6 4.3. Scalable Support for Multihoming . . . . . . . . . . . . . 7 4.4. Scalable Support for Mobility . . . . . . . . . . . . . . 8 4.5. Simplified Renumbering . . . . . . . . . . . . . . . . . . 9 4.6. Decoupling Location and Identification . . . . . . . . . . 9 4.7. First-Class Elements . . . . . . . . . . . . . . . . . . . 9 4.8. Routing Quality . . . . . . . . . . . . . . . . . . . . . 10 4.9. Routing Security . . . . . . . . . . . . . . . . . . . . . 11 4.10. Deployability . . . . . . . . . . . . . . . . . . . . . . 12 5. Routing Research Group Design Goals . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 LISP Authors Expires September 11, 2008 [Page 2] Internet-Draft LISP Analysis March 2008 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. LISP Authors Expires September 11, 2008 [Page 3] Internet-Draft LISP Analysis March 2008 2. Authorship The authors of this specification are Scott Brim, Dino Farinacci, Vince Fuller, Eliot Lear, Darrel Lewis, David Meyer, and David Oran. LISP Authors Expires September 11, 2008 [Page 4] Internet-Draft LISP Analysis March 2008 3. Introduction This document discusses LISP (Locator/Identifier Separation Protocol) [lisp], and how the LISP protocol answers issues raised in the IRTF Routing Research Group design goals [rrg]. A future version may address issues raised in the IETF Routing Area problem statement [radir]. In general "map-and-encapsulate" approaches to routing and addressing architecture allow one to decouple the two aspects of mapping and encapsulating. In the case of LISP there is one base encapsulation protocol, and a number of possible mapping mechanisms. Because of the looseness of this coupling it is difficult to analyze "LISP". Some potentially interesting mapping mechanisms have been proposed but are still very incomplete. Therefore this document primarily discusses the base LISP protocol, and then discusses possibilities with some of the mapping mechanisms but does not try to be a complete survey. LISP Authors Expires September 11, 2008 [Page 5] Internet-Draft LISP Analysis March 2008 4. Routing Research Group Design Goals If the text from the design goals draft is not too long, it is included at the start of each section for context. 4.1. Improved Routing Scalability "Long experience with inter-domain routing has shown us that the global BGP routing table is continuing to grow rapidly [BGPGrowth]. Carrying this large amount of state in the control plane is expensive and places undue cost burdens on network participants that do not necessarily get value from the increases in the routing table size. Thus, the first required goal is to provide significant improvement to the scalability of the control plane. It is strongly desired to make the control plane scale independently from the growth of the Internet user population." There are three aspects to routing scalability: o The amount of state in a router's routing databases. o The rate of change of a routing database. o Convergence time. Principally the scalability problem is in the core of the Internet (the "default-free zone"), not in the periphery. A map-and-encapsulate approach such as LISP removes routing information from the core of the Internet by removing announcements of prefixes at the edge. Edge site routing and core routing are decoupled. Also, edge sites are the source of most routing volatility. When edge prefix announcements are removed, routing has significantly less churn. LISP reaches these non-globally-routed EIDs by encapsulating packets to them in an outer IP header and a LISP header at an ITR (ingress tunnel router) and decapsulating them at an ETR (egress tunnel router). No extra processing is required within edge sites or at core routers. They perceive no difference in their protocols. 4.2. Scalable Support for Traffic Engineering "Traffic engineering is the capability of directing traffic along paths other than those that would be computed by normal IGP/EGP routing. Inter-domain traffic engineering today is frequently accomplished by injecting more-specific prefixes into LISP Authors Expires September 11, 2008 [Page 6] Internet-Draft LISP Analysis March 2008 the global routing table, which results in a negative impact on routing scalability. A scalable solution for inter-domain traffic engineering is strongly desired." There are several kinds of traffic engineering. The focus of this item is on the desire to have particular prefixes in a domain reached via particular edge routers. With LISP, BGP is used as it is today for the core of the Internet, and the current mechanisms can be used. For the edge of the Internet, where EIDs are no longer globally routed, LISP supports TE by communicating priorities for ETRs. The details depend on the mapping mechanism used, but generally a mapping also includes priorities as to which ETR the ITR should use for a particular prefix. Thus this design goal is met directly, not by using a routing protocol to implement policy indirectly as is done now. These priorities can be updated dynamically, on a per-flow basis by using ETR reachability in LISP packet headers as well as by LISP mapping control messages. No handling is required except at the xTRs. In addition, with LISP a site has more policy-based control of how traffic reaches it than it does now with BGP, where a site's wishes can be overridden unexpectedly by intermediate routers. 4.3. Scalable Support for Multihoming "Multi-homing is the capability of an organization to be connected to the Internet via more than one other organization. The current mechanism for supporting multi-homing is to let the organization advertise one or multiple prefixes into the global routing system, again resulting in a negative impact on routing scalability. More scalable solutions for multi-homing are strongly desired." LISP solves this problem, supporting multihoming scalably and with lower operating expense, by mapping and encapsulating. Map-and- encapsulate removes routing state from the core of the Internet while allowing fine-grain control of how a prefix is reached. Also, LISP allows a site to get multihoming without requiring it to run BGP in its edge routers. Not only that, but with mapping systems such as LISP-ALT [alt], the policy controlling multihoming can be dynamic. Since the decision about how to tell a remote site to reach a particular prefix is made by the destination site's ETR, the decision can be made on the fly. It does not need to be pre-configured. LISP Authors Expires September 11, 2008 [Page 7] Internet-Draft LISP Analysis March 2008 4.4. Scalable Support for Mobility "Mobility is the capability of a host, network, or organization to change its topological connectivity with respect to the remainder of the Internet, while continuing to receive packets from the Internet. Existing mechanisms to provide mobility support include (1) renumbering the mobile entity as it changes its topological attachment point(s) to the Internet; (2) renumbering and creating a tunnel from the entity's new topological location back to its original location; and (3) letting the mobile entity announce its prefixes from its new attachment point(s). The first approach alone is considered unsatisfactory as the change of IP address may break existing transport or higher level connections for those protocols using IP addresses as identifiers. The second requires the deployment of a 'home agent' to keep track of the mobile entity's current location and adds overhead to the routers involved, as well as adding stretch to the path of inbound packet. Neither of the first two approaches impacts the routing scalability. The third approach, however, injects dynamic updates into the global routing system as the mobile entity moves. Mechanisms that help to provide more efficient and scalable mobility support are desired, especially when they can be coupled with security and support topological changes at a high-rate." Since the next section is on ease of renumbering, only "fast" mobility will be discussed in this section. With regard to a single entity moving rapidly and wishing to maintain its IP address, LISP does not intend, and does not believe it is important, for global routing to maintain what is essentially a network attachment identifier as a node changes its network attachment. Solutions to disruption of sessions due to changing IP address (the first approach mentioned above) should not be sought in IP routing. Mobility is important, and routing and addressing architecture must support mobility as a major way of using the Internet, but that does not mean that direct support mechanisms must be built into routing. Routing and addressing are fundamental, and the Internet community has learned through experience that it is important to architect for generality and flexibility, and not for support of specific things running on that architecture. Therefore there is no need for the third approach mentioned above for individual devices. It can be used, but it does not need to be used. If it is used, LISP and LISP mapping approaches can support it. It can be supported directly using LISP-ALT for mapping, through gleaning mapping information from data packet LISP headers, and through expedited remapping. It can LISP Authors Expires September 11, 2008 [Page 8] Internet-Draft LISP Analysis March 2008 also be supported in conjunction with Mobile IP (the second approach above). The constraints on its use come in the size of the mapping cache in ITRs and thrashing of the mapping system if it needs to be updated, but not in core routing. This approach can be used for whole networks moving as well. As for the second approach (MIP), a node will always need a "home" where it can be found by others establishing new sessions with it. Even updates to DNS will have some latency. Therefore we need at least the first part of MIP, the home agent and initial tunneling of packets, no matter what else we do. Since there is hardly any deployment of MIPv6 and only partial deployment of MIPv4, we need not be constrained by the details of those particular approaches. 4.5. Simplified Renumbering The goal is to make it easier to change upstream providers without renumbering. Renumbering is "slow mobility". Under LISP, a site can change upstream providers with or without changing its prefix. If it keeps its prefix, information fed to the mapping system needs to be changed. This can be done -- limitations are not technical. If it changes its prefix, nothing in routing needs to change. 4.6. Decoupling Location and Identification The goal is to avoid the problems of coupling endpoint attachment point information and identification information. The principal goal of LISP is to save core routing by reducing the amount of "rate*state" it experiences. It can also be used to support network layer routing by any network layer names. LISP only assumes that an EID is globally unique and can be used to deliver packets within the site in which the EID can be found. Sites are able to use anything they want as EIDs as long as the site has peer sites with which its users can communicate using those EIDs. LISP documentation assumes that EIDs will be continuations of current IP addresses because this is the most likely deployment path. 4.7. First-Class Elements "If a solution makes use of a mechanism, it is strongly desired that the mechanism be a first-class element in the architecture [FirstClass]. More specifically, if a tunneling mechanism is used to provide network layering, connectivity virtualization, or a connection-oriented mode, then it is strongly desired that the tunneling mechanism be a first-class element in the LISP Authors Expires September 11, 2008 [Page 9] Internet-Draft LISP Analysis March 2008 architecture." This seems to be true for LISP. Further analysis requires further discussion of the goal. 4.8. Routing Quality The goal is to have a routing system that produces routes that are at least as good as today's routes in terms of convergence, stability and stretch. The LISP mapping mechanism is for RLOC discovery. Paths for actual forwarding of LISP-encapsulated packets across the core are controlled by BGP, running as now, or whatever replaces it. Therefore, to start with the quality of paths selected using LISP is at least as good as those currently produced by BGP. However, routing quality is improved in several ways. Because both state and rate will be reduced in the core by removal of the most volatile and error-prone routing information (that from the edge), stability and convergence time will improve. Because there is a better possibility of traffic engineering and policy-based routing with LISP, destination sites can control their ingress points better and quality of paths may be better from their point of view. They are not subject to route damping or unexpected policies in the middle of the network. Finally, with easier and more ubiquitous use of active-active multi-homing, traffic will be more evenly spread across the core, and the experienced quality of paths will improve. Currently when a CE goes down, it takes some time for BGP to converge so that packets from a remote site can reestablish a good route. With LISP, when an xTR goes down all packets from within the site will start flowing through a different xTR (assuming there is one), and they will arrive at the remote xTR with the locator reachability bits set to indicate that the first xTR is no longer useable. The remote site will be able to change its routing for all prefixes to use the new xTR immediately, without waiting for BGP convergence. This benefit can be characterized in further research. There has been concern about delay in some proposed mapping mechanisms. Initial experiments suggest that when delay occurs, it is not highly significant. This issue is being pursued and cannot be resolved until more information is collected. LISP can support multicast. A draft is being prepared. Stability in the mapping system depends on which mapping mechanism is used. All of the ones currently being considered are inherently LISP Authors Expires September 11, 2008 [Page 10] Internet-Draft LISP Analysis March 2008 stable because only one source is recognized as authoritative for a particular EID prefix to RLOC mapping. LISP-ALT is inherently stable because information is only distributed from the destination site's ETRs or their representatives. In ALT, new prefix mappings can be added to the system without affecting stability because their announcement is quickly absorbed by aggregation. NERD [nerd] is stable because the flow of information is administrative and there is no reason for thrashing unless the sources are thrashing. 4.9. Routing Security "Currently, the routing subsystem is secured through a number of protocol specific mechanisms of varying strength and applicability. Any new architecture is required to provide at least the same level of security as is deployed as of when the new architecture is deployed." The current system of routers, and BGP, will continue to be used for routing of LISP-encapsulated packets. Therefore for routing and forwarding across the Internet core, the same security issues and practices apply as are used now. As in any Locator/identifier split approach, a critical operation is the creation of Locator to ID binding state that devices will use over time. In the case of LISP, the critical operation is the creation of EID prefix to RLOC mappings in the ITR and the ETR. These mappings can be obtained in three ways: o By using information obtained from a LISP data packet. o By using information contained in a Map-Reply message. o By using an EID prefix to RLOC mapping system. LISP mitigates attacks on the first two techniques by including a nonce in the LISP header. The nonce is a 32-bit randomly generated number (generated by the source ITR), and is used to test route returnability. More specifically, an ETR will echo the nonce back to the ITR in a Map-Reply message. The nonce, combined with the ITR accepting only solicited Map-Replies provides a base level of authentication for Map-Replies. Note that these techniques do not protect against Man-In-The-Middle attacks. The LISP design assumes that mapping systems will all employ the security mechanisms of the technologies they are built on. If a mapping system is used (the third technique above) the particular mapping system chosen will inherit the security characteristics of its technologies. LISP Authors Expires September 11, 2008 [Page 11] Internet-Draft LISP Analysis March 2008 As a mapping system, LISP-ALT shares many of the security characteristics of BGP. Its security mechanisms are comprised of existing technologies in wide operational use today. Securing LISP- ALT is much simpler than securing BGP. Compared to BGP, LISP-ALT routers are not topologically bound, allowing them to be put in locations away from the vulnerable AS border (unlike eBGP speakers). 4.10. Deployability "Since solutions that are not deployable are simply academic exercises, solutions are required to be deployable from a technical perspective. Furthermore, given the extensive deployed base of today's Internet, a solution is required to be incrementally." Deployability includes many things, from operational burden to ability to coexist with current and future deployments of other approaches. IPv4 will be with us for years. For IPv4, because of utilization and address size we have no choice but to use a map-and-encapsulate strategy. Address rewriting strategies are only viable for IPv6, and adopting them requires some kind of encapsulation or translation for IPv4. LISP has a strategy that works for both IPv4 and IPv6. LISP does not require changes within sites or in the Internet core. Changes are only required at xTRs and in the LISP mapping system. Network operators who have been polled have said they prefer changes at site edges more than changes in user systems. LISP can be incrementally deployed, and when doing SNAT according to the LISP interworking draft [interwk], prefixes can be withdrawn from the main BGP routing system right away during the early stages of LISP deployment. This can give core routing an immediate lessening of load while increasing capability -- one of the critical goals of this effort. LISP does not require new silicon to be deployed. xTR functionality can be deployed in software-based routers, and updated quickly. As needs are discovered they can be met right away. By using a map-and-encapsulate approach instead of header rewriting, you have complete visibility of EIDs as well as RLOCs. A rewrite scheme loses information that may be needed by ACLs in firewalls and other security processes. Compared to management of BGP, management of LISP is trivial. This has been experienced in actual deployments. LISP Authors Expires September 11, 2008 [Page 12] Internet-Draft LISP Analysis March 2008 LISP is the only approach whose documentation you can implement from, and thus truly test its viability. LISP Authors Expires September 11, 2008 [Page 13] Internet-Draft LISP Analysis March 2008 5. Routing Research Group Design Goals TBD LISP Authors Expires September 11, 2008 [Page 14] Internet-Draft LISP Analysis March 2008 6. Security Considerations See Section 4.9. LISP Authors Expires September 11, 2008 [Page 15] Internet-Draft LISP Analysis March 2008 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [alt] Fuller, V., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-01.txt (work in progress), November 2007. [interwk] Lewis, D., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt (work in progress), December 2007. [lisp] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp--06.txt (work in progress), February 2008. [nerd] Lear, E., "A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-03.txt (work in progress), January 2008. [rrg] Li, T., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01.txt (work in progress), July 2007. 7.2. Informative References [radir] Narten, T., "Routing and Addressing Problem Statement", draft-narten-radir-problem-statement-00.txt (work in progress), July 2007. LISP Authors Expires September 11, 2008 [Page 16] Internet-Draft LISP Analysis March 2008 Author's Address LISP Authors cisco Tasman Drive San Jose, CA 95134 USA Email: lisp-beta@external.cisco.com LISP Authors Expires September 11, 2008 [Page 17] Internet-Draft LISP Analysis March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. LISP Authors Expires September 11, 2008 [Page 18]