--- 1/draft-ietf-lisp-alt-08.txt 2011-09-20 07:14:21.486133024 +0200 +++ 2/draft-ietf-lisp-alt-09.txt 2011-09-20 07:14:21.530132617 +0200 @@ -1,20 +1,20 @@ Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental D. Meyer -Expires: March 11, 2012 D. Lewis +Expires: March 23, 2012 D. Lewis Cisco - September 8, 2011 + September 20, 2011 LISP Alternative Topology (LISP+ALT) - draft-ietf-lisp-alt-08.txt + draft-ietf-lisp-alt-09.txt Abstract 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 @@ -32,21 +32,21 @@ 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 March 11, 2012. + This Internet-Draft will expire on March 23, 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 @@ -67,41 +67,42 @@ 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 . . . . . . . . . . 17 - 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 + 5.3. ALT Datagram forwarding falure . . . . . . . . . . . . . . 17 + 6. BGP configuration and protocol considerations . . . . . . . . 19 + 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19 + 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 19 + 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 20 + 7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 20 + 7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 21 + 7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 21 + 8. Connecting sites to the ALT network . . . . . . . . . . . . . 23 + 8.1. ETRs originating information into the ALT . . . . . . . . 23 + 8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 23 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 26 + 10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 27 + 10.3. Use of new IETF standard BGP Security mechanisms . . . . . 27 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction 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. @@ -446,21 +447,21 @@ In summary, LISP+ALT uses BGP to build paths through ALT Routers so that an ALT Datagram sent into the ALT can be forwarded to the ETR that holds the EID-to-RLOC mapping for that EID-prefix. This reachability is carried as IPv4 or ipv6 NLRI without modification (since an EID-prefix has the same syntax as IPv4 or ipv6 address prefix). ALT Routers establish BGP sessions with one another, forming the ALT. An ALT Router at the "edge" of the topology learns EID-prefixes originated by authoritative ETRs. Learning may be though the Map Server interface, by static configuration, or via BGP with the ETRs. An ALT Router may also be configured to aggregate - EID-prefixes received from ETRs or from other LISP+ALT routers that + EID-prefixes received from ETRs or from other LISP+ALT Routers that are topologically "downstream" from it. 4.1. ITR traffic handling When an ITR receives a packet originated by an end system within its site (i.e. a host for which the ITR is the exit path out of the site) and the destination EID for that packet is not known in the ITR's mapping cache, the ITR creates either a Map-Request for the destination EID or the original packet encapsulated as a Data Probe (see Section 3.3 for caveats on the usability of Data Probes). The @@ -593,21 +594,21 @@ the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned from the original Map-Request. See sections 6.1.2 and 6.2 of [LISP] for more information on the use of the Map-Request ITR RLOC field. Keep in mind that the ITR RLOC field supports mulitple RLOCs in multiple address families, so a Map-Reply sent in response to a Map- Request is not necessarily sent to back to the Map-Request RLOC source. There may be scenarios, perhaps to encourage caching of EID-to-RLOC mappings by ALT Routers, where Map-Replies could be sent over the ALT - or where a "first-hop" ALT router might modify the originating RLOC + or where a "first-hop" ALT Router might modify the originating RLOC on a Map-Request received from an ITR to force the Map-Reply to be returned to the "first-hop" ALT Router. These cases will not be supported by initial LISP+ALT implementations but may be subject to future experimentation. ALT Routers propagate path information via BGP ([RFC4271]) that is used by ITRs to send ALT Datagrams toward the appropriate ETR for each EID-prefix. BGP is run on the inter-ALT Router links, and possibly between an edge ("last hop") ALT Router and an ETR or between an edge ("first hop") ALT Router and an ITR. The ALT BGP RIB @@ -642,20 +643,55 @@ As documented in [LISP], when an ETR generates a Map-Reply message to return to a querying ITR, it sets the outer header IP destination address to one of the requesting ITR's RLOCs so that the Map-Reply will be sent on the underlying Internet topology, not on the ALT; this avoids any latency penalty (or "stretch") that might be incurred by sending the Map-Reply via the ALT, reduces load on the ALT, and ensures that the Map-Reply can be routed even if the original ITR does not have an ALT-routed EID. For details on how an ETR selects which ITR RLOC to use, see section 6.1.5 of [LISP]. +5.3. ALT Datagram forwarding falure + + Intermediate ALT Routers, forward ALT Datagrams using normal, hop-by- + hop routing on the ALT overlay network. Should an ALT router not be + able to forward an ALT Datagram, whether due to an unreachable next- + hop, TTL exceeded, or other problem, it has several choices: + + o If the ALT Router understands the LISP protocol, as is the case + for a Map Resolver or Map Server, it may respond to a forwarding + failure by returning a negative Map-Reply, as described in + Section 4.2 and [LISP-MS]. + + o If the ALT Router does not understand LISP, it may attempt to + return an ICMP message to the source IP address of the packet that + cannot be forwarded. Since the source address is an RLOC, an ALT + Router would send this ICMP message using "native" Internet + connectivity, not via the ALT overlay. + + o A non-LISP-capable ALT Router may also choose to silently drop the + non-forwardable ALT Datagram. + + [LISP] and [LISP-MS] define how the source of an ALT Datagram should + handle each of these cases. The last case, where an ALT Datagram is + silently discarded, will generally result in several retransmissions + by the source, followed by treating the destination as unreachable + via LISP when no Map-Reply is received. If a problem on the ALT is + severe enough to prevent ALT Datagrams from being delivered to a + specific EID, this is probably the only sensible way to handle this + case. + + Note that the use of GRE tunnels should prevent MTU problems from + ever occurring on the ALT; an ALT Datagram that exceeds an + intermediate MTU will be fragmented at that point and will be + reassembled by the target of the GRE tunnel. + 6. BGP configuration and protocol considerations 6.1. Autonomous System Numbers (ASNs) in LISP+ALT The primary use of BGP today is to define the global Internet routing topology in terms of its participants, known as Autonomous Systems. LISP+ALT specifies the use of BGP to create a global overlay network (the ALT) for finding EID-to-RLOC mappings. While related to the global routing database, the ALT serves a very different purpose and is organized into a very different hierarchy. Because LISP+ALT does @@ -994,32 +1030,33 @@ deployed, LISP+ALT can readily use these mechanisms to provide authentication of EID-prefix origination and EID-to-RLOC mappings. 11. Acknowledgments The authors would like to specially thank J. Noel Chiappa who was a key contributer to the design of the LISP-CONS mapping database (many ideas from which made their way into LISP+ALT) and who has continued 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. + Flinck, Amit Jain, John Scudder, Scott Brim, and Jari Arkko. 12. References 12.1. Normative References [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15.txt (work in progress), July 2011. [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", - draft-ietf-lisp-ms-11.txt (work in progress), August 2011. + draft-ietf-lisp-ms-12.txt (work in progress), + September 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