--- 1/draft-ietf-lisp-alt-09.txt 2011-12-06 22:13:51.730670637 +0100 +++ 2/draft-ietf-lisp-alt-10.txt 2011-12-06 22:13:51.782699415 +0100 @@ -1,52 +1,50 @@ Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental D. Meyer -Expires: March 23, 2012 D. Lewis +Expires: June 8, 2012 D. Lewis Cisco - September 20, 2011 + December 6, 2011 LISP Alternative Topology (LISP+ALT) - draft-ietf-lisp-alt-09.txt + draft-ietf-lisp-alt-10.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 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. + Generic Routing Encapsulation (GRE). 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 March 23, 2012. + This Internet-Draft will expire on June 8, 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 @@ -62,21 +60,21 @@ 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.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 14 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 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 @@ -185,23 +184,20 @@ 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). - Legacy Internet: The portion of the Internet which does not run - LISP and does not participate in LISP+ALT. - ALT Router: The devices which run on the ALT. The ALT is a static network built using tunnels between ALT Routers. These routers are deployed in a roughly-hierarchical mesh in which routers at each level in the topology are responsible for aggregating EID- prefixes learned from those logically "below" them and advertising summary prefixes to those logically "above" them. Prefix learning and propagation between ALT Routers is done using BGP. An ALT Router at the lowest level, or "edge" of the ALT, learns EID- prefixes from its "client" ETRs. See Section 3.1 for a description of how EID-prefixes are learned at the "edge" of the @@ -267,27 +263,27 @@ EID-to-RLOC Mapping: A binding between an EID-prefix and the set of RLOCs that can be used to reach it; sometimes referred to simply as a "mapping". EID-prefix Reachability: An EID-prefix is said to be "reachable" if at least one of its locators is reachable. That is, an EID-prefix is reachable if the ETR that is authoritative for a given EID-to- RLOC mapping is reachable. Default Mapping: A Default Mapping is a mapping entry for EID- - prefix 0.0.0.0/0 (0::/0 for ipv6). It maps to a locator-set used + prefix 0.0.0.0/0 (::/0 for ipv6). It maps to a locator-set used for all EIDs in the Internet. If there is a more specific EID- prefix in the mapping cache it overrides the Default Mapping entry. The Default Mapping can be learned by configuration or from a Map-Reply message. - ALT Default Route: An EID-prefix value of 0.0.0.0/0 (or 0::/0 for + ALT Default Route: An EID-prefix value of 0.0.0.0/0 (or ::/0 for ipv6) which may be learned from the ALT or statically configured on an edge ALT Router. The ALT-Default Route defines a forwarding path for a packet to be sent into the ALT on a router which does not have a full ALT forwarding database. 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: @@ -413,25 +409,28 @@ The basic idea embodied in LISP+ALT is to use BGP, running on a tunneled overlay network (the ALT), to establish reachability between ALT Routers. The ALT BGP Route Information Base (RIB) is comprised of EID-prefixes and associated next hops. ALT Routers interconnect using BGP and propagate EID-prefix updates among themselves. EID- prefix information is learned from ETRs at the "edge" of the ALT either through the use of the Map Server interface (the commmon case), static configuration, or by BGP-speaking ETRs. - An ITR uses the ALT to learn the best path for forwarding an ALT - Datagram destined to a particular EID-prefix. An ITR will normally - use a Map Resolver to send its ALT Datagrams on to the ALT but may, - in unusual circumstances, use a static ALT Default Route or connect - to the ALT using BGP. + Map Resolvers learns paths through the ALT to Map Servers for EID- + prefixes. An ITR will normally use a Map Resolver to send its ALT + Datagrams on to the ALT but may, in unusual cases (see + Section 3.1.2), use a static ALT Default Route or connect to the ALT + using BGP. Likewise, an ETR will normally register its prefixes in + the mapping database using a Map Server can sometimes (see + Section 3.1.1) connect directly to the ALT using BGP. See [LISP-MS] + for details on Map Servers and Map Resolvers. Note that while this document specifies the use of Generic Routing Encapsulation (GRE) as a tunneling mechanism, there is no reason that parts of the ALT cannot be built using other tunneling technologies, particularly in cases where GRE does not meet security, management, or other operational requirements. References to "GRE tunnel" in later sections of this document should therefore not be taken as prohibiting or precluding the use of other tunneling mechanisms. Note also that two ALT Routers that are directly adjacent (with no layer-3 router hops between them) need not use a tunnel between them; @@ -489,28 +488,29 @@ Traffic routed on to the ALT consists solely of ALT Datagrams, i.e. Map-Requests and Data Probes (if supported). Given the relatively low performance expected of a tunneled topology, ALT Routers (and Map Resolvers) should aggressively rate-limit the ingress of ALT Datagrams from ITRs and, if possible, should be configured to not accept packets that are not ALT Datagrams. 4.2. EID Assignment - Hierarchy and Topology - EID-prefixes are expected to be allocated to a LISP site by Internet - Registries. Where a site has multiple allocations which are aligned - on a power-of-2 block boundary, they should be aggregated into a - single EID-prefix for advertisement. The ALT network is built in a - roughly hierarchical, partial mesh which is intended to allow - aggregation where clearly-defined hierarchical boundaries exist. - Building such a structure should minimize the number of EID-prefixes - carried by LISP+ALT nodes near the top of the hierarchy. + The ALT database is organized in a herarchical manner with EID- + prefixs aggregated on power-of-2 block boundaries. Where a LISP site + has multiple EID-prefixes that are aligned on apower-of-2 block + boundary, they should be aggregated into a single EID-prefix for + advertisement. The ALT network is built in a roughly hierarchical, + partial mesh which is intended to allow aggregation where clearly- + defined hierarchical boundaries exist. Building such a structure + should minimize the number of EID-prefixes carried by LISP+ALT nodes + near the top of the hierarchy. Routes on the ALT do not need to respond to changes in policy, subscription, or underlying physical connectivity, so the topology can remain relatively static and aggregation can be sustained. Because routing on the ALT uses BGP, the same rules apply for generating aggregates; in particular, a ALT Router should only be configured to generate an aggregate if it is configured with BGP sessions to all of the originators of components (more-specific prefixes) of that aggregate. Not all of the components of need to be present for the aggregate to be originated (some may be holes in the @@ -812,23 +812,23 @@ There are major open questions regarding how the ALT will be deployed and what organization(s) will operate it. In a simple, non- distributed world, centralized administration of EID prefix assignment and ALT network design would facilitate a well- aggregated ALT routing system. Business and other realities will likely result in a more complex, distributed system involving multiple levels of prefix delegation, multiple operators of parts of the ALT infrastructure, and a combination of competition and cooperation among the participants. In addition, re-use of existing IP address - assignments, both "PI" and "PA", to avoid renumbering when sites - transition to LISP will further complicate the processes of building - and operating the ALT. + assignments, both provider-independent ("PI") and provider-assigned + ("PA"), to avoid renumbering when sites transition to LISP will + further complicate the processes of building and operating the ALT. A number of conflicting considerations need to be kept in mind when designing and building the ALT. Among them are: 1. Target ALT routing state size and level of aggregation. As described in Section 7.1, the ALT should not suffer from some of the performance constraints or stability issues as the Internet global routing system, so some reasonable level of deaggregation and increased number of EID prefixes beyond what might be considered ideal should be acceptable. That said, measures, such @@ -953,23 +953,23 @@ security mechanisms are comprised of existing technologies in wide operational use today, so securing the ALT should be mostly a matter of applying the same technology that is used to secure the BGP-based global routing system (see Section 10.3 below). 10.1. Apparent LISP+ALT Vulnerabilities This section briefly lists the known potential vulnerabilities of LISP+ALT. - Mapping Integrity: Can an attacker insert bogus mappings to black- - hole (create Denial-of-Service, or DoS attack) or intercept LISP - data-plane packets? + Mapping Integrity: Potential for an attacker to insert bogus + mappings to black-hole (create Denial-of-Service, or DoS attack) + or intercept LISP data-plane packets. ALT Router Availability: Can an attacker DoS the ALT Routers connected to a given ETR? If a site's ETR cannot advertise its EID-to-RLOC mappings, the site is essentially unavailable. ITR Mapping/Resources: Can an attacker force an ITR or ALT Router to drop legitimate mapping requests by flooding it with random destinations for which it will generate large numbers of Map- Requests and fill its mapping cache? Further study is required to see the impact of admission control on the overlay network. @@ -988,53 +988,54 @@ prepared to rate-limit traffic (ALT Datagrams) that could be received across the ALT. UDP Map-Reply from ETR: Since Map-Replies are sent directly from the ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various types of DoS attacks (this is a general property of LISP, not an LISP+ALT vulnerability). More-specific prefix leakage: Because EID-prefixes on the ALT are expected to be fairly well-aggregated and EID-prefixes propagated - out to the global Internet (see [LISP-IW] much more so, accidental - leaking or malicious advertisement of an EID-prefix into the - global routing system could cause traffic redirection away from a - LISP site. This is not really a new problem, though, and its - solution can only be achieved by much more strict prefix filtering - and authentication on the global routing system. + out to the global Internet (see [LISP-IW]) much more so, + accidental leaking or malicious advertisement of an EID-prefix + into the global routing system could cause traffic redirection + away from a LISP site. This is not really a new problem, though, + and its solution can only be achieved by much more strict prefix + filtering and authentication on the global routing system. + Section Section 10.3 describes an existingapproach to solving this + problem. 10.2. Survey of LISP+ALT Security Mechanisms Explicit peering: The devices themselves can both prioritize incoming packets, as well as potentially do key checks in hardware to protect the control plane. Use of TCP to connect elements: This makes it difficult for third parties to inject packets. - Use of HMAC Protected BGP/TCP Connections: HMAC is used to verify - message integrity and authenticity, making it nearly impossible - for third party devices to either insert or modify messages. + Use of HMAC to protect BGP/TCP connections: HMAC [RFC5925] is used + to verify the integrity and authenticity of TCP connections used + to exchange BGP messages, making it nearly impossible for third + party devices to either insert or modify messages. - Message Sequence Numbers and Nonce Values in Messages: This allows + Message sequence numbers and nonce values in messages: This allows an ITR to verify that the Map-Reply from an ETR is in response to a Map-Request originated by that ITR (this is a general property of LISP; LISP+ALT does not change this behavior). 10.3. Use of new IETF standard BGP Security mechanisms - LISP+ALT's use of BGP allows the ALT to take advantage of BGP - security features designed for existing Internet BGP use. Should the - Internet community converge on the work currently being done in the - IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr] - or soBGP [I-D.white-sobgparchitecture] be implemented and widely- - deployed, LISP+ALT can readily use these mechanisms to provide + LISP+ALT's use of BGP allows it to take advantage of BGP security + features designed for existing Internet BGP use. This means that + LISP+ALT can and should use technology developed for adding security + to BGP (in the IETF SIDR working group or elsewhere) 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, Scott Brim, and Jari Arkko. @@ -1042,55 +1043,47 @@ 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-12.txt (work in progress), - September 2011. + October 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 Plan", BCP 122, RFC 4632, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 12.2. Informative References - [I-D.murphy-bgp-secr] - Murphy, S., "BGP Security Analysis", - draft-murphy-bgp-secr-04 (work in progress), - November 2001. - - [I-D.white-sobgparchitecture] - White, R., "Architecture and Deployment Considerations for - Secure Origin BGP (soBGP)", - draft-white-sobgparchitecture-00 (work in progress), - May 2004. - [LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and ipv6", draft-ietf-lisp-interworking-02.txt (work in progress), March 2011. + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, June 2010. + Authors' Addresses Vince Fuller Cisco Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com