idnits 2.17.1 draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 7, 2012) is 4187 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR D. McPherson 3 Internet-Draft Verisign, Inc. 4 Intended status: Informational S. Amante 5 Expires: May 11, 2013 Level 3 Communications, Inc. 6 E. Osterweil 7 Verisign, Inc. 8 November 7, 2012 10 Route Leaks & MITM Attacks Against BGPSEC 11 draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 13 Abstract 15 This document describes a very simple attack vector that illustrates 16 how RPKI-enabled BGPSEC machinery as currently defined can be easily 17 circumvented in order to launch a Man In The Middle (MITM) attack via 18 BGP. It is meant to serve as input to the IETF's Secure Inter-Domain 19 Routing working group during routing security requirements 20 discussions and subsequent specification. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 11, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 This document describes a very simple attack vector that illustrates 67 how RPKI-enabled BGPSEC [I-D.ietf-sidr-bgpsec-protocol] machinery, as 68 currently defined, can be easily circumvented in order to launch a 69 Man In The Middle (MITM) attack via BGP [RFC4271]. It is meant to 70 serve as input to the IETF's SIDR Working Group during routing 71 security requirements discussions and subsequent specification. 73 This draft shows evidence that the attack vector described herein is 74 extremely common, with over 9.6 million candidate instances being 75 recorded since 2007. As a result of this evidence (and additional 76 contextual knowledge), the authors believe the capability to prevent 77 leaks and MITM leak-attacks should be a first-order engineering 78 objective in any secure routing architecture. 80 While the formal definition of a route leak has proven elusive in the 81 literature, their rampant occurrence and persistent operational 82 threats have proven to be anything but elusive. This document is 83 intended to serve as an existence proof for this threat vector, and 84 any supplementary formal models are left for future work. 86 2. Discussion 88 In order to understand how a MITM attack can be launched with this 89 attack vector, assume a multi-homed Autonomous System (AS), AS1, 90 connects to two ISPs (ISP1 & ISP2), and wishes to insert themselves 91 in the data-path between a target network (prefix P) connected to 92 ISP2 and systems in ISP1's network in order to launch a Man In The 93 Middle (MITM) attack. Further, assume that an RPKI-enabled BGPSEC 94 [I-D.ietf-sidr-bgpsec-protocol] as currently defined is fully 95 deployed by all parties in this scenario and functioning as designed. 97 +------+ +------+ 98 | ISP1 | | ISP2 |_ 99 +------+ +------ \ 100 \ / ( P ) 101 \ / \___/ 102 +-----+ 103 | AS1 | 104 +-----+ 106 This figure depicts a multi-homed AS1, who is connected to two 107 upstream ISPs (ISP1 and ISP2). 109 Network operators on the Internet today typically prefer customer 110 routes over routes learned from bi-lateral or settlement free peers. 111 Network operators commonly accomplish this via application of one or 112 more BGP [RFC4271] Path Attributes, most commonly, LOCAL_PREF as 113 illustrated in [RFC1998], that are evaluated earlier in the BGP Path 114 Selection process than AS_PATH length. 116 As currently defined, [I-D.ietf-sidr-bgpsec-protocol] only provides 117 two functions: 119 1. Is an Autonomous System authorized to originate an IP prefix? 120 2. Is the AS_PATH (or any similarly derived attribute such as 121 BGPSEC_Path) in the route the same as the list of ASes through 122 which the NLRI traveled? 124 In order for an attacker (AS1) to divert traffic from ISP1 for prefix 125 P through their AS they simply fail to scope the propagation of the 126 target prefix P (received from ISP2) by announcing a (syntactically 127 correct) BGPSEC update for prefix P to ISP1. This vulnerability is 128 what the authors refer to as a 'route leak' or a 'leak-attack' (when 129 intent aligns with actions). It is important to note that the 130 default behavior in BGP [RFC4271] is to announce all best paths to 131 external BGP peers, unless explicitly scoped by a BGP speaker through 132 configuration. Because ISP1 prefers prefixes learned from customers 133 (AS1) over prefixes learned from peers (ISP2), they begin forwarding 134 traffic for prefix P destinations through the attacker's AS (AS1). 135 Voila! 137 It is important to note that the route leaks described herein are NOT 138 'misorginiations.' Rather, these are cases in which routes are 139 propagated with their authentic origins, but are misdirected through 140 unexpected intermediaries. 142 It should be understood that any multi-homed AS can potentially 143 launch such an attack, even if through simple misconfiguration, as is 144 a common occurrence today on the Internet. As a matter of fact, 145 advertising these prefixes is the default behavior is many BGP 146 implementations, and explicit action must be taken to not advertise 147 all prefixes learned in BGP. Such occurrences have been historically 148 archived [ROUTE_LEAK_DETECTION_TOOL] and presented to the operational 149 community [NANOG_LEAK_TALK] since 2007. To date, over 9.6 million 150 such events have been recorded and are queriable 151 [ROUTE_LEAK_DETECTION_TOOL]. This corpus serves as a low pass 152 filter, and likely contains some degree of false positives. Thus, 153 while some may debate how many of the occurrences were malicious, or 154 how many were actually real leaks, the corpus itself (and its sheer 155 size) serves as evidence of the large magnitude of this problem. 156 Determination of benign versus malicious intent in these situations 157 is usually imperceptible, and as such, preventative controls are 158 requisite. 160 To illustrate the above point, consider the events that transpired on 161 November 6th, 2012 [LEAK_ATTACK_ON_GOOGLE]. On that day a large 162 Internet property (who services hundreds of billions of public end 163 user transactions every day) became unreachable for roughly 27 164 minutes. At a transaction volume like that, an outage of 27 minutes 165 is a very visible (and likely financially measurable) event. In this 166 case, services became unreachable because a peered AS improperly 167 propagated the impacted party's AS' prefix(s). In leaks such as 168 this, there exists public acknowledgment by the impacted party that 169 [RFC6480] and [I-D.ietf-sidr-bgpsec-protocol] would be unable to 170 detect or remediate this attack. 172 In an environment where [I-D.ietf-sidr-bgpsec-protocol] is fully 173 deployed, it is expected that there would be high assurances that 174 guard the syntactic integrity of the AS_PATH (or BGPSEC_Path) 175 attribute. As such, one would expect that such an attribute would, 176 indeed, accurately reflect the attacker's AS number in the 177 appropriate location of the AS_PATH; however, it would not prevent an 178 attacker from inserting his AS in the first place. That is, nothing 179 in [I-D.ietf-sidr-bgpsec-protocol] would stop an attacker from 180 launching this type of leak-attack. 182 Discussion of out of band methods to mitigate this attack are beyond 183 the scope of this document, as its objective is to inform routing 184 protocol design choices currently being considered within the IETF's 185 SIDR Working Group. 187 3. Acknowledgements 189 4. IANA Considerations 191 5. Security Considerations 193 This document describes an attack on an RPKI-enabled BGPSEC and is 194 meant to inform the IETF Secure Inter-Domain Routing working group on 195 the vulnerability that exists as a result of "leaks" and attacks that 196 conform to this type of behavior. 198 The authors believe the capability to prevent leaks and leak-attacks 199 should be a first-order engineering objective in any secure routing 200 architecture. 202 6. Informative References 204 [I-D.ietf-sidr-bgpsec-protocol] 205 Lepinski, M., "BGPSEC Protocol Specification", 206 draft-ietf-sidr-bgpsec-protocol-06 (work in progress), 207 October 2012. 209 [LEAK_ATTACK_ON_GOOGLE] 210 CloudFlare, CF., "Why Google Went Offline Today and a Bit 211 about How the Internet Works", November 2012, . 215 [NANOG_LEAK_TALK] 216 Mauch, J., "Detecting Routing Leaks by Counting", 217 October 2007, . 220 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 221 Community Attribute in Multi-home Routing", RFC 1998, 222 August 1996. 224 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 225 Protocol 4 (BGP-4)", RFC 4271, January 2006. 227 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 228 Secure Internet Routing", RFC 6480, February 2012. 230 [ROUTE_LEAK_DETECTION_TOOL] 231 Mauch, J., "BGP Routing Leak Detection System Routing Leak 232 Detection System", September 2007, 233 . 235 Authors' Addresses 237 Danny McPherson 238 Verisign, Inc. 239 12061 Bluemont Way 240 Reston, VA 20190 241 USA 243 Phone: +1 703.948.3200 244 Email: dmcpherson@verisign.com 245 Shane Amante 246 Level 3 Communications, Inc. 247 1025 Eldorado Boulevard 248 Broomfield, CO 80021 249 US 251 Phone: +1 720.888.1000 252 Email: shane@level3.net 254 Eric Osterweil 255 Verisign, Inc. 256 12061 Bluemont Way 257 Reston, VA 20190 258 USA 260 Email: eosterweil@verisign.com