--- 1/draft-ietf-grow-simple-leak-attack-bgpsec-no-help-01.txt 2013-08-01 09:14:20.860460105 -0700 +++ 2/draft-ietf-grow-simple-leak-attack-bgpsec-no-help-02.txt 2013-08-01 09:14:20.880460624 -0700 @@ -1,212 +1,240 @@ GROW D. McPherson Internet-Draft Verisign, Inc. Intended status: Informational S. Amante -Expires: November 4, 2013 Level 3 Communications, Inc. +Expires: February 2, 2014 Level 3 Communications, Inc. E. Osterweil Verisign, Inc. D. Mitchell Twitter, Inc. - May 3, 2013 + August 1, 2013 - Route Leaks & MITM Attacks Against BGPSEC - draft-ietf-grow-simple-leak-attack-bgpsec-no-help-01 + Route-Leaks & MITM Attacks Against BGPSEC + draft-ietf-grow-simple-leak-attack-bgpsec-no-help-02 Abstract This document describes a very simple attack vector that illustrates how RPKI-enabled BGPSEC machinery as currently defined can be easily 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 - Routing working group during routing security requirements + BGP. It is meant to serve as input to the IETF's Global Routing + Operations Working group (GROW) during routing security requirements discussions and subsequent specification. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document describes a very simple attack vector that illustrates how RPKI-enabled BGPSEC [I-D.ietf-sidr-bgpsec-protocol] machinery, as currently defined, can be easily circumvented in order to launch a 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 - security requirements discussions and subsequent specification. + serve as input to the IETF's Global Routing Operations Working Group + (GROW) during routing security requirements discussions and + subsequent specification. This draft shows evidence that the attack vector described herein is extremely common, with over 9.6 million candidate instances being - recorded since 2007. As a result of this evidence (and additional - contextual knowledge), the authors believe the capability to prevent - leaks and MITM leak-attacks should be a first-order engineering - objective in any secure routing architecture. + recorded since 2007. As a result of this evidence and additional + contextual knowledge, the authors believe the capability to prevent + leaks and MITM leak-attacks should be a primary engineering objective + in any secure routing architecture. - While the formal definition of a route leak has proven elusive in the - literature, their rampant occurrence and persistent operational - threats have proven to be anything but elusive. This document is - intended to serve as an existence proof for this attack vector, and + While the formal definition of a 'route-leak' has proven elusive in + literature, the rampant occurrence and persistent operational threats + have proven to be anything but uncommon. This document is intended + to serve as a proof of existence for the referenced attack vector and any supplementary formal models are left for future work. 2. Discussion - In order to understand how a MITM attack can be launched with this - attack vector, assume a multi-homed Autonomous System (AS), AS1, - 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. + In order to understand how a Man In the Middle (MITM) Attack can be + conducted using this attack vector, refer to the below example. - +------+ +------+ - | ISP1 | | ISP2 |_ + Assume a multi-homed Autonomous System (AS), AS1, connects to two + ISPs (ISP1 and ISP2) and wishes to insert themselves in the data-path + between target network (prefix P) connected to ISP2 and systems in + ISP1's network in order to proceed with an MITM attack. + + Assume that an RPKI-enabled BGPSEC deployment + [I-D.ietf-sidr-bgpsec-protocol] is currently operational by all + parties in the scenario and functioning as designed. + + +------+ peer +------+ + | ISP1 | <------> | ISP2 |_ +------+ +------ \ - \ / ( P ) - \ / \___/ - +-----+ + \ / ( P )--1.1.1.0/24 + \ customer / \___/ + \ / + +-------+ | AS1 | - +-----+ + +-------+ - This figure depicts a multi-homed AS1, who is connected to two - upstream ISPs (ISP1 and ISP2). + 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 routes over routes learned from bi-lateral or settlement free peers. Network operators commonly accomplish this via application of one or more BGP [RFC4271] Path Attributes, most commonly, LOCAL_PREF as illustrated in [RFC1998], that are evaluated earlier in the BGP Path Selection process than AS_PATH length. 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 BGPSEC_Path) in the route the same as the list of ASes through which the NLRI traveled? - In order for an attacker (AS1) to divert traffic from ISP1 for prefix - P through their AS they simply fail to scope the propagation of the - target prefix P (received from ISP2) by announcing a (syntactically - correct) BGPSEC update for prefix P to ISP1. This vulnerability is - what the authors refer to as a 'route leak' or a 'leak-attack' (when - 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! + In order for an attacker (AS1) to divert traffic from ISP1 toward + prefix P through their AS, AS1 must simply fail to scope the + propagation of the target prefix P (1.1.1.0/24), received from ISP2. + This is completed by announcing a syntactically correct BGPSEC update + for prefix P to ISP1. - It is important to note that the route leaks described herein are NOT - 'misorginiations.' Rather, these are cases in which routes are - propagated with their authentic origins, but are misdirected through - unexpected intermediaries. + This vulnerability is what authors refer to as a 'route-leak' or + 'leak-attack', respectively, when 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 + 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 - launch such an attack, even if through simple misconfiguration, as is - a common occurrence today on the Internet. As a matter of fact, - advertising these prefixes is the default behavior is many BGP - implementations, and explicit action must be taken to not advertise - all prefixes learned in BGP. Such occurrences have been historically - 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. + launch such an attack, even if through simple misconfiguration, which + is a common occurrence on the Internet. As a matter of fact, + advertising these prefixes is the default behavior of many BGP + implementations and explicit action must be taken to not advertise + all prefixes learned in BGP. - To illustrate the above point, consider the events that transpired on - November 6th, 2012 [LEAK_ATTACK_ON_GOOGLE]. On that day a large - Internet property (who services hundreds of billions of public end - user transactions every day) became unreachable for roughly 27 - minutes. At a transaction volume like that, an outage of 27 minutes - is a very visible (and likely financially measurable) event. In this - case, services became unreachable because a peered AS improperly - propagated the impacted party's AS' prefix(s). In leaks such as - this, there exists public acknowledgment by the impacted party that + Such occurrences have been historically archived and presented to the + operational community since 2007 [NANOG_LEAK_TALK]. To date, over + 9.6 million such events have been recorded within the + [ROUTE_LEAK_DETECTION_TOOL]. + + Said dataset serves as a basis for analysis and likely contains a + degree of false positives. Even while some may debate how many of + the incidents were malicious route-leaks versus accidental + 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 - detect or remediate this attack. + detect or prevent this type of attack. In an environment where [I-D.ietf-sidr-bgpsec-protocol] is fully - deployed, it is expected that there would be high assurances that - guard the syntactic integrity of the AS_PATH (or BGPSEC_Path) - attribute. As such, one would expect that such an attribute would, - indeed, accurately reflect the attacker's AS number in the - appropriate location of the AS_PATH; however, it would not prevent an - attacker from inserting his AS in the first place. That is, nothing - in [I-D.ietf-sidr-bgpsec-protocol] would stop an attacker from - launching this type of leak-attack. + deployed, it is expected that there would be substantial assurances + as to the semantic integrity of the AS_PATH or BGPSEC_Path attribute. + An operator would expect that such an attribute would accurately + reflect the attacker's ASN in the appropriate location of the + BGPSEC_Path. Unfortunately, as currently designed, + [I-D.ietf-sidr-bgpsec-protocol] is unable to distinguish whether an + ASN is allowed, by policy, to add their ASN within the BGPSEC_Path + 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 - important but beyond the scope of this document, as its objective is - to inform routing protocol design choices currently being considered - within the IETF's SIDR Working Group. + important; albeit beyond the scope of this document. This document + is meant to provide input into routing protocol design choices being + considered within the IETF, and to foster discussion of the practical + implications of "policy" and "intent" in operational routing system + security. 3. Acknowledgements 4. IANA Considerations + There are no actions for IANA in the document. + 5. Security Considerations This document describes an attack on an RPKI-enabled BGPSEC and is - meant to inform the IETF Secure Inter-Domain Routing working group on - the vulnerability that exists as a result of "leaks" and attacks that - conform to this type of behavior. + meant to inform the IETF community that this vulnerability exists as + a result of route-leaks and attacks that conform to this type of + 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 - should be a first-order engineering objective in any secure routing - architecture. + The authors believe the capability to prevent route-leaks and leak- + attacks should be a primary engineering objective in any secure + routing architecture. 6. Informative References [I-D.ietf-sidr-bgpsec-protocol] Lepinski, M., "BGPSEC Protocol Specification", February 2013. [LEAK_ATTACK_ON_GOOGLE] CloudFlare, CF., "Why Google Went Offline Today and a Bit about How the Internet Works", November 2012,