Routing Protocol Security S. Convery Requirements (rpsec) D. Cook Internet-Draft M. Franz Expires: March 17, 2004 Cisco September 17, 2003 An Attack Tree for the Border Gateway Protocol draft-convery-bgpattack-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 17, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This I-D presents all known attack vectors into or using BGP. The data is presented in "Attack Tree" format as published by Schneier [ATTACKTREE] and detailed by the CERT in "Attack Modeling for Information Security and Survivability" [MODELING]. Future security improvements to BGP (whether best practices or enhancements to the protocol) should consider the attacks outlined here when determining the relative security improvements such changes provide. Convery, et al. Expires March 17, 2004 [Page 1] Internet-Draft BGP Attack Tree September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. BGP Attack Tree . . . . . . . . . . . . . . . . . . . . . . 6 2.1 BGP Atomic Goals . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Compromise MD5 Authentication . . . . . . . . . . . . . . . 7 2.1.2 Establish Unauthorized BGP Session with Peer . . . . . . . . 8 2.1.3 Originate Unauthorized Prefix/Attribute into Peer Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.4 Change Path Preference of a Prefix . . . . . . . . . . . . . 9 2.1.5 Conduct Denial/Degradation of Service Attack Against BGP Process . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.6 Reset a Single BGP Session . . . . . . . . . . . . . . . . . 10 2.1.7 Send Spoofed BGP Message . . . . . . . . . . . . . . . . . . 11 2.2 Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Disable Critical Portions of the Internet by Disrupting Internet Routing Tables . . . . . . . . . . . . . . . . . . 12 2.2.2 Force a Multi-homed AS to use an Alternate Path to/from an Outside Network Instead of the Preferred Path . . . . . . 13 2.2.3 Disable a Single-homed AS . . . . . . . . . . . . . . . . . 13 2.2.4 Disable a Multi-homed AS . . . . . . . . . . . . . . . . . . 14 2.2.5 Blackhole Traffic . . . . . . . . . . . . . . . . . . . . . 14 3. Testing Considerations . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 A. Supporting Atomic Goals . . . . . . . . . . . . . . . . . . 18 A.1 Compromise Router . . . . . . . . . . . . . . . . . . . . . 18 A.2 Denial of Service (DoS) Router . . . . . . . . . . . . . . . 18 A.3 Intercept or Modify Data Through Man-in-the-Middle (MITM) Attack . . . . . . . . . . . . . . . . . . . . . . . 19 A.4 TCP Sequence Number Attack . . . . . . . . . . . . . . . . . 20 A.5 Sniff Traffic . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 Convery, et al. Expires March 17, 2004 [Page 2] Internet-Draft BGP Attack Tree September 2003 1. Introduction BGP and other infrastructure protocols such as DNS have received significant critical attention as the overall awareness of Internet security has increased. Although BGP threat models have been published [BGPVULN] that identify inherent vulnerabilities in the protocol, none have considered the full range of options available to the adversary or their relative difficulty. The use of attack trees focuses analysis on measurable goals that can ultimately be translated into specific tests against popular implementations. This analysis technique also encourages a structured elaboration of events that must occur for a successful intrusion. Since each node (an attacker goal) may be decomposed into subordinate nodes (sub-goals, or means of achieving the parent goal), attack trees allow security analysis to be conducted at multiple layers of abstraction. This allows common attacks to be referenced as reusable modules that apply to common network scenarios. Although a comprehensive discussion of attack trees is outside the scope of this I-D, it is useful to provide a general overview of their function and value. The clearest way to demonstrate this is through examples, as illustrated in [ATTACKTREE]. Consider an individual trying to gain unauthorized physical access to a building. An attack tree for such an act might look like this: Goal: Gain unauthorized physical access to building Attack: OR 1. Unlock door with key 2. Pick lock 3. Break window 4. Follow authorized individual into building This simple tree should be read as follows: to gain unauthorized physical access to a building, the adversary must unlock the door with a key, pick the lock, break a window, or follow an authorized individual into the building. The "OR" operator defines that only one is required. In the same tree, replacing the "OR" with "AND" would require that all subordinate goals be achieved to realize the parent goal. Attack trees at this level of detail are of limited use. Their true value comes in understanding how an adversary can execute one of the listed subordinate goals. This requires the following, more detailed, attack tree: Goal: Gain unauthorized physical access to building Attack: Convery, et al. Expires March 17, 2004 [Page 3] Internet-Draft BGP Attack Tree September 2003 OR 1. Unlock door with key OR 1. Steal Key 2. Social Engineering OR 1. Borrow key 2. Convince locksmith to unlock door 2. Pick lock 3. Break window 4. Follow authorized individual into building OR 1. Act like you belong and follow someone else 2. Befriend someone authorized outside a building 3. Appear in need of assistance (such as carrying a large box) AND 4. Wear appropriate clothing for the location Now the various sub nodes of the tree are better defined. In order to "unlock door with key" you need to either steal the key or perform some type of social engineering. Sub goal 4 (Follow authorized individual into building) illustrates the use of "OR" and "AND" at the same level of the tree. This should be read as follows: In order to follow an individual into the building the adversary needs to do one of the first 3 listed items, and wear appropriate clothing for the location. The use of attack trees also allows comparison between technical and non-technical means of attack, and leads to a more comprehensive analysis of threats and vulnerabilities. Even without extensive elaboration, we learn in this tree that following someone into a building is probably the easiest way of gaining entrance with the lowest amount of cost or risk to the adversary. This class of attacks collectively known as "social engineering" is listed but not elaborated throughout this I-D. In many cases social engineering is the easiest form of attack and could result in the greatest damage. This I-D illustrates a simple BGP attack tree: subsequent analysis could assign attributes (and possibly values) to each node of the tree. This allows more quantitative methods to be used in analyzing the attack tree data. These attributes could include: o Impact of the attack o Ease of attack execution o Cost of the attack o Presence of countermeasures (such as best practices) o Access/trust requirements to conduct attack Analysis of this data will yield the subset of attacks that result in Convery, et al. Expires March 17, 2004 [Page 4] Internet-Draft BGP Attack Tree September 2003 the most damage, are the easiest to launch, the least costly, have the least access requirements, and are unlikely to be mitigated by current best practices. Addressing these attacks should be the initial focus of any improvements to BGP or relevant best practices. Computer security terms used in this I-D are in accordance with RFC 2828 [GLOSSARY]. Convery, et al. Expires March 17, 2004 [Page 5] Internet-Draft BGP Attack Tree September 2003 2. BGP Attack Tree This I-D divides the attack tree into three main sections to reduce redundancy and provide greater portability into subsequent trees defined in other I-Ds. When another section of this I-D is referenced within a specific tree, the tree located at the referenced section should be attached at the point the reference is made. The first section details BGP Atomic Goals of an adversary and is detailed in Section 2.1. BGP Atomic Goals are defined in this I-D as the narrowest form of attack by an adversary specifically directed against BGP. BGP Atomic Goals consist of unique attack techniques and Supporting Atomic Goals as detailed in Appendix A. Supporting Atomic Goals are common network attack methods used in more than one BGP Atomic Goal. The third main section of the document details higher level adversary goals that make use of BGP Atomic Goals (and therefore supporting atomic goals as well). These goals are referred to as Attack Scenarios and are detailed in Section 2.2. It is worth noting that the inclusion of an attack in this attack tree says nothing with regard to the likelihood such an attack will occur or even the reasonable possibility it could occur. Future testing and analysis, as mentioned earlier, is required to accurately interpret the data in this tree. Some of this analysis has been done in [VULNTEST] but further testing is warranted. Some of the results from this testing have been incorporated into this I-D. 2.1 BGP Atomic Goals The following atomic goals are defined and used throughout the attack tree: o Compromise MD5 authentication o Establish unauthorized BGP session with peer o Originate unauthorized prefix into peer route table o Change path preference of a prefix o Conduct denial/degradation of service against BGP process o Reset single BGP session o Spoof a BGP message Convery, et al. Expires March 17, 2004 [Page 6] Internet-Draft BGP Attack Tree September 2003 2.1.1 Compromise MD5 Authentication The common-sense view is that most adversaries will choose the path of least resistance, so that all but the most sophisticated threats would target a BGP speaker whose sessions are not protected by RFC 2385 [BGPMD5] authentication. Nevertheless, attempting a compromise of MD5 authenticated BGP messages could be done as follows: Attack: OR 1. Use social engineering to obtain MD5 password 2. Capture Password OR 1. Keystroke logger AND 1. Compromise/gain access to administrative host 2. Install hostile application on administrative host 3. Observe MD5 password as it is typed/viewed on screen 2. Sniff MD5 password from management traffic (Appendix A.4) 3. Capture password from router configuration OR 1. Compromise network management server OR 1. View unencrypted router configuration 2. Decrypt encrypted router configuration 2. Compromise router (Appendix A.1) 3. Brute-Force MD5 password OR 1. Active attack - Send signed message to peer eliciting signed response AND 1. Send segment with RFC 2385 option to router 2. Observe response from router to determine if your hash was valid 3. Gain physical/local access to link between peers 2. Passive Attack AND 1. Obtain hashed packet (to facilitate offline attack) 2. Use RFC 2385 cracking tool to discover password 5. Discover implementation flaw in RFC 2385 6. Discover new attack against MD5 7. Exploit hash collision attack against MD5 To validate our assumptions about the relative difficulty of attacking RFC2385 authentication, we must have test data that measures the relative ease/difficulty of such attacks (or the side effects of unsuccessful attacks) against popular BGP/TCP implementations. When observing the response from an RFC 2385 authenticated session, sniffing will be necessary if using a spoofed SYN. Findings from [VULNTEST] indicate that an inline adversary is easily able to determine the MD5 key if weak passwords are chosen but that a sufficiently strong password is as difficult to attack as any other strong password using in modern computing today. Preliminary tool development indicates that an offline attack is far more viable than an online attack. Convery, et al. Expires March 17, 2004 [Page 7] Internet-Draft BGP Attack Tree September 2003 2.1.2 Establish Unauthorized BGP Session with Peer Establishing an unauthorized BGP session with a peer is defined by achieving a peering arrangement without the knowledge or permission of both sides of the session. This includes peering sessions established by routers and/or any other device capable of being a BGP speaker. In this this attack, "permissive router" is meant to mean a router which will allow BGP peering without explicit neighbor IP / AS configuration. Attack: OR 1. Establish session with permissive router OR 1. Find available local BGP speaker OR 1. Port Scan 2. Social Engineering 2. Find available remote (EBGP-multi) speaker OR 1. Port Scan 2. Social Engineering AND 3. Establish peering relationship with discovered router 2. Compromise router and reconfigure to allow peering session AND 1. Compromise Router (Appendix A.1) 2. Configure router to allow peering from attacking router 3. Simulate BGP Session from non-router Once a peering session has been established, the adversary can much more easily launch attacks that not only effect the peer, but the entire network. Internet scanning performed in [VULNTEST] indicates that "permissive routers" are a very small percentage of deployed routers and that with basic BCPs a router can be sufficiently masked so as to make blind attacks impossible. When the adversary is inline, much more damage is possible. 2.1.3 Originate Unauthorized Prefix/Attribute into Peer Route Table To accomplish this goal, an adversary must insert a new prefix into a peer's routing table. This attack can be used to change traffic patterns in a network in the case that the prefix is more specific than the route previously used to direct traffic. This can lead to stolen or blackholed traffic across the network. This introduced prefix/attribute could be used for all sorts of malicious goals some of which are detailed in Section 2.2. Attack: OR 1. Send from valid Router OR 1. Misconfigured 2. Compromise router (Appendix A.1) 2. Send from Invalid Router AND 1. Gag valid router Convery, et al. Expires March 17, 2004 [Page 8] Internet-Draft BGP Attack Tree September 2003 OR 1. Kill Router OR 1. Power Off/Physical Layer 2. Crash and prevent reboot 3. Conduct denial of service against router (Appendix A.2) 2. Steal IP Addr OR 1. ARP Spoof 2. Steal MAC 2. Introduce rogue router (Assume IP) OR 1. Steal IP Addr (section 2.1.3.1.2) 2. More Specific Route Introduction 3. Establish unauthorized BGP session w/peer (Section 2.1.2) 3. Send spoofed BGP Update from Non-Router OR 1. Conduct TCP Sequence Number Attack (Appendix A.4) 2. Conduct Man-in-the-Middle (Appendix A.3) AND 4. Craft BGP Message This is one of several attacks that can be caused by misconfiguration as opposed to a deliberate attack. Launching this attack from a compromised / misconfigured router is by far the easiest with findings from [VULNTEST] indicating that sending spoofed updates as a blind adversary is more difficult than previously posited. 2.1.4 Change Path Preference of a Prefix Changing the path preference of a prefix can lead to the same types of attacks that occur by inserting a new prefix into a peer's routing table. This atomic goal is defined by altering the attributes of a prefix so that the BGP decision process is affected. This goal is different from originating an unauthorized prefix in that altering the attributes implies that the prefix already exists in the BGP table. There are different methods that can be used to accomplish each of these goals so they will be analyzed separately. Attack: OR 1. Modify (AS-PATH, Next-Hop, MED, local-pref, communites) OR 1. Valid BGP Speaker OR 1. rogue transit implementation 2. compromise edge (origin/recipient) router 2. Man-in-the-middle attack (Appendix A.3) 3. Compromise router (Appendix A.1) In reality, any attribute could be altered to change the path preference. The five listed are the most common. Convery, et al. Expires March 17, 2004 [Page 9] Internet-Draft BGP Attack Tree September 2003 2.1.5 Conduct Denial/Degradation of Service Attack Against BGP Process BGP routing processes are susceptible to a variety of attacks which can prevent establishment of new sessions, exchange of routing updates, or cause the router itself to become inoperable. Attack: OR 1. Denial of service against router (Appendix A.2) 2. TCP Resource Exhaustion against Port 179 OR 1. SYN Flood - exhaust SYN_RCVD state in TCP stack 2. Connect() - repeated full (3-way handshake) connections 3. LAST_ACK - complete 3-way handshake, then FIN-ACK 3. Invalid BGP Messages OR 1. OPEN 2. UPDATE 3. KEEPALIVE 4. NOTIFICATION 4. Valid BGP Messages OR 1. Update Flooding OR 1. Flood routes (/32, etc.) 2. Excessively long path attributes 2. Update/Withdraw Flooding 3. MD5 Resource Exhaustion Given the nearly infinite number of attacks and operational conditions that could cause a routing process to stop performing as expected, a significant testing effort will be needed to increase the level of assurance in popular BGP implementations. Findings from [VULNTEST] indicate that basic TCP resource exhaustion attacks are difficult against current popular BGP implementations particularly if the peer has been already established. MD5 resource exhaustion attacks are similarly difficult. The easiest DoS against the BGP process itself is update flooding from a compromised router or inline adversary. 2.1.6 Reset a Single BGP Session In this attack, the adversary is trying to cause a current BGP session in the established state to reset. Such an attack could be launched over and over again to prevent two peers from reliably exchanging routing information. Attack: OR 1. Send message to router causing reset OR 1. Send RST message to TCP stack 2. Send BGP Message OR 1. Notify Convery, et al. Expires March 17, 2004 [Page 10] Internet-Draft BGP Attack Tree September 2003 2. Open 3. Keepalive AND 3. TCP Sequence number Attack (Appendix A.4) 2. Alter configuration via compromised router (Appendix A.1) It is unknown why an adversary would choose to reset a session via Section 2.1.6.1.2. Since the preconditions of attack Section 2.1.6.1.1 are required in order to be successful. Also, it should be noted that the sequence number attack detailed in Appendix A.4 is far from trivial to properly execute. Findings from [VULNTEST] indicate the attack can easily be rendered impossible for blind attackers with basic BCPs and even without BCPs determining the proper TCP packet to cause the reset without inline access to the routers is very difficult. 2.1.7 Send Spoofed BGP Message An adversary could send a BGP message to a BGP speaker and potentially alter the behavior of the routing process. This attack is mainly designed to insert false information into a BGP session, or to reset a session. Attack: OR 1. TCP Sequence number Attack (Appendix A.4) 2. Intercept or Modify Data Through Man-in-the-Middle (MITM) Attack (Appendix A.3) AND 3. Build a valid BGP packet This attack assumes that the adversary is able to cause the BGP speaker to accept a message without establishing a peering relationship. Spoofing the message is the primary mechanism to accomplish this. Because of the requirement for the TCP sequence number attack, this attack is quite difficult and findings in [VULNTEST] indicate that after the spoofed update is sent, the legitimate TCP session will begin to ACK storm resulting in a session reset in several minutes. 2.2 Attack Scenarios The attack scenarios represent larger goals an adversary may have which use BGP as a means to accomplish them. These attacks use the atomic goals discussed in Section 2.1 as a mechanism to reduce the duplication of information within each tree. The following attack scenarios are defined: o Disable critical portions of the Internet by disrupting Internet Convery, et al. Expires March 17, 2004 [Page 11] Internet-Draft BGP Attack Tree September 2003 routing tables o Force a multi-homed AS to use an alternate path to/from an outside network instead of the preferred path o Disable a single-homed AS o Disable a multi-homed AS o Blackhole traffic 2.2.1 Disable Critical Portions of the Internet by Disrupting Internet Routing Tables Common concerns regarding BGP have described scenarios where large section of the Internet become unreachable due to the lack of security features in BGP. In theory, the attack can be done in one of three main ways: physical destruction, social engineering, or routing attacks. Attack: OR 1. Physical Destruction OR 1. Destroy Peering Points 2. Strategic Link Destruction (backhoe) 2. Social Engineering 3. Routing Attacks OR 1. Alter global Internet routing table OR 1. Insert unauth prefix into route table (Section 2.1.3) 2. Establish unauthorized BGP session with peer (Section 2.1.2) AND 3. Ensure propagation in spite of prefix filtering 4. Repeat for ASs at multiple ISP 2. Disable critical core routers OR 1. Router overload leading to crash OR 1. DDoS 2. Worm 3. Loops 4. Change prefix paths (Section 2.1.4) 2. Exploit pervasive implementation flaw on router OR 1. Memory exhaustion 2. CPU exhaustion 3. Magic packet (buffer overflow, etc.) 3. DoS BGP Process (Section 2.1.5) 4. Exploit routing table memory limitations AND 1. Find unfiltered routing distribution point 2. Send the most specific routes that will be accepted and propagated upstream Convery, et al. Expires March 17, 2004 [Page 12] Internet-Draft BGP Attack Tree September 2003 Since this I-D is focused on BGP, this tree elaborates on the routing related portion of the tree. Any of the above listed attack goals are non-trivial and would require extensive coordination and potentially insider involvement. 2.2.2 Force a Multi-homed AS to use an Alternate Path to/from an Outside Network Instead of the Preferred Path Another way that BGP can be compromised is by forcing a multihomed AS to change the normal path preference. This can result in the entire AS using a suboptimal path, or using links that cost the AS more money. In the extreme case, changing the path preference could cause a link to become oversubscribed and result in the loss of data or control traffic. Attack: OR 1. Force traffic from outside network to use alternate path OR 1. Lower preference of preferred path OR 1. Change path preference of a prefix (Section 2.1.4) 2. DoS BGP Process (Section 2.1.5) 3. Reset BGP Session (Section 2.1.6) 4. Compromise Router (Appendix A.1) 2. Raise preference of alternate path (Section 2.1.4) 2. Force traffic going to outside network to use alternate path OR 1. Lower preference of preferred path OR 1. Change path preference of a prefix (Section 2.1.4) 2. DoS BGP Process (Section 2.1.5) 3. Reset BGP Session (Section 2.1.6) 4. Compromise Router (Appendix A.1) 2. Raise preference of alternate path (Section 2.1.4) 2.2.3 Disable a Single-homed AS This attack is a smaller scale version of the attack described in Section 2.2.1. Here the adversary need only prevent a single-homed AS from communicating with the rest of the Internet. Attack: OR 1. Disable provider link OR 1. Physical link destruction 2. Social engineering 3. Turn off the link by compromising the upstream router (Appendix A.1) 2. Disable AS via routing protocol attack OR 1. DoS BGP Process (Section 2.1.5) 2. Reset BGP Session (Section 2.1.6) 3. Compromise router (Appendix A.1) Convery, et al. Expires March 17, 2004 [Page 13] Internet-Draft BGP Attack Tree September 2003 Any crashes or resets initiated by the adversary in Section 2.2.3.2.1 or .2.2 would usually require the attack be generated continually to prevent the router from reestablishing proper communications with its peer. 2.2.4 Disable a Multi-homed AS This attack is a combination of Section 2.2.3 and Section 2.2.1. The number of links the AS under attack has with other ASs will dictate the type of attack necessary to most efficiently achieve the adversary's objectives. This attack sequence, in particular, would benefit from further testing through lab simulation and the association of attributes to each of the leaf nodes. Attack: OR 1. Disable links 1...N (Section 2.2.3) 2. Disable critical portions of the ASs network (Section 2.2.1) To summarize, the adversary can either consider the attack like disabling several individually connected single-homed ASs, or as a smaller version of the Internet as a whole. 2.2.5 Blackhole Traffic BGP can be used to blackhole traffic. If an adversary has access to the forwarding path of the target system, he can quietly discard the traffic while continuing to function as a BGP speaker. The adversary could also affect the BGP tables of his neighbors using BGP advertisements so that they would send traffic to the incorrect destination. One way this could be accomplished is through the unauthorized origination of a prefix. Attack: OR 1. Drop traffic on the wire itself (Section 2.1.4.1.2) 2. Drop traffic on a router (without using BGP) OR 1. Policy route to null 2. Static route to null AND 3. Gain administrative access to the router OR 1. Rouge router 2. Misconfigured router 3. Compromise router (Appendix A.1) 3. Drop traffic using bogus BGP messages OR 1. Establish unauthorized BGP session with peer (Section 2.1.2) 2. Originate unauthorized prefix/attribute (Section 2.1.3) 3. Compromise router (Appendix A.1) Convery, et al. Expires March 17, 2004 [Page 14] Internet-Draft BGP Attack Tree September 2003 3. Testing Considerations BGP design decisions (such as the selection of TCP as the transport protocol) certainly impact the security of the Internet routing infrastructure. However, operational considerations and the quality of the BGP implementations may have a greater impact on Internet security. Testing (as the ultimate determination of relative difficulty of an attack) is especially critical for threat/ vulnerability analyses that use attack trees. This is because the likelihood, criticality, and access requirements of leaf nodes determine which are the most likely paths through the tree. As discussed earlier, test procedures and results could be released in a subsequent I-D. Such analysis should be environment specific. For example, the analysis of this attack tree will be fundamentally different for Internet service provider networks and enterprise networks. The same can also be said of the differences in attack methods between a remote blind adversary and a trusted insider. Early findings in this area are available in [VULNTEST]. Convery, et al. Expires March 17, 2004 [Page 15] Internet-Draft BGP Attack Tree September 2003 References [ATTACKTREE] Schneier, B., "Attack Trees", December 1999. [MODELING] Moore, A., Ellison, R. and R. Linger, "Attack Modeling for Information Security and Survivability", March 2001. [BGPVULN] Murphy, S., "BGP Security Vulnerabilities Analysis", February 2002. [GLOSSARY] Shirey, R., "Internet Security Glossary, RFC 2828", December 1999. [BGPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option, RFC 2385", August 1998. [SEQATTACKS] Bellovin, S., "Defending Against Sequence Number Attacks, RFC 1948", May 1996. [RANDOMINC] SEQATTACKS, T., "The Problem With Random Increments", March 2001. [BGP] BGP, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4), RFC 1771", March 1995. [VULNTEST] Convery, S. and M. Franz, "BGP Vulnerability Testing: Separating Fact from FUD", June 2003. Authors' Addresses Sean Convery Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US Phone: +1 408 853 8753 EMail: sean@cisco.com Convery, et al. Expires March 17, 2004 [Page 16] Internet-Draft BGP Attack Tree September 2003 David Cook Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 US Phone: +1 919 392-8772 EMail: dacook@cisco.com Matthew Franz Cisco Systems, Inc. 12515 Research Blvd. Austin, TX 78759 US Phone: +1 512 378 1648 EMail: mfranz@cisco.com Convery, et al. Expires March 17, 2004 [Page 17] Internet-Draft BGP Attack Tree September 2003 Appendix A. Supporting Atomic Goals A.1 Compromise Router Although outside the scope of routing protocol security, if the routers themselves can be compromised the routing infrastructure can be subverted. Attack: OR 1. Gain physical access to router AND 1. Gain physical access to data center 2. Guess passwords OR 3. Perform password recovery 2. Gain logical access to router OR 1. Compromise network manager system OR 1. Exploit application layer vulnerability in server 2. Hijack management traffic 2. Login to router OR 1. Guess password 2. Sniff password 3. Hijack management session OR 1. Telnet 2. SSH 3. SNMP 4. Social engineering 3. Exploit implementation flaw in protocol/application in router OR 1. Telnet 2. SSH 3. SNMP 4. Proprietary management protocol The ability of an adversary to compromise a BGP speaker is largely dependent on operational best practices: use of secure management protocols and authentication mechanisms, use of intrusion detection systems, etc. A.2 Denial of Service (DoS) Router Denial/degradation of service attacks can be conducted against network devices using a variety of well-known techniques. Attack: OR 1. Physical destruction of router 2. Link layer attacks OR 1. Protocol attack using link layer protocol 2. Physical link attack Convery, et al. Expires March 17, 2004 [Page 18] Internet-Draft BGP Attack Tree September 2003 3. ARP attacks 4. IP attacks OR 1. ICMP Message OR 1. Flooding 2. Malformed 2. IP Fragmentation Attack 5. UDP attacks 6. TCP attacks OR 1. SYN Flood 2. Connect() 3. LAST_ACK 4. New/undiscovered DoS against TCP 7. Application-Layer DoS OR 1. Telnet 2. SSH 3. SNMP 4. Other aplication layer protocol All of these attacks are outside the scope of BGP design or implementation and ultimately depend on the survivability of the routing device itself, its ability withstand attack, and the proper configuration of the device based on published best-practices. A.3 Intercept or Modify Data Through Man-in-the-Middle (MITM) Attack Man in the middle attacks against cryptographic protocols or application layer protocols allow an adversary to effectively proxy communication between two parties allowing any data to either be read or altered. Although not impossible to conduct after a session has been established, the attack is easier done prior to session initiation. Attack: AND 1. Gain write access to network segment of one or more peers 2. Subvert address infrastructure OR 1. ARP/MAC spoofing 2. DNS spoofing 3. Proxy BGP sessions between BGP speakers The goals of a MITM attack against BGP are almost identical to a TCP Sequence Number Attack (Appendix A.4) against a BGP session. DNS Spoofing may be unlikely because many implementations/configurations are unlikely to use hostnames in router configurations. Convery, et al. Expires March 17, 2004 [Page 19] Internet-Draft BGP Attack Tree September 2003 A.4 TCP Sequence Number Attack TCP suffers from well-known design flaws which make it possible to hijack or terminate applications that use it as their transport protocol. As a blind adversary, these attacks are quite difficult to execute, particularly as they apply to BGP. Attack: OR 1. Blind Spoofing Attack AND 1. Guess sequence number use by a BGP speaker 2. Inject valid BGP message 2. Non-Blind Spoofing attack AND 1. Sniff Traffic (Appendix A.5) 2. Inject valid BGP message based on sequence numbers Adequate initial sequence number randomness [SEQATTACKS] should mitigate most blind attacks, although some research [RANDOMINC] suggests blind attacks may be easier that previously thought, all of these attacks require a large sample set of ISNs, something which can be easily mitigated with proper BGP BCPs. A.5 Sniff Traffic Depending on the network topology, there are many ways of gaining read-access to a network to conduct passive attacks. The most common method would be to compromise a system (typically a general purpose operating system) on the segment and install software the puts a network interface card in promiscuous mode and captures traffic. Attack: OR 1. Gain local network access to a segment AND 1. Compromise server 2. Install sniffing software 2. Tap physical medium 3. Redirect traffic through a compromised host ARP/MAC spoofing may be necessary to sniff traffic on switched networks and many tools are available which make this a trivial task. Convery, et al. Expires March 17, 2004 [Page 20] Internet-Draft BGP Attack Tree September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Convery, et al. Expires March 17, 2004 [Page 21] Internet-Draft BGP Attack Tree September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Convery, et al. Expires March 17, 2004 [Page 22]