One document matched: draft-dickson-sidr-route-leak-def-00.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 rfc1033 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1033.xml'>
  <!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
  <!ENTITY rfc1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
  <!ENTITY rfc2136 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml'>
  <!ENTITY rfc2181 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml'>
  <!ENTITY rfc2308 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml'>
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc4033 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
  <!ENTITY rfc4034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml'>
  <!ENTITY rfc4035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml'>
  <!ENTITY rfc4035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml'>
   <!ENTITY rfc5155 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5155.xml'>
]>
<?rfc compact="yes" ?>
<rfc ipr="trust200902" docName="draft-dickson-sidr-route-leak-def-00">
<?rfc toc='yes'?>
<front>
    <Creation month="March" year="2012" day="4" />
    <creation month="March" year="2012" day="4" />
    <created month="March" year="2012" day="4" />

    <title abbrev="Route Leak Definitions">
Route Leaks -- Definitions
</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 analysis of what a route leak is, and what the scope of the problem space for route leaks is.
    <vspace blankLines="1" />
   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: Informational.
    </t>
    </note>
  </front>
<middle>
<section title="Introduction">


<section title="Rationale">
<t>
   A route-leak occurs when a prefix is originated by one party, propagated by other parties, and received by the observer, where the path used was not intentional end-to-end.
   It is a leak if the receiver did not want the route, from a generic policy perspective. It does not matter which party caused the situation – a leak is in the eye of the receiver.
   By their nature - unintentional, unwanted, and harmful, route leaks are bad.
   <vspace blankLines="1" />
   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.
</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 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.
<vspace blankLines="1" />
   The following terminology is used throughout this document:
<vspace blankLines="1" />
Route (or synonomously, prefix):  an NLRI in BGP, including all its attributes.
<vspace blankLines="1" />
Neighbor (or "peer", not capitalized): A toplogically adjacent Autonomous System, with whom routes are exchanged.
<vspace blankLines="1" />
Link: A BGP connection to a Neighbor. A Neighbor may be reached via one or more links.
<vspace blankLines="1" />
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.
<vspace blankLines="1" />
Local Policy: The set of rules, as applied on a single Neighbor Link, on which routes are announced, which routes are accepted, and what attributes are changed to affect choice of BGP Best Path per prefix.
<vspace blankLines="1" />
Path: Also known as AS Path, the sequence of ASNs through which a route has passed from Originator to recipient.
<vspace blankLines="1" />
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.
<vspace blankLines="1" />
Validated Origination: a route whose origination has been validated via cryptographic means, using an ROA.
</t>
</section>
</section>
<section title="Scope Limitations">
<t>
The following issues are not in the scope of route leaks. Each item in the list includes the rationale for excluding it.
<list>
<t>Hijacked Routes -  Origin Validation already addresses the issue of Hijacked Routes. By limiting Route Leak efforts to Validated Routes, we are able to presume the origin is correct.</t>
<t>Violations of Local Policy - issues between adjacent ASNs which do not propogate any further, or which do not violate the Link Classification.</t>
<t>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 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.</t>
</list>
Essentially, the only elements being considered are the Path, and Link Classifications at each hop in the Path.
</t>
</section>
<section title="Route Leak Definitions">
<t>
Route Leak Initiation: A Route announced over a Link by a Neighbor which does not match the Link Classification, where the Neighbor is either the Originator, or had received the Route where the Neighbor's Link Classification matched the Route that the Neighbor received.

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).
<vspace blankLines="1" />
Route Leak Propagation: A Route announced over a Link by a Neighbor, where the Neighbor received the Route as either a Route Leak Initiation, or a Route Leak Propagation.

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.
<vspace blankLines="1" />
Link Classifications: a Link may be classified as:
<list>
<t>Customer</t>
<t>Transit</t>
<t>Peer</t>
<t>Mutual Transit</t>
</list>
<vspace blankLines="1" />
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 Links where one is Transit and the other is Customer.
<vspace blankLines="1" />

</t>
</section>
<section title="Peer Links and Routes">
<t>
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).
<vspace blankLines="1" />
A Link which is classified as a Peer, will see us as a Peer Classification as well. The relationship is symmetric in nature.
</t>
</section>
<section title="Customer Links and Routes">
<t>
A Customer Link Classification: The Customer sends us only their own Routes, and the Customer's Customer's Routes (and Customer^Nth Routes).
The Customer relationship is transitive.
<vspace blankLines="1" />
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.
<vspace blankLines="1" />
Transit and Customer are the opposite ends of the same Link, by definition.
<vspace blankLines="1" />
The Customer Classification is a superset of the actual Local Policy of a specific Customer.
This means that while a Customer 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.
<vspace blankLines="1" />
<section title="Customer's Customer">
<t>
It is important to define when a Route is a Customer's Customer Route.
<vspace blankLines="1" />
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 Mutual Transit, which is a superset of Customer.
</t>
</section>
</t>
</section>
<section title="Non-Initiation Links">
<t>
To help identify the exact conditions where a Route Leak Initiation can occur, it is helpful to exclude Link Classifications where it is not possible to cause a Route Leak Initiation.
<vspace blankLines="1" />
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 Mutual Transit Classification cannot be the source of a Route Leak Initiation.
<vspace blankLines="1" />
This leads to a more precise definition of a Route Leak Initiation.
</t>
</section>
<section title="Route Leak Initiation">
<t>Route Leak Initiation: Non-Customer Route received over a Peer or Customer Link,.
</t>
</section>
<section title="Route Leak">
<t>
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".)
</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">
      &rfc1033;
      &rfc1034;
      &rfc1035;
      &rfc2136;
      &rfc2181;
      &rfc2308;
      &rfc4033;
      &rfc4034;
      &rfc4035;
      &rfc5011;
      &rfc5155;
    </references>
    <references title="Informative References">
    &rfc2119;
    </references>
  </back>
</rfc>