draft-ietf-grow-route-leak-problem-definition-01.txt		draft-ietf-grow-route-leak-problem-definition-02.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: September 10, 2015 D. McPherson		Expires: January 6, 2016 D. McPherson
	E. Osterweil		E. Osterweil
	Verisign, Inc.		Verisign, Inc.
	March 9, 2015		B. Dickson
			Twitter, Inc.
			July 5, 2015
	Problem Definition and Classification of BGP Route Leaks		Problem Definition and Classification of BGP Route Leaks
	draft-ietf-grow-route-leak-problem-definition-01		draft-ietf-grow-route-leak-problem-definition-02
	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 46
	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 September 10, 2015.		This Internet-Draft will expire on January 6, 2016.
	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 25		skipping to change at page 2, line 25
	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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. Informative References . . . . . . . . . . . . . . . . . . . 7		8. Informative References . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Frequent incidents [Huston2012][Cowie2013][Cowie2010][Madory][Zmijews		Frequent incidents [Huston2012][Cowie2013][Toonk2015-A][Toonk2015-B][
	ki][Paseka][LRL][Khare] that result in significant disruptions to		Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in
	Internet routing are commonly called "route leaks". Examination of		significant disruptions to Internet routing are commonly called
	the details of some of these incidents reveals that they vary in		"route leaks". Examination of the details of some of these incidents
	their form and technical details. Before we can discuss solutions to		reveals that they vary in their form and technical details. Before
	"the route leak problem" we need a clear, technical definition of the		we can discuss solutions to "the route leak problem" we need a clear,
	problem and its most common forms. In Section 2, we provide a		technical definition of the problem and its most common forms. In
	working definition of route leaks, keeping in view many recent		Section 2, we provide a working definition of route leaks, keeping in
	incidents that have received significant attention. Further, in		view many recent incidents that have received significant attention.
	Section 3, we attempt to enumerate (though not exhaustively)		Further, in Section 3, we attempt 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. We aim to provide a taxonomy that covers several forms of		on the Internet. We aim to provide a taxonomy that covers several
	route leaks that have been observed and are of concern to Internet		forms of route leaks that have been observed and are of concern to
	user community as well as the network operator community.		Internet user community as well as the network operator community.
			This document builds on and extends earlier work in the IETF by
			Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-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 36		skipping to change at page 3, line 36
	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 AS3 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.		the leaked update to its customers, peers, and transit ISPs.
	/\ /\		/\ /\
	\ route-leak(P)/		\ route-leak(P)/
	\ propagated /		\ propagated /
	\ /		\ /
	+------------+ peer +------------+		+------------+ peer +------------+
	______| ISP1 (AS2) |----------->| ISP2 (AS3)|---------->		______| 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(AS1) |		| 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		We propose the following taxonomy for classification of route leaks
	aiming to cover several types of recently observed route leaks, while		aiming to cover several types of recently observed route leaks, while
	acknowledging that the list is not meant to be exhaustive. In what		acknowledging that the list is not meant to be exhaustive. In what
	follows, we refer to the AS that announces a route that is in		follows, we refer to the AS that announces a route that is in
	violation of the intended policies as the "offending AS".		violation of the intended policies as the "offending AS".
	skipping to change at page 4, line 46		skipping to change at page 4, line 46
	accidental (i.e. not malicious). The update basically makes a		accidental (i.e. not malicious). The update basically makes a
	U-turn at the attacker's multi-homed AS. The attack (accidental		U-turn at the attacker's multi-homed AS. The attack (accidental
	or deliberate) often succeeds because the second ISP prefers		or deliberate) often succeeds because the second ISP prefers
	customer announcement over peer announcement of the same prefix.		customer announcement over peer announcement of the same prefix.
	Data packets would reach the legitimate destination albeit via the		Data packets would reach the legitimate destination albeit via the
	offending AS, unless they are dropped at the offending AS due to		offending AS, unless they are dropped at the offending AS due to
	its inability to handle resulting large volumes of traffic.		its inability to handle resulting large volumes of traffic.
	* Example incidents: Examples of Type 1 route-leak incidents are		* Example incidents: Examples of Type 1 route-leak incidents are
	(1) the Dodo-Telstra incident in March 2012 [Huston2012], (2)		(1) the Dodo-Telstra incident in March 2012 [Huston2012], (2)
	the Moratel-PCCW leak of Google prefixes in November 2012		the Moratel-PCCW route leak of Google prefixes in November 2012
	[Paseka], and (3) the VolumeDrive-Atrato incident in September		[Paseka], (3) the VolumeDrive-Atrato incident in September 2014
	2014 [Madory].		[Madory], (4) the Hathway-Airtel route leak of 336 Google
			prefixes causing widespread interruption of Google services in
			Europe and Asia [Toonk2015-A], and (5) the massive Telekom
			Malaysia route-leaks of about 179,000 prefixes, which in turn
			Level3 accepted and propagated [Toonk2015-B].
	o Type 2 "U-Turn with More Specific Prefix": A multi-homed AS learns		o Type 2 "U-Turn with More Specific Prefix": A multi-homed AS learns
	a prefix route from one upstream ISP and announces a sub-prefix		a prefix route from one upstream ISP and announces a sub-prefix
	(subsumed in the prefix) to another upstream ISP. The AS path in		(subsumed in the prefix) to another upstream ISP. The AS path in
	the update is not altered. Update is crafted by the attacker to		the update is not altered. Update is crafted by the attacker to
	have a subprefix to maximize the success of the attack while		have a subprefix to maximize the success of the attack while
	reverse path is kept open by the path poisoning techniques as in		reverse path is kept open by the path poisoning techniques as in
	[Kapela-Pilosov]. Data packets reach the legitimate destination		[Kapela-Pilosov]. Data packets reach the legitimate destination
	albeit via the offending AS.		albeit via the offending AS.
	* Example incidents: An example of Type 2 route-leak incident is		* Example incidents: One example is the demo performed at
	the demo performed at DEFCON-16 in August 2008		DEFCON-16 in August 2008 [Kapela-Pilosov]. Another example is
	[Kapela-Pilosov]. An attacker who deliberately performs a Type		the earlier-mentioned incident of route leaks from Telekom
	1 route leak (with full prefix) can just as easily perform a		Malaysia via Level3, in which out of about 179,000 total route-
	Type 2 route leak (with subprefix) to achieve a greater impact.		leaked prefixes, about 10,000 were more specifics of previously
			announced aggregates [Toonk2015-B]. [Note: An attacker who
			deliberately performs a Type 1 route leak (with full prefix)
			can just as easily perform a Type 2 route leak (with subprefix)
			to achieve a greater impact.]
	o Type 3 "Prefix Hijack with Data Path to Legitimate Origin": A		o Type 3 "Prefix Mis-Origination with Data Path to Legitimate
	multi-homed AS learns a prefix route from one upstream ISP and		Origin": A multi-homed AS learns a prefix route from one upstream
	announces the prefix to another upstream ISP as if it is being		ISP and announces the prefix to another upstream ISP as if it is
	originated by it (i.e. strips the received AS path, and re-		being originated by it (i.e. strips the received AS path, and re-
	originates the prefix). This amounts to straightforward		originates the prefix). This amounts to mis-origination or
	hijacking. However, somehow (not attributable to the use of path		hijacking. However, somehow (not attributable to the use of path
	poisoning trick by the attacker) a reverse path is present, and		poisoning trick by the attacker) a reverse path is present, and
	data packets reach the legitimate destination albeit via the		data packets reach the legitimate destination albeit via the
	offending AS. But sometimes the reverse path may not be there,		offending AS. But sometimes the reverse path may not be there,
	and data packets get dropped following receipt by the offending		and data packets get dropped following receipt by the offending
	AS.		AS.
	* Example incidents: Examples of Type 3 route leak include (1)		* Example incidents: Examples of Type 3 route leak include (1)
	the China Telecom incident in April 2010		the China Telecom incident in April 2010
	[Hiran][Cowie2010][Labovitz], (2) the Belarusian GlobalOneBel		[Hiran][Cowie2010][Labovitz], (2) the Belarusian GlobalOneBel
	skipping to change at page 6, line 5		skipping to change at page 6, line 14
	leaked announcements are due to some transient failures within the		leaked announcements are due to some transient failures within the
	AS; they are short-lived, and typically withdrawn quickly		AS; they are short-lived, and typically withdrawn quickly
	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][Toonk2014].
	o Type 5 "Lateral ISP-ISP-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
	skipping to change at page 7, line 18		skipping to change at page 7, line 27
	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 Danny McPherson and Eric Osterweil for		The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,
	discussions related to this work. Also, thanks are due to Jared		Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Ruediger
	Mauch, Jeff Haas, Warren Kumari, Brian Dickson, Amogh Dhamdhere,		Volk, Andrei Robachevsky, Chris Morrow, and Sandy Murphy for
	Jakob Heitz, Geoff Huston, Randy Bush, Ruediger Volk, Andrei		comments, suggestions, and critique. The authors are also thankful
	Robachevsky, Chris Morrow, and Sandy Murphy for comments,		to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim for their
	suggestions, and critique. The authors are also thankful to Padma		comments and review.
	Krishnaswamy, Oliver Borchert, and Okhee Kim 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/>.
			[draft-dickson-sidr-route-leak-def]
			Dickson, B., "Route Leaks -- Definitions", IETF Internet
			Draft (expired), October 2012,
			<https://tools.ietf.org/html/draft-dickson-sidr-route-
			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		[Gao] Gao, L. and J. Rexford, "Stable Internet routing without
	global coordination", IEEE/ACM Transactions on Networking,		global coordination", IEEE/ACM Transactions on Networking,
	December 2001, <http://www.cs.princeton.edu/~jrex/papers/		December 2001, <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, January 2014,
	<https://www.cs.bu.edu/~goldbe/papers/survey.pdf>.		<https://www.cs.bu.edu/~goldbe/papers/survey.pdf>.
	skipping to change at page 8, line 37		skipping to change at page 9, line 10
	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/
	paper/12-imc-hijack.pdf/>.		paper/12-imc-hijack.pdf/>.
	[LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks",
	Project web page, 2012,
	<http://nrl.cs.arizona.edu/projects/
	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 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",
			Project web page, 2012,
			<http://nrl.cs.arizona.edu/projects/
			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", IMC 2013, 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/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/>.
	skipping to change at page 9, line 25		skipping to change at page 9, line 47
	Mauch, J., "Detecting Routing Leaks by Counting", NANOG-41		Mauch, J., "Detecting Routing Leaks by Counting", NANOG-41
	Albuquerque, NM, USA, October 2007,		Albuquerque, NM, USA, 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", 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		[Toonk2014]
			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/>.
			[Toonk2015-A]
			Toonk, A., "What caused the Google service interruption",
			March 2015, <http://www.bgpmon.net/
			what-caused-the-google-service-interruption/>.
			[Toonk2015-B]
			Toonk, A., "Massive route leak causes Internet slowdown",
			June 2015, <http://www.bgpmon.net/
			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", RIPE-69, November 2014,		BGP Route Leaks", RIPE-69, November 2014,
	<https://ripe69.ripe.net/presentations/157-RIPE-69-		<https://ripe69.ripe.net/presentations/157-RIPE-69-
	Routing-WG.pdf>.		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/
	skipping to change at page 10, line 4		skipping to change at page 10, line 38
	Kotikalapudi Sriram		Kotikalapudi Sriram
	US NIST		US NIST
	Email: ksriram@nist.gov		Email: ksriram@nist.gov
	Doug Montgomery		Doug Montgomery
	US NIST		US NIST
	Email: dougm@nist.gov		Email: dougm@nist.gov
	Danny McPherson		Danny McPherson
	Verisign, Inc.		Verisign, Inc.
	Email: dmcpherson@verisign.com		Email: dmcpherson@verisign.com
	Eric Osterweil		Eric Osterweil
	Verisign, Inc.		Verisign, Inc.
	Email: eosterweil@verisign.com		Email: eosterweil@verisign.com
			Brian Dickson
			Twitter, Inc.
			Email: bdickson@twitter.com
End of changes. 23 change blocks.
	52 lines changed or deleted		87 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/