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