draft-ietf-grow-route-leak-problem-definition-00.txt		draft-ietf-grow-route-leak-problem-definition-01.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 29, 2015 D. McPherson		Expires: September 10, 2015 D. McPherson
	E. Osterweil		E. Osterweil
	Verisign, Inc.		Verisign, Inc.
	February 25, 2015		March 9, 2015
	Problem Definition and Classification of BGP Route Leaks		Problem Definition and Classification of BGP Route Leaks
	draft-ietf-grow-route-leak-problem-definition-00		draft-ietf-grow-route-leak-problem-definition-01
	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 we have lacked a common definition of the term. In this
	document, we provide a working definition of route leaks, keeping in		document, we provide a working definition of route leaks, keeping in
	mind the real occurrences that have received significant attention.		mind the real occurrences that have received significant attention.
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	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 29, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 26		skipping to change at page 2, line 26
	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 . . . . . . . . . . . . . . . . . . . . . . . . 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
	4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. Informative References . . . . . . . . . . . . . . . . . . . 7		8. Informative References . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Frequent incidents [Huston2012][Cowie2013][Cowie2010][Madory][Zmijews		Frequent incidents [Huston2012][Cowie2013][Cowie2010][Madory][Zmijews
	ki][Paseka][LRL][Khare] that result in significant disruptions to		ki][Paseka][LRL][Khare] that result in significant disruptions to
	Internet routing are commonly called "route leaks". Examination of		Internet routing are commonly called "route leaks". Examination of
	the details of some of these incidents reveals that they vary in		the details of some of these incidents reveals that they vary in
	their form and technical details. Before we can discuss solutions to		their form and technical details. Before we can discuss solutions to
	"the route leak problem" we need a clear, technical definition of the		"the route leak problem" we need a clear, technical definition of the
	problem and its most common forms. In Section 2, we provide a		problem and its most common forms. In Section 2, we provide a
	skipping to change at page 3, line 17		skipping to change at page 3, line 17
	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
	redistribution/filtering policies distributed among the ASes		redistribution/filtering policies distributed among the ASes
	involved. Often, these intended policies are defined in terms of the		involved. Often, these intended policies are defined in terms of the
	pair-wise peering business relationship between ASes (e.g., customer,		pair-wise peering business relationship between ASes (e.g., customer,
	provider, peer).		provider, peer). For literature related to AS relationships and
			routing policies, see [Gao][Gill][Luckie]. For measurements of
			valley-free violations in Internet routing, see [Giotsas][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.
	Perceptions vary widely about what constitutes a route leak. 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 starting to work		incidents so that the IETF community has a basis for starting to work
	on route leak mitigation methods.		on route leak mitigation methods.
	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 AS1 in Figure 1) learns a prefix		multi-homed customer AS (such as AS1 in Figure 1) learns a prefix
	update from one provider (ISP1) and leaks the update to another		update from one provider (ISP1) and leaks the update to another
	provider (ISP2) in violation of intended routing policies, and		provider (ISP2) in violation of intended routing policies, and
	further the second provider does not detect the leak and propagates		further the second provider does not detect the leak and propagates
	the leaked update to its customers, peers, and transit ISPs. (Note:		the leaked update to its customers, peers, and transit ISPs.
	The Figure was modified from a similar Figure in
	[I-D.ietf-grow-simple-leak-attack-bgpsec-no-help].)
	/\ /\		/\ /\
	\ route-leak(P)/		\ route-leak(P)/
	\ propagated /		\ propagated /
	\ /		\ /
	+------------+ peer +------------+		+------------+ peer +------------+
	______| ISP1 (AS2) |----------->| ISP2 (AS3)|---------->		______| ISP1 (AS2) |----------->| ISP2 (AS3)|---------->
	/ ------------+ prefix(P) +------------+ route-leak(P)		/ ------------+ prefix(P) +------------+ route-leak(P)
	| prefix | \ update /\ \ propagated		| prefix | \ update /\ \ propagated
	\ (P) / \ / \		\ (P) / \ / \
	------- prefix(P) \ / \		------- prefix(P) \ / \
	skipping to change at page 6, line 7		skipping to change at page 6, line 7
	following the announcements.		following the announcements.
	* Example incidents: Leaks of internal prefix-routes occur		* Example incidents: Leaks of internal prefix-routes occur
	frequently (e.g. multiple times in a week), and the number of		frequently (e.g. multiple times in a week), and the number of
	prefixes leaked range from hundreds to thousands per incident.		prefixes leaked range from hundreds to thousands per incident.
	One highly conspicuous and widely disruptive leak of internal		One highly conspicuous and widely disruptive leak of internal
	prefixes happened recently in August 2014 when AS701 and AS705		prefixes happened recently in August 2014 when AS701 and AS705
	leaked about 22,000 more specifics of already announced		leaked about 22,000 more specifics of already announced
	aggregates [Huston2014][Toonk].		aggregates [Huston2014][Toonk].
	o Type 5 "Lateral ISP to ISP Leak": This type of route leak		o Type 5 "Lateral ISP-ISP-ISP Leak": This type of route leak
	typically occurs when, for example, three sequential ISP peers		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		(e.g. ISP-A, ISP-B and ISP-C) are involved, and ISP-B receives a
	prefix-route from ISP-A and in turn leaks it to ISP-C. The		prefix-route from ISP-A and in turn leaks it to ISP-C. The
	typical routing policy between laterally (i.e. non-hierarchically)		typical routing policy between laterally (i.e. non-hierarchically)
	peering ISPs is that they should only propagate to each other		peering ISPs is that they should only propagate to each other
	their respective customer prefixes.		their respective customer prefixes.
	* Example incidents: In [Mauch-nanog][Mauch], route leaks of this		* Example incidents: In [Mauch-nanog][Mauch], route leaks of this
	type are reported by monitoring updates in the global BGP		type are reported by monitoring updates in the global BGP
	system and finding three or more very large ISP ASNs in a		system and finding three or more very large ISP ASNs in a
	sequence in a BGP update's AS path. Mauch [Mauch] observes		sequence in a BGP update's AS path. Mauch [Mauch] observes
	that these are anomalies and potentially route leaks because		that these are anomalies and potentially route leaks because
	very large ISPs such as ATT, Sprint, Verizon, and		very large ISPs such as ATT, Sprint, Verizon, and
	Globalcrossing do not in general buy transit services from each		Globalcrossing do not in general buy transit services from each
	other. However, he also notes that there are exceptions when		other. However, he also notes that there are exceptions when
	one very large ISP does indeed buy transit from another very		one very large ISP does indeed buy transit from another very
	large ISP, and accordingly exceptions are made in his detection		large ISP, and accordingly exceptions are made in his detection
	algorithm for known cases.		algorithm for known cases.
			o Type 6 "Leak of Provider Prefixes to Peer": This type of route
			leak occurs when an offending AS leaks prefix-routes learned from
			its provider to a lateral peer.
			* Example incidents: The incidents reported in [Mauch] include
			the Type 6 leaks.
			o Type 7 "Leak of Peer Prefixes to Provider": This type of route
			leak occurs when an offending AS leaks prefix-routes learned from
			a lateral peer to its (the AS's) own provider. These leaked
			prefix-routes typically originate from the customer cone of the
			lateral peer.
			* Example incidents: Some of the example incidents cited for Type
			1 route leaks above are also inclusive of Type 7 route leaks.
			For instance, in the Dodo-Telstra incident [Huston2012], the
			leaked routes from Dodo to Telstra included routes that Dodo
			learned from its providers as well as lateral peers.
	4. Summary		4. Summary
	We attempted to provide a working definition of route leak. We also		We attempted to provide a working definition of route leak. We also
	presented a taxonomy for categorizing route leaks. It covers not all		presented a taxonomy for categorizing route leaks. It covers not all
	but at least several forms of route leaks that have been observed and		but at least several forms of route leaks that have been observed and
	are of concern to Internet user and network operator communities. We		are of concern to Internet user and network operator communities. We
	hope that this work provides the IETF community a basis for pursuing		hope that this work provides the IETF community a basis for pursuing
	possible BGP enhancements for route leak detection and mitigation.		possible BGP enhancements for route leak detection and mitigation.
	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. IANA Considerations
	No updates to the registries are suggested by this document.		No updates to the registries are suggested by this document.
	7. Acknowledgements		7. Acknowledgements
	The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,		The authors wish to thank Danny McPherson and Eric Osterweil for
			discussions related to this work. Also, thanks are due to Jared
			Mauch, Jeff Haas, Warren Kumari, Brian Dickson, Amogh Dhamdhere,
	Jakob Heitz, Geoff Huston, Randy Bush, Ruediger Volk, Andrei		Jakob Heitz, Geoff Huston, Randy Bush, Ruediger Volk, Andrei
	Robachevsky, Chris Morrow, and Sandy Murphy for comments,		Robachevsky, Chris Morrow, and Sandy Murphy for comments,
	suggestions, critique at the IETF-90 in the hall-ways and/or during		suggestions, and critique. The authors are also thankful to Padma
	the GROW WG meeting and/or on the GROW mailing list. The authors are		Krishnaswamy, Oliver Borchert, and Okhee Kim for their comments and
	also thankful to Padma Krishnaswami, Oliver Borchert, and Okhee Kim		review.
	for their comments and review.
	8. Informative References		8. Informative References
	[Cowie2010]		[Cowie2010]
	Cowie, J., "China's 18 Minute Mystery", Dyn Research/		Cowie, J., "China's 18 Minute Mystery", Dyn Research/
	Renesys Blog, November 2010,		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/Renesys Blog, November 2013,
	<http://research.dyn.com/2013/11/		<http://research.dyn.com/2013/11/
	mitm-internet-hijacking/>.		mitm-internet-hijacking/>.
			[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/
			sigmetrics00.long.pdf>.
			[Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of
			Interdomain Routing Policies", ACM SIGCOMM Computer
			Communication Review, January 2014,
			<https://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",
			IEEE ICC 2012, June 2012,
			<http://www0.cs.ucl.ac.uk/staff/V.Giotsas/files/
			giotsas.icc.2012.pdf>.
	[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", PAM 2013, 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", 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?", September
	2014, <http://labs.apnic.net/blabs/?p=520/>.		2014, <http://labs.apnic.net/blabs/?p=520/>.
	[I-D.ietf-grow-simple-leak-attack-bgpsec-no-help]
	McPherson, D., Amante, S., Osterweil, E., and D. Mitchell,
	"Route-Leaks & MITM Attacks Against BGPSEC", draft-ietf-
	grow-simple-leak-attack-bgpsec-no-help-04 (work in
	progress), April 2014.
	[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", DEFCON-16 Las
	Vegas, NV, USA, August 2008,		Vegas, NV, USA, August 2008,
	<https://www.defcon.org/images/defcon-16/dc16-		<https://www.defcon.org/images/defcon-16/dc16-
	presentations/defcon-16-pilosov-kapela.pdf/>.		presentations/defcon-16-pilosov-kapela.pdf/>.
	[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", IMC 2012, Boston, MA,
	November 2012, <http://www.cs.arizona.edu/~bzhang/		November 2012, <http://www.cs.arizona.edu/~bzhang/
	skipping to change at page 8, line 17		skipping to change at page 8, line 49
	<http://nrl.cs.arizona.edu/projects/		<http://nrl.cs.arizona.edu/projects/
	lsrl-events-from-2003-to-2009/>.		lsrl-events-from-2003-to-2009/>.
	[Labovitz]		[Labovitz]
	Labovitz, C., "Additional Discussion of the April China		Labovitz, C., "Additional Discussion of the April China
	BGP Hijack Inciden", Arbor Networks IT Security Blog,		BGP Hijack Inciden", 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/>.
			[Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and
			kc. claffy, "AS Relationships, Customer Cones, and
			Validation", IMC 2013, October 2013,
			<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/Renesys Blog, September 2014,
	<http://research.dyn.com/2014/09/		<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]
	skipping to change at page 8, line 41		skipping to change at page 9, line 29
	[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", CloudFare 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/>.
	[Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August		[Toonk] Toonk, A., "What Caused Today's Internet Hiccup", August
	2014, <http://www.bgpmon.net/		2014, <http://www.bgpmon.net/
	what-caused-todays-internet-hiccup/>.		what-caused-todays-internet-hiccup/>.
			[Wijchers]
			Wijchers, B. and B. Overeinder, "Quantitative Analysis of
			BGP Route Leaks", RIPE-69, November 2014,
			<https://ripe69.ripe.net/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/Renesys Blog, April 2014,
	<http://research.dyn.com/2014/04/		<http://research.dyn.com/2014/04/
	indonesia-hijacks-world/>.		indonesia-hijacks-world/>.
	Authors' Addresses		Authors' Addresses
	Kotikalapudi Sriram		Kotikalapudi Sriram
	US NIST		US NIST
End of changes. 16 change blocks.
	24 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/