sidr B. Dickson Internet-Draft Brian Dickson Expires: September 7, 2012 March 6, 2012 Route Leaks -- Requirements for Detection and Prevention thereof draft-dickson-sidr-route-leak-reqts-02 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. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document is a requirements document for detection of (and prevention of) route leaks. Together with the definitions document, it is intended to suggest solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective 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 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 7, 2012. Copyright Notice Dickson Expires September 7, 2012 [Page 1] Internet-Draft Route Leak Detection Requirements March 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Peering Terms and Symbols . . . . . . . . . . . . . . . . . . . 3 3. Local Non-Leak Prefix Advertisement Matrix & Rules . . . . . . 4 4. Route Leak Detection Requirements . . . . . . . . . . . . . . . 5 4.1. Coloring Rules . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Route Modification Rules . . . . . . . . . . . . . . . . . 6 4.3. Single Party Rules . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Dickson Expires September 7, 2012 [Page 2] Internet-Draft Route Leak Detection Requirements March 2012 1. Introduction 1.1. Rationale This document analyzes the particulars of situations which introduce route leaks, or propagates those leaks. Using the definitions previously established, those conditions are reduced to a minimum set of requirements for the identification of route leaks. Those conditions are validated at length, and all of the assumptions stated, and consequential conditions enumerated. The result is a set of criteria for solving the route leak problem, preventing any single source of leakage regardless of intent or nature (operator, implementor, bad actor). 1.2. 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.3. Terminology The reader is assumed to be familiar with the IETF. 2. Peering Terms and Symbols We can represent the per-link peering categorizations with the following symbols: Neighbor is: a. Transit Provider - T b. (Transit) Customer - C c. Peer - P d. Mutual Transit In any neighbor relationship, the roles of the parties on either end of the link would be: Dickson Expires September 7, 2012 [Page 3] Internet-Draft Route Leak Detection Requirements March 2012 T-C C-T P-P Mc-Mtp Mtp-Mc (where the last two, Mc/Mtp are a semantic and/or coloring distinction on routes, rather than two separate links.) 3. Local Non-Leak Prefix Advertisement Matrix & Rules The following matrix shows what prefixes from a given source peering relationship, may be advertised to a given neighbor peering relationship without causing a route leak. +------------+---+---+-----+----+---+ | Src \ Dest | P | T | Mtp | Mc | C | +------------+---+---+-----+----+---+ | P | - | - | - | Y | Y | | T | - | - | - | Y | Y | | Mtp | - | - | - | Y | Y | | Mc | Y | Y | Y | - | Y | | C | Y | Y | Y | - | Y | +------------+---+---+-----+----+---+ Grouping the like items (by row and column) we get: +------------+-------+---+----+---+ | Src \ Dest | T/Mtp | P | Mc | C | +------------+-------+---+----+---+ | T/Mtp | - | - | Y | Y | | P | - | - | Y | Y | | C/Mc | Y | Y | - | Y | +------------+-------+---+----+---+ When a prefix is sent to any T neighbor, the receiving neighbor sees it as C. Similarly, Mc is seen at Mtp. The inverse of these is also true: C->T, Mtp->Mc. And lastly, a prefix sent to a (P) will be received by the neighbor Dickson Expires September 7, 2012 [Page 4] Internet-Draft Route Leak Detection Requirements March 2012 as a (P). This means that once a prefix has been sent to any of the two type sets "P" or "C/Mc", it must only subsequently be sent to "C" or "Mc" types. This results in the regular expression for a valid (non-leaked) path: Origin - (T - |Mtp - )*(P - )?(C - |Mc - )* Destination Thus we have the basis for a simple set of rules, which would enable detecting and preventing route leaks. 4. Route Leak Detection Requirements Based on the advertisement rules, we now have enough information to specify the main rules that a Route Leak Detector would need to observe. 4.1. Coloring Rules In no particular order, here are the requirements for coloring the path of a route. o Every BGP peering session (Link) MUST have a type associated with it. o Neighbors Agree - both sides of a BGP peering link must negotiate and agree on the link type. o Last Color Agrees with Link - the last color applied to the route must be the consistent with the link type. o If the Color used towards "Transit" is "Green", and the Color used towards "Peer" or "Customer" is "Yellow", then: * The entire Path must have a corresponding set of Colors, one for each AS-Hop. * The Path must be of the form (Green)*(Green|Yellow)(Yellow)*. * Once a Path has switched to Yellow, it cannot switch back to Green. Dickson Expires September 7, 2012 [Page 5] Internet-Draft Route Leak Detection Requirements March 2012 * Routes sent to T neighbors must mark the path Green. * Only Green Routes may be sent to T or P neighbors. * Routes sent to C or P neighbors must mark the path Yellow. * A route learned via a P neighbor must be all Green followed by a single Yellow. * A route learned via a T neighbor must be zero or more Greens followed by one or more Yellows. * A route learned via a C neighbor must be one or more Greens (and no Yellows). * Mutual Transit links must preserve the current color. * Colors may be explicitly marked, or may be inferred as long as there is no room for ambiguity. 4.2. Route Modification Rules In addressing accidental route leaks, the secondary goal is to also prevent malicious route leaks. The only additional rule for this is, that any additional BGP attributes implementing this would need to be included in the set of things cryptographically signed. This provides tamper evidence and prevention of substitution of values (on received routes). This means that the assigning of colors must be handed by implementation based only on Link Type (and current Route color), with no over-ride by the operator possible, with a single exception: It should always be possible to "demote" a route from Green to Yellow, locally before or while sending. Similarly, route-leak filtering of routes on both the send and receive direction, MUST be done based only on color vs link type. There cannot be an operator-exposed over-ride. For an operator who has a need to make a routing announcement that violates the Link Type, the correct course of action would be to change the Link type. This would need to be done cooperatively with the party at the other end of the link. Dickson Expires September 7, 2012 [Page 6] Internet-Draft Route Leak Detection Requirements March 2012 4.3. Single Party Rules One objective in preventing Route Leaks from being initiated or propogated, is to examine the control points of the routing path itself. By treating this as a path where the goal is to avoid any single point of failure, we can derive additional rules. Here, the term "failure" is synonymous with "route leak". In other words, are their any points where a single error or omission can cause a route leak? If there are any, the goal should be to replace those with equivalent elements which would require two errors or actions, by independent parties, to cause a route leak. Here are some of the places where this is accomplished or needs to be done by solutions: o Sender/Receiver - both ends of a link need to agree on the type. Unilateral error here must fail "safe" -> BGP does not establish, with errors. o Always Validate Color Rules - while the blocking of leaked routes should occur automatically at the point of leak, failure to block a leak SHOULD be detected and the route SHOULD be blocked by the next recipient. 5. Security Considerations None per se. 6. IANA Considerations This document contains no IANA-specific material. 7. Acknowledgements To be added later. 8. References Dickson Expires September 7, 2012 [Page 7] Internet-Draft Route Leak Detection Requirements March 2012 8.1. Normative References [RFC1773] Traina, P., "Experience with the BGP-4 protocol", RFC 1773, March 1995. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 8.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 September 7, 2012 [Page 8]