One document matched: draft-dickson-sidr-route-leak-reqts-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "D:/Program%20Files/XML%20Copy%20Editor/dtd/rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc1773 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1773.xml'>
  <!ENTITY rfc1997 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1997.xml'>
  <!ENTITY rfc4271 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml'>
  <!ENTITY rfc4456 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4456.xml'>
  <!ENTITY rfc4760 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml'>
]>
<?rfc compact="yes" ?>
<rfc ipr="trust200902" docName="draft-dickson-sidr-route-leak-reqts-01">
<?rfc toc='yes'?>
<front>
    <Creation month="March" year="2012" day="5" />
    <creation month="March" year="2012" day="5" />
    <created month="March" year="2012" day="5" />

    <title abbrev="Route Leak Detection Requirements">
Route Leaks -- Requirements for Detection and Prevention thereof
</title>
    <author initials="B.P." surname="Dickson" fullname="Brian Dickson">
      <organization>
Brian Dickson
</organization>
      <address>
        <postal>
          <street>
703 Palmer Drive,
</street>
          <city>
Herndon
</city>
          <region>
VA
</region>
          <code>
20170
</code>
          <country>
USA
</country>
        </postal>
        <email>
brian.peter.dickson@gmail.com
</email>
      </address>
    </author>
    <date month="March" year="2012"/>
    <area>Internet</area>
    <workgroup>sidr</workgroup>
    <keyword>
DNSOP
</keyword>
    <abstract>
      <t>
      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.
    <vspace blankLines="1" />
   This document is a requirements document for detection of (and prevention of) route leaks.
    <vspace blankLines="1" />
   Together with the definitions document, it is intended to suggest solutions which meet these criteria, and to facilitate evaluation of proposed solutions.
    <vspace blankLines="1" />
   The fundamental objective is to "solve the route leaks problem".
</t>
    </abstract>
    <note title="Author's Note">
    <t>
      Intended Status: Informational.
    </t>
    </note>
  </front>
<middle>
<section title="Introduction">


<section title="Rationale">
<t>
   This document analyzes the particulars of situations which introduce route leaks, or propagates those leaks.
    <vspace blankLines="1" />
   Using the definitions previously established, those conditions are reduced to a minimum set of requirements for the identification of route leaks.
    <vspace blankLines="1" />
   Those conditions are validated at length, and all of the assumptions stated, and consequential conditions enumerated.
    <vspace blankLines="1" />
   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).
</t>
</section> 
<section title="Requirements">
<t>
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
      <xref target="RFC2119" />.
</t>
</section>
<section title="Terminology">
<t>
The reader is assumed to be familiar with the IETF.</t>
</section>
</section>
<section title="Peering Terms and Symbols">
<t>
We can represent the per-link peering categorizations with the following symbols:
    <vspace blankLines="1" />

Neighbor is:
<list style="letters">
<t>Transit Provider - T</t>
<t>(Transit) Customer - C</t>
<t>Peer - P</t>
<t>Mutual Transit
<list style="letters">
a.	Mutual Transit – customer - Mc
b.	Mutual Transit – transit/peer – Mtp
</list>
</t>
</list>

In any neighbor relationship, the roles of the parties on either end of the link would be:
<list>
<t>T-C</t>
<t>C-T</t>
<t>P-P</t>
<t>Mc-Mtp</t>
<t>Mtp-Mc</t>
</list>
(where the last two, Mc/Mtp are a semantic and/or coloring distinction on routes, rather than two separate links.)
</t>
</section>
<section title="Local Non-Leak Prefix Advertisement Matrix & Rules">
<t>
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.
    <vspace blankLines="1" />
<texttable>
<ttcol align='left'>Src \ Dest</ttcol>
<ttcol align='center'>P</ttcol>
<ttcol align='center'>T</ttcol>
<ttcol align='center'>Mtp</ttcol>
<ttcol align='center'>Mc</ttcol>
<ttcol align='center'>C</ttcol>
<c>P</c><c>-</c><c>-</c><c>-</c><c>Y</c><c>Y</c>
<c>T</c><c>-</c><c>-</c><c>-</c><c>Y</c><c>Y</c>
<c>Mtp</c><c>-</c><c>-</c><c>-</c><c>Y</c><c>Y</c>
<c>Mc</c><c>Y</c><c>Y</c><c>Y</c><c>-</c><c>Y</c>
<c>C</c><c>Y</c><c>Y</c><c>Y</c><c>-</c><c>Y</c>
</texttable>
    <vspace blankLines="1" />
Grouping the like items (by row and column) we get:
    <vspace blankLines="1" />
<texttable>
<ttcol align='left'>Src \ Dest</ttcol>
<ttcol align='center'>T/Mtp</ttcol>
<ttcol align='center'>P</ttcol>
<ttcol align='center'>Mc</ttcol>
<ttcol align='center'>C</ttcol>
<c>T/Mtp</c><c>-</c><c>-</c><c>Y</c><c>Y</c>
<c>P</c><c>-</c><c>-</c><c>Y</c><c>Y</c>
<c>C/Mc</c><c>Y</c><c>Y</c><c>-</c><c>Y</c>
</texttable>
    <vspace blankLines="1" />
When a prefix is sent to any T neighbor, the receiving neighbor sees it as C. Similarly, Mc is seen at Mtp.
    <vspace  />
The inverse of these is also true: C->T, Mtp->Mc.
    <vspace  />
And lastly, a prefix sent to a (P) will be received by the neighbor as a (P).
    <vspace blankLines="1" />
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.
    <vspace blankLines="1" />

This results in the regular expression for a valid (non-leaked) path:
    <vspace blankLines="1" />
<artwork>
       Origin - (T - |Mtp - )*(P - )?(C - |Mc - )* Destination
</artwork>
    <vspace blankLines="1" />
Thus we have the basis for a simple set of rules, which would enable detecting and preventing route leaks.
</t>
</section>
<section title="Route Leak Detection Requirements">
<t>
Based on the advertisement rules, we now have enough information to specify the main rules that a Route Leak Detector would need to observe.
</t>
<section title="Coloring Rules">
<t>
In no particular order, here are the requirements for coloring the path of a route.
<list style="symbols">
<t>Every BGP peering session (Link) MUST have a type associated with it.</t>
<t>Neighbors Agree - both sides of a BGP peering link must negotiate and agree on the link type.</t>
<t>Last Color Agrees with Link - the last color applied to the route must be the consistent with the link type.</t>
<t>If the Color used towards "Transit" is "Green", and the Color used towards "Peer" or "Customer" is "Yellow", then:
<list style="symbols">
<t>The entire Path must have a corresponding set of Colors, one for each AS-Hop.</t>
<t>The Path must be of the form (Green)*(Green|Yellow)(Yellow)*.</t>
<t>Once a Path has switched to Yellow, it cannot switch back to Green.</t>
<t>Routes sent to T neighbors must mark the path Green.</t>
<t>Only Green Routes may be sent to T or P neighbors.</t>
<t>Routes sent to C or P neighbors must mark the path Yellow.</t>
<t>A route learned via a P neighbor must be all Green followed by a single Yellow.</t>
<t>A route learned via a T neighbor must be zero or more Greens followed by one or more Yellows.</t>
<t>A route learned via a C neighbor must be one or more Greens (and no Yellows).</t>
<t>Mutual Transit links must preserve the current color.</t>
<t>Colors may be explicitly marked, or may be inferred as long as there is no room for ambiguity.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Route Modification Rules">
<t>
In addressing accidental route leaks, the secondary goal is to also prevent malicious route leaks.
    <vspace blankLines="1" />
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).
    <vspace blankLines="1" />
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.
    <vspace blankLines="1" />
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.
    <vspace blankLines="1" />
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.
</t>
</section>
<section title="Single Party Rules">
<t>
One objective in preventing Route Leaks from being initiated or propogated, is to examine the control points of the routing path itself.
    <vspace blankLines="1" />
By treating this as a path where the goal is to avoid any single point of failure, we can derive additional rules.
    <vspace blankLines="1" />
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?
    <vspace blankLines="1" />
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.
    <vspace blankLines="1" />
Here are some of the places where this is accomplished or needs to be done by solutions:
<list style="symbols">
<t>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.</t>
<t>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 blocked by the next recipient.</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>
None per se.
</t>
</section>
<section title="IANA Considerations">
<t>
   This document contains no IANA-specific material.
</t>
</section>
<section title="Acknowledgements">
<t>
To be added later.
</t>
</section>
</middle>
  <back>
    <references title="Normative References">
      &rfc1773;
      &rfc1997;
      &rfc4271;
      &rfc4456;
      &rfc4760;
    </references>
    <references title="Informative References">
    &rfc2119;
    </references>
  </back>
</rfc>