summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7908.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7908.txt')
-rw-r--r--doc/rfc/rfc7908.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc7908.txt b/doc/rfc/rfc7908.txt
new file mode 100644
index 0000000..921fbfd
--- /dev/null
+++ b/doc/rfc/rfc7908.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Sriram
+Request for Comments: 7908 D. Montgomery
+Category: Informational US NIST
+ISSN: 2070-1721 D. McPherson
+ E. Osterweil
+ Verisign, Inc.
+ B. Dickson
+ June 2016
+
+
+ Problem Definition and Classification of BGP Route Leaks
+
+Abstract
+
+ A systemic vulnerability of the Border Gateway Protocol routing
+ system, known as "route leaks", has received significant attention in
+ recent years. Frequent incidents that result in significant
+ disruptions to Internet routing are labeled route leaks, but to date
+ a common definition of the term has been lacking. This document
+ provides a working definition of route leaks while keeping in mind
+ the real occurrences that have received significant attention.
+ Further, this document attempts to enumerate (though not
+ exhaustively) different types of route leaks based on observed events
+ on the Internet. The aim is to provide a taxonomy that covers
+ several forms of route leaks that have been observed and are of
+ concern to the Internet user community as well as the network
+ operator community.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Sriram, et al. Informational [Page 1]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3
+ 3. Classification of Route Leaks Based on Documented Events . . 4
+ 3.1. Type 1: Hairpin Turn with Full Prefix . . . . . . . . . . 4
+ 3.2. Type 2: Lateral ISP-ISP-ISP Leak . . . . . . . . . . . . 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.5. Type 5: Prefix Re-origination with Data Path to
+ Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6
+ 3.6. Type 6: Accidental Leak of Internal Prefixes and More-
+ Specific Prefixes . . . . . . . . . . . . . . . . . . . . 6
+ 4. Additional Comments about the Classification . . . . . . . . 7
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 6. Informative References . . . . . . . . . . . . . . . . . . . 7
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sriram, et al. Informational [Page 2]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+1. Introduction
+
+ Frequent incidents [Huston2012] [Cowie2013] [Toonk2015-A]
+ [Toonk2015-B] [Cowie2010] [Madory] [Zmijewski] [Paseka] [LRL] [Khare]
+ that result in significant disruptions to Internet routing are
+ commonly called "route leaks". Examination of the details of some of
+ these incidents reveals that they vary in their form and technical
+ details. In order to pursue solutions to "the route-leak problem" it
+ is important to first provide a clear, technical definition of the
+ problem and enumerate its most common forms. Section 2 provides a
+ working definition of route leaks, keeping in view many recent
+ incidents that have received significant attention. Section 3
+ attempts to enumerate (though not exhaustively) different types of
+ route leaks based on observed events on the Internet. Further,
+ Section 3 provides a taxonomy that covers several forms of route
+ leaks that have been observed and are of concern to the Internet user
+ community as well as the network operator community. This document
+ builds on and extends earlier work in the IETF [ROUTE-LEAK-DEF]
+ [ROUTE-LEAK-REQ].
+
+2. Working Definition of Route Leaks
+
+ A proposed working definition of "route leak" is as follows:
+
+ A route leak is the propagation of routing announcement(s) beyond
+ their intended scope. That is, an announcement from an Autonomous
+ System (AS) of a learned BGP 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 path. The intended scope is usually
+ defined by a set of local redistribution/filtering policies
+ distributed among the ASes involved. Often, these intended policies
+ are defined in terms of the pair-wise peering business relationship
+ between ASes (e.g., customer, transit provider, peer). For
+ literature related to AS relationships and routing policies, see
+ [Gao], [Luckie], and [Gill]. For measurements of valley-free
+ violations in Internet routing, see [Anwar], [Giotsas], and
+ [Wijchers].
+
+ The result of a route leak can be redirection of traffic through an
+ unintended path that may enable eavesdropping or traffic analysis 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
+ misconfigurations.
+
+ The above definition is not intended to be all encompassing. Our aim
+ here is to have a working definition that fits enough observed
+ incidents so that the IETF community has a basis for developing
+ solutions for route-leak detection and mitigation.
+
+
+
+Sriram, et al. Informational [Page 3]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+3. Classification of Route Leaks Based on Documented Events
+
+ As illustrated in Figure 1, a common form of route leak occurs when a
+ multihomed customer AS (such as AS3 in Figure 1) learns a prefix
+ update from one transit provider (ISP1) and leaks the update to
+ another transit provider (ISP2) in violation of intended routing
+ policies, and further, the second transit provider does not detect
+ the leak and propagates the leaked update to its customers, peers,
+ and transit ISPs.
+
+ /\ /\
+ \ route leak(P)/
+ \ propagated /
+ \ /
+ +------------+ peer +------------+
+ ______| ISP1 (AS1) |----------->| ISP2 (AS2)|---------->
+ / ------------+ prefix(P) +------------+ route leak(P)
+ | prefix | \ update /\ \ propagated
+ \ (P) / \ / \
+ ------- prefix(P) \ / \
+ update \ / \
+ \ /route leak(P) \/
+ \/ /
+ +---------------+
+ | customer(AS3) |
+ +---------------+
+
+ Figure 1: Basic Notion of a Route Leak
+
+ This document proposes the following taxonomy to cover several types
+ of observed route leaks while acknowledging that the list is not
+ 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
+ the "offending AS".
+
+3.1. Type 1: Hairpin Turn with Full Prefix
+
+ Description: A multihomed AS learns a route from one upstream ISP and
+ simply propagates it to another upstream ISP (the turn essentially
+ resembling a hairpin). Neither the prefix nor the AS path in the
+ update is altered. This is similar to a straightforward path-
+ poisoning attack [Kapela-Pilosov], but with full prefix. It should
+ be noted that leaks of this type are often accidental (i.e., not
+ malicious). The update basically makes a hairpin turn at the
+ offending AS's multihomed AS. The leak often succeeds (i.e., the
+ leaked update is accepted and propagated) because the second ISP
+ prefers customer announcement over peer announcement of the same
+ prefix. Data packets would reach the legitimate destination, albeit
+
+
+
+Sriram, et al. Informational [Page 4]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+ via the 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)
+ the Dodo-Telstra incident in March 2012 [Huston2012], (2) the
+ VolumeDrive-Atrato incident in September 2014 [Madory], and (3)
+ the massive Telekom Malaysia route leak of about 179,000 prefixes,
+ which in turn Level3 accepted and propagated [Toonk2015-B].
+
+3.2. Type 2: Lateral ISP-ISP-ISP Leak
+
+ Description: The term "lateral" here is synonymous with "non-transit"
+ 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-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
+ (i.e., non-transit) peering ISPs is that they should only propagate
+ to each other their respective customer prefixes.
+
+ o Example incidents: In [Mauch-nanog] and [Mauch], route leaks of
+ this type are reported by monitoring updates in the global BGP
+ system and finding three or more very large ISPs' Autonomous
+ System Numbers (ASNs) in a sequence in a BGP update's AS path.
+ [Mauch] observes that its detection algorithm detects for these
+ anomalies and potentially route leaks because very large ISPs do
+ not, in general, buy transit services from each other. However,
+ it also notes that there are exceptions when one very large ISP
+ does indeed buy transit from another very large ISP, and
+ accordingly, exceptions are made in its detection algorithm for
+ known cases.
+
+3.3. Type 3: Leak of Transit-Provider Prefixes to Peer
+
+ Description: This type of route leak occurs when an offending AS
+ leaks routes learned from its transit provider to a lateral (i.e.,
+ non-transit) peer.
+
+ o Example incidents: The incidents reported in [Mauch] include
+ Type 3 leaks.
+
+3.4. Type 4: Leak of Peer Prefixes to Transit Provider
+
+ Description: This type of route leak occurs when an offending AS
+ leaks routes learned from a lateral (i.e., non-transit) peer to its
+ (the AS's) own transit provider. These leaked routes typically
+ originate from the customer cone of the lateral peer.
+
+
+
+
+
+Sriram, et al. Informational [Page 5]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+ o Example incidents: Examples of Type 4 route-leak incidents are (1)
+ the Axcelx-Hibernia route leak of Amazon Web Services (AWS)
+ prefixes causing disruption of AWS and a variety of services that
+ run on AWS [Kephart], (2) the Hathway-Airtel route leak of 336
+ Google prefixes causing widespread interruption of Google services
+ in Europe and Asia [Toonk2015-A], (3) the Moratel-PCCW route leak
+ of Google prefixes causing Google's services to go offline
+ [Paseka], and (4) some of the example incidents cited for Type 1
+ route leaks above are also inclusive of Type 4 route leaks. For
+ instance, in the Dodo-Telstra incident [Huston2012], the leaked
+ routes from Dodo to Telstra included routes that Dodo learned from
+ its transit providers as well as lateral peers.
+
+3.5. Type 5: Prefix Re-origination with Data Path to Legitimate Origin
+
+ Description: A multihomed AS learns a route from one upstream ISP 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
+ the prefix). This can be called re-origination or mis-origination.
+ However, somehow a reverse path to the legitimate origination AS may
+ be present and data packets reach the legitimate destination albeit
+ via the offending AS. (Note: The presence of a reverse path here is
+ not attributable to the use of a path-poisoning trick by the
+ offending 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
+ China Telecom incident in April 2010 [Hiran] [Cowie2010]
+ [Labovitz], (2) the Belarusian GlobalOneBel route-leak incidents
+ in February-March 2013 and May 2013 [Cowie2013], (3) the Icelandic
+ Opin Kerfi-Simmin route-leak incidents in July-August 2013
+ [Cowie2013], and (4) the Indosat route-leak incident in April 2014
+ [Zmijewski]. The reverse paths (i.e., data paths from the
+ offending AS to the legitimate destinations) were present in
+ incidents #1, #2, and #3 cited above, but not in incident #4. In
+ incident #4, the misrouted data packets were dropped at Indosat's
+ AS.
+
+3.6. Type 6: Accidental Leak of Internal Prefixes and More-Specific
+ Prefixes
+
+ Description: An offending AS simply leaks its internal prefixes to
+ one or more of its transit-provider ASes and/or ISP peers. The
+ leaked internal prefixes are often more-specific prefixes subsumed by
+ an already announced, less-specific prefix. The more-specific
+ prefixes were not intended to be routed in External BGP (eBGP).
+ Further, the AS receiving those leaks fails to filter them.
+
+
+
+Sriram, et al. Informational [Page 6]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+ Typically, these leaked 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., 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
+
+ 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
+ context of the leaked-route source AS and destination AS roles.
+
+ A Type 5 route leak (i.e., prefix mis-origination with data path to
+ legitimate origin) can also happen in conjunction with the AS
+ relationship contexts in Types 2, 3, and 4. While these
+ possibilities are acknowledged, simply enumerating more types to
+ consider all such special cases does not add value as far as solution
+ development for route leaks is concerned. Hence, the special cases
+ mentioned here are not included in enumerating route-leak types.
+
+5. Security Considerations
+
+ No security considerations apply since this is a problem definition
+ document.
+
+6. Informative References
+
+ [Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P.,
+ and N. Katz-Bassett, "Investigating Interdomain Routing
+ Policies in the Wild", In Proceedings of the 2015
+ ACM Internet Measurement Conference (IMC),
+ DOI 10.1145/2815675.2815712, October 2015,
+ <http://www.cs.usc.edu/assets/007/94928.pdf>.
+
+ [Cowie2010]
+ Cowie, J., "China's 18 Minute Mystery", Dyn Research: The
+ New Home of Renesys Blog, November 2010,
+ <http://research.dyn.com/2010/11/
+ chinas-18-minute-mystery/>.
+
+
+
+Sriram, et al. Informational [Page 7]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+ [Cowie2013]
+ Cowie, J., "The New Threat: Targeted Internet Traffic
+ Misdirection", Dyn Research: The New Home of Renesys Blog,
+ November 2013, <http://research.dyn.com/2013/11/
+ mitm-internet-hijacking/>.
+
+ [Gao] Gao, L. and J. Rexford, "Stable Internet Routing Without
+ Global Coordination", IEEE/ACM Transactions on Networking
+ (TON), Volume 9, Issue 6, pp 689-692,
+ DOI 10.1109/90.974523, December 2001,
+ <http://www.cs.princeton.edu/~jrex/papers/
+ sigmetrics00.long.pdf>.
+
+ [Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of
+ Interdomain Routing Policies", ACM SIGCOMM Computer
+ 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>.
+
+ [Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in
+ Internet routing - Analysis based on BGP Community data",
+ 2012 IEEE International Conference on
+ Communications (ICC), DOI 10.1109/ICC.2012.6363987, June
+ 2012.
+
+ [Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing
+ Large-Scale Routing Anomalies: A Case Study of the China
+ 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/
+ CTelecom.html>.
+
+ [Huston2012]
+ Huston, G., "Leaking Routes", Asia Pacific Network
+ Information Centre (APNIC) Blog, March 2012,
+ <http://labs.apnic.net/blabs/?p=139/>.
+
+ [Huston2014]
+ Huston, G., "What's so special about 512?", Asia Pacific
+ Network Information Centre (APNIC) Blog, September 2014,
+ <http://labs.apnic.net/blabs/?p=520/>.
+
+
+
+
+
+
+
+
+
+Sriram, et al. Informational [Page 8]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+ [Kapela-Pilosov]
+ Pilosov, A. and T. Kapela, "Stealing the Internet: An
+ Internet-Scale Man in the Middle Attack", 16th
+ Defcon Conference, August 2008,
+ <https://www.defcon.org/images/defcon-16/
+ dc16-presentations/defcon-16-pilosov-kapela.pdf>.
+
+ [Kephart] Kephart, N., "Route Leak Causes Amazon and AWS Outage",
+ ThousandEyes Blog, June 2015,
+ <https://blog.thousandeyes.com/
+ route-leak-causes-amazon-and-aws-outage>.
+
+ [Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix
+ Hijacks: Occurrence and Impacts", In Proceedings of the
+ 2013 ACM Internet Measurement Conference (IMC),
+ DOI 10.1145/2398776.2398780, November 2012,
+ <http://www.cs.arizona.edu/~bzhang/
+ paper/12-imc-hijack.pdf>.
+
+ [Labovitz] Labovitz, C., "Additional Discussion of the April China
+ BGP Hijack Incident", Arbor Networks IT Security Blog,
+ November 2010,
+ <http://www.arbornetworks.com/asert/2010/11/additional-
+ discussion-of-the-april-china-bgp-hijack-incident/>.
+
+ [LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks",
+ University of Arizona (UA) Network Research Lab: Projects
+ Webpage, 2012, <http://nrl.cs.arizona.edu/projects/
+ lsrl-events-from-2003-to-2009/>.
+
+ [Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
+ kc. claffy, "AS Relationships, Customer Cones, and
+ 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>.
+
+ [Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke
+ Today", Dyn Research: The New Home of Renesys Blog,
+ September 2014, <http://research.dyn.com/2014/09/
+ why-the-internet-broke-today/>.
+
+ [Mauch] Mauch, J., "BGP Routing Leak Detection System", Project
+ web page, 2014,
+ <http://puck.nether.net/bgp/leakinfo.cgi/>.
+
+
+
+
+
+
+Sriram, et al. Informational [Page 9]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+ [Mauch-nanog]
+ Mauch, J., "Detecting Routing Leaks by Counting", 41st
+ NANOG Conference, October 2007,
+ <https://www.nanog.org/meetings/nanog41/presentations/
+ mauch-lightning.pdf>.
+
+ [Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about
+ How the Internet Works", CloudFlare Blog, November 2012,
+ <http://blog.cloudflare.com/
+ 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]
+ Toonk, A., "What caused today's Internet hiccup",
+ BGPMON Blog, August 2014, <http://www.bgpmon.net/
+ what-caused-todays-internet-hiccup/>.
+
+ [Toonk2015-A]
+ Toonk, A., "What caused the Google service interruption",
+ BGPMON Blog, March 2015, <http://www.bgpmon.net/
+ what-caused-the-google-service-interruption/>.
+
+ [Toonk2015-B]
+ Toonk, A., "Massive route leak causes Internet slowdown",
+ BGPMON Blog, June 2015, <http://www.bgpmon.net/
+ massive-route-leak-cause-internet-slowdown/>.
+
+ [Wijchers] Wijchers, B. and B. Overeinder, "Quantitative Analysis of
+ BGP Route Leaks", Reseaux IP Europeens (RIPE) 69th
+ Meeting, November 2014, <http://ripe69.ripe.net/
+ presentations/157-RIPE-69-Routing-WG.pdf>.
+
+ [Zmijewski]
+ Zmijewski, E., "Indonesia Hijacks the World", Dyn
+ Research: The New Home of Renesys Blog, April 2014,
+ <http://research.dyn.com/2014/04/
+ indonesia-hijacks-world/>.
+
+
+
+
+
+Sriram, et al. Informational [Page 10]
+
+RFC 7908 Route-Leak Problem Definition June 2016
+
+
+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
+
+ Kotikalapudi Sriram
+ US NIST
+
+ Email: ksriram@nist.gov
+
+
+ Doug Montgomery
+ US NIST
+
+ Email: dougm@nist.gov
+
+
+ Danny McPherson
+ Verisign, Inc.
+
+ Email: dmcpherson@verisign.com
+
+
+ Eric Osterweil
+ Verisign, Inc.
+
+ Email: eosterweil@verisign.com
+
+
+ Brian Dickson
+
+ Email: brian.peter.dickson@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sriram, et al. Informational [Page 11]
+