draft-ietf-grow-route-leak-problem-definition-04.txt   draft-ietf-grow-route-leak-problem-definition-05.txt 
Global Routing Operations K. Sriram Global Routing Operations K. Sriram
Internet-Draft D. Montgomery Internet-Draft D. Montgomery
Intended status: Informational US NIST Intended status: Informational US NIST
Expires: August 14, 2016 D. McPherson Expires: October 31, 2016 D. McPherson
E. Osterweil E. Osterweil
Verisign, Inc. Verisign, Inc.
B. Dickson B. Dickson
February 11, 2016 April 29, 2016
Problem Definition and Classification of BGP Route Leaks Problem Definition and Classification of BGP Route Leaks
draft-ietf-grow-route-leak-problem-definition-04 draft-ietf-grow-route-leak-problem-definition-05
Abstract Abstract
A systemic vulnerability of the Border Gateway Protocol routing A systemic vulnerability of the Border Gateway Protocol routing
system, known as 'route leaks', has received significant attention in system, known as 'route leaks', has received significant attention in
recent years. Frequent incidents that result in significant recent years. Frequent incidents that result in significant
disruptions to Internet routing are labeled "route leaks", but to disruptions to Internet routing are labeled "route leaks", but to
date we have lacked a common definition of the term. In this date a common definition of the term has been lacking. This document
document, we provide a working definition of route leaks, keeping in provides a working definition of route leaks, keeping in mind the
mind the real occurrences that have received significant attention. real occurrences that have received significant attention. Further,
Further, we attempt to enumerate (though not exhaustively) different this document attempts to enumerate (though not exhaustively)
types of route leaks based on observed events on the Internet. We different types of route leaks based on observed events on the
aim to provide a taxonomy that covers several forms of route leaks Internet. The aim is to provide a taxonomy that covers several forms
that have been observed and are of concern to Internet user community of route leaks that have been observed and are of concern to Internet
as well as the network operator community. user community as well as the network operator community.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2016. This Internet-Draft will expire on October 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3 2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3
3. Classification of Route Leaks Based on Documented Events . . 3 3. Classification of Route Leaks Based on Documented Events . . 3
3.1. Type 1: Hairpin Turn with Full Prefix . . . . . . . . . . 4 3.1. Type 1: Hairpin Turn with Full Prefix . . . . . . . . . . 4
3.2. Type 2: Lateral ISP-ISP-ISP Leak . . . . . . . . . . . . 5 3.2. Type 2: Lateral ISP-ISP-ISP Leak . . . . . . . . . . . . 5
3.3. Type 3: Leak of Transit-Provider Prefixes to Peer . . . . 5 3.3. Type 3: Leak of Transit-Provider Prefixes to Peer . . . . 5
3.4. Type 4: Leak of Peer Prefixes to Transit Provider . . . . 5 3.4. Type 4: Leak of Peer Prefixes to Transit Provider . . . . 5
3.5. Type 5: Prefix Re-Origination with Data Path to 3.5. Type 5: Prefix Re-Origination with Data Path to
Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6 Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6
3.6. Type 6: Accidental Leak of Internal Prefixes and More 3.6. Type 6: Accidental Leak of Internal Prefixes and More
Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6 Specific Prefixes . . . . . . . . . . . . . . . . . . . . 6
4. Additional Comments about the Classification . . . . . . . . 7 4. Additional Comments about the Classification . . . . . . . . 7
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Frequent incidents [Huston2012][Cowie2013][Toonk2015-A][Toonk2015-B][ Frequent incidents [Huston2012][Cowie2013][Toonk2015-A][Toonk2015-B][
Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in
significant disruptions to Internet routing are commonly called significant disruptions to Internet routing are commonly called
"route leaks". Examination of the details of some of these incidents "route leaks". Examination of the details of some of these incidents
reveals that they vary in their form and technical details. Before reveals that they vary in their form and technical details. In order
we can discuss solutions to "the route leak problem" we need a clear, to pursue solutions to "the route leak problem" it is important to
technical definition of the problem and its most common forms. In first provide a clear, technical definition of the problem and
Section 2, we provide a working definition of route leaks, keeping in enumerate its most common forms. Section 2 provides a working
view many recent incidents that have received significant attention. definition of route leaks, keeping in view many recent incidents that
Further, in Section 3, we attempt to enumerate (though not have received significant attention. Section 3 attempts to enumerate
exhaustively) different types of route leaks based on observed events (though not exhaustively) different types of route leaks based on
on the Internet. We aim to provide a taxonomy that covers several observed events on the Internet. Further, Section 3 provides a
forms of route leaks that have been observed and are of concern to taxonomy that covers several forms of route leaks that have been
Internet user community as well as the network operator community. observed and are of concern to Internet user community as well as the
This document builds on and extends earlier work in the IETF by network operator community. This document builds on and extends
Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route- earlier work in the IETF [draft-dickson-sidr-route-leak-def][draft-di
leak-reqts]. ckson-sidr-route-leak-reqts].
2. Working Definition of Route Leaks 2. Working Definition of Route Leaks
A proposed working definition of route leak is as follows: A proposed working definition of route leak is as follows:
A "route leak" is the propagation of routing announcement(s) beyond A "route leak" is the propagation of routing announcement(s) beyond
their intended scope. That is, an AS's announcement of a learned BGP their intended scope. That is, an AS's announcement of a learned BGP
route to another AS is in violation of the intended policies of the route to another AS is in violation of the intended policies of the
receiver, the sender and/or one of the ASes along the preceding AS receiver, the sender and/or one of the ASes along the preceding AS
path. The intended scope is usually defined by a set of local path. The intended scope is usually defined by a set of local
skipping to change at page 3, line 35 skipping to change at page 3, line 34
and routing policies, see [Gao] [Luckie] [Gill]. For measurements of and routing policies, see [Gao] [Luckie] [Gill]. For measurements of
valley-free violations in Internet routing, see [Anwar] [Giotsas] valley-free violations in Internet routing, see [Anwar] [Giotsas]
[Wijchers].) [Wijchers].)
The result of a route leak can be redirection of traffic through an The result of a route leak can be redirection of traffic through an
unintended path which may enable eavesdropping or traffic analysis, unintended path which may enable eavesdropping or traffic analysis,
and may or may not result in an overload or black-hole. Route leaks and may or may not result in an overload or black-hole. Route leaks
can be accidental or malicious, but most often arise from accidental can be accidental or malicious, but most often arise from accidental
misconfigurations. misconfigurations.
The above definition is not intended to be all encompassing. The above definition is not intended to be all encompassing. Our aim
Perceptions vary widely about what constitutes a route leak. Our aim
here is to have a working definition that fits enough observed here is to have a working definition that fits enough observed
incidents so that the IETF community has a basis for developing incidents so that the IETF community has a basis for developing
solutions for route leak detection and mitigation. solutions for route leak detection and mitigation.
3. Classification of Route Leaks Based on Documented Events 3. Classification of Route Leaks Based on Documented Events
As illustrated in Figure 1, a common form of route leak occurs when a As illustrated in Figure 1, a common form of route leak occurs when a
multi-homed customer AS (such as AS3 in Figure 1) learns a prefix multi-homed customer AS (such as AS3 in Figure 1) learns a prefix
update from one transit provider (ISP1) and leaks the update to update from one transit provider (ISP1) and leaks the update to
another transit provider (ISP2) in violation of intended routing another transit provider (ISP2) in violation of intended routing
skipping to change at page 4, line 24 skipping to change at page 4, line 24
------- prefix(P) \ / \ ------- prefix(P) \ / \
update \ / \ update \ / \
\ /route-leak(P) \/ \ /route-leak(P) \/
\/ / \/ /
+---------------+ +---------------+
| customer(AS3) | | customer(AS3) |
+---------------+ +---------------+
Figure 1: Illustration of the basic notion of a route leak. Figure 1: Illustration of the basic notion of a route leak.
We propose the following taxonomy for classification of route leaks This document proposes the following taxonomy to cover several types
aiming to cover several types of recently observed route leaks, while of observed route leaks, while acknowledging that the list is not
acknowledging that the list is not meant to be exhaustive. In what meant to be exhaustive. In what follows, the AS that announces a
follows, we refer to the AS that announces a route that is in route that is in violation of the intended policies is referred to as
violation of the intended policies as the "offending AS". the "offending AS".
3.1. Type 1: Hairpin Turn with Full Prefix 3.1. Type 1: Hairpin Turn with Full Prefix
Description: A multi-homed AS learns a route from one upstream ISP Description: A multi-homed AS learns a route from one upstream ISP
and simply propagates it to another upstream ISP (the turn and simply propagates it to another upstream ISP (the turn
essentially resembling a hairpin). Neither the prefix nor the AS essentially resembling a hairpin). Neither the prefix nor the AS
path in the update is altered. This is similar to a straight forward path in the update is altered. This is similar to a straight forward
path-poisoning attack [Kapela-Pilosov], but with full prefix. It path-poisoning attack [Kapela-Pilosov], but with full prefix. It
should be noted that leaks of this type are often accidental (i.e. should be noted that leaks of this type are often accidental (i.e.
not malicious). The update basically makes a hairpin turn at the not malicious). The update basically makes a hairpin turn at the
offending AS's multi-homed AS. The leak often succeeds because the offending AS's multi-homed AS. The leak often succeeds (i.e. leaked
second ISP prefers customer announcement over peer announcement of update is accepted and propagated) because the second ISP prefers
the same prefix. Data packets would reach the legitimate destination customer announcement over peer announcement of the same prefix.
albeit via the offending AS, unless they are dropped at the offending Data packets would reach the legitimate destination albeit via the
AS due to its inability to handle resulting large volumes of traffic. offending AS, unless they are dropped at the offending AS due to its
inability to handle resulting large volumes of traffic.
o Example incidents: Examples of Type 1 route-leak incidents are (1) o Example incidents: Examples of Type 1 route-leak incidents are (1)
the Dodo-Telstra incident in March 2012 [Huston2012], (2) the the Dodo-Telstra incident in March 2012 [Huston2012], (2) the
VolumeDrive-Atrato incident in September 2014 [Madory], and (3) VolumeDrive-Atrato incident in September 2014 [Madory], and (3)
the massive Telekom Malaysia route leak of about 179,000 prefixes, the massive Telekom Malaysia route leak of about 179,000 prefixes,
which in turn Level3 accepted and propagated [Toonk2015-B]. which in turn Level3 accepted and propagated [Toonk2015-B].
3.2. Type 2: Lateral ISP-ISP-ISP Leak 3.2. Type 2: Lateral ISP-ISP-ISP Leak
Description: The term "lateral" here is synonymous with "non-transit" Description: The term "lateral" here is synonymous with "non-transit"
or "peer-to-peer". This type of route leak typically occurs when, or "peer-to-peer". This type of route leak typically occurs when,
for example, three sequential ISP peers (e.g. ISP-A, ISP-B, and ISP- for example, three sequential ISP peers (e.g. ISP-A, ISP-B, and ISP-
C) are involved, and ISP-B receives a route from ISP-A and in turn C) are involved, and ISP-B receives a route from ISP-A and in turn
leaks it to ISP-C. The typical routing policy between laterally leaks it to ISP-C. The typical routing policy between laterally
(i.e. non-transit) peering ISPs is that they should only propagate to (i.e. non-transit) peering ISPs is that they should only propagate to
each other their respective customer prefixes. each other their respective customer prefixes.
o Example incidents: In [Mauch-nanog][Mauch], route leaks of this o Example incidents: In [Mauch-nanog][Mauch], route leaks of this
type are reported by monitoring updates in the global BGP system type are reported by monitoring updates in the global BGP system
and finding three or more very large ISP ASNs in a sequence in a and finding three or more very large ISP ASNs in a sequence in a
BGP update's AS path. Mauch [Mauch] observes that these are BGP update's AS path. [Mauch] observes that these are anomalies
anomalies and potentially route leaks because very large ISPs such and potentially route leaks because very large ISPs such as ATT,
as ATT, Sprint, Verizon, and Globalcrossing do not in general buy Sprint, Verizon, and Globalcrossing do not in general buy transit
transit services from each other. However, he also notes that services from each other. However, it also notes that there are
there are exceptions when one very large ISP does indeed buy exceptions when one very large ISP does indeed buy transit from
transit from another very large ISP, and accordingly exceptions another very large ISP, and accordingly exceptions are made in its
are made in his detection algorithm for known cases. detection algorithm for known cases.
3.3. Type 3: Leak of Transit-Provider Prefixes to Peer 3.3. Type 3: Leak of Transit-Provider Prefixes to Peer
Description: This type of route leak occurs when an offending AS Description: This type of route leak occurs when an offending AS
leaks routes learned from its transit provider to a lateral (i.e. leaks routes learned from its transit provider to a lateral (i.e.
non-transit) peer. non-transit) peer.
o Example incidents: The incidents reported in [Mauch] include the o Example incidents: The incidents reported in [Mauch] include the
Type 3 leaks. Type 3 leaks.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
instance, in the Dodo-Telstra incident [Huston2012], the leaked instance, in the Dodo-Telstra incident [Huston2012], the leaked
routes from Dodo to Telstra included routes that Dodo learned from routes from Dodo to Telstra included routes that Dodo learned from
its transit providers as well as lateral peers. its transit providers as well as lateral peers.
3.5. Type 5: Prefix Re-Origination with Data Path to Legitimate Origin 3.5. Type 5: Prefix Re-Origination with Data Path to Legitimate Origin
Description: A multi-homed AS learns a route from one upstream ISP Description: A multi-homed AS learns a route from one upstream ISP
and announces the prefix to another upstream ISP as if it is being and announces the prefix to another upstream ISP as if it is being
originated by it (i.e. strips the received AS path, and re-originates originated by it (i.e. strips the received AS path, and re-originates
the prefix). This can be called re-origination or mis-origination. the prefix). This can be called re-origination or mis-origination.
However, somehow (not attributable to the use of path poisoning trick However, somehow a reverse path to the legitimate origination AS may
by the offending AS) a reverse path is present, and data packets be present and data packets reach the legitimate destination albeit
reach the legitimate destination albeit via the offending AS. But via the offending AS. (Note: The presence of a reverse path here is
sometimes the reverse path may not be there, and data packets get not attributable to the use of path poisoning trick by the offending
dropped following receipt by the offending AS. AS.) But sometimes the reverse path may not be present, and data
packets destined for the leaked prefix may be simply discarded at the
offending AS.
o Example incidents: Examples of Type 5 route leak include (1) the o Example incidents: Examples of Type 5 route leak include (1) the
China Telecom incident in April 2010 [Hiran][Cowie2010][Labovitz], China Telecom incident in April 2010 [Hiran][Cowie2010][Labovitz],
(2) the Belarusian GlobalOneBel route leak incidents in February- (2) the Belarusian GlobalOneBel route leak incidents in February-
March 2013 and May 2013 [Cowie2013], (3) the Icelandic Opin Kerfi- March 2013 and May 2013 [Cowie2013], (3) the Icelandic Opin Kerfi-
Simmin route leak incidents in July-August 2013 [Cowie2013], and Simmin route leak incidents in July-August 2013 [Cowie2013], and
(4) the Indosat route leak incident in April 2014 [Zmijewski]. (4) the Indosat route leak incident in April 2014 [Zmijewski].
The reverse paths (i.e. data paths from the offending AS to the The reverse paths (i.e. data paths from the offending AS to the
legitimate destinations) were present in incidents #1, #2 and #3 legitimate destinations) were present in incidents #1, #2 and #3
cited above, but not in incident #4. In incident #4, the cited above, but not in incident #4. In incident #4, the
misrouted data packets were dropped at Indosat's AS. misrouted data packets were dropped at Indosat's AS.
3.6. Type 6: Accidental Leak of Internal Prefixes and More Specifics 3.6. Type 6: Accidental Leak of Internal Prefixes and More Specific
Prefixes
Description: An offending AS simply leaks its internal prefixes to Description: An offending AS simply leaks its internal prefixes to
one or more of its transit-provider ASes and/or ISP peers. The one or more of its transit-provider ASes and/or ISP peers. The
leaked internal prefixes are often more specifics subsumed by an leaked internal prefixes are often more specific prefixes subsumed by
already announced less specific prefix. The more specifics were not an already announced less specific prefix. The more specific
intended to be routed in eBGP. Further, the AS receiving those leaks prefixes were not intended to be routed in eBGP. Further, the AS
fails to filter them. Typically these leaked announcements are due receiving those leaks fails to filter them. Typically, these leaked
to some transient failures within the AS; they are short-lived, and announcements are due to some transient failures within the AS; they
typically withdrawn quickly following the announcements. However, are short-lived and typically withdrawn quickly following the
these more specifics may momentarily cause the routes to be preferred announcements. However, these more specific prefixes may momentarily
over other aggregate route announcements, thus redirecting traffic cause the routes to be preferred over other aggregate (i.e. less
from its normal best path. specific) route announcements, thus redirecting traffic from its
normal best path.
o Example incidents: Leaks of internal routes occur frequently (e.g. o Example incidents: Leaks of internal routes occur frequently (e.g.
multiple times in a week), and the number of prefixes leaked range multiple times in a week), and the number of prefixes leaked range
from hundreds to thousands per incident. One highly conspicuous from hundreds to thousands per incident. One highly conspicuous
and widely disruptive leak of internal routes happened recently in and widely disruptive leak of internal routes happened in August
August 2014 when AS701 and AS705 leaked about 22,000 more 2014 when AS701 and AS705 leaked about 22,000 more specifics of
specifics of already announced aggregates [Huston2014][Toonk2014]. already announced aggregates [Huston2014][Toonk2014].
4. Additional Comments about the Classification 4. Additional Comments about the Classification
It is worth noting that Types 1 through 4 are similar in that a route It is worth noting that Types 1 through 4 are similar in that a route
is leaked in violation of policy in each case, but what varies is the is leaked in violation of policy in each case, but what varies is the
context of the leaked-route source AS and destination AS roles. context of the leaked-route source AS and destination AS roles.
Type 5 route leak (i.e. prefix mis-origination with data path to Type 5 route leak (i.e. prefix mis-origination with data path to
legitimate origin) can also happen in conjunction with the AS legitimate origin) can also happen in conjunction with the AS
relationship contexts in Types 2, 3, and 4. While these relationship contexts in Types 2, 3, and 4. While these
possibilities are acknowledged, simply enumerating more types to possibilities are acknowledged, simply enumerating more types to
consider all such special cases does not add value as far as solution consider all such special cases does not add value as far as solution
development for route leaks is concerned. Hence, the special cases development for route leaks is concerned. Hence, the special cases
mentioned here are not included in enumerating route leak types. mentioned here are not included in enumerating route leak types.
5. Summary 5. Security Considerations
We attempted to provide a working definition of route leak. We also
presented a taxonomy for categorizing route leaks. It covers not all
but at least several forms of route leaks that have been observed and
are of concern to Internet user and network operator communities. We
hope that this work provides the IETF community a basis for pursuing
possible BGP enhancements for route leak detection and mitigation.
6. Security Considerations
No security considerations apply since this is a problem definition No security considerations apply since this is a problem definition
document. document.
7. IANA Considerations 6. IANA Considerations
No updates to the registries are suggested by this document. This document does not require an action from IANA.
8. Acknowledgements 7. Acknowledgements
The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari, The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,
Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Job Snijders, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Job Snijders,
Ruediger Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow, Ruediger Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow,
and Sandy Murphy for comments, suggestions, and critique. The and Sandy Murphy for comments, suggestions, and critique. The
authors are also thankful to Padma Krishnaswamy, Oliver Borchert, and authors are also thankful to Padma Krishnaswamy, Oliver Borchert, and
Okhee Kim for their comments and review. Okhee Kim for their comments and review.
9. Informative References 8. Informative References
[Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P., [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P.,
and N. Katz-Bassett, "Investigating Interdomain Routing and N. Katz-Bassett, "Investigating Interdomain Routing
Policies in the Wild", ACM Internet Measurement Policies in the Wild", ACM Internet Measurement
Conference (IMC), October 2015, Conference (IMC), October 2015,
<http://www.cs.usc.edu/assets/007/94928.pdf>. <http://www.cs.usc.edu/assets/007/94928.pdf>.
[Cowie2010] [Cowie2010]
Cowie, J., "China's 18 Minute Mystery", Dyn Cowie, J., "China's 18 Minute Mystery", Dyn
Research/Renesys Blog, November 2010, Research/Renesys Blog, November 2010,
 End of changes. 21 change blocks. 
82 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/