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]