idnits 2.17.1 draft-ietf-grow-simple-leak-attack-bgpsec-no-help-04.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 30, 2014) is 3620 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 1, 2014 Level 3 Communications, Inc. 6 E. Osterweil 7 Verisign, Inc. 8 D. Mitchell 9 Twitter, Inc. 10 April 30, 2014 12 Route-Leaks & MITM Attacks Against BGPSEC 13 draft-ietf-grow-simple-leak-attack-bgpsec-no-help-04 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 Global Routing 21 Operations Working group (GROW) 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 1, 2014. 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 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 Global Routing Operations Working Group 73 (GROW) during routing security requirements discussions and 74 subsequent specification. 76 This draft shows evidence that the attack vector described herein is 77 extremely common, with over 9.6 million candidate instances being 78 recorded since 2007. As a result of this evidence and additional 79 contextual knowledge, the authors believe the capability to prevent 80 leaks and MITM leak-attacks should be a primary engineering objective 81 in any secure routing architecture. 83 While the formal definition of a 'route-leak' has proven elusive in 84 literature, the rampant occurrence and persistent operational threats 85 have proven to be anything but uncommon. This document is intended 86 to serve as a proof of existence for the referenced attack vector and 87 any supplementary formal models are left for future work. 89 2. Discussion 91 In order to understand how a Man In the Middle (MITM) Attack can be 92 conducted using this attack vector, refer to the below example. 94 Assume a multi-homed Autonomous System (AS), AS1, connects to two 95 ISPs (ISP1 and ISP2) and wishes to insert themselves in the data-path 96 between target network (prefix P) connected to ISP2 and systems in 97 ISP1's network in order to proceed with an MITM attack. 99 Assume that an RPKI-enabled BGPSEC deployment 100 [I-D.ietf-sidr-bgpsec-protocol] is currently operational by all 101 parties in the scenario and functioning as designed. 103 +------+ peer +------+ 104 | ISP1 | <------> | ISP2 |_ 105 +------+ +------ \ 106 \ / ( P )--1.1.1.0/24 107 \ customer / \___/ 108 \ / 109 +-------+ 110 | AS1 | 111 +-------+ 113 This figure depicts a multi-homed AS, AS1, that is a customer 114 connected to two upstream ISPs (ISP1 and ISP2). ISP2 has a second 115 customer, P, that is assigned prefix 1.1.1.0/24. 117 Network operators on the Internet today typically prefer customer 118 routes over routes learned from bi-lateral or settlement free peers. 119 Network operators commonly accomplish this via application of one or 120 more BGP [RFC4271] Path Attributes, most commonly, LOCAL_PREF as 121 illustrated in [RFC1998], that are evaluated earlier in the BGP Path 122 Selection process than AS_PATH length. 124 As currently defined, [I-D.ietf-sidr-bgpsec-protocol] only provides 125 two methods for validating an announced NLRI: 127 1. Is the Autonomous System authorized to originate an IP prefix? 128 2. Is the AS_PATH (or any similarly derived attribute such as 129 BGPSEC_Path) in the route the same as the list of ASes through 130 which the NLRI traveled? 132 In order for an attacker (AS1) to divert traffic from ISP1 toward 133 prefix P through their AS, AS1 must simply fail to scope the 134 propagation of the target prefix P (1.1.1.0/24), received from ISP2. 135 This is completed by announcing a syntactically correct BGPSEC update 136 for prefix P to ISP1. 138 This vulnerability is what authors refer to as a 'route-leak' or 139 'leak-attack', respectively, when intent aligns with actions. It is 140 important to note that the default behavior in BGP [RFC4271] is to 141 announce all best paths to external BGP peers, unless explicitly 142 configured otherwise by a BGP speaker. Because ISP1 prefers prefixes 143 learned from customers (AS1) over prefixes learned from peers (ISP2), 144 ISP1 begins forwarding traffic for prefix P through the attacker 145 (AS1), thus successfully completing the route hijack. 147 It is important to note that the route-leaks described herein are not 148 illegal NLRI origins. These are cases in which routes are propagated 149 with an authentic origin AS, as per [RFC6480]. Furthermore, the 150 BGPSEC route for prefix P is propagated through intermediate ASN's, 151 in this case AS1, that each applies a valid BGPSEC_Path attribute to 152 the route. Ultimately, ISP1 receives two, valid BGPSEC routes for 153 prefix P, (one directly from ISP2 and one directly from AS1); 154 however, due to the local policy implemented within ISP1, it prefers 155 the customer route, due to higher LOCAL_PREF, received from customer 156 AS1. This will cause ISP1 to misdirect packets through a invalid 157 intermediate ASN, AS1, to reach prefix P. 159 It should be understood that any multi-homed AS can potentially 160 launch such an attack, even if through simple misconfiguration, which 161 is a common occurrence on the Internet. As a matter of fact, 162 advertising these prefixes is the default behavior of many BGP 163 implementations and explicit action must be taken to not advertise 164 all prefixes learned in BGP. 166 Such occurrences have been historically archived and presented to the 167 operational community since 2007 [NANOG_LEAK_TALK]. To date, over 168 9.6 million such events have been recorded within the 169 [ROUTE_LEAK_DETECTION_TOOL]. 171 Said dataset serves as a basis for analysis and likely contains a 172 degree of false positives. Even while some may debate how many of 173 the incidents were malicious route-leaks versus accidental 174 misconfiguration that resulted in leaked routes, the size of the 175 dataset provides evidence of the magnitude of the issue. 177 Determination of intent in these situations is difficult to ascertain 178 and requires preventative controls be put in place to mitigate 179 occurrences of route-leaks. In order to illustrate the difficulty in 180 determining intent, consider the events that transpired on November 181 6th, 2012 [LEAK_ATTACK_ON_GOOGLE]. 183 Google is the largest Internet site and processes billions of end- 184 user transactions per day. It became unreachable for approximately 185 27 minutes. At their scale, an outage of 27 minutes is extremely 186 visible and, most likely, a financially measurable event. In this 187 example, its services became unreachable because a BGP peer 188 improperly propagated the company's prefixes. Because this was a 189 highly visible outage, there exists a public acknowledgment of 190 improper intent executed by one of Google's peers, proving that 191 [RFC6480] and [I-D.ietf-sidr-bgpsec-protocol] would be unable to 192 detect or prevent this type of attack. 194 In an environment where [I-D.ietf-sidr-bgpsec-protocol] is fully 195 deployed, it is expected that there would be substantial assurances 196 as to the semantic integrity of the AS_PATH or BGPSEC_Path attribute. 197 An operator would expect that such an attribute would accurately 198 reflect the attacker's ASN in the appropriate location of the 199 BGPSEC_Path. Unfortunately, as currently designed, 200 [I-D.ietf-sidr-bgpsec-protocol] is unable to distinguish whether an 201 ASN is allowed, by policy, to add their ASN within the BGPSEC_Path 202 attribute before the BGP update is propagated to downstream ASNs. 203 This proves that mechanisms defined in 204 [I-D.ietf-sidr-bgpsec-protocol] would not stop an attacker from 205 completing this type of attack. 207 It should be noted that the attack scenario described in this 208 document can be mitigated by performing proper route filtering 209 techniques. 211 Discussion of out of band methods to mitigate this attack are 212 important; albeit beyond the scope of this document. This document 213 is meant to provide input into routing protocol design choices being 214 considered within the IETF, and to foster discussion of the practical 215 implications of "policy" and "intent" in operational routing system 216 security. 218 3. Acknowledgements 220 The authors gratefully acknowledge the contributions of John Curran. 222 4. IANA Considerations 224 There are no actions for IANA in the document. 226 5. Security Considerations 228 This document describes an attack on an RPKI-enabled BGPSEC and is 229 meant to inform the IETF community that this vulnerability exists as 230 a result of route-leaks and attacks that conform to this type of 231 behavior, and that operators should not assume that that work items 232 and designs address these operational security issues. 234 The authors believe the capability to prevent route-leaks and leak- 235 attacks should be a primary engineering objective in any secure 236 routing architecture. 238 6. Informative References 240 [I-D.ietf-sidr-bgpsec-protocol] 241 Lepinski, M., "BGPSEC Protocol Specification", 242 November 2013. 244 [LEAK_ATTACK_ON_GOOGLE] 245 CloudFlare, CF., "Why Google Went Offline Today and a Bit 246 about How the Internet Works", November 2012, . 250 [NANOG_LEAK_TALK] 251 Mauch, J., "Detecting Routing Leaks by Counting", 252 October 2007, . 255 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 256 Community Attribute in Multi-home Routing", RFC 1998, 257 August 1996. 259 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 260 Protocol 4 (BGP-4)", RFC 4271, January 2006. 262 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 263 Secure Internet Routing", RFC 6480, February 2012. 265 [ROUTE_LEAK_DETECTION_TOOL] 266 Mauch, J., "BGP Routing Leak Detection System Routing Leak 267 Detection System", September 2007, 268 . 270 Authors' Addresses 272 Danny McPherson 273 Verisign, Inc. 274 12061 Bluemont Way 275 Reston, VA 20190 276 USA 278 Phone: +1 703.948.3200 279 Email: dmcpherson@verisign.com 281 Shane Amante 282 Level 3 Communications, Inc. 283 1025 Eldorado Boulevard 284 Broomfield, CO 80021 285 US 287 Phone: +1 720.888.1000 288 Email: shane@level3.net 289 Eric Osterweil 290 Verisign, Inc. 291 12061 Bluemont Way 292 Reston, VA 20190 293 USA 295 Phone: +1 703.948.3200 296 Email: eosterweil@verisign.com 298 Dave Mitchell 299 Twitter, Inc. 300 1355 Market Street, Suite 900 301 San Francisco, CA 94103 302 USA 304 Email: dave@twitter.com