sidr B. Dickson Internet-Draft Brian Dickson Expires: April 26, 2013 October 23, 2012 Route Leaks -- Definitions draft-dickson-sidr-route-leak-def-03 Abstract The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Routes may be announced to neighbors, contrary to the receiver's local peering policy. If that occurs, those routes may then be propagated indiscriminantly, once they have been accepted. This document considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios. The purpose of these definitions is to facilitate analysis of what a route leak is, and what the scope of the problem space for route leaks is. This, in turn, is intended to inform a requirements document for detection of (and prevention of) route leaks. And finally, the definitions and requirements are intended to allow proposed solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The ultimate goal is to "solve the route leaks problem". Author's Note Intended Status: Informational. 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 Dickson Expires April 26, 2013 [Page 1]
Internet-Draft Route Leak Definitions October 2012 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 April 26, 2013. Copyright Notice Copyright (c) 2012 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. Dickson Expires April 26, 2013 [Page 2]
Internet-Draft Route Leak Definitions October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope Limitations . . . . . . . . . . . . . . . . . . . . . . 5 3. Route Leak Definitions . . . . . . . . . . . . . . . . . . . . 6 4. Peer Links and Routes . . . . . . . . . . . . . . . . . . . . 7 5. Customer Links and Routes . . . . . . . . . . . . . . . . . . 7 5.1. Customer's Customer . . . . . . . . . . . . . . . . . . . 7 6. Non-Leak-Initiation Links . . . . . . . . . . . . . . . . . . 8 7. Route Leak Initiation . . . . . . . . . . . . . . . . . . . . 8 8. Route Leak . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Dickson Expires April 26, 2013 [Page 3]
Internet-Draft Route Leak Definitions October 2012 1. Introduction 1.1. Assumptions Much of this document assumes the observer has total knowledge of the state of everything in the hypothetical examples presented. It is understood that participants in the real world routing scenarios will not have that knowledge. The purpose of presuming that total knowledge here, is to illustrate how little is needed to identify leaked routes. In particular, it is hoped that this leads to a correspondingly simple set of definitions with useful real-world meaning. 1.2. Rationale Generally speaking, a route-leak occurs when a route goes somewhere it should not. In other words, that somewhere along the path, a route was sent that somehow violated the implicit or explicit policy between two neighbors, without being blocked by the recipient. Route leaks cause harm, in a variety of ways. They expose traffic to Man- In-The-Middle (MITM) attacks. They may result in traffic congestion, latency, or even black-holing of traffic. It is a leak if any receiver in the propogation path did not want the route, from a generic policy perspective. It does not matter which party caused the situation - a leaks are in the eye of the receivers. By their nature - unintentional, unwanted, and harmful - route leaks are bad. By first establishing a more precise definition of route leak, the intent is to find requirements for mechanisms for stopping route leaks, and then finding solutions that meet those requirements. 1.3. Requirements 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]. 1.4. Terminology The reader is assumed to be familiar with BGP version 4, both from a protocol perspective and from an operational perspective. BGP4 is defined in [RFC1771], and updated or enhanced by a variety of other RFCs. Dickson Expires April 26, 2013 [Page 4]
Internet-Draft Route Leak Definitions October 2012 The following additional terminology is used throughout this document: Route (or synonomously, prefix): an NLRI in BGP, including all its attributes. (This term subject to change by GROW.) Neighbor (or "peer", not capitalized): A toplogically adjacent Autonomous System, with whom routes are exchanged. Link: A BGP connection to a Neighbor. A Neighbor may be reached via one or more links, where each link may have a different classification, and/or local policy. Link Classification: The "intent" of a given BGP peering session, which addresses only the categories of route announced and accepted, and which is further modified by Local Policy. Local Policy: The set of rules, as applied on a single Neighbor Link, specifying which routes are announced, which routes are accepted, and what attributes are changed to affect choice of BGP Best Path per prefix. Path: Also known as AS_PATH (or optionally AS4_PATH), the sequence of ASNs through which a route has passed from Originator to recipient. Hijacked Route: A route which has been originated by a party other than the owner of the prefix. This could be via a forged ASN, or from another ASN. Validated Origination: a route whose origination has been validated, e.g. via cryptographic means, such as using an ROA. 2. Scope Limitations The following issues are not in the scope of route leaks. Each item in the list includes the rationale for excluding it. o Hijacked Routes - Origin Validation (proposed work in the SIDR WG) addresses the issue of Hijacked Routes. By limiting Route Leak efforts to Validated Routes, we are able to presume the origin is correct, and narrow the scope. o Violations of Local Policy - issues between adjacent ASNs which do not propogate any further, or which do not violate the Link Classification. o Other-ASN Relationship - The "correctness" of a given prefix received over a Link, is determined only by the Link Classifications of each Link in the Path. The existence of other Links, to Neighbors with ASNs on a given Path (which may have Dickson Expires April 26, 2013 [Page 5]
Internet-Draft Route Leak Definitions October 2012 differing Link Classifications), is a classic "apples to oranges" comparision. It is incorrect to compare ASNs outside the context of the AS path, so we exclude those comparisons from this work. Essentially, the only elements being considered are the Path, and Link Classifications at each hop in the Path. 3. Route Leak Definitions Route Leak Initiation: A Route announced over a Link by a Neighbor, which does not match the Link Classification, where one of the following is true: o the Neighbor is the Originator o the Neighbor received the Route, where the received Route was not a Route Leak In lay terms, this means that the Neighbor is the party that caused the route leak, by announcing a route contrary to the Link Classification (and consequently also violated the Local Policy). Route Leak Propagation: A Route announced over a Link by a Neighbor, where the Route that the Neighbor received was either a Route Leak Initiation, or a Route Leak Propagation. Once a Route has become a Route Leak Initiation, any further announcement of that Route is a Route Leak Propagation. NB: A Route Leak Propagation may appear to match the Link Classification, since the Path appears similar to non-leaked routes for the first two ASNs in the Path. Link Classifications: a Link may be classified as: o Customer o Transit o Peer o Special (which includes Mutual Transit, Sibling, and other non- trivial arrangements) Special (e.g. Mutual Transit): a Link where the two parties agree to provide full routes, and to advertise each others' customers routes the same as they would advertise their own customers' routes. Semantically, this behaves the same as having two parallel Links between the same two Neighbors, where one Link Policy is Transit and the other Link Policy is Customer. Recall, Link Classification is the superset of Local Policy - the term "full routes" here means simply that any route in addition to customers' routes, is permitted. Dickson Expires April 26, 2013 [Page 6]
Internet-Draft Route Leak Definitions October 2012 4. Peer Links and Routes A Peer Classification is a Link over which the two parties send ONLY their respective Customer Routes (and their Customer's Routes, and so on). A Link which is classified as a Peer, will see us as a Peer Classification as well. The relationship is symmetric in nature. 5. Customer Links and Routes A Customer Link Classification: The Customer sends us only their own (locally originated) Routes, and the Customer's Customer's Routes (and Customer^Nth Routes). The Customer relationship is transitive. A Transit Link Classification: The Transit provider sends all Routes. This include the Transit Provider's Customers, the Transit Provider's Peers, and if there are any, the Transit Provider's Transit Provider's Routes. The Transit Provider relationship is also transitive. Transit and Customer are the opposite ends of the same Link, by definition. The Transit Link Classification is a superset of the actual Local Policy of a specific Customer. This means that while a Transit Link Classification means "we send all routes", the actual Local Policy for a specific Customer might differ, and the Customer might only receive some Routes, or none at all. Similarly, the Classification means that we are prepared to accept the Customer's own Routes, as well as those of the Customer's Customers. However, the Local Policy might be to accept only a specific subset of the Customer's Routes. 5.1. Customer's Customer It is important to define when a Route is a Customer's Customer Route. A Customer's Customer Route: the Path to be from the Customer's Customer, to the Customer, to us. Similarly, Customer^Nth Paths must proceed directly from Customer^N to Customer^(N-1) to Customer to us. It is not sufficient for the Origin of the Route to be the ASN of a Customer's Customer. Each Link must be a Customer Classification (or Special, e.g. Mutual Transit, which is a superset of Customer). In particular, if the Path were to include any Link which were not a Dickson Expires April 26, 2013 [Page 7]
Internet-Draft Route Leak Definitions October 2012 Customer Link, the Route would NOT be a Customer^N. NB: It is sufficient that the Customer's Customer relationship is declared. The "Customer" relationship, in the context of route leaks, is restrictive. Erroneous or inadvertent classification as Customer cannot result in a route leak. 6. Non-Leak-Initiation Links To help identify the exact conditions where a Route Leak Initiation can occur, it is helpful to exclude Link Classifications where it is axiomatically impossible to cause a Route Leak Initiation. Since a Transit Classification, by definition, can receive all routes, a Transit Link cannot be the source of a Route Leak Initiation. By the same logic, a Special (e.g. Mutual Transit) Classification cannot be the source of a Route Leak Initiation. This leads to a more precise definition of a Route Leak Initiation. 7. Route Leak Initiation Route Leak Initiation: A Non-Customer Route which is received over a Peer or Customer Link. 8. Route Leak Route Leak: any Route where, somewhere in the Path, a Non-Customer Route was received over a Peer or Customer Link. (This is synomous with "was sent over a Peer or Transit Link".) It should be observed that a route which is not a route leak, has an as-path that matches the following pattern: {C|S}*P?{T|S}* Where C is Customer, T is Transit, P is Peer, and S is Special, and "{ | }" denotes either/or, "*" means zero or more occurrences of, and "?" means zero or one occurrences of. 9. Security Considerations None per se. Dickson Expires April 26, 2013 [Page 8]
Internet-Draft Route Leak Definitions October 2012 10. IANA Considerations This document contains no IANA-specific material. 11. Acknowledgements To be added later. 12. References 12.1. Normative References [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. Dickson Expires April 26, 2013 [Page 9]
Internet-Draft Route Leak Definitions October 2012 12.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Brian Dickson Brian Dickson 703 Palmer Drive, Herndon, VA 20170 USA Email: brian.peter.dickson@gmail.com Dickson Expires April 26, 2013 [Page 10]