Internet DRAFT - draft-dickson-sidr-route-leak-def
draft-dickson-sidr-route-leak-def
sidr B. Dickson
Internet-Draft Brian Dickson
Expires: April 26, 2013 October 23, 2012
Route Leaks -- Definitions
draft-dickson-sidr-route-leak-def-03
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. Routes may be
announced to neighbors, contrary to the receiver's local peering
policy. If that occurs, those routes may then be 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 ultimate goal 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 April 26, 2013 [Page 1]
Internet-Draft Route Leak Definitions October 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 April 26, 2013.
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 April 26, 2013 [Page 2]
Internet-Draft Route Leak Definitions October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope Limitations . . . . . . . . . . . . . . . . . . . . . . 5
3. Route Leak Definitions . . . . . . . . . . . . . . . . . . . . 6
4. Peer Links and Routes . . . . . . . . . . . . . . . . . . . . 7
5. Customer Links and Routes . . . . . . . . . . . . . . . . . . 7
5.1. Customer's Customer . . . . . . . . . . . . . . . . . . . 7
6. Non-Leak-Initiation Links . . . . . . . . . . . . . . . . . . 8
7. Route Leak Initiation . . . . . . . . . . . . . . . . . . . . 8
8. Route Leak . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Dickson Expires April 26, 2013 [Page 3]
Internet-Draft Route Leak Definitions October 2012
1. Introduction
1.1. Assumptions
Much of this document assumes the observer has total knowledge of the
state of everything in the hypothetical examples presented.
It is understood that participants in the real world routing
scenarios will not have that knowledge.
The purpose of presuming that total knowledge here, is to illustrate
how little is needed to identify leaked routes.
In particular, it is hoped that this leads to a correspondingly
simple set of definitions with useful real-world meaning.
1.2. Rationale
Generally speaking, a route-leak occurs when a route goes somewhere
it should not. In other words, that somewhere along the path, a
route was sent that somehow violated the implicit or explicit policy
between two neighbors, without being blocked by the recipient. Route
leaks cause harm, in a variety of ways. They expose traffic to Man-
In-The-Middle (MITM) attacks. They may result in traffic congestion,
latency, or even black-holing of traffic.
It is a leak if any receiver in the propogation path did not want the
route, from a generic policy perspective. It does not matter which
party caused the situation - a leaks are in the eye of the receivers.
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.3. 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.4. 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.
Dickson Expires April 26, 2013 [Page 4]
Internet-Draft Route Leak Definitions October 2012
The following additional terminology is used throughout this
document:
Route (or synonomously, prefix): an NLRI in BGP, including all its
attributes. (This term subject to change by GROW.)
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, where each link may have a different
classification, and/or local policy.
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,
specifying which routes are announced, which routes are accepted, and
what attributes are changed to affect choice of BGP Best Path per
prefix.
Path: Also known as AS_PATH (or optionally AS4_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,
e.g. via cryptographic means, such as using an ROA.
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.
o Hijacked Routes - Origin Validation (proposed work in the SIDR WG)
addresses the issue of Hijacked Routes. By limiting Route Leak
efforts to Validated Routes, we are able to presume the origin is
correct, and narrow the scope.
o Violations of Local Policy - issues between adjacent ASNs which do
not propogate any further, or which do not violate the Link
Classification.
o 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
Dickson Expires April 26, 2013 [Page 5]
Internet-Draft Route Leak Definitions October 2012
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.
3. Route Leak Definitions
Route Leak Initiation: A Route announced over a Link by a Neighbor,
which does not match the Link Classification, where one of the
following is true:
o the Neighbor is the Originator
o the Neighbor received the Route, where the received Route was not
a Route Leak
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 Route that the Neighbor received was either a Route Leak
Initiation, or a Route Leak Propagation.
Once a Route has become a Route Leak Initiation, any further
announcement of that Route is a Route Leak Propagation.
NB: 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.
Link Classifications: a Link may be classified as:
o Customer
o Transit
o Peer
o Special (which includes Mutual Transit, Sibling, and other non-
trivial arrangements)
Special (e.g. 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 parallel Links
between the same two Neighbors, where one Link Policy is Transit and
the other Link Policy is Customer. Recall, Link Classification is
the superset of Local Policy - the term "full routes" here means
simply that any route in addition to customers' routes, is permitted.
Dickson Expires April 26, 2013 [Page 6]
Internet-Draft Route Leak Definitions October 2012
4. 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.
5. Customer Links and Routes
A Customer Link Classification: The Customer sends us only their own
(locally originated) 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 Transit Link Classification is a superset of the actual Local
Policy of a specific Customer. This means that while a Transit Link
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.
5.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
Special, e.g. Mutual Transit, which is a superset of Customer).
In particular, if the Path were to include any Link which were not a
Dickson Expires April 26, 2013 [Page 7]
Internet-Draft Route Leak Definitions October 2012
Customer Link, the Route would NOT be a Customer^N.
NB: It is sufficient that the Customer's Customer relationship is
declared. The "Customer" relationship, in the context of route
leaks, is restrictive. Erroneous or inadvertent classification as
Customer cannot result in a route leak.
6. Non-Leak-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
axiomatically impossible to cause a Route Leak Initiation.
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 Special (e.g. Mutual Transit)
Classification cannot be the source of a Route Leak Initiation.
This leads to a more precise definition of a Route Leak Initiation.
7. Route Leak Initiation
Route Leak Initiation: A Non-Customer Route which is received over a
Peer or Customer Link.
8. 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".)
It should be observed that a route which is not a route leak, has an
as-path that matches the following pattern:
{C|S}*P?{T|S}*
Where C is Customer, T is Transit, P is Peer, and S is Special, and
"{ | }" denotes either/or, "*" means zero or more occurrences of, and
"?" means zero or one occurrences of.
9. Security Considerations
None per se.
Dickson Expires April 26, 2013 [Page 8]
Internet-Draft Route Leak Definitions October 2012
10. IANA Considerations
This document contains no IANA-specific material.
11. Acknowledgements
To be added later.
12. References
12.1. Normative References
[RFC1033] Lottor, M., "Domain administrators operations guide",
RFC 1033, November 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
Dickson Expires April 26, 2013 [Page 9]
Internet-Draft Route Leak Definitions October 2012
12.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 April 26, 2013 [Page 10]
