Towards A Practical and Effective BGP Defense System

Towards A Practical and Effective BGP Defense System Douglas Comer, Parmjeet Singh, and Subramanian Vasudevan Abstract At the center of the Internet, major ISPs use the Border Gateway Protocol (BGP) to propagate information about Internet destinations and how to reach them. Despite decades of research, BGP problems still exist. In particular, the Internet has a long history of hijacking incidents in which an ISP uses BGP to advertise an incorrect path for a given destination, causing traffic to be diverted away from the destination to the advertising ISP. This paper considers the problem of defending BGP against both unintended and intentional hijacking attacks. It considers extant solutions and presents some preliminary findings about a new approach. To put our ongoing work in context, the paper discusses prior work, analyzes techniques that use external validation as well as techniques that employ local data analysis, and shows why neither approach handles all cases. It then focuses on a new hybrid solution. Keywords BGP, BGP defense, BGP security, Internet routing, route hijacking. T I. INTRODUCTION HE Border Gateway Protocol (BGP) is, de facto, the standard for exterior routing in the Internet. Although BGP is decades old, problems still exist. For example, black holes can occur in which packets cannot be delivered to a given set of addresses. Similarly, rapid route changes (called route flaps) and misconfigurations disrupt service. For example, serious incidents have been reported in [1, 2]. We make a key observation about most of the incidents that have been reported: Most attacks are unintentional, and are caused by misconfiguration or human errors rather than by malicious intent. Such problems can occur easily and quickly because BGP offers no protection against incorrect routing information. In essence, the trust model is based on endpoints. After a pair of ISPs agrees to use BGP to exchange routing information, each ISP specifies the address of a router that the ISP will use. Each side configures its BGP to speak BGP with the other Douglas Comer is Distinguished Professor at the Computer Science Department of Purdue University (comer@cs.purdue.edu). Parmjeet Singh is a Graduate Student at the Computer Science Department of Purdue University (singh136@purdue.edu). Subramanian Vasudevan is a Graduate Student at the Computer Science Department of Purdue University (svasudev@purdue.edu). ISP s router. Requiring an explicit configuration of endpoints provides a level of trust because doing so prevents an ISP from accepting BGP advertisements from a random site. Once BGP endpoints have been configured, however, the protocol blindly trusts all advertisements sent by the other side without checking the validity of the data it receives. In fact, an ISP cannot configure BGP to validate data because the protocol has no mechanisms for doing so. Consequently, if a human at one ISP accidentally misconfigures routes, BGP will advertise the routes to its peer and the peer will accept the routes. Furthermore, the peer will advertise to its peers, and the error can propagate across the entire Internet. Thus, a small error at one ISP has the potential to be catastrophic. To better understand the problem, consider an incident in 2009 in which traffic to YouTube was hijacked by Pakistan Telecom [3]. Human error caused a router in Pakistan to be misconfigured with a range of network prefixes that belong to YouTube. BGP running on the router picked up the incorrect information and sent an advertisement to its peer. As a result, the peer began to direct YouTube traffic to the misconfigured router in Pakistan. The peer then started advertising a path to YouTube to its neighbors, and they started forwarding traffic to the misconfigured router. Soon, the incorrect information propagated throughout the Internet, and YouTube traffic was misdirected. Of course, a BGP defense scheme that only handles inadvertent attacks is incomplete. It is essential that a defense also works against malicious attacks. In particular, a defense must avoid man-in-the-middle attacks [4] in which an attacker diverts traffic through a path that allows the attacker to examine packets before passing them on to their intended destination. II. PRIOR WORK Both network researchers and network operators have proposed hijack prevention schemes. For example, Secure BGP (S-BGP) [7], Secure-Origin BGP (So-BGP) [5], and Key Chain based BGP (KC-BGP) [6] are well-known. However, the solutions have not been deployed widely, either because they introduce inordinate complexity and computational overhead or require modification of underlying protocols, such as IP. In practice, less draconian techniques, such as route filtering, are used to handle many of the common problems. That is, when configuring BGP, an ISP specifies a set of prefixes that should be ignored (filtered) in incoming advertisements. Typically, each ISP includes its own customers in the list, thereby preventing any other ISP from misdirecting the customers traffic. Existing hijack prevention mechanisms can be classified 45

into two categories: proactive and reactive. A reactive mechanism monitors routes, looks for indications that a problem has occurred, and then creates a response accordingly. A proactive mechanism monitors incoming BGP advertisements, looks for indications that a given advertisement will cause problems, and tries to prevent the problem from occurring. For example, route filtering is the most primitive type of proactive defense. From data collected during hijack incidents we make a key observation: Route Hijacks typically persist for only a few hours. The point is that early detection is important: a mechanism that spends many minutes to detect a hijack may miss a significant percentage of the hijack. Furthermore, given that most hijacks are caused by human error and corrected once the error has been discovered, after-the-fact analysis of cause is unimportant because human error will be part of the problem. Although a proactive mechanism that offers rapid detection and prevention can minimize disruption, all solutions pose tradeoffs. A proactive solution can err by being too conservative. For example, in the extreme, a proactive filter will block all advertisements until each route has been verified manually, defeating the ability of Internet routing to accommodate failures quickly and automatically. Even if a proactive mechanism only introduces a moderate delay, it may not accept legitimate route changes quickly, meaning that old routes will persist longer after a network or router failure. III. RAPID RECOVERY AND SUBNET ADVERTISEMENT Once a hijack has been detected, global routing must be reestablished quickly. The ultimate solution consists of identifying and informing the ISP that initiated the incorrect BGP advertisements so the incorrect routes can be withdrawn. However, identifying the culprit often requires a manual process that can take several hours. Network operators have devised an ingenious scheme known as rapid recovery that allows routing to be corrected before the incorrect routes have been withdrawn: the ISP that owns a hijacked prefix can start sending subnet advertisements that cover the range. For example, suppose the ISP that owns prefix: 128.10.0.0 / 16 discovers its prefix has been hijacked. While working to identify the cause of the hijacking, the ISP can advertise two subnet routes: 128.10.0.0 / 17 128.10.128.0 / 17 Which taken together cover the hijacked range. Although it does not guarantee correct routing will be established, rapid recovery is widely used and usually works because most BGP systems are configured to prefer the most-specific routes. For example, an incident occurred during February, 2008 when YouTube was hijacked. At 20:07:25, YouTube began to announce a subnet route, 208.65.153.0/24. By 20:08:30, over 40 service providers had stopped using the hijacked path; the hijacked route was not withdrawn until 21:10. Hijack prevention mechanisms can hinder rapid recovery: if a proactive mechanism refuses new routes after detecting an error, it will also refuse sub-net advertisements. Thus, we can consider the latency that hijack prevention introduces and the reaction time. We understand that if too little time elapses before a new route is accepted, the system will not prevent hijacking, but if too much time elapses before a new route is accepted, the system will not recover quickly and traffic will continue to flow along an incorrect path. IV. ORGANIZATION OF THE PAPER This paper, which reports on-going work to analyze the costs and benefits of approaches used to strengthen BGP, is organized as follows: We first give a brief history of prefix hijack incidents and make observations about prevention. We discuss the effectiveness of history-based and registry-based techniques and show how each covers some cases. We then focus on the feasibility and effectiveness of a hybrid proactive solution and give preliminary results that show a hybrid scheme can provide path validation at low overhead. V. PREFIX HIJACKS AND INCIDENTS Prefix hijacking, sometimes referred to as BGP - hijacking or route hijacking occurs when an ISP incorrectly advertises an IP prefix that belongs to another ISP. As noted above, many hijacks are unintentional a human misconfigures routes which BGP propagates throughout the Internet, disrupting the ability to reach the affected routes. Of course, incidents may occur in which an ISP deliberately propagates incorrect information to aid in sending spam or denial of service attacks. IP prefix hijacking can occur in several ways [1, 2]. An ISP hijacker can announce that it owns (i.e., is the origin for) an IP address or can insert itself in a BGP path. The former means that traffic for the specified addresses will be directed incorrectly to the hijacker rather than to the owner. As a result, the owner is cut off and will not receive traffic for IP addresses it owns. The latter form means that the origin of the IP address is unaffected, but traffic detours to the ISP that inserted itself in the path. The data collected from various hijack incidents shows that origin hijacking is the primary source of problems, and forms the focus of our research and this paper. Two forms of origin hijacking are important: full prefix hijacking and sub prefix hijacking. We use the term full prefix to characterize a situation in which a hijacker sends an advertisement that matches the owner s. That is, the prefix in a hijacker s announcement exactly matches the prefix in the owner s announcement. It should be noted that some organizations only announce subnets of their IP addresses (e.g., a multihomed organization may announce some subnets through one ISP and other subnets through another). Thus, the definition of full does not imply a prefix covers all the addresses of a particular organization. Because both victim and hijacker announce the same prefix, all other ISPs in the Internet will select one of the two paths. Several full-prefix hijacks have 46

occurred. For example, on May 7, 2005, Google s (AS15169) prefix 64.233.161.0/24 was mistakenly announced by Cogent (AS174). Subnet prefix hijacking occurs when the hijacker announces a subnet (i.e., a subprefix) of the IP prefix announced by the victim. Interestingly, many ISPs apply the longest-prefix rule, which states that when multiple prefixes cover a given address, the longest prefix (i.e., the most-specific route) is preferred. The longest-prefix is useful because it allows an organization s address space to be divided into multiple segments (e.g., to accommodate multi-homing), while simultaneously permitting ISPs farther away to aggregate the information into a single prefix. However, the longest-prefix rule means that subnet hijacks will be preferred, and will propagate throughout the Internet. Many recent hijacks fall into the subnet category. For example, a subnet prefix hijack sent YouTube traffic into a black hole for nearly two hours [3]. An unusual type of prefix-hijack, known as a bulk prefix hijack, occurred on December 24, 2004 (Christmas Eve) when over 100,000 routes were incorrectly advertised by TTnet (AS9121). The incorrect information propagated globally, affecting over ten thousand networks. The need for defense against bulk prefix incidents (and a description of the current lack of preparation) was brought up in NANOG 34 [11]. VI. HISTORY AND REGISTRY PREVENTION TECHNIQUES BGP hijack prevention techniques can be divided into two broad categories: one uses a history of past advertisements and the other uses information from an external source, typically one of the routing registries. The history-based approach is easiest to understand: BGP software builds a database by collecting incoming route advertisements. After a short time (less than two weeks), the database will contain paths to all possible destinations in the Internet. Furthermore, the database will contain alternate routes (i.e., paths that are announced, but which are not preferred). BGP then uses the database to validate incoming advertisements: if a BGP peer advertises a new route that is not in the database, the new route is flagged as suspect, and propagated with lower local preference. An advertisement of a subprefix of a prefix already in the history is also considered suspicious, and is quarantined. The quarantine remains in effect for a fixed period (e.g., 24 hours). If the prefix is not withdrawn by the end of the quarantine period, the subprefix is propagated. To understand the registry approach, it is necessary to know that a set of Regional Internet Registries (RIRs) maintains information about IP prefixes and the organization that owns each. An RIR manages the allocation and registration of IP addresses and Autonomous System (AS) numbers for a particular region of the world. Five RIRs exist: African Network Information Centre (AfriNIC) for Africa, American Registry for Internet Numbers (ARIN) for the United States, Canada, and several parts of the Caribbean region, Asia- Pacific Network Information Centre (APNIC) for Asia, Australia, New Zealand, and neighboring countries, Latin America and Caribbean Network Information Centre (LACNIC) for Latin America and parts of the Caribbean region, and Reseaux IP Europeens Network Coordination Centre (RIPE) for Europe, the Middle East, and Central Asia. Registries make their data-base available to ISPs for use in checking prefixes and handling hijacks. Prevention techniques that use a registry approach use a registry database to validate incoming BGP advertisements. In particular, a registry approach can be used to check the origin associated with each prefix: if the origin given in a BGP update does not match the owner of the IP prefix, the new route is flagged as an error. VII. DESIRABLE PROPERTIES OF A HIJACK PREVENTION SYSTEM A hijack prevention system should have the following salient features: Proactive Behavior. Most hijacks last for only a few hours. Thus, a defense system needs to act quickly to prevent the acceptance and propagation of incorrect routes. Reactive schemes do not provide sufficient protection and suffer from long delays before detection completes. Broad Hijack Coverage. The system should handle both prefix hijacks and subnet prefix hijacks. It should also flag bulk prefix announcements. Validation of subnet prefixes presents a challenge. On one hand, BGP must be especially cautious before accepting a subnet prefix because the longest-match rule gives subnet prefixes the potential to cause severe problems. On the other hand, BGP must accept authoritative subnet prefixes because rapid recovery relies on subnet prefix announcements. Prefix Ownership Validation. Although validation of an origin should be straightforward, it is not. Registry databases are inconsistent: a substantial fraction of IP prefixes are unregistered. Further-more, the registries do not exchange information. The instability and inconsistency of various regional registries has been discussed in [10]. Thus, only a history-based approach can handle unregistered prefixes. Support for Recovery. One of the biggest challenges of history-based systems such as PHAS [8] or PGBGP [12] arises once a victim announces a subnet prefix to reverse the effect of a hijack. History-based techniques flag the announcement and either ignore it or propagate it with a lower preference than the full prefix. Thus, a false positive occurs, disabling any recovery attempt. Practical. To be practical, a defense system can-not require changes in the underlying transport protocols (i.e., cannot change IP or TCP). Furthermore, a hijack mechanism cannot require manual updates or extensive configuration. VIII. HYBRID MODEL As we have seen, neither a history-based approach nor a registry-based approach handles all problems. A history-based approach cannot validate the origin on new subnet advertisements, and a registry-based approach cannot handle unregistered prefixes. Thus, to handle all cases, a hybrid approach is needed that uses both a history and a registry database. We will consider hybrid schemes for both origin validation and validation of path elements. A. Hybrid Model For Origin Validation We are experimenting with a hybrid mechanism for hijack prevention by keeping a history and using data from the ARIN Registry. We have accessed the ARIN database and compared 47

the costs of two access mechanisms: online access and caching a local copy. ARIN s online service is known as the Whois Restful Web Service (Whois-RWS). It pro-vides access to registration data contained within ARIN s registration database. The web service is appropriate for cases where the system needs to verify a small number of prefixes. To handle the case where the system encounters a bulk prefix announcement (such as the incident where TTnet announced more than 100,000 prefixes), we maintain a local copy of regional registries. Fortunately, the registry database changes infrequently. To optimize our history database, we decided to pre initialize values with data collected from the Internet. RIPE sets up Remote Route Collectors (RRCs), that peers with tier-1 ISPs and use Quagga routing software to collect raw BGP messages. The data, which is stored in MRT format, is available at the RIPE website [13]. Section 9 describes the implementation. B. Hybrid Model For Path Validation We are extending our experiments with hybrid mechanisms to consider path validation. Each BGP advertisement includes a path of autonomous systems used to reach the specified destination. Thus, an advertisement consists of a tuple (P, AS1, AS2,...ASn), where P is a prefix, ASi is an autonomous system number, and ASn is the origin autonomous system (i.e., the owner of the prefix). External data is available that provides two important properties that can be used to assess the path. First, external data that gives the interconnection of autonomous systems [14] can be used to verify the pair wise interconnections. That is, the path is only valid if each pair along the path (ASi, ASi+1) has a connection. Second, external data that gives topology and AS relationships [15] can be used to verify that the path does not divert to a lower-tier and then move back to a top-tier (diversion is strong indicator of a man-in-the-middle attack. In addition to using external data, we are working on a hybrid approach that uses a combination of sanity checks and a history of the paths specified in past advertisements to assess the validity of a path. In particular, when a path changes, the new path will be announced with lower preference. IX. ARIN S DATA MODEL ARIN provides five top-level data objects, four of which are pertinent to this paper: Network specifies IP address allocation, and the constituent IP CIDR blocks. Autonomous System Number (ASN) records the organization that owns an AS number. Organization gives information about an organization, including a point of contact. Point of Contact (POC) identifies an administrator within an organization ARIN s data model means that hijack prevention software needs to access at least two separate objects: a network object and an autonomous system object. Because two separate transactions must be made for each prefix, the cost of online access prohibits using an online lookup during a bulk prefix hijacking incident. To provide higher-speed lookup, it is possible to download a copy of the entire ARIN database, which we have done. Although downloading the data and storing it in a local database can take hours, the process only needs to be repeated once a day. Moreover, having a local copy may be necessary during a hijacking incident because routing problems may make it impossible for a given BGP system to communicate with an ARIN registry server. X. PRELIMINARY RESULTS AND FUTURE WORK The chart in Figure 1 lists our hybrid approach along with the two major BGP defense mechanisms (SBGP and SO- BGP), and shows the type of attacks each can handle. Much work remains to validate the results and show that a BGP hijack prevention system can be efficient and practical. For example, an initial proto-type for local validation that used a relational data-base to store registry information required over 12 minutes to validate 1000 prefixes. To reduce the time by two orders of magnitude, the database is being replaced with a TRIE. Similarly, we are working on a fast data structure for path validation. TYPE OF ATTACKS S-BGP SO-BGP OUR HYBRID APPROACH Prefix Hijack (mostly misconfiguration ) Strong Strong Strong Path Hijack (man in middle) Limited (Only Topology) Strong Strong Route Leaks (Exploiting Business relations) No No Considerable Fig. 1 Properties of BGP defense mechanism 48

XI. SUMMARY We are investigating BGP hijack incidents and the methods used to detect and prevent hijacks. Most hijacks result from human error in which an ISP inadvertently advertises prefixes that are owned by another ISP. Because BGP does not provide mechanisms that verify the correctness of data, incorrect routes can propagate across the entire Inter-net quickly. A hijack prevention mechanism is needed. Mechanisms used to validate prefixes can be classified as history-based or registry-based. Neither approach alone can prevent all hijacks: a history-based approach does not validate the origin of each prefix, and a registry-based approach cannot handle the many unregistered prefixes. XII. ACKNOWLEDGMENTS The authors acknowledge the support of Cisco Systems and the National Science Foundation Grant No. 1040675. Any opinions, findings, and conclusions or recommendations are the author(s) and do not necessarily reflect the views of the NSF or Cisco. XIII. REFERENCES [1] V. Bono, Explanation and Apology, NANOG Email, April 26, 1997. [2] M. Lad, R. Oliveira, B. Zhang, and L. Zhang, Understanding Resiliency of Internet Topology against Prefix Hijack Attacks, Proc. IEEE/IFIP DSN, 2007. [3] NANOG, YouTube IP Hijacking, February, 2008. [4] DEFCON Attack, reported August 10th, 2008, http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16- pilosov-kapela.pdf [5] J. Ng, Extensions to BGP to support Secure Origin BGP (So-BGP), Internet Draft draft-ng-sobgp-extensions-00, October, 2002. [6] H. Yin, B. Sheng, H. Wang, and J. Pan, Keychain-Based Signatures for Securing BGP, IEEE Journal on Selected Areas in Communications, 28:8, October, 2010, pp 1308-1318. [7] S. Kent, C. Lynn, and K. Seo, Secure Border Gateway Protocol (S- BGP), IEEE Journal on Selected Areas in Communications, 18:4, April, 2000, pp 582-592. [8] M. Lad, D. Massey, D. Pei, Y. Wu, B. Zhang, and L. Zhang, PHAS: A Prefix Hijack Alert Sys-tem, 2006. [9] Y. Hu, A. Perrig, and M. Sirbu, ABSTRACT SPV: Secure Path Vector Routing for Securing BGP, 2004. [10] K. Sriram, O. Borchert, O. Kim, P. Gleichmann, and D. Montgomery, A Comparative Analysis of BGP Anomaly Detection and Robustness Algorithms, Proc. of the 2009 Cyber security Applications & Technology Conference for Homeland Security, 2009, pp 25-38. [11] A Popescu, B. Premore, and T. Underwood, Anatomy of a Leak: AS9121 (or, "How We Learned To Start Worrying and Hate Maximum Prefix Lim-its"), NANOG 34, May 16, 2005. [12] J. Karlin, S. Forrest, and J. Rexford, Pretty Good BGP: Improving BGP by Cautiously Adopting Routes, Proc. of the 2006 IEEE International Conference on Network Protocols, 2006, pp 290-299. [13] RIPE, RIS Raw Data in http://www.ripe.net/data-tools/stats/ris/ris-raw-data [14] CAIDA database of relationships: http://www.caida.org/data/active/as-relationships/ [15] AS Taxonomy data from CAIDA: http://www.caida.org/data/active/as_taxonomy/ 49