draft-ietf-grow-route-leak-problem-definition-06.txt   rfc7908.txt 
Global Routing Operations K. Sriram Internet Engineering Task Force (IETF) K. Sriram
Internet-Draft D. Montgomery Request for Comments: 7908 D. Montgomery
Intended status: Informational US NIST Category: Informational US NIST
Expires: November 6, 2016 D. McPherson ISSN: 2070-1721 D. McPherson
E. Osterweil E. Osterweil
Verisign, Inc. Verisign, Inc.
B. Dickson B. Dickson
May 5, 2016 June 2016
Problem Definition and Classification of BGP Route Leaks Problem Definition and Classification of BGP Route Leaks
draft-ietf-grow-route-leak-problem-definition-06
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
date a common definition of the term has been lacking. This document a common definition of the term has been lacking. This document
provides a working definition of route leaks, keeping in mind the provides a working definition of route leaks while keeping in mind
real occurrences that have received significant attention. Further, the real occurrences that have received significant attention.
this document attempts to enumerate (though not exhaustively) Further, this document attempts to enumerate (though not
different types of route leaks based on observed events on the exhaustively) different types of route leaks based on observed events
Internet. The aim is to provide a taxonomy that covers several forms on the Internet. The aim is to provide a taxonomy that covers
of route leaks that have been observed and are of concern to Internet several forms of route leaks that have been observed and are of
user community as well as the network operator community. concern to the Internet 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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on November 6, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7908.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . 4
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-
Specific Prefixes . . . . . . . . . . . . . . . . . . . . 6 Specific Prefixes . . . . . . . . . . . . . . . . . . . . 6
4. Additional Comments about the Classification . . . . . . . . 7 4. Additional Comments about the Classification . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Informative References . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Frequent incidents [Huston2012][Cowie2013][Toonk2015-A][Toonk2015-B][ Frequent incidents [Huston2012] [Cowie2013] [Toonk2015-A]
Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in [Toonk2015-B] [Cowie2010] [Madory] [Zmijewski] [Paseka] [LRL] [Khare]
significant disruptions to Internet routing are commonly called that result in significant disruptions to Internet routing are
"route leaks". Examination of the details of some of these incidents commonly called "route leaks". Examination of the details of some of
reveals that they vary in their form and technical details. In order these incidents reveals that they vary in their form and technical
to pursue solutions to "the route leak problem" it is important to details. In order to pursue solutions to "the route-leak problem" it
first provide a clear, technical definition of the problem and is important to first provide a clear, technical definition of the
enumerate its most common forms. Section 2 provides a working problem and enumerate its most common forms. Section 2 provides a
definition of route leaks, keeping in view many recent incidents that working definition of route leaks, keeping in view many recent
have received significant attention. Section 3 attempts to enumerate incidents that have received significant attention. Section 3
(though not exhaustively) different types of route leaks based on attempts to enumerate (though not exhaustively) different types of
observed events on the Internet. Further, Section 3 provides a route leaks based on observed events on the Internet. Further,
taxonomy that covers several forms of route leaks that have been Section 3 provides a taxonomy that covers several forms of route
observed and are of concern to Internet user community as well as the leaks that have been observed and are of concern to the Internet user
network operator community. This document builds on and extends community as well as the network operator community. This document
earlier work in the IETF [draft-dickson-sidr-route-leak-def][draft-di builds on and extends earlier work in the IETF [ROUTE-LEAK-DEF]
ckson-sidr-route-leak-reqts]. [ROUTE-LEAK-REQ].
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 announcement from an Autonomous
route to another AS is in violation of the intended policies of the System (AS) of a learned BGP route to another AS is in violation of
receiver, the sender and/or one of the ASes along the preceding AS the intended policies of the receiver, the sender, and/or one of the
path. The intended scope is usually defined by a set of local ASes along the preceding AS path. The intended scope is usually
redistribution/filtering policies distributed among the ASes defined by a set of local redistribution/filtering policies
involved. Often, these intended policies are defined in terms of the distributed among the ASes involved. Often, these intended policies
pair-wise peering business relationship between ASes (e.g., customer, are defined in terms of the pair-wise peering business relationship
transit provider, peer). (For literature related to AS relationships between ASes (e.g., customer, transit provider, peer). For
and routing policies, see [Gao] [Luckie] [Gill]. For measurements of literature related to AS relationships and routing policies, see
valley-free violations in Internet routing, see [Anwar] [Giotsas] [Gao], [Luckie], and [Gill]. For measurements of valley-free
[Wijchers].) violations in Internet routing, see [Anwar], [Giotsas], and
[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 that may enable eavesdropping or traffic analysis and
and may or may not result in an overload or black-hole. Route leaks may or may not result in an overload or black hole. Route leaks can
can be accidental or malicious, but most often arise from accidental be accidental or malicious but most often arise from accidental
misconfigurations. misconfigurations.
The above definition is not intended to be all encompassing. Our aim The above definition is not intended to be all encompassing. 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 multihomed 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
policies, and further the second transit provider does not detect the policies, and further, the second transit provider does not detect
leak and propagates the leaked update to its customers, peers, and the leak and propagates the leaked update to its customers, peers,
transit ISPs. and transit ISPs.
/\ /\ /\ /\
\ route-leak(P)/ \ route leak(P)/
\ propagated / \ propagated /
\ / \ /
+------------+ peer +------------+ +------------+ peer +------------+
______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> ______| ISP1 (AS1) |----------->| ISP2 (AS2)|---------->
/ ------------+ prefix(P) +------------+ route-leak(P) / ------------+ prefix(P) +------------+ route leak(P)
| prefix | \ update /\ \ propagated | prefix | \ update /\ \ propagated
\ (P) / \ / \ \ (P) / \ / \
------- 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: Basic Notion of a Route Leak
This document proposes the following taxonomy to cover several types This document proposes the following taxonomy to cover several types
of observed route leaks, while acknowledging that the list is not of observed route leaks while acknowledging that the list is not
meant to be exhaustive. In what follows, the AS that announces a meant to be exhaustive. In what follows, the AS that announces a
route that is in violation of the intended policies is referred to as route that is in violation of the intended policies is referred to 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 multihomed AS learns a route from one upstream ISP and
and simply propagates it to another upstream ISP (the turn simply propagates it to another upstream ISP (the turn essentially
essentially resembling a hairpin). Neither the prefix nor the AS resembling a hairpin). Neither the prefix nor the AS path in the
path in the update is altered. This is similar to a straight forward update is altered. This is similar to a straightforward path-
path-poisoning attack [Kapela-Pilosov], but with full prefix. It poisoning attack [Kapela-Pilosov], but with full prefix. It should
should be noted that leaks of this type are often accidental (i.e. be noted that leaks of this type are often accidental (i.e., not
not malicious). The update basically makes a hairpin turn at the malicious). The update basically makes a hairpin turn at the
offending AS's multi-homed AS. The leak often succeeds (i.e. leaked offending AS's multihomed AS. The leak often succeeds (i.e., the
update is accepted and propagated) because the second ISP prefers leaked update is accepted and propagated) because the second ISP
customer announcement over peer announcement of the same prefix. prefers customer announcement over peer announcement of the same
Data packets would reach the legitimate destination albeit via the prefix. Data packets would reach the legitimate destination, albeit
offending AS, unless they are dropped at the offending AS due to its via the offending AS, unless they are dropped at the offending AS due
inability to handle resulting large volumes of traffic. 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
C) are involved, and ISP-B receives a route from ISP-A and in turn ISP-C) are involved, and ISP-B receives a route from ISP-A and in
leaks it to ISP-C. The typical routing policy between laterally turn 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
each other their respective customer prefixes. to each other their respective customer prefixes.
o Example incidents: In [Mauch-nanog][Mauch], route leaks of this o Example incidents: In [Mauch-nanog] and [Mauch], route leaks of
type are reported by monitoring updates in the global BGP system this type are reported by monitoring updates in the global BGP
and finding three or more very large ISP ASNs in a sequence in a system and finding three or more very large ISPs' Autonomous
BGP update's AS path. [Mauch] observes that its detection System Numbers (ASNs) in a sequence in a BGP update's AS path.
algorithm detects for these anomalies and potentially route leaks [Mauch] observes that its detection algorithm detects for these
because very large ISPs do not in general buy transit services anomalies and potentially route leaks because very large ISPs do
from each other. However, it also notes that there are exceptions not, in general, buy transit services from each other. However,
when one very large ISP does indeed buy transit from another very it also notes that there are exceptions when one very large ISP
large ISP, and accordingly exceptions are made in its detection does indeed buy transit from another very large ISP, and
algorithm for known cases. accordingly, exceptions are made in its 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
Type 3 leaks. Type 3 leaks.
3.4. Type 4: Leak of Peer Prefixes to Transit Provider 3.4. Type 4: Leak of Peer Prefixes to Transit Provider
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 a lateral (i.e. non-transit) peer to its leaks routes learned from a lateral (i.e., non-transit) peer to its
(the AS's) own transit provider. These leaked routes typically (the AS's) own transit provider. These leaked routes typically
originate from the customer cone of the lateral peer. originate from the customer cone of the lateral peer.
o Example incidents: Examples of Type 4 route-leak incidents are (1) o Example incidents: Examples of Type 4 route-leak incidents are (1)
the Axcelx-Hibernia route leak of Amazon Web Services (AWS) the Axcelx-Hibernia route leak of Amazon Web Services (AWS)
prefixes causing disruption of AWS and a variety of services that prefixes causing disruption of AWS and a variety of services that
run on AWS [Kephart],(2) the Hathway-Airtel route leak of 336 run on AWS [Kephart], (2) the Hathway-Airtel route leak of 336
Google prefixes causing widespread interruption of Google services Google prefixes causing widespread interruption of Google services
in Europe and Asia [Toonk2015-A], (3) the Moratel-PCCW route leak in Europe and Asia [Toonk2015-A], (3) the Moratel-PCCW route leak
of Google prefixes causing Google's services to go offline of Google prefixes causing Google's services to go offline
[Paseka], and (4) Some of the example incidents cited for Type 1 [Paseka], and (4) some of the example incidents cited for Type 1
route leaks above are also inclusive of Type 4 route leaks. For route leaks above are also inclusive of Type 4 route leaks. For
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 multihomed AS learns a route from one upstream ISP and
and announces the prefix to another upstream ISP as if it is being 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 a reverse path to the legitimate origination AS may However, somehow a reverse path to the legitimate origination AS may
be present and data packets reach the legitimate destination albeit be present and data packets reach the legitimate destination albeit
via the offending AS. (Note: The presence of a reverse path here is via the offending AS. (Note: The presence of a reverse path here is
not attributable to the use of path poisoning trick by the offending not attributable to the use of a path-poisoning trick by the
AS.) But sometimes the reverse path may not be present, and data offending AS.) But sometimes the reverse path may not be present,
packets destined for the leaked prefix may be simply discarded at the and data packets destined for the leaked prefix may be simply
offending AS. 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]
(2) the Belarusian GlobalOneBel route leak incidents in February- [Labovitz], (2) the Belarusian GlobalOneBel route-leak incidents
March 2013 and May 2013 [Cowie2013], (3) the Icelandic Opin Kerfi- in February-March 2013 and May 2013 [Cowie2013], (3) the Icelandic
Simmin route leak incidents in July-August 2013 [Cowie2013], and Opin Kerfi-Simmin route-leak incidents in July-August 2013
(4) the Indosat route leak incident in April 2014 [Zmijewski]. [Cowie2013], and (4) the Indosat route-leak incident in April 2014
The reverse paths (i.e. data paths from the offending AS to the [Zmijewski]. The reverse paths (i.e., data paths from the
legitimate destinations) were present in incidents #1, #2 and #3 offending AS to the legitimate destinations) were present in
cited above, but not in incident #4. In incident #4, the incidents #1, #2, and #3 cited above, but not in incident #4. In
misrouted data packets were dropped at Indosat's AS. incident #4, the misrouted data packets were dropped at Indosat's
AS.
3.6. Type 6: Accidental Leak of Internal Prefixes and More Specific 3.6. Type 6: Accidental Leak of Internal Prefixes and More-Specific
Prefixes 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 specific prefixes subsumed by leaked internal prefixes are often more-specific prefixes subsumed by
an already announced less specific prefix. The more specific an already announced, less-specific prefix. The more-specific
prefixes were not intended to be routed in eBGP. Further, the AS prefixes were not intended to be routed in External BGP (eBGP).
receiving those leaks fails to filter them. Typically, these leaked Further, the AS receiving those leaks fails to filter them.
announcements are due to some transient failures within the AS; they
are short-lived and typically withdrawn quickly following the
announcements. However, these more specific prefixes may momentarily
cause the routes to be preferred over other aggregate (i.e. less
specific) route announcements, thus redirecting traffic from its
normal best path.
o Example incidents: Leaks of internal routes occur frequently (e.g. Typically, these leaked announcements are due to some transient
multiple times in a week), and the number of prefixes leaked range failures within the AS; they are short-lived and typically withdrawn
from hundreds to thousands per incident. One highly conspicuous quickly following the announcements. However, these more-specific
and widely disruptive leak of internal routes happened in August prefixes may momentarily cause the routes to be preferred over other
2014 when AS701 and AS705 leaked about 22,000 more specifics of aggregate (i.e., less specific) route announcements, thus redirecting
already announced aggregates [Huston2014][Toonk2014]. traffic from its normal best path.
o Example incidents: Leaks of internal routes occur frequently
(e.g., multiple times in a week), and the number of prefixes
leaked range from hundreds to thousands per incident. One highly
conspicuous and widely disruptive leak of internal routes happened
in August 2014 when AS701 and AS705 leaked about 22,000 more-
specific prefixes of 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 A 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. Security Considerations 5. Security Considerations
No security considerations apply since this is a problem definition No security considerations apply since this is a problem definition
document. document.
6. IANA Considerations 6. Informative References
This document does not require an action from IANA.
7. Acknowledgements
The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,
Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Job Snijders,
Ruediger Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow,
and Sandy Murphy for comments, suggestions, and critique. The
authors are also thankful to Padma Krishnaswamy, Oliver Borchert, and
Okhee Kim for their comments and review.
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", In Proceedings of the 2015
Conference (IMC), October 2015, ACM Internet Measurement Conference (IMC),
DOI 10.1145/2815675.2815712, 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: The
Research/Renesys Blog, November 2010, New Home of Renesys Blog, November 2010,
<http://research.dyn.com/2010/11/ <http://research.dyn.com/2010/11/
chinas-18-minute-mystery/>. chinas-18-minute-mystery/>.
[Cowie2013] [Cowie2013]
Cowie, J., "The New Threat: Targeted Internet Traffic Cowie, J., "The New Threat: Targeted Internet Traffic
Misdirection", Dyn Research/Renesys Blog, November 2013, Misdirection", Dyn Research: The New Home of Renesys Blog,
<http://research.dyn.com/2013/11/ November 2013, <http://research.dyn.com/2013/11/
mitm-internet-hijacking/>. mitm-internet-hijacking/>.
[draft-dickson-sidr-route-leak-def] [Gao] Gao, L. and J. Rexford, "Stable Internet Routing Without
Dickson, B., "Route Leaks -- Definitions", IETF Internet Global Coordination", IEEE/ACM Transactions on Networking
Draft (expired), October 2012, (TON), Volume 9, Issue 6, pp 689-692,
<https://tools.ietf.org/html/draft-dickson-sidr-route- DOI 10.1109/90.974523, December 2001,
leak-def-03>.
[draft-dickson-sidr-route-leak-reqts]
Dickson, B., "Route Leaks -- Requirements for Detection
and Prevention thereof", IETF Internet Draft (expired),
March 2012, <http://tools.ietf.org/html/
draft-dickson-sidr-route-leak-reqts-02>.
[Gao] Gao, L. and J. Rexford, "Stable Internet routing without
global coordination", IEEE/ACM Transactions on
Networking, December 2001,
<http://www.cs.princeton.edu/~jrex/papers/ <http://www.cs.princeton.edu/~jrex/papers/
sigmetrics00.long.pdf>. sigmetrics00.long.pdf>.
[Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of
Interdomain Routing Policies", ACM SIGCOMM Computer Interdomain Routing Policies", ACM SIGCOMM Computer
Communication Review, January 2014, Communication Review, Volume 44, Issue 1, pp 28-34,
DOI 10.1145/2567561.2567566, January 2014,
<http://www.cs.bu.edu/~goldbe/papers/survey.pdf>. <http://www.cs.bu.edu/~goldbe/papers/survey.pdf>.
[Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in
Internet routing - Analysis based on BGP Community data", Internet routing - Analysis based on BGP Community data",
IEEE ICC 2012, June 2012. 2012 IEEE International Conference on
Communications (ICC), DOI 10.1109/ICC.2012.6363987, June
2012.
[Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing
Large-scale Routing Anomalies: A Case Study of the China Large-Scale Routing Anomalies: A Case Study of the China
Telecom Incident", PAM 2013, March 2013, Telecom Incident", In Proceedings of the 14th
International Conference on Passive and Active Measurement
(PAM) 2013, DOI 10.1007/978-3-642-36516-4_23, March 2013,
<http://www3.cs.stonybrook.edu/~phillipa/papers/ <http://www3.cs.stonybrook.edu/~phillipa/papers/
CTelecom.html>. CTelecom.html>.
[Huston2012] [Huston2012]
Huston, G., "Leaking Routes", March 2012, Huston, G., "Leaking Routes", Asia Pacific Network
Information Centre (APNIC) Blog, March 2012,
<http://labs.apnic.net/blabs/?p=139/>. <http://labs.apnic.net/blabs/?p=139/>.
[Huston2014] [Huston2014]
Huston, G., "What's so special about 512?", September Huston, G., "What's so special about 512?", Asia Pacific
2014, <http://labs.apnic.net/blabs/?p=520/>. Network Information Centre (APNIC) Blog, September 2014,
<http://labs.apnic.net/blabs/?p=520/>.
[Kapela-Pilosov] [Kapela-Pilosov]
Pilosov, A. and T. Kapela, "Stealing the Internet: An Pilosov, A. and T. Kapela, "Stealing the Internet: An
Internet-Scale Man in the Middle Attack", DEFCON-16 Las Internet-Scale Man in the Middle Attack", 16th
Vegas, NV, USA, August 2008, Defcon Conference, August 2008,
<https://www.defcon.org/images/defcon-16/dc16- <https://www.defcon.org/images/defcon-16/
presentations/defcon-16-pilosov-kapela.pdf>. dc16-presentations/defcon-16-pilosov-kapela.pdf>.
[Kephart] Kephart, N., "Route Leak Causes Amazon and AWS Outage", [Kephart] Kephart, N., "Route Leak Causes Amazon and AWS Outage",
ThousandEyes Blog, June 2015, ThousandEyes Blog, June 2015,
<https://blog.thousandeyes.com/route-leak-causes-amazon- <https://blog.thousandeyes.com/
and-aws-outage>. route-leak-causes-amazon-and-aws-outage>.
[Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix
Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, Hijacks: Occurrence and Impacts", In Proceedings of the
November 2012, <http://www.cs.arizona.edu/~bzhang/ 2013 ACM Internet Measurement Conference (IMC),
DOI 10.1145/2398776.2398780, November 2012,
<http://www.cs.arizona.edu/~bzhang/
paper/12-imc-hijack.pdf>. paper/12-imc-hijack.pdf>.
[Labovitz] [Labovitz] Labovitz, C., "Additional Discussion of the April China
Labovitz, C., "Additional Discussion of the April China BGP Hijack Incident", Arbor Networks IT Security Blog,
BGP Hijack Incident", Arbor Networks IT Security Blog,
November 2010, November 2010,
<http://www.arbornetworks.com/asert/2010/11/additional- <http://www.arbornetworks.com/asert/2010/11/additional-
discussion-of-the-april-china-bgp-hijack-incident/>. discussion-of-the-april-china-bgp-hijack-incident/>.
[LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks",
Project web page, 2012, University of Arizona (UA) Network Research Lab: Projects
<http://nrl.cs.arizona.edu/projects/ Webpage, 2012, <http://nrl.cs.arizona.edu/projects/
lsrl-events-from-2003-to-2009/>. lsrl-events-from-2003-to-2009/>.
[Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
kc. claffy, "AS Relationships, Customer Cones, and kc. claffy, "AS Relationships, Customer Cones, and
Validation", IMC 2013, October 2013, Validation", In Proceedings of the 2013 ACM Internet
Measurement Conference (IMC), DOI 10.1145/2504730.2504735,
October 2013,
<http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>. <http://www.caida.org/~amogh/papers/asrank-IMC13.pdf>.
[Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke
Today", Dyn Research/Renesys Blog, September 2014, Today", Dyn Research: The New Home of Renesys Blog,
<http://research.dyn.com/2014/09/ September 2014, <http://research.dyn.com/2014/09/
why-the-internet-broke-today/>. why-the-internet-broke-today/>.
[Mauch] Mauch, J., "BGP Routing Leak Detection System", Project [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project
web page, 2014, web page, 2014,
<http://puck.nether.net/bgp/leakinfo.cgi/>. <http://puck.nether.net/bgp/leakinfo.cgi/>.
[Mauch-nanog] [Mauch-nanog]
Mauch, J., "Detecting Routing Leaks by Counting", Mauch, J., "Detecting Routing Leaks by Counting", 41st
NANOG-41 Albuquerque, NM, USA, October 2007, NANOG Conference, October 2007,
<https://www.nanog.org/meetings/nanog41/presentations/ <https://www.nanog.org/meetings/nanog41/presentations/
mauch-lightning.pdf>. mauch-lightning.pdf>.
[Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about
How the Internet Works", CloudFare Blog, November 2012, How the Internet Works", CloudFlare Blog, November 2012,
<http://blog.cloudflare.com/ <http://blog.cloudflare.com/
why-google-went-offline-today-and-a-bit-about/>. why-google-went-offline-today-and-a-bit-about/>.
[ROUTE-LEAK-DEF]
Dickson, B., "Route Leaks -- Definitions", Work in
Progress, draft-dickson-sidr-route-leak-def-03, October
2012.
[ROUTE-LEAK-REQ]
Dickson, B., "Route Leaks -- Requirements for Detection
and Prevention thereof", Work in Progress, draft-dickson-
sidr-route-leak-reqts-02, March 2012.
[Toonk2014] [Toonk2014]
Toonk, A., "What caused today's Internet hiccup", August Toonk, A., "What caused today's Internet hiccup",
2014, <http://www.bgpmon.net/ BGPMON Blog, August 2014, <http://www.bgpmon.net/
what-caused-todays-internet-hiccup/>. what-caused-todays-internet-hiccup/>.
[Toonk2015-A] [Toonk2015-A]
Toonk, A., "What caused the Google service interruption", Toonk, A., "What caused the Google service interruption",
March 2015, <http://www.bgpmon.net/ BGPMON Blog, March 2015, <http://www.bgpmon.net/
what-caused-the-google-service-interruption/>. what-caused-the-google-service-interruption/>.
[Toonk2015-B] [Toonk2015-B]
Toonk, A., "Massive route leak causes Internet slowdown", Toonk, A., "Massive route leak causes Internet slowdown",
June 2015, <http://www.bgpmon.net/ BGPMON Blog, June 2015, <http://www.bgpmon.net/
massive-route-leak-cause-internet-slowdown/>. massive-route-leak-cause-internet-slowdown/>.
[Wijchers] [Wijchers] Wijchers, B. and B. Overeinder, "Quantitative Analysis of
Wijchers, B. and B. Overeinder, "Quantitative Analysis of BGP Route Leaks", Reseaux IP Europeens (RIPE) 69th
BGP Route Leaks", RIPE-69, November 2014, Meeting, November 2014, <http://ripe69.ripe.net/
<http://ripe69.ripe.net/
presentations/157-RIPE-69-Routing-WG.pdf>. presentations/157-RIPE-69-Routing-WG.pdf>.
[Zmijewski] [Zmijewski]
Zmijewski, E., "Indonesia Hijacks the World", Dyn Zmijewski, E., "Indonesia Hijacks the World", Dyn
Research/Renesys Blog, April 2014, Research: The New Home of Renesys Blog, April 2014,
<http://research.dyn.com/2014/04/ <http://research.dyn.com/2014/04/
indonesia-hijacks-world/>. indonesia-hijacks-world/>.
Acknowledgements
The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,
Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Job Snijders,
Ruediger Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow,
and Sandy Murphy for comments, suggestions, and critique. The
authors are also thankful to Padma Krishnaswamy, Oliver Borchert, and
Okhee Kim for their comments and review.
Authors' Addresses Authors' Addresses
Kotikalapudi Sriram Kotikalapudi Sriram
US NIST US NIST
Email: ksriram@nist.gov Email: ksriram@nist.gov
Doug Montgomery Doug Montgomery
US NIST US NIST
 End of changes. 68 change blocks. 
221 lines changed or deleted 229 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/