One document matched: draft-dickson-sidr-route-leak-solns-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 subcompact="no" ?>
<rfc ipr="trust200902" docName="draft-dickson-sidr-route-leak-solns-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 Leaks - Proposed Solutions">
Route Leaks -- Proposed Solutions
</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 considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios.
   <vspace blankLines="1" />
   The purpose of these definitions is to facilitate discussion on 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.
    <vspace blankLines="1" />
   The fundamental objective is to "solve the route leaks problem".
</t>
    </abstract>
    <note title="Author's Note">
    <t>
      Intended Status: Standards track.
    </t>
    </note>
  </front>
<middle>
<section title="Introduction">


<section title="Rationale">
<t>
   This document describes two different schemes for implementing a solution for route leaks.
    <vspace blankLines="1" />
   They represent different trade-offs between simplicity of implementation, versus embedding information.
   The information embedded can be inferred currently from a variety of sources, so the risk/cost of doing so is marginal.
    <vspace blankLines="1" />
   Either solution would be adequate to solve the route leak problem.
    <vspace blankLines="1" />
   Due to the requirement for mandatory establishment of peering link types, and cryptographic protection, the ideal time and place to implement this would be coincident with BGPSEC.
    <vspace blankLines="1" />
   Including route leak protection with BGPSEC may be beneficial to the latter.
   It is more compelling to deploy a solution to both sets of problems, than to deploy a solution to one or the other alone.
</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="Prefix Attribute Possibilities">
<t>
If we presume that there are two possible colors for a prefix, then we have three ways to express those colors:
<list style="numbers">
<t>A single bit, with two possible values, always attached to a prefix.</t>
<t>An attribute whose presence signals one of the colors, and whose absence signals the other color.</t>
<t>The same as 2, but with the other color being signaled.</t>
</list>
For sake of clarity, we will use a fairly universally understood pair of colors, “green” (meaning “proceed”), and “yellow” (meaning “caution”).
<vspace blankLines="1" />
So, the three ways of marking the colors are:
<list>
<t>Use a green/yellow bit (green if 1, yellow if 0)</t>
<t>Use a “green” attribute (green if present, yellow otherwise)</t>
<t>Use a “yellow” attribute (yellow if present, green otherwise).</t>
</list>
Since information is leaked for both the "green/yellow bit" and "yellow attribute", there is no reason to discuss the "yellow attribute" option.
It is inferior to both other methods.
</t>
</section>
<section title="Encoding Color via Choice of Algorithm">
<t>
Here, we are presuming that BGPSEC is in use on prefixes, and that BGPSEC includes an explicit algorithm identifier.
Currently, the identifier only specifies which algorithm to use to validate the signature in the signature block.
    <vspace blankLines="1" />
This would be augmented so that for any given algorithm, two identifiers would be assigned.
One would be the identifier signifying "Green", and the other would signify "Yellow".
When sending a "green" route, the current "green" algorithm would be used.
When sending a "yellow" route, the current "yellow" algorithm would be used.
Validation would work as usual, with the additional ability to validate the color rules for preventing route leaks.
    <vspace blankLines="1" />
No additional changes to the structure of the BGPSEC protocol or wire format are needed.
    <vspace blankLines="1" />
However, there is the leak of information about transit relationships, which is unavoidable with this design.
    <vspace blankLines="1" />
Routes which violate the path coloring rules but otherwise validate, would be blocked. (They should not occur, but should be checked regardless.)
Routes which do not validate under BGPSEC would be blocked regardless, also preventing a potential source of route leaks.
</t>
</section>
<section title="Encoding Color via a Second Signature Block">
<t>
A signature block analogous to the AS-PATH signature block, would be included on any announcement that is “green”.
The local sender would add her signature to the signature block on these "green" announcements.
In addition, the new signature block would be sent across the “green/yellow” boundary to any Peer.
However, when sending across the “green/yellow” boundary, would not add her signature to the block.
    <vspace blankLines="1" />
The recipient would be able to validate all the “green” signatures up to the sender, and if present, the sender's signature as well.
If the “green” signature does not include the sender, no more signatures can be attached.
When sending to a "yellow" peer, the “green attribute” block is stripped (if present).
The absence of a "green block" means the prefix is considered "yellow".
This mechanism is not “free” in that more crypto calculations are needed, the structure of the BGPSEC attributes change, and more data is needed on each announcement within the “green” zone.
    <vspace blankLines="1" />
However, no information concerning relationships is leaked, beyond what the recipient can already infer.
A transit provider already knows his/her customers, and their customers, etc.
    <vspace blankLines="1" />
From a scaling perspective, it should be noted that only customers' prefixes require additional signatures, so the number of prefixes with those signatures is proportionally smaller.
Signature validation is only done on the "green block" upon receiving a customer's routes or a peer's routes. This also minimizes the incremental cost.
    <vspace blankLines="1" />
Since it is physically impossible to promote a "yellow" route to a "green" route, because the originators "green" block is absent, this is a very strong mechanism for stopping route leaks.
Validating link type versus color, after validation of any "green block" present, is sufficient to stop route leaks.
</t>
</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>