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/