draft-ietf-grow-route-leak-problem-definition-03.txt		draft-ietf-grow-route-leak-problem-definition-04.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: April 14, 2016 D. McPherson		Expires: August 14, 2016 D. McPherson
	E. Osterweil		E. Osterweil
	Verisign, Inc.		Verisign, Inc.
	B. Dickson		B. Dickson
	Twitter, Inc.		February 11, 2016
	October 12, 2015
	Problem Definition and Classification of BGP Route Leaks		Problem Definition and Classification of BGP Route Leaks
	draft-ietf-grow-route-leak-problem-definition-03		draft-ietf-grow-route-leak-problem-definition-04
	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 46		skipping to change at page 1, line 45
	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 April 14, 2016.		This Internet-Draft will expire on August 14, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3		2. Working Definition of Route Leaks . . . . . . . . . . . . . . 3
	3. Classification of Route Leaks Based on Documented Events . . 3		3. Classification of Route Leaks Based on Documented Events . . 3
	3.1. Type 1: U-Shaped 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: U-Shaped Turn with More Specific Prefix . . . . . 6		3.5. Type 5: Prefix Re-Origination with Data Path to
	3.6. Type 6: Prefix Re-Origination with Data Path to
	Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6		Legitimate Origin . . . . . . . . . . . . . . . . . . . . 6
	3.7. Type 7: Accidental Leak of Internal Prefixes and More		3.6. Type 6: Accidental Leak of Internal Prefixes and More
	Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6		Specifics . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Additional Comments about the Classification . . . . . . . . 7		4. Additional Comments about the Classification . . . . . . . . 7
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	9. Informative References . . . . . . . . . . . . . . . . . . . 8		9. 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][Toonk2015-B][
	Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in		Cowie2010][Madory][Zmijewski][Paseka][LRL][Khare] that result in
	significant disruptions to Internet routing are commonly called		significant disruptions to Internet routing are commonly called
	"route leaks". Examination of the details of some of these incidents		"route leaks". Examination of the details of some of these incidents
	reveals that they vary in their form and technical details. Before		reveals that they vary in their form and technical details. Before
	we can discuss solutions to "the route leak problem" we need a clear,		we can discuss solutions to "the route leak problem" we need a clear,
	technical definition of the problem and its most common forms. In		technical definition of the problem and its most common forms. In
	skipping to change at page 3, line 26		skipping to change at page 3, line 24
	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,
	transit provider, peer). For literature related to AS relationships		transit provider, peer). (For literature related to AS relationships
	and routing policies, see [Gao] [Luckie] [Gill]. For measurements of		and routing policies, see [Gao] [Luckie] [Gill]. For measurements of
	valley-free violations in Internet routing, see [Anwar] [Giotsas]		valley-free violations in Internet routing, see [Anwar] [Giotsas]
	[Wijchers].		[Wijchers].)
	The result of a route leak can be redirection of traffic through an		The result of a route leak can be redirection of traffic through an
	unintended path which may enable eavesdropping or traffic analysis,		unintended path which may enable eavesdropping or traffic analysis,
	and may or may not result in an overload or black-hole. Route leaks		and may or may not result in an overload or black-hole. Route leaks
	can be accidental or malicious, but most often arise from accidental		can be accidental or malicious, but most often arise from accidental
	misconfigurations.		misconfigurations.
	The above definition is not intended to be all encompassing.		The above definition is not intended to be all encompassing.
	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
	skipping to change at page 4, line 30		skipping to change at page 4, line 30
	+---------------+		+---------------+
	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".
	3.1. Type 1: U-Shaped Turn with Full Prefix		3.1. Type 1: Hairpin Turn with Full Prefix
	Description: A multi-homed AS learns a route from one upstream ISP		Description: A multi-homed AS learns a route from one upstream ISP
	and simply propagates it to another upstream ISP. Neither the prefix		and simply propagates it to another upstream ISP (the turn
	nor the AS path in the update is altered. This is similar to a		essentially resembling a hairpin). Neither the prefix nor the AS
	straight forward path-poisoning attack [Kapela-Pilosov], but with		path in the update is altered. This is similar to a straight forward
	full prefix. It should be noted that leaks of this type are often		path-poisoning attack [Kapela-Pilosov], but with full prefix. It
	accidental (i.e. not malicious). The update basically makes a		should be noted that leaks of this type are often accidental (i.e.
	U-shaped turn at the offending AS's multi-homed AS. The leak often		not malicious). The update basically makes a hairpin turn at the
	succeeds because the second ISP prefers customer announcement over		offending AS's multi-homed AS. The leak often succeeds because the
	peer announcement of the same prefix. Data packets would reach the		second ISP prefers customer announcement over peer announcement of
	legitimate destination albeit via the offending AS, unless they are		the same prefix. Data packets would reach the legitimate destination
	dropped at the offending AS due to its inability to handle resulting		albeit via the offending AS, unless they are dropped at the offending
	large volumes of traffic.		AS due to its inability to handle resulting large volumes of traffic.
	o Example incidents: Examples of Type 1 route-leak incidents are (1)		o Example incidents: Examples of Type 1 route-leak incidents are (1)
	the Dodo-Telstra incident in March 2012 [Huston2012], (2) the		the Dodo-Telstra incident in March 2012 [Huston2012], (2) the
	Moratel-PCCW route leak of Google prefixes in November 2012		VolumeDrive-Atrato incident in September 2014 [Madory], and (3)
	[Paseka], (3) the VolumeDrive-Atrato incident in September 2014		the massive Telekom Malaysia route leak of about 179,000 prefixes,
	[Madory], (4) the Hathway-Airtel route leak of 336 Google prefixes		which in turn Level3 accepted and propagated [Toonk2015-B].
	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].
	3.2. Type 2: Lateral ISP-ISP-ISP Leak		3.2. Type 2: Lateral ISP-ISP-ISP Leak
	Description: The term "lateral" here is synonymous with "non-transit"		Description: The term "lateral" here is synonymous with "non-transit"
	or "peer-to-peer". This type of route leak typically occurs when,		or "peer-to-peer". This type of route leak typically occurs when,
	for example, three sequential ISP peers (e.g. ISP-A, ISP-B, and ISP-		for example, three sequential ISP peers (e.g. ISP-A, ISP-B, and ISP-
	C) are involved, and ISP-B receives a route from ISP-A and in turn		C) are involved, and ISP-B receives a route from ISP-A and in turn
	leaks it to ISP-C. The typical routing policy between laterally		leaks it to ISP-C. The typical routing policy between laterally
	(i.e. non-transit) peering ISPs is that they should only propagate to		(i.e. non-transit) peering ISPs is that they should only propagate to
	each other their respective customer prefixes.		each other their respective customer prefixes.
	skipping to change at page 5, line 44		skipping to change at page 5, line 42
	o Example incidents: The incidents reported in [Mauch] include the		o Example incidents: The incidents reported in [Mauch] include the
	Type 3 leaks.		Type 3 leaks.
	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: Some of the example incidents cited for Type 1		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		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: U-Shaped Turn with More Specific Prefix		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
	and announces a subprefix (subsumed in the prefix) to another
	upstream ISP. The AS path in the update is not altered. Update is
	crafted by the offending AS to have a subprefix to maximize the
	success of the attack while reverse path is kept open by the path
	poisoning techniques as in [Kapela-Pilosov]. Data packets reach the
	legitimate destination albeit via the offending AS.
	o Example incidents: One example is the demo performed at DEFCON-16
	in August 2008 [Kapela-Pilosov]. Another example is the earlier-
	mentioned incident of route leaks from Telekom Malaysia via
	Level3, in which out of about 179,000 total route-leaked prefixes,
	about 10,000 were more specifics of previously announced less
	specific prefixes [Toonk2015-B]. [Note: An attacker who
	deliberately performs a Type 1 route leak (with full prefix) can
	just as easily perform a Type 5 route leak (with subprefix) to
	achieve a greater impact.]
	3.6. Type 6: Prefix Re-Origination with Data Path to Legitimate Origin
	Description: A multi-homed AS learns a route from one upstream ISP		Description: A multi-homed AS learns a route from one upstream ISP
	and announces the prefix to another upstream ISP as if it is being		and announces the prefix to another upstream ISP as if it is being
	originated by it (i.e. strips the received AS path, and re-originates		originated by it (i.e. strips the received AS path, and re-originates
	the prefix). This can be called re-origination or mis-origination.		the prefix). This can be called re-origination or mis-origination.
	However, somehow (not attributable to the use of path poisoning trick		However, somehow (not attributable to the use of path poisoning trick
	by the offending AS) a reverse path is present, and data packets		by the offending AS) a reverse path is present, and data packets
	reach the legitimate destination albeit via the offending AS. But		reach the legitimate destination albeit via the offending AS. But
	sometimes the reverse path may not be there, and data packets get		sometimes the reverse path may not be there, and data packets get
	dropped following receipt by the offending AS.		dropped following receipt by the offending AS.
	o Example incidents: Examples of Type 6 route leak include (1) the		o Example incidents: Examples of Type 5 route leak include (1) the
	China Telecom incident in April 2010 [Hiran][Cowie2010][Labovitz],		China Telecom incident in April 2010 [Hiran][Cowie2010][Labovitz],
	(2) the Belarusian GlobalOneBel route leak incidents in February-		(2) the Belarusian GlobalOneBel route leak incidents in February-
	March 2013 and May 2013 [Cowie2013], (3) the Icelandic Opin Kerfi-		March 2013 and May 2013 [Cowie2013], (3) the Icelandic Opin Kerfi-
	Simmin route leak incidents in July-August 2013 [Cowie2013], and		Simmin route leak incidents in July-August 2013 [Cowie2013], and
	(4) the Indosat route leak incident in April 2014 [Zmijewski].		(4) the Indosat route leak incident in April 2014 [Zmijewski].
			The reverse paths (i.e. data paths from the offending AS to the
			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.7. Type 7: Accidental Leak of Internal Prefixes and More Specifics		3.6. Type 6: Accidental Leak of Internal Prefixes and More Specifics
	Description: An offending AS simply leaks its internal prefixes to		Description: An offending AS simply leaks its internal prefixes to
	one or more of its transit-provider ASes and/or ISP peers. The		one or more of its transit-provider ASes and/or ISP peers. The
	leaked internal prefixes are often more specifics subsumed by an		leaked internal prefixes are often more specifics subsumed by an
	already announced less specific prefix. The more specifics were not		already announced less specific prefix. The more specifics were not
	intended to be routed in eBGP. Further, the AS receiving those leaks		intended to be routed in eBGP. Further, the AS receiving those leaks
	fails to filter them. Typically these leaked announcements are due		fails to filter them. Typically these leaked announcements are due
	to some transient failures within the AS; they are short-lived, and		to some transient failures within the AS; they are short-lived, and
	typically withdrawn quickly following the announcements. However,		typically withdrawn quickly following the announcements. However,
	these more specifics may momentarily cause the routes to be preferred		these more specifics may momentarily cause the routes to be preferred
	skipping to change at page 7, line 22		skipping to change at page 7, line 11
	and widely disruptive leak of internal routes happened recently in		and widely disruptive leak of internal routes happened recently in
	August 2014 when AS701 and AS705 leaked about 22,000 more		August 2014 when AS701 and AS705 leaked about 22,000 more
	specifics of already announced aggregates [Huston2014][Toonk2014].		specifics 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.
	It is also worth noting that Type 5 route leak involves a subprefix		Type 5 route leak (i.e. prefix mis-origination with data path to
	and is a special case of Type 1, which involves a full prefix.		legitimate origin) can also happen in conjunction with the AS
	Similarly, subprefix versions of other types of route leaks may also		relationship contexts in Types 2, 3, and 4. While these
	be considered, for example, for Types 2, 3, and 4. Similarly, Type 6		possibilities are acknowledged, simply enumerating more types to
	(i.e. prefix mis-origination with data path to legitimate origin) can		consider all such special cases does not add value as far as solution
	be also conceived to happen in conjunction with Types 2, 3, and 4.		development for route leaks is concerned. Hence, the special cases
	While these possibilities are acknowledged, simply enumerating more		mentioned here are not included in enumerating route leak types.
	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. Summary		5. 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.
	skipping to change at page 8, line 12		skipping to change at page 7, line 40
	No security considerations apply since this is a problem definition		No security considerations apply since this is a problem definition
	document.		document.
	7. IANA Considerations		7. IANA Considerations
	No updates to the registries are suggested by this document.		No updates to the registries are suggested by this document.
	8. Acknowledgements		8. Acknowledgements
	The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,		The authors wish to thank Jared Mauch, Jeff Haas, Warren Kumari,
	Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Ruediger		Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Job Snijders,
	Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow, and Sandy		Ruediger Volk, Andrei Robachevsky, Charles van Niman, Chris Morrow,
	Murphy for comments, suggestions, and critique. The authors are also		and Sandy Murphy for comments, suggestions, and critique. The
	thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim for		authors are also thankful to Padma Krishnaswamy, Oliver Borchert, and
	their comments and review.		Okhee Kim for their comments and review.
	9. Informative References		9. Informative References
	[Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P.,		[Anwar] Anwar, R., Niaz, H., Choffnes, D., Cunha, I., Gill, P.,
	and N. Katz-Bassett, "Investigating Interdomain Routing		and N. Katz-Bassett, "Investigating Interdomain Routing
	Policies in the Wild", ACM Internet Measurement		Policies in the Wild", ACM Internet Measurement
	Conference (IMC), October 2015,		Conference (IMC), October 2015,
	<http://www.cs.usc.edu/assets/007/94928.pdf>.		<http://www.cs.usc.edu/assets/007/94928.pdf>.
	[Cowie2010]		[Cowie2010]
	skipping to change at page 9, line 41		skipping to change at page 9, line 16
	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/>.
	[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>.
			[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		[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>.
	[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-
	skipping to change at page 11, line 40		skipping to change at page 11, line 20
	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		Brian Dickson
	Twitter, Inc.
	Email: bdickson@twitter.com		Email: brian.peter.dickson@gmail.com
End of changes. 24 change blocks.
	76 lines changed or deleted		61 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/