sidr B. Dickson
Internet-Draft Brian Dickson
Expires: September 6, 2012 March 5, 2012
Route Leaks -- Definitions
draft-dickson-sidr-route-leak-def-01
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 considers the situations that can lead to routes being
leaked, and tries to find acceptable definitions for describing these
scenarios.
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.
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.
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
Dickson Expires September 6, 2012 [Page 1]
Internet-Draft Route Leak Definitions March 2012
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 6, 2012.
Copyright Notice
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.
Dickson Expires September 6, 2012 [Page 2]
Internet-Draft Route Leak Definitions March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
3. Route Leak Definitions . . . . . . . . . . . . . . . . . . . . 6
3.1. Peer Links and Routes . . . . . . . . . . . . . . . . . . . 6
3.2. Customer Links and Routes . . . . . . . . . . . . . . . . . 6
3.2.1. Customer's Customer . . . . . . . . . . . . . . . . . . 7
3.3. Mutual Transit . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Non-Initiation Links . . . . . . . . . . . . . . . . . . . 7
3.5. Route Leak Initiation . . . . . . . . . . . . . . . . . . . 7
3.6. Route Leak . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Dickson Expires September 6, 2012 [Page 3]
Internet-Draft Route Leak Definitions March 2012
1. Introduction
1.1. Rationale
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.
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.
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 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.
The following terminology is used throughout this document:
Route (or synonomously, prefix): an NLRI in BGP, including all its
attributes.
Neighbor (or "peer", not capitalized): A toplogically adjacent
Autonomous System, with whom routes are exchanged.
Link: A BGP connection to a Neighbor. A Neighbor may be reached via
one or more links.
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.
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.
Dickson Expires September 6, 2012 [Page 4]
Internet-Draft Route Leak Definitions March 2012
Path: Also known as AS Path, the sequence of ASNs through which a
route has passed from Originator to recipient.
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.
Validated Origination: a route whose origination has been validated
via cryptographic means, using an ROA.
Link Classifications: a Link may be classified as:
o Customer
o Transit
o Peer
o Mutual Transit
2. Scope Limitations
The following issues are not in the scope of route leaks. Each item
in the list includes the rationale for excluding it.
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.
Violations of Local Policy:
Issues between adjacent ASNs which do not propogate any further,
or which do not violate the Link Classification.
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.
Essentially, the only elements being considered are the Path, and
Link Classifications at each hop in the Path.
Dickson Expires September 6, 2012 [Page 5]
Internet-Draft Route Leak Definitions March 2012
3. Route Leak Definitions
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).
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.
3.1. Peer Links and Routes
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).
A Link which is classified as a Peer, will see us as a Peer
Classification as well. The relationship is symmetric in nature.
3.2. Customer Links and Routes
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.
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.
Transit and Customer are the opposite ends of the same Link, by
definition.
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.
Dickson Expires September 6, 2012 [Page 6]
Internet-Draft Route Leak Definitions March 2012
3.2.1. Customer's Customer
It is important to define when a Route is a Customer's Customer
Route.
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.
3.3. Mutual Transit
A Mutual Transit Classification is 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.
3.4. Non-Initiation Links
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.
A Transit Classification, by definition, can receive all routes.
Thus, a Transit Classification 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.
This leads to a more precise definition of a Route Leak Initiation.
3.5. Route Leak Initiation
Route Leak Initiation: Non-Customer Route received over a Peer or
Customer Link.
3.6. Route Leak
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".)
Dickson Expires September 6, 2012 [Page 7]
Internet-Draft Route Leak Definitions March 2012
4. Security Considerations
None per se.
5. IANA Considerations
This document contains no IANA-specific material.
6. Acknowledgements
To be added later.
7. References
7.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.
7.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Dickson Expires September 6, 2012 [Page 8]
Internet-Draft Route Leak Definitions March 2012
Author's Address
Brian Dickson
Brian Dickson
703 Palmer Drive,
Herndon, VA 20170
USA
Email: brian.peter.dickson@gmail.com
Dickson Expires September 6, 2012 [Page 9]