draft-ietf-grow-simple-leak-attack-bgpsec-no-help-01.txt		draft-ietf-grow-simple-leak-attack-bgpsec-no-help-02.txt
	GROW D. McPherson		GROW D. McPherson
	Internet-Draft Verisign, Inc.		Internet-Draft Verisign, Inc.
	Intended status: Informational S. Amante		Intended status: Informational S. Amante
	Expires: November 4, 2013 Level 3 Communications, Inc.		Expires: February 2, 2014 Level 3 Communications, Inc.
	E. Osterweil		E. Osterweil
	Verisign, Inc.		Verisign, Inc.
	D. Mitchell		D. Mitchell
	Twitter, Inc.		Twitter, Inc.
	May 3, 2013		August 1, 2013
	Route Leaks & MITM Attacks Against BGPSEC		Route-Leaks & MITM Attacks Against BGPSEC
	draft-ietf-grow-simple-leak-attack-bgpsec-no-help-01		draft-ietf-grow-simple-leak-attack-bgpsec-no-help-02
	Abstract		Abstract
	This document describes a very simple attack vector that illustrates		This document describes a very simple attack vector that illustrates
	how RPKI-enabled BGPSEC machinery as currently defined can be easily		how RPKI-enabled BGPSEC machinery as currently defined can be easily
	circumvented in order to launch a Man In The Middle (MITM) attack via		circumvented in order to launch a Man In The Middle (MITM) attack via
	BGP. It is meant to serve as input to the IETF's Secure Inter-Domain		BGP. It is meant to serve as input to the IETF's Global Routing
	Routing working group during routing security requirements		Operations Working group (GROW) during routing security requirements
	discussions and subsequent specification.		discussions and subsequent specification.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 4, 2013.		This Internet-Draft will expire on February 2, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. Informative References . . . . . . . . . . . . . . . . . . . . 6		6. Informative References . . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	This document describes a very simple attack vector that illustrates		This document describes a very simple attack vector that illustrates
	how RPKI-enabled BGPSEC [I-D.ietf-sidr-bgpsec-protocol] machinery, as		how RPKI-enabled BGPSEC [I-D.ietf-sidr-bgpsec-protocol] machinery, as
	currently defined, can be easily circumvented in order to launch a		currently defined, can be easily circumvented in order to launch a
	Man In The Middle (MITM) attack via BGP [RFC4271]. It is meant to		Man In The Middle (MITM) attack via BGP [RFC4271]. It is meant to
	serve as input to the IETF's SIDR Working Group during routing		serve as input to the IETF's Global Routing Operations Working Group
	security requirements discussions and subsequent specification.		(GROW) during routing security requirements discussions and
			subsequent specification.
	This draft shows evidence that the attack vector described herein is		This draft shows evidence that the attack vector described herein is
	extremely common, with over 9.6 million candidate instances being		extremely common, with over 9.6 million candidate instances being
	recorded since 2007. As a result of this evidence (and additional		recorded since 2007. As a result of this evidence and additional
	contextual knowledge), the authors believe the capability to prevent		contextual knowledge, the authors believe the capability to prevent
	leaks and MITM leak-attacks should be a first-order engineering		leaks and MITM leak-attacks should be a primary engineering objective
	objective in any secure routing architecture.		in any secure routing architecture.
	While the formal definition of a route leak has proven elusive in the		While the formal definition of a 'route-leak' has proven elusive in
	literature, their rampant occurrence and persistent operational		literature, the rampant occurrence and persistent operational threats
	threats have proven to be anything but elusive. This document is		have proven to be anything but uncommon. This document is intended
	intended to serve as an existence proof for this attack vector, and		to serve as a proof of existence for the referenced attack vector and
	any supplementary formal models are left for future work.		any supplementary formal models are left for future work.
	2. Discussion		2. Discussion
	In order to understand how a MITM attack can be launched with this		In order to understand how a Man In the Middle (MITM) Attack can be
	attack vector, assume a multi-homed Autonomous System (AS), AS1,		conducted using this attack vector, refer to the below example.
	connects to two ISPs (ISP1 & ISP2), and wishes to insert themselves
	in the data-path between a target network (prefix P) connected to
	ISP2 and systems in ISP1's network in order to launch a Man In The
	Middle (MITM) attack. Further, assume that an RPKI-enabled BGPSEC
	[I-D.ietf-sidr-bgpsec-protocol] as currently defined is fully
	deployed by all parties in this scenario and functioning as designed.
	+------+ +------+		Assume a multi-homed Autonomous System (AS), AS1, connects to two
	| ISP1 | | ISP2 |_		ISPs (ISP1 and ISP2) and wishes to insert themselves in the data-path
	+------+ +------ \		between target network (prefix P) connected to ISP2 and systems in
	\ / ( P )		ISP1's network in order to proceed with an MITM attack.
	\ / \___/
	+-----+
	| AS1 |
	+-----+
	This figure depicts a multi-homed AS1, who is connected to two		Assume that an RPKI-enabled BGPSEC deployment
	upstream ISPs (ISP1 and ISP2).		[I-D.ietf-sidr-bgpsec-protocol] is currently operational by all
			parties in the scenario and functioning as designed.
			+------+ peer +------+
			| ISP1 | <------> | ISP2 |_
			+------+ +------ \
			\ / ( P )--1.1.1.0/24
			\ customer / \___/
			\ /
			+-------+
			| AS1 |
			+-------+
			This figure depicts a multi-homed AS, AS1, that is a customer
			connected to two upstream ISPs (ISP1 and ISP2). ISP2 has a second
			customer, P, that is assigned prefix 1.1.1.0/24.
	Network operators on the Internet today typically prefer customer		Network operators on the Internet today typically prefer customer
	routes over routes learned from bi-lateral or settlement free peers.		routes over routes learned from bi-lateral or settlement free peers.
	Network operators commonly accomplish this via application of one or		Network operators commonly accomplish this via application of one or
	more BGP [RFC4271] Path Attributes, most commonly, LOCAL_PREF as		more BGP [RFC4271] Path Attributes, most commonly, LOCAL_PREF as
	illustrated in [RFC1998], that are evaluated earlier in the BGP Path		illustrated in [RFC1998], that are evaluated earlier in the BGP Path
	Selection process than AS_PATH length.		Selection process than AS_PATH length.
	As currently defined, [I-D.ietf-sidr-bgpsec-protocol] only provides		As currently defined, [I-D.ietf-sidr-bgpsec-protocol] only provides
	two functions:		two methods for validating an announced NLRI:
	1. Is an Autonomous System authorized to originate an IP prefix?		1. Is the Autonomous System authorized to originate an IP prefix?
	2. Is the AS_PATH (or any similarly derived attribute such as		2. Is the AS_PATH (or any similarly derived attribute such as
	BGPSEC_Path) in the route the same as the list of ASes through		BGPSEC_Path) in the route the same as the list of ASes through
	which the NLRI traveled?		which the NLRI traveled?
	In order for an attacker (AS1) to divert traffic from ISP1 for prefix		In order for an attacker (AS1) to divert traffic from ISP1 toward
	P through their AS they simply fail to scope the propagation of the		prefix P through their AS, AS1 must simply fail to scope the
	target prefix P (received from ISP2) by announcing a (syntactically		propagation of the target prefix P (1.1.1.0/24), received from ISP2.
	correct) BGPSEC update for prefix P to ISP1. This vulnerability is		This is completed by announcing a syntactically correct BGPSEC update
	what the authors refer to as a 'route leak' or a 'leak-attack' (when		for prefix P to ISP1.
	intent aligns with actions). It is important to note that the
	default behavior in BGP [RFC4271] is to announce all best paths to
	external BGP peers, unless explicitly scoped by a BGP speaker through
	configuration. Because ISP1 prefers prefixes learned from customers
	(AS1) over prefixes learned from peers (ISP2), they begin forwarding
	traffic for prefix P destinations through the attacker's AS (AS1).
	Voila!
	It is important to note that the route leaks described herein are NOT		This vulnerability is what authors refer to as a 'route-leak' or
	'misorginiations.' Rather, these are cases in which routes are		'leak-attack', respectively, when intent aligns with actions. It is
	propagated with their authentic origins, but are misdirected through		important to note that the default behavior in BGP [RFC4271] is to
	unexpected intermediaries.		announce all best paths to external BGP peers, unless explicitly
			configured otherwise by a BGP speaker. Because ISP1 prefers prefixes
			learned from customers (AS1) over prefixes learned from peers (ISP2),
			ISP1 begins forwarding traffic for prefix P through the attacker
			(AS1), thus successfully completing the route hijack.
			It is important to note that the route-leaks described herein are not
			illegal NLRI origins. These are cases in which routes are propagated
			with an authentic origin AS, as per [RFC6480]. Furthermore, the
			BGPSEC route for prefix P is propagated through intermediate ASN's,
			in this case AS1, that each applies a valid BGPSEC_Path attribute to
			the route. Ultimately, ISP1 receives two, valid BGPSEC routes for
			prefix P, (one directly from ISP2 and one directly from AS1);
			however, due to the local policy implemented within ISP1, it prefers
			the customer route, due to higher LOCAL_PREF, received from customer
			AS1. This will cause ISP1 to misdirect packets through a invalid
			intermediate ASN, AS1, to reach prefix P.
	It should be understood that any multi-homed AS can potentially		It should be understood that any multi-homed AS can potentially
	launch such an attack, even if through simple misconfiguration, as is		launch such an attack, even if through simple misconfiguration, which
	a common occurrence today on the Internet. As a matter of fact,		is a common occurrence on the Internet. As a matter of fact,
	advertising these prefixes is the default behavior is many BGP		advertising these prefixes is the default behavior of many BGP
	implementations, and explicit action must be taken to not advertise		implementations and explicit action must be taken to not advertise
	all prefixes learned in BGP. Such occurrences have been historically		all prefixes learned in BGP.
	archived [ROUTE_LEAK_DETECTION_TOOL] and presented to the operational
	community [NANOG_LEAK_TALK] since 2007. To date, over 9.6 million
	such events have been recorded and are queriable
	[ROUTE_LEAK_DETECTION_TOOL]. This corpus serves as a low pass
	filter, and likely contains some degree of false positives. Thus,
	while some may debate how many of the occurrences were malicious, or
	how many were actually real leaks, the corpus itself (and its sheer
	size) serves as evidence of the large magnitude of this problem.
	Determination of benign versus malicious intent in these situations
	is usually imperceptible, and as such, preventative controls are
	requisite.
	To illustrate the above point, consider the events that transpired on		Such occurrences have been historically archived and presented to the
	November 6th, 2012 [LEAK_ATTACK_ON_GOOGLE]. On that day a large		operational community since 2007 [NANOG_LEAK_TALK]. To date, over
	Internet property (who services hundreds of billions of public end		9.6 million such events have been recorded within the
	user transactions every day) became unreachable for roughly 27		[ROUTE_LEAK_DETECTION_TOOL].
	minutes. At a transaction volume like that, an outage of 27 minutes
	is a very visible (and likely financially measurable) event. In this		Said dataset serves as a basis for analysis and likely contains a
	case, services became unreachable because a peered AS improperly		degree of false positives. Even while some may debate how many of
	propagated the impacted party's AS' prefix(s). In leaks such as		the incidents were malicious route-leaks versus accidental
	this, there exists public acknowledgment by the impacted party that		misconfiguration that resulted in leaked routes, the size of the
			dataset provides evidence of the magnitude of the issue.
			Determination of intent in these situations is difficult to ascertain
			and requires preventative controls be put in place to mitigate
			occurrences of route-leaks. In order to illustrate the difficulty in
			determining intent, consider the events that transpired on November
			6th, 2012 [LEAK_ATTACK_ON_GOOGLE].
			Google is the largest Internet site and processes billions of end-
			user transactions per day. It became unreachable for approximately
			27 minutes. At their scale, an outage of 27 minutes is extremely
			visible and, most likely, a financially measurable event. In this
			example, its services became unreachable because a BGP peer
			improperly propagated the company's prefixes. Because this was a
			highly visible outage, there exists a public acknowledgment of
			improper intent executed by one of Google's peers, proving that
	[RFC6480] and [I-D.ietf-sidr-bgpsec-protocol] would be unable to		[RFC6480] and [I-D.ietf-sidr-bgpsec-protocol] would be unable to
	detect or remediate this attack.		detect or prevent this type of attack.
	In an environment where [I-D.ietf-sidr-bgpsec-protocol] is fully		In an environment where [I-D.ietf-sidr-bgpsec-protocol] is fully
	deployed, it is expected that there would be high assurances that		deployed, it is expected that there would be substantial assurances
	guard the syntactic integrity of the AS_PATH (or BGPSEC_Path)		as to the semantic integrity of the AS_PATH or BGPSEC_Path attribute.
	attribute. As such, one would expect that such an attribute would,		An operator would expect that such an attribute would accurately
	indeed, accurately reflect the attacker's AS number in the		reflect the attacker's ASN in the appropriate location of the
	appropriate location of the AS_PATH; however, it would not prevent an		BGPSEC_Path. Unfortunately, as currently designed,
	attacker from inserting his AS in the first place. That is, nothing		[I-D.ietf-sidr-bgpsec-protocol] is unable to distinguish whether an
	in [I-D.ietf-sidr-bgpsec-protocol] would stop an attacker from		ASN is allowed, by policy, to add their ASN within the BGPSEC_Path
	launching this type of leak-attack.		attribute before the BGP update is propagated to downstream ASNs.
			This proves that mechanisms defined in
			[I-D.ietf-sidr-bgpsec-protocol] would not stop an attacker from
			completing this type of attack.
	Discussion of out of band methods to mitigate this attack are		Discussion of out of band methods to mitigate this attack are
	important but beyond the scope of this document, as its objective is		important; albeit beyond the scope of this document. This document
	to inform routing protocol design choices currently being considered		is meant to provide input into routing protocol design choices being
	within the IETF's SIDR Working Group.		considered within the IETF, and to foster discussion of the practical
			implications of "policy" and "intent" in operational routing system
			security.
	3. Acknowledgements		3. Acknowledgements
	4. IANA Considerations		4. IANA Considerations
			There are no actions for IANA in the document.
	5. Security Considerations		5. Security Considerations
	This document describes an attack on an RPKI-enabled BGPSEC and is		This document describes an attack on an RPKI-enabled BGPSEC and is
	meant to inform the IETF Secure Inter-Domain Routing working group on		meant to inform the IETF community that this vulnerability exists as
	the vulnerability that exists as a result of "leaks" and attacks that		a result of route-leaks and attacks that conform to this type of
	conform to this type of behavior.		behavior, and that operators should not assume that that work items
			and designs address these operational security issues.
	The authors believe the capability to prevent leaks and leak-attacks		The authors believe the capability to prevent route-leaks and leak-
	should be a first-order engineering objective in any secure routing		attacks should be a primary engineering objective in any secure
	architecture.		routing architecture.
	6. Informative References		6. Informative References
	[I-D.ietf-sidr-bgpsec-protocol]		[I-D.ietf-sidr-bgpsec-protocol]
	Lepinski, M., "BGPSEC Protocol Specification",		Lepinski, M., "BGPSEC Protocol Specification",
	February 2013.		February 2013.
	[LEAK_ATTACK_ON_GOOGLE]		[LEAK_ATTACK_ON_GOOGLE]
	CloudFlare, CF., "Why Google Went Offline Today and a Bit		CloudFlare, CF., "Why Google Went Offline Today and a Bit
	about How the Internet Works", November 2012, <http://		about How the Internet Works", November 2012, <http://
	skipping to change at page 7, line 21		skipping to change at page 8, line 4
	Email: shane@level3.net		Email: shane@level3.net
	Eric Osterweil		Eric Osterweil
	Verisign, Inc.		Verisign, Inc.
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	USA		USA
	Phone: +1 703.948.3200		Phone: +1 703.948.3200
	Email: eosterweil@verisign.com		Email: eosterweil@verisign.com
	Dave Mitchell		Dave Mitchell
	Twitter, Inc.		Twitter, Inc.
			1355 Market Street, Suite 900
			San Francisco, CA 94103
			USA
	Email: dave@twitter.com		Email: dave@twitter.com
End of changes. 27 change blocks.
	101 lines changed or deleted		131 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/