--- 1/draft-ietf-lisp-alt-06.txt 2011-06-30 23:15:45.000000000 +0200 +++ 2/draft-ietf-lisp-alt-07.txt 2011-06-30 23:15:45.000000000 +0200 @@ -1,124 +1,128 @@ Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental D. Meyer -Expires: September 5, 2011 D. Lewis +Expires: January 1, 2012 D. Lewis Cisco - March 4, 2011 + June 30, 2011 LISP Alternative Topology (LISP+ALT) - draft-ietf-lisp-alt-06.txt + draft-ietf-lisp-alt-07.txt Abstract - This document describes a simple mapping database to be used by the - Locator/ID Separation Protocol (LISP) to find Endpoint Identifier - (EID) to Routing Locator (RLOC) mappings. Termed the Alternative - Logical Topology (ALT), the database is built as an overlay network - on the public Internet using the Border Gateway Protocol (BGP) and - the Generic Routing Encapsulation (GRE). Using these proven - protocols, the ALT can be built and deployed relatively quickly - without major changes to the existing routing infrastructure. + This document describes a simple distributed index system to be used + by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router + (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) + which holds the mapping information for a particular Endpoint + Identifier (EID). The MR can then query that ETR to obtain the + actual mapping information, which consists of a list of Routing + Locators (RLOCs) for the EID. Termed the Alternative Logical + Topology (ALT), the index is built as an overlay network on the + public Internet using the Border Gateway Protocol (BGP) and the + Generic Routing Encapsulation (GRE). Using these proven protocols, + the ALT can be built and deployed relatively quickly without any + changes to the existing routing infrastructure. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 5, 2011. + This Internet-Draft will expire on January 1, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 - 3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 9 - 3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 9 - 3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 9 - 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9 - 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 10 - 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 12 - 4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 12 - 4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 14 - 5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 15 - 5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 15 - 5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 15 - 6. BGP configuration and protocol considerations . . . . . . . . 17 - 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 17 - 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 17 - 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 18 - 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 18 - 7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 18 - 7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 19 - 7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 19 - 8. Connecting sites to the ALT network . . . . . . . . . . . . . 21 - 8.1. ETRs originating information into the ALT . . . . . . . . 21 - 8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 21 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 24 - 10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 25 - 10.3. Use of new IETF standard BGP Security mechanisms . . . . . 25 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 + 3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 9 + 3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 10 + 3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10 + 3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10 + 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10 + 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11 + 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13 + 4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13 + 4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15 + 5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16 + 5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16 + 5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 16 + 6. BGP configuration and protocol considerations . . . . . . . . 18 + 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18 + 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 18 + 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 19 + 7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 19 + 7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 20 + 7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 20 + 8. Connecting sites to the ALT network . . . . . . . . . . . . . 22 + 8.1. ETRs originating information into the ALT . . . . . . . . 22 + 8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 22 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 25 + 10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 26 + 10.3. Use of new IETF standard BGP Security mechanisms . . . . . 26 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction - This document describes the LISP+ALT mapping database, to be used by - LISP to find EID-to-RLOC mappings. The ALT network is built using - the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol - extension [RFC4760], and the Generic Routing Encapsulation (GRE, - [RFC2784]) to construct an overlay network of devices (ALT Routers) - which operate on EID-prefixes and use EIDs as forwarding - destinations. + This document describes the LISP+ALT system, used by a [LISP] ITR or + MR to find the ETR that holds the RLOC mapping information for a + particular EID. The ALT network is built using the Border Gateway + Protocol (BGP, [RFC4271]), the BGP multi-protocol extension + [RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to + construct an overlay network of devices (ALT Routers) which operate + on EID-prefixes and use EIDs as forwarding destinations. ALT Routers advertise hierarchically-delegated segments of the EID namespace (i.e., prefixes) toward the rest of the ALT; they also forward traffic destined for an EID covered by one of those prefixes toward the network element that is authoritative for that EID and is the origin of the BGP advertisement for that EID-prefix. An Ingress - Tunnel Router (ITR) uses this overlay to send a LISP Map-Request (see - [LISP]) to the Egress Tunnel Router (ETR) that holds the EID-to-RLOC - mapping for a matching EID-prefix. In most cases, an ITR does not - connect directly to the overlay network but instead sends Map- - Requests via a Map-Resolver (MR; see [LISP-MS]) which does. + Tunnel Router (ITR) uses this overlay to send a LISP Map-Request + (defined in [LISP]) to the Egress Tunnel Router (ETR) that holds the + EID-to-RLOC mapping for a matching EID-prefix. In most cases, an ITR + does not connect directly to the overlay network but instead sends + Map-Requests via a Map-Resolver (described in [LISP-MS]) which does. Likewise, in most cases, an ETR does not connect directly to the overlay network but instead registers its EID-prefixes with a Map- Server that advertises those EID-prefixes on to the ALT and forwards Map-Requests for them to the ETR. It is important to note that the ALT does not distribute actual EID- to-RLOC mappings. What it does provide is a forwarding path from an ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which holds that mapping. The ITR/MR uses this path to send an ALT Datagram (see Section 3) to an ETR which then responds with a Map- @@ -130,35 +134,33 @@ and GRE); little, if any, LISP-specific modifications should be needed for such devices to be deployed on the ALT. Note, though, that organizational and operational considerations suggest that ALT Routers be both logically and physically separate from the "native" Internet packet transport system; deploying this overlay on those routers which are already participating in the global routing system and actively forwarding Internet traffic is not recommended. The remainder of this document is organized as follows: Section 2 provides the definitions of terms used in this document. Section 3 - outlines the basic LISP 1.5 model. Section 4 provides a basic - overview of the LISP Alternate Topology architecture, and Section 5 - describes how the ALT uses BGP to propagate Endpoint Identifier - reachability over the overlay network and Section 6 describes other - considerations for using BGP on the ALT. Section 7 describes the - construction of the ALT aggregation hierarchy, and Section 8 - discusses how LISP+ALT elements are connected to form the overlay - network. + outlines the LISP ALT model, where EID prefixes are routed across an + overlay network. Section 4 provides a basic overview of the LISP + Alternate Topology architecture, and Section 5 describes how the ALT + uses BGP to propagate Endpoint Identifier reachability over the + overlay network and Section 6 describes other considerations for + using BGP on the ALT. Section 7 describes the construction of the + ALT aggregation hierarchy, and Section 8 discusses how LISP+ALT + elements are connected to form the overlay network. 2. Definition of Terms - LISP+ALT operates on two name spaces and introduces a new network - element, the LISP+ALT Router (see below). This section provides - high-level definitions of the LISP+ALT name spaces, network elements, - and message types. + This section provides high-level definitions of LISP concepts and + components involved with and affected by LISP+ALT. Alternative Logical Topology (ALT): The virtual overlay network made up of tunnels between LISP+ALT Routers. The Border Gateway Protocol (BGP) runs between ALT Routers and is used to carry reachability information for EID-prefixes. The ALT provides a way to forward Map-Requests (and, if supported, Data Probes) toward the ETR that "owns" an EID-prefix. As a tunneled overlay, its performance is expected to be quite limited so use of it to forward high-bandwidth flows of Data Probes is strongly discouraged (see Section 3.3 for additional discussion). @@ -260,41 +262,41 @@ 3. The LISP+ALT model The LISP+ALT model uses the same basic query/response protocol that is documented in [LISP]. In particular, LISP+ALT provides two types of packet that an ITR can originate to obtain EID-to-RLOC mappings: Map-Request: A Map-Request message is sent into the ALT to request an EID-to-RLOC mapping. The ETR which owns the mapping will respond to the ITR with a Map-Reply message. Since the ALT only forwards on EID destinations, the destination address of the Map- - Request sent on the ALT must be an EID. See [LISP] for the format - of Map-Request and Map-Reply packets. + Request sent on the ALT must be an EID. Data Probe: Alternatively, an ITR may encapsulate and send the first data packet destined for an EID with no known RLOCs into the ALT as a Data Probe. This might be done minimize packet loss and to probe for the mapping. As above, the authoritative ETR for the EID-prefix will respond to the ITR with a Map-Reply message when it receives the data packet over the ALT. As a side-effect, the encapsulated data packet is delivered to the end-system at the ETR site. Note that the Data Probe's inner IP destination address, which is an EID, is copied to the outer IP destination address so that the resulting packet can be routed over the ALT. See Section 3.3 for caveats on the usability of Data Probes. The term "ALT Datagram" is short-hand for a Map-Request or Data Probe - to be sent into or forwarded on the ALT. Note that while the outer - header Source Address of an ALT Datagram is currently expected to be - an RLOC, there may be situations (e.g. for experimentation with - caching in intermediate ALT nodes) where an EID would be used to - force a Map-Reply to be routed back through the ALT. + to be sent into or forwarded on the ALT. Note that such packets use + an RLOC as the outer header source IP address and an EID as the outer + header destination IP address. + + Detailed descriptions of the LISP packet types referenced by this + document may be found in [LISP]. 3.1. Routeability of EIDs A LISP EID has the same syntax as IP address and can be used, unaltered, as the source or destination of an IP datagram. In general, though, EIDs are not routable on the public Internet; LISP+ ALT provides a separate, virtual network, known as the LISP Alternative Logical Topology (ALT) on which a datagram using an EID as an IP destination address may be transmitted. This network is built as an overlay on the public Internet using tunnels to @@ -698,28 +700,25 @@ owns it, it is possible to perform site-to-site traffic engineering by setting the preference and/or weight fields, and by including more-specific EID-to-RLOC information in Map-Reply messages. This is a powerful mechanism that can conceivably replace the traditional practice of routing prefix deaggregation for traffic engineering purposes. Rather than propagating more-specific information into the global routing system for local- or regional- optimization of traffic flows, such more-specific information can be exchanged, through LISP (not LISP+ALT), on an as-needed basis between - only those ITRs/ETRs (and, thus, site pairs) that need it. Should a - receiving ITR decide that it does not wish to store such more- - specific information, it has the option of discarding it as long as a - shorter, covering EID-prefix exists. Such an exchange of "more- - specifics" between sites facilitates traffic engineering, by allowing - richer and more fine-grained policies to be applied without - advertising additional prefixes into either the ALT or the global - routing system. + only those ITRs/ETRs (and, thus, site pairs) that need it. Such an + exchange of "more-specifics" between sites facilitates traffic + engineering, by allowing richer and more fine-grained policies to be + applied without advertising additional prefixes into either the ALT + or the global routing system. Note that these new traffic engineering capabilities are an attribute of LISP and are not specific to LISP+ALT; discussion is included here because the BGP-based global routing system has traditionally used propagation of more-specific routes as a crude form of traffic engineering. 7.3. Edge aggregation and dampening Normal BGP best common practices apply to the ALT network. In @@ -782,21 +781,21 @@ placement of aggregation boundaries. 4. EID prefix portability between competing operators of the ALT infrastructure. A significant benefit for an end-site to adopt LISP is the availability of EID space that is not tied to a specific connectivity provider; it is important to ensure that an end site doesn't trade lock-in to a connectivity provider for lock-in to a provider of its EID assignment, ALT connectivity, or Map Server facilities. - This is, by no means, and exhaustive list. + This is, by no means, an exhaustive list. While resolving these issues is beyond the scope of this document, the authors recommend that existing distributed resource structures, such as the IANA/Regional Internet Registries and the ICANN/Domain Registrar, be carefully considered when designing and deploying the ALT infrastructure. 8. Connecting sites to the ALT network 8.1. ETRs originating information into the ALT @@ -971,24 +970,24 @@ to provide invaluable insight as the LISP effort has evolved. Others who have provided valuable contributions include John Zwiebel, Hannu Flinck, Amit Jain, John Scudder, and Scott Brim. 12. References 12.1. Normative References [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-10.txt (work in progress), March 2011. + draft-ietf-lisp-14.txt (work in progress), June 2011. [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", - draft-ietf-lisp-ms-07.txt (work in progress), March 2011. + draft-ietf-lisp-ms-09.txt (work in progress), May 2011. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation