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