idnits 2.17.1 draft-ietf-rpsec-bgpattack-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 6) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([MODELING], [ATTACKTREE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2004) is 7358 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BGP' is defined on line 650, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ATTACKTREE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODELING' -- Possible downref: Non-RFC (?) normative reference: ref. 'BGPVULN' ** Obsolete normative reference: RFC 2828 (ref. 'GLOSSARY') (Obsoleted by RFC 4949) ** Obsolete normative reference: RFC 2385 (ref. 'BGPMD5') (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 1948 (ref. 'SEQATTACKS') (Obsoleted by RFC 6528) -- Possible downref: Non-RFC (?) normative reference: ref. 'RANDOMINC' ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'VULNTEST' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing Protocol Security S. Convery 2 Requirements (rpsec) D. Cook 3 Internet-Draft M. Franz 4 Expires: August 26, 2004 Cisco 5 February 26, 2004 7 An Attack Tree for the Border Gateway Protocol 8 draft-ietf-rpsec-bgpattack-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 26, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This I-D presents all known attack vectors into or using BGP. The 39 data is presented in "Attack Tree" format as published by Schneier 40 [ATTACKTREE] and detailed by the CERT in "Attack Modeling for 41 Information Security and Survivability" [MODELING]. Future security 42 improvements to BGP (whether best practices or enhancements to the 43 protocol) should consider the attacks outlined here when determining 44 the relative security improvements such changes provide. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. BGP Attack Tree . . . . . . . . . . . . . . . . . . . . . . 6 50 2.1 BGP Atomic Goals . . . . . . . . . . . . . . . . . . . . . . 6 51 2.1.1 Compromise MD5 Authentication . . . . . . . . . . . . . . . 7 52 2.1.2 Establish Unauthorized BGP Session with Peer . . . . . . . . 8 53 2.1.3 Originate Unauthorized Prefix/Attribute into Peer Route 54 Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 2.1.4 Change Path Preference of a Prefix . . . . . . . . . . . . . 9 56 2.1.5 Conduct Denial/Degradation of Service Attack Against BGP 57 Process . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 2.1.6 Reset a Single BGP Session . . . . . . . . . . . . . . . . . 11 59 2.1.7 Send Spoofed BGP Message . . . . . . . . . . . . . . . . . . 12 60 2.2 Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . 12 61 2.2.1 Disable Critical Portions of the Internet by Disrupting 62 Internet Routing Tables . . . . . . . . . . . . . . . . . . 13 63 2.2.2 Force a Multi-homed AS to use an Alternate Path to/from 64 an Outside Network Instead of the Preferred Path . . . . . . 14 65 2.2.3 Disable a Single-homed AS . . . . . . . . . . . . . . . . . 14 66 2.2.4 Disable a Multi-homed AS . . . . . . . . . . . . . . . . . . 15 67 2.2.5 Blackhole Traffic . . . . . . . . . . . . . . . . . . . . . 15 68 3. Testing Considerations . . . . . . . . . . . . . . . . . . . 16 69 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 71 A. Supporting Atomic Goals . . . . . . . . . . . . . . . . . . 19 72 A.1 Compromise Router . . . . . . . . . . . . . . . . . . . . . 19 73 A.2 Denial of Service (DoS) Router . . . . . . . . . . . . . . . 20 74 A.3 Intercept or Modify Data Through Man-in-the-Middle 75 (MITM) Attack . . . . . . . . . . . . . . . . . . . . . . . 20 76 A.4 TCP Sequence Number Attack . . . . . . . . . . . . . . . . . 21 77 A.5 Sniff Traffic . . . . . . . . . . . . . . . . . . . . . . . 21 78 Intellectual Property and Copyright Statements . . . . . . . 22 80 1. Introduction 82 BGP and other infrastructure protocols such as DNS have received 83 significant critical attention as the overall awareness of Internet 84 security has increased. Although BGP threat models have been 85 published [BGPVULN] that identify inherent vulnerabilities in the 86 protocol, none have considered the full range of options available to 87 the adversary or their relative difficulty. 89 The use of attack trees focuses analysis on measurable goals that can 90 ultimately be translated into specific tests against popular 91 implementations. This analysis technique also encourages a structured 92 elaboration of events that must occur for a successful intrusion. 93 Since each node (an attacker goal) may be decomposed into subordinate 94 nodes (sub-goals, or means of achieving the parent goal), attack 95 trees allow security analysis to be conducted at multiple layers of 96 abstraction. This allows common attacks to be referenced as reusable 97 modules that apply to common network scenarios. 99 Although a comprehensive discussion of attack trees is outside the 100 scope of this I-D, it is useful to provide a general overview of 101 their function and value. The clearest way to demonstrate this is 102 through examples, as illustrated in [ATTACKTREE]. Consider an 103 individual trying to gain unauthorized physical access to a building. 104 An attack tree for such an act might look like this: 106 Goal: Gain unauthorized physical access to building 108 Attack: 109 OR 1. Unlock door with key 110 2. Pick lock 111 3. Break window 112 4. Follow authorized individual into building 114 This simple tree should be read as follows: to gain unauthorized 115 physical access to a building, the adversary must unlock the door 116 with a key, pick the lock, break a window, or follow an authorized 117 individual into the building. The "OR" operator defines that only one 118 is required. In the same tree, replacing the "OR" with "AND" would 119 require that all subordinate goals be achieved to realize the parent 120 goal. Attack trees at this level of detail are of limited use. Their 121 true value comes in understanding how an adversary can execute one of 122 the listed subordinate goals. This requires the following, more 123 detailed, attack tree: 125 Goal: Gain unauthorized physical access to building 127 Attack: 128 OR 1. Unlock door with key 129 OR 1. Steal Key 130 2. Social Engineering 131 OR 1. Borrow key 132 2. Convince locksmith to unlock door 133 2. Pick lock 134 3. Break window 135 4. Follow authorized individual into building 136 OR 1. Act like you belong and follow someone else 137 2. Befriend someone authorized outside a building 138 3. Appear in need of assistance (such as carrying a large box) 139 AND 4. Wear appropriate clothing for the location 141 Now the various sub nodes of the tree are better defined. In order to 142 "unlock door with key" you need to either steal the key or perform 143 some type of social engineering. Sub goal 4 (Follow authorized 144 individual into building) illustrates the use of "OR" and "AND" at 145 the same level of the tree. This should be read as follows: In order 146 to follow an individual into the building the adversary needs to do 147 one of the first 3 listed items, and wear appropriate clothing for 148 the location. 150 The use of attack trees also allows comparison between technical and 151 non-technical means of attack, and leads to a more comprehensive 152 analysis of threats and vulnerabilities. Even without extensive 153 elaboration, we learn in this tree that following someone into a 154 building is probably the easiest way of gaining entrance with the 155 lowest amount of cost or risk to the adversary. This class of attacks 156 collectively known as "social engineering" is listed but not 157 elaborated throughout this I-D. In many cases social engineering is 158 the easiest form of attack and could result in the greatest damage. 160 This I-D illustrates a simple BGP attack tree: subsequent analysis 161 could assign attributes (and possibly values) to each node of the 162 tree. This allows more quantitative methods to be used in analyzing 163 the attack tree data. These attributes could include: 165 o Impact of the attack 167 o Ease of attack execution 169 o Cost of the attack 171 o Presence of countermeasures (such as best practices) 172 o Access/trust requirements to conduct attack 174 Analysis of this data will yield the subset of attacks that result in 175 the most damage, are the easiest to launch, the least costly, have 176 the least access requirements, and are unlikely to be mitigated by 177 current best practices. Addressing these attacks should be the 178 initial focus of any improvements to BGP or relevant best practices. 180 Computer security terms used in this I-D are in accordance with RFC 181 2828 [GLOSSARY]. 183 2. BGP Attack Tree 185 This I-D divides the attack tree into three main sections to reduce 186 redundancy and provide greater portability into subsequent trees 187 defined in other I-Ds. When another section of this I-D is referenced 188 within a specific tree, the tree located at the referenced section 189 should be attached at the point the reference is made. 191 The first section details BGP Atomic Goals of an adversary and is 192 detailed in Section 2.1. BGP Atomic Goals are defined in this I-D as 193 the narrowest form of attack by an adversary specifically directed 194 against BGP. BGP Atomic Goals consist of unique attack techniques and 195 Supporting Atomic Goals as detailed in Appendix A. Supporting Atomic 196 Goals are common network attack methods used in more than one BGP 197 Atomic Goal. The third main section of the document details higher 198 level adversary goals that make use of BGP Atomic Goals (and 199 therefore supporting atomic goals as well). These goals are referred 200 to as Attack Scenarios and are detailed in Section 2.2. 202 It is worth noting that the inclusion of an attack in this attack 203 tree says nothing with regard to the likelihood such an attack will 204 occur or even the reasonable possibility it could occur. Future 205 testing and analysis, as mentioned earlier, is required to accurately 206 interpret the data in this tree. Some of this analysis has been done 207 in [VULNTEST] but further testing is warranted. Some of the results 208 from this testing have been incorporated into this I-D. 210 2.1 BGP Atomic Goals 212 The following atomic goals are defined and used throughout the attack 213 tree: 215 o Compromise MD5 authentication 217 o Establish unauthorized BGP session with peer 219 o Originate unauthorized prefix into peer route table 221 o Change path preference of a prefix 223 o Conduct denial/degradation of service against BGP process 225 o Reset single BGP session 227 o Spoof a BGP message 229 2.1.1 Compromise MD5 Authentication 231 The common-sense view is that most adversaries will choose the path 232 of least resistance, so that all but the most sophisticated threats 233 would target a BGP speaker whose sessions are not protected by RFC 234 2385 [BGPMD5] authentication. Nevertheless, attempting a compromise 235 of MD5 authenticated BGP messages could be done as follows: 237 Attack: 238 OR 1. Use social engineering to obtain MD5 password 239 2. Capture Password 240 OR 1. Keystroke logger 241 AND 1. Compromise/gain access to administrative host 242 2. Install hostile application on administrative host 243 3. Observe MD5 password as it is typed/viewed on screen 244 2. Sniff MD5 password from management traffic (Appendix A.4) 245 3. Capture password from router configuration 246 OR 1. Compromise network management server 247 OR 1. View unencrypted router configuration 248 2. Decrypt encrypted router configuration 249 2. Compromise router (Appendix A.1) 250 3. Brute-Force MD5 password 251 OR 1. Active attack - Send signed message to peer eliciting signed response 252 AND 1. Send segment with RFC 2385 option to router 253 2. Observe response from router to determine if your hash 254 was valid 255 3. Gain physical/local access to link between peers 256 2. Passive Attack 257 AND 1. Obtain hashed packet (to facilitate offline attack) 258 2. Use RFC 2385 cracking tool to discover password 259 5. Discover implementation flaw in RFC 2385 260 6. Discover new attack against MD5 261 7. Exploit hash collision attack against MD5 263 To validate our assumptions about the relative difficulty of 264 attacking RFC2385 authentication, we must have test data that 265 measures the relative ease/difficulty of such attacks (or the side 266 effects of unsuccessful attacks) against popular BGP/TCP 267 implementations. When observing the response from an RFC 2385 268 authenticated session, sniffing will be necessary if using a spoofed 269 SYN. Findings from [VULNTEST] indicate that an inline adversary is 270 easily able to determine the MD5 key if weak passwords are chosen but 271 that a sufficiently strong password is as difficult to attack as any 272 other strong password using in modern computing today. Preliminary 273 tool development indicates that an offline attack is far more viable 274 than an online attack. 276 2.1.2 Establish Unauthorized BGP Session with Peer 278 Establishing an unauthorized BGP session with a peer is defined by 279 achieving a peering arrangement without the knowledge or permission 280 of both sides of the session. This includes peering sessions 281 established by routers and/or any other device capable of being a BGP 282 speaker. In this this attack, "permissive router" is meant to mean a 283 router which will allow BGP peering without explicit neighbor IP / AS 284 configuration. 286 Attack: 287 OR 1. Establish session with permissive router 288 OR 1. Find available local BGP speaker 289 OR 1. Port Scan 290 2. Social Engineering 291 2. Find available remote (EBGP-multi) speaker 292 OR 1. Port Scan 293 2. Social Engineering 294 AND 3. Establish peering relationship with discovered router 295 2. Compromise router and reconfigure to allow peering session 296 AND 1. Compromise Router (Appendix A.1) 297 2. Configure router to allow peering from attacking router 298 3. Simulate BGP Session from non-router 300 Once a peering session has been established, the adversary can much 301 more easily launch attacks that not only effect the peer, but the 302 entire network. Internet scanning performed in [VULNTEST] indicates 303 that "permissive routers" are a very small percentage of deployed 304 routers and that with basic BCPs a router can be sufficiently masked 305 so as to make blind attacks impossible. When the adversary is inline, 306 much more damage is possible. 308 2.1.3 Originate Unauthorized Prefix/Attribute into Peer Route Table 310 To accomplish this goal, an adversary must insert a new prefix into a 311 peer's routing table. This attack can be used to change traffic 312 patterns in a network in the case that the prefix is more specific 313 than the route previously used to direct traffic. This can lead to 314 stolen or blackholed traffic across the network. This introduced 315 prefix/attribute could be used for all sorts of malicious goals some 316 of which are detailed in Section 2.2. 318 Attack: 319 OR 1. Send from valid Router 320 OR 1. Misconfigured 321 2. Compromise router (Appendix A.1) 322 2. Send from Invalid Router 323 AND 1. Gag valid router 324 OR 1. Kill Router 325 OR 1. Power Off/Physical Layer 326 2. Crash and prevent reboot 327 3. Conduct denial of service against router (Appendix A.2) 328 2. Steal IP Addr 329 OR 1. ARP Spoof 330 2. Steal MAC 331 2. Introduce rogue router (Assume IP) 332 OR 1. Steal IP Addr (section 2.1.3.1.2) 333 2. More Specific Route Introduction 334 3. Establish unauthorized BGP session w/peer (Section 2.1.2) 335 3. Send spoofed BGP Update from Non-Router 336 OR 1. Conduct TCP Sequence Number Attack (Appendix A.4) 337 2. Conduct Man-in-the-Middle (Appendix A.3) 338 AND 4. Craft BGP Message 340 This is one of several attacks that can be caused by misconfiguration 341 as opposed to a deliberate attack. Launching this attack from a 342 compromised / misconfigured router is by far the easiest with 343 findings from [VULNTEST] indicating that sending spoofed updates as a 344 blind adversary is more difficult than previously posited. 346 2.1.4 Change Path Preference of a Prefix 347 Changing the path preference of a prefix can lead to the same types 348 of attacks that occur by inserting a new prefix into a peer's routing 349 table. This atomic goal is defined by altering the attributes of a 350 prefix so that the BGP decision process is affected. This goal is 351 different from originating an unauthorized prefix in that altering 352 the attributes implies that the prefix already exists in the BGP 353 table. There are different methods that can be used to accomplish 354 each of these goals so they will be analyzed separately. 356 Attack: 357 OR 1. Modify (AS-PATH, Next-Hop, MED, local-pref, communites) 358 OR 1. Valid BGP Speaker 359 OR 1. rogue transit implementation 360 2. compromise edge (origin/recipient) router 361 2. Man-in-the-middle attack (Appendix A.3) 362 3. Compromise router (Appendix A.1) 364 In reality, any attribute could be altered to change the path 365 preference. The five listed are the most common. 367 2.1.5 Conduct Denial/Degradation of Service Attack Against BGP Process 369 BGP routing processes are susceptible to a variety of attacks which 370 can prevent establishment of new sessions, exchange of routing 371 updates, or cause the router itself to become inoperable. 373 Attack: 374 OR 1. Denial of service against router (Appendix A.2) 375 2. TCP Resource Exhaustion against Port 179 376 OR 1. SYN Flood - exhaust SYN_RCVD state in TCP stack 377 2. Connect() - repeated full (3-way handshake) connections 378 3. LAST_ACK - complete 3-way handshake, then FIN-ACK 379 3. Invalid BGP Messages 380 OR 1. OPEN 381 2. UPDATE 382 3. KEEPALIVE 383 4. NOTIFICATION 384 4. Valid BGP Messages 385 OR 1. Update Flooding 386 OR 1. Flood routes (/32, etc.) 387 2. Excessively long path attributes 388 2. Update/Withdraw Flooding 389 3. MD5 Resource Exhaustion 391 Given the nearly infinite number of attacks and operational 392 conditions that could cause a routing process to stop performing as 393 expected, a significant testing effort will be needed to increase the 394 level of assurance in popular BGP implementations. Findings from 395 [VULNTEST] indicate that basic TCP resource exhaustion attacks are 396 difficult against current popular BGP implementations particularly if 397 the peer has been already established. MD5 resource exhaustion 398 attacks are similarly difficult. The easiest DoS against the BGP 399 process itself is update flooding from a compromised router or inline 400 adversary. 402 2.1.6 Reset a Single BGP Session 404 In this attack, the adversary is trying to cause a current BGP 405 session in the established state to reset. Such an attack could be 406 launched over and over again to prevent two peers from reliably 407 exchanging routing information. 409 Attack: 410 OR 1. Send message to router causing reset 411 OR 1. Send RST message to TCP stack 412 2. Send BGP Message 413 OR 1. Notify 414 2. Open 415 3. Keepalive 416 AND 3. TCP Sequence number Attack (Appendix A.4) 417 2. Alter configuration via compromised router (Appendix A.1) 419 It is unknown why an adversary would choose to reset a session via 420 Section 2.1.6.1.2. Since the preconditions of attack Section 421 2.1.6.1.1 are required in order to be successful. Also, it should be 422 noted that the sequence number attack detailed in Appendix A.4 is far 423 from trivial to properly execute. Findings from [VULNTEST] indicate 424 the attack can easily be rendered impossible for blind attackers with 425 basic BCPs and even without BCPs determining the proper TCP packet to 426 cause the reset without inline access to the routers is very 427 difficult. 429 2.1.7 Send Spoofed BGP Message 431 An adversary could send a BGP message to a BGP speaker and 432 potentially alter the behavior of the routing process. This attack is 433 mainly designed to insert false information into a BGP session, or to 434 reset a session. 436 Attack: 438 OR 1. TCP Sequence number Attack (Appendix A.4) 439 2. Intercept or Modify Data Through Man-in-the-Middle (MITM) 440 Attack (Appendix A.3) 441 AND 3. Build a valid BGP packet 443 This attack assumes that the adversary is able to cause the BGP 444 speaker to accept a message without establishing a peering 445 relationship. Spoofing the message is the primary mechanism to 446 accomplish this. Because of the requirement for the TCP sequence 447 number attack, this attack is quite difficult and findings in 448 [VULNTEST] indicate that after the spoofed update is sent, the 449 legitimate TCP session will begin to ACK storm resulting in a session 450 reset in several minutes. 452 2.2 Attack Scenarios 454 The attack scenarios represent larger goals an adversary may have 455 which use BGP as a means to accomplish them. These attacks use the 456 atomic goals discussed in Section 2.1 as a mechanism to reduce the 457 duplication of information within each tree. 459 The following attack scenarios are defined: 461 o Disable critical portions of the Internet by disrupting Internet 462 routing tables 464 o Force a multi-homed AS to use an alternate path to/from an outside 465 network instead of the preferred path 467 o Disable a single-homed AS 469 o Disable a multi-homed AS 471 o Blackhole traffic 473 2.2.1 Disable Critical Portions of the Internet by Disrupting Internet 474 Routing Tables 476 Common concerns regarding BGP have described scenarios where large 477 section of the Internet become unreachable due to the lack of 478 security features in BGP. In theory, the attack can be done in one of 479 three main ways: physical destruction, social engineering, or routing 480 attacks. 482 Attack: 483 OR 1. Physical Destruction 484 OR 1. Destroy Peering Points 485 2. Strategic Link Destruction (backhoe) 486 2. Social Engineering 487 3. Routing Attacks 488 OR 1. Alter global Internet routing table 489 OR 1. Insert unauth prefix into route table (Section 2.1.3) 490 2. Establish unauthorized BGP session with peer (Section 2.1.2) 491 AND 3. Ensure propagation in spite of prefix filtering 492 4. Repeat for ASs at multiple ISP 493 2. Disable critical core routers 494 OR 1. Router overload leading to crash 495 OR 1. DDoS 496 2. Worm 497 3. Loops 498 4. Change prefix paths (Section 2.1.4) 499 2. Exploit pervasive implementation flaw on router 500 OR 1. Memory exhaustion 501 2. CPU exhaustion 502 3. Magic packet (buffer overflow, etc.) 503 3. DoS BGP Process (Section 2.1.5) 504 4. Exploit routing table memory limitations 505 AND 1. Find unfiltered routing distribution point 506 2. Send the most specific routes that will be accepted and 507 propagated upstream 509 Since this I-D is focused on BGP, this tree elaborates on the routing 510 related portion of the tree. Any of the above listed attack goals are 511 non-trivial and would require extensive coordination and potentially 512 insider involvement. 514 2.2.2 Force a Multi-homed AS to use an Alternate Path to/from an Outside 515 Network Instead of the Preferred Path 517 Another way that BGP can be compromised is by forcing a multihomed AS 518 to change the normal path preference. This can result in the entire 519 AS using a suboptimal path, or using links that cost the AS more 520 money. In the extreme case, changing the path preference could cause 521 a link to become oversubscribed and result in the loss of data or 522 control traffic. 524 Attack: 525 OR 1. Force traffic from outside network to use alternate path 526 OR 1. Lower preference of preferred path 527 OR 1. Change path preference of a prefix (Section 2.1.4) 528 2. DoS BGP Process (Section 2.1.5) 529 3. Reset BGP Session (Section 2.1.6) 530 4. Compromise Router (Appendix A.1) 531 2. Raise preference of alternate path (Section 2.1.4) 532 2. Force traffic going to outside network to use alternate path 533 OR 1. Lower preference of preferred path 534 OR 1. Change path preference of a prefix (Section 2.1.4) 535 2. DoS BGP Process (Section 2.1.5) 536 3. Reset BGP Session (Section 2.1.6) 537 4. Compromise Router (Appendix A.1) 538 2. Raise preference of alternate path (Section 2.1.4) 540 2.2.3 Disable a Single-homed AS 542 This attack is a smaller scale version of the attack described in 543 Section 2.2.1. Here the adversary need only prevent a single-homed AS 544 from communicating with the rest of the Internet. 546 Attack: 547 OR 1. Disable provider link 548 OR 1. Physical link destruction 549 2. Social engineering 550 3. Turn off the link by compromising the upstream 551 router (Appendix A.1) 552 2. Disable AS via routing protocol attack 553 OR 1. DoS BGP Process (Section 2.1.5) 554 2. Reset BGP Session (Section 2.1.6) 555 3. Compromise router (Appendix A.1) 557 Any crashes or resets initiated by the adversary in Section 2.2.3.2.1 558 or .2.2 would usually require the attack be generated continually to 559 prevent the router from reestablishing proper communications with its 560 peer. 562 2.2.4 Disable a Multi-homed AS 564 This attack is a combination of Section 2.2.3 and Section 2.2.1. The 565 number of links the AS under attack has with other ASs will dictate 566 the type of attack necessary to most efficiently achieve the 567 adversary's objectives. This attack sequence, in particular, would 568 benefit from further testing through lab simulation and the 569 association of attributes to each of the leaf nodes. 571 Attack: 572 OR 1. Disable links 1...N (Section 2.2.3) 573 2. Disable critical portions of the ASs network (Section 2.2.1) 575 To summarize, the adversary can either consider the attack like 576 disabling several individually connected single-homed ASs, or as a 577 smaller version of the Internet as a whole. 579 2.2.5 Blackhole Traffic 581 BGP can be used to blackhole traffic. If an adversary has access to 582 the forwarding path of the target system, he can quietly discard the 583 traffic while continuing to function as a BGP speaker. The adversary 584 could also affect the BGP tables of his neighbors using BGP 585 advertisements so that they would send traffic to the incorrect 586 destination. One way this could be accomplished is through the 587 unauthorized origination of a prefix. 589 Attack: 590 OR 1. Drop traffic on the wire itself (Section 2.1.4.1.2) 591 2. Drop traffic on a router (without using BGP) 592 OR 1. Policy route to null 593 2. Static route to null 594 AND 3. Gain administrative access to the router 595 OR 1. Rouge router 596 2. Misconfigured router 597 3. Compromise router (Appendix A.1) 598 3. Drop traffic using bogus BGP messages 599 OR 1. Establish unauthorized BGP session with peer (Section 2.1.2) 600 2. Originate unauthorized prefix/attribute (Section 2.1.3) 601 3. Compromise router (Appendix A.1) 603 3. Testing Considerations 605 BGP design decisions (such as the selection of TCP as the transport 606 protocol) certainly impact the security of the Internet routing 607 infrastructure. However, operational considerations and the quality 608 of the BGP implementations may have a greater impact on Internet 609 security. Testing (as the ultimate determination of relative 610 difficulty of an attack) is especially critical for threat/ 611 vulnerability analyses that use attack trees. This is because the 612 likelihood, criticality, and access requirements of leaf nodes 613 determine which are the most likely paths through the tree. 615 As discussed earlier, test procedures and results could be released 616 in a subsequent I-D. Such analysis should be environment specific. 617 For example, the analysis of this attack tree will be fundamentally 618 different for Internet service provider networks and enterprise 619 networks. The same can also be said of the differences in attack 620 methods between a remote blind adversary and a trusted insider. Early 621 findings in this area are available in [VULNTEST]. 623 References 625 [ATTACKTREE] 626 Schneier, B., "Attack Trees", December 1999. 628 [MODELING] 629 Moore, A., Ellison, R. and R. Linger, "Attack Modeling for 630 Information Security and Survivability", March 2001. 632 [BGPVULN] Murphy, S., "BGP Security Vulnerabilities Analysis", 633 February 2002. 635 [GLOSSARY] 636 Shirey, R., "Internet Security Glossary, RFC 2828", 637 December 1999. 639 [BGPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 640 Signature Option, RFC 2385", August 1998. 642 [SEQATTACKS] 643 Bellovin, S., "Defending Against Sequence Number Attacks, 644 RFC 1948", May 1996. 646 [RANDOMINC] 647 SEQATTACKS, T., "The Problem With Random Increments", 648 March 2001. 650 [BGP] BGP, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4), 651 RFC 1771", March 1995. 653 [VULNTEST] 654 Convery, S. and M. Franz, "BGP Vulnerability Testing: 655 Separating Fact from FUD", June 2003. 657 Authors' Addresses 659 Sean Convery 660 Cisco Systems, Inc. 661 170 W. Tasman Dr. 662 San Jose, CA 95134 663 US 665 Phone: +1 408 853 8753 666 EMail: sean@cisco.com 667 David Cook 668 Cisco Systems, Inc. 669 7025 Kit Creek Rd. 670 Research Triangle Park, NC 27709 671 US 673 Phone: +1 919 392-8772 674 EMail: dacook@cisco.com 676 Matthew Franz 677 Cisco Systems, Inc. 678 12515 Research Blvd. 679 Austin, TX 78759 680 US 682 Phone: +1 512 378 1648 683 EMail: mfranz@cisco.com 685 Appendix A. Supporting Atomic Goals 687 A.1 Compromise Router 689 Although outside the scope of routing protocol security, if the 690 routers themselves can be compromised the routing infrastructure can 691 be subverted. 693 Attack: 694 OR 1. Gain physical access to router 695 AND 1. Gain physical access to data center 696 2. Guess passwords 697 OR 3. Perform password recovery 698 2. Gain logical access to router 699 OR 1. Compromise network manager system 700 OR 1. Exploit application layer vulnerability in server 701 2. Hijack management traffic 702 2. Login to router 703 OR 1. Guess password 704 2. Sniff password 705 3. Hijack management session 706 OR 1. Telnet 707 2. SSH 708 3. SNMP 709 4. Social engineering 710 3. Exploit implementation flaw in protocol/application in router 711 OR 1. Telnet 712 2. SSH 713 3. SNMP 714 4. Proprietary management protocol 716 The ability of an adversary to compromise a BGP speaker is largely 717 dependent on operational best practices: use of secure management 718 protocols and authentication mechanisms, use of intrusion detection 719 systems, etc. 721 A.2 Denial of Service (DoS) Router 723 Denial/degradation of service attacks can be conducted against 724 network devices using a variety of well-known techniques. 726 Attack: 727 OR 1. Physical destruction of router 728 2. Link layer attacks 729 OR 1. Protocol attack using link layer protocol 730 2. Physical link attack 731 3. ARP attacks 732 4. IP attacks 733 OR 1. ICMP Message 734 OR 1. Flooding 735 2. Malformed 736 2. IP Fragmentation Attack 737 5. UDP attacks 738 6. TCP attacks 739 OR 1. SYN Flood 740 2. Connect() 741 3. LAST_ACK 742 4. New/undiscovered DoS against TCP 743 7. Application-Layer DoS 744 OR 1. Telnet 745 2. SSH 746 3. SNMP 747 4. Other aplication layer protocol 749 All of these attacks are outside the scope of BGP design or 750 implementation and ultimately depend on the survivability of the 751 routing device itself, its ability withstand attack, and the proper 752 configuration of the device based on published best-practices. 754 A.3 Intercept or Modify Data Through Man-in-the-Middle (MITM) Attack 756 Man in the middle attacks against cryptographic protocols or 757 application layer protocols allow an adversary to effectively proxy 758 communication between two parties allowing any data to either be read 759 or altered. Although not impossible to conduct after a session has 760 been established, the attack is easier done prior to session 761 initiation. 763 Attack: 764 AND 1. Gain write access to network segment of one or more peers 765 2. Subvert address infrastructure 766 OR 1. ARP/MAC spoofing 767 2. DNS spoofing 768 3. Proxy BGP sessions between BGP speakers 770 The goals of a MITM attack against BGP are almost identical to a TCP 771 Sequence Number Attack (Appendix A.4) against a BGP session. DNS 772 Spoofing may be unlikely because many implementations/configurations 773 are unlikely to use hostnames in router configurations. 775 A.4 TCP Sequence Number Attack 777 TCP suffers from well-known design flaws which make it possible to 778 hijack or terminate applications that use it as their transport 779 protocol. As a blind adversary, these attacks are quite difficult to 780 execute, particularly as they apply to BGP. 782 Attack: 783 OR 1. Blind Spoofing Attack 784 AND 1. Guess sequence number use by a BGP speaker 785 2. Inject valid BGP message 786 2. Non-Blind Spoofing attack 787 AND 1. Sniff Traffic (Appendix A.5) 788 2. Inject valid BGP message based on sequence numbers 790 Adequate initial sequence number randomness [SEQATTACKS] should 791 mitigate most blind attacks, although some research [RANDOMINC] 792 suggests blind attacks may be easier that previously thought, all of 793 these attacks require a large sample set of ISNs, something which can 794 be easily mitigated with proper BGP BCPs. 796 A.5 Sniff Traffic 798 Depending on the network topology, there are many ways of gaining 799 read-access to a network to conduct passive attacks. The most common 800 method would be to compromise a system (typically a general purpose 801 operating system) on the segment and install software the puts a 802 network interface card in promiscuous mode and captures traffic. 804 Attack: 805 OR 1. Gain local network access to a segment 806 AND 1. Compromise server 807 2. Install sniffing software 808 2. Tap physical medium 809 3. Redirect traffic through a compromised host 811 ARP/MAC spoofing may be necessary to sniff traffic on switched 812 networks and many tools are available which make this a trivial task. 814 Intellectual Property Statement 816 The IETF takes no position regarding the validity or scope of any 817 intellectual property or other rights that might be claimed to 818 pertain to the implementation or use of the technology described in 819 this document or the extent to which any license under such rights 820 might or might not be available; neither does it represent that it 821 has made any effort to identify any such rights. Information on the 822 IETF's procedures with respect to rights in standards-track and 823 standards-related documentation can be found in BCP-11. Copies of 824 claims of rights made available for publication and any assurances of 825 licenses to be made available, or the result of an attempt made to 826 obtain a general license or permission for the use of such 827 proprietary rights by implementors or users of this specification can 828 be obtained from the IETF Secretariat. 830 The IETF invites any interested party to bring to its attention any 831 copyrights, patents or patent applications, or other proprietary 832 rights which may cover technology that may be required to practice 833 this standard. Please address the information to the IETF Executive 834 Director. 836 Full Copyright Statement 838 Copyright (C) The Internet Society (2004). All Rights Reserved. 840 This document and translations of it may be copied and furnished to 841 others, and derivative works that comment on or otherwise explain it 842 or assist in its implementation may be prepared, copied, published 843 and distributed, in whole or in part, without restriction of any 844 kind, provided that the above copyright notice and this paragraph are 845 included on all such copies and derivative works. However, this 846 document itself may not be modified in any way, such as by removing 847 the copyright notice or references to the Internet Society or other 848 Internet organizations, except as needed for the purpose of 849 developing Internet standards in which case the procedures for 850 copyrights defined in the Internet Standards process must be 851 followed, or as required to translate it into languages other than 852 English. 854 The limited permissions granted above are perpetual and will not be 855 revoked by the Internet Society or its successors or assignees. 857 This document and the information contained herein is provided on an 858 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 859 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 860 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 861 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 862 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 864 Acknowledgment 866 Funding for the RFC Editor function is currently provided by the 867 Internet Society.