Hi-BGP: A Lightweight Hijack-proof Inter-domain Routing Protocol

Transcription

1 1 Hi-BGP: A Lightweight Hijack-proof Inter-domain Routing Protocol Jian Qiu and Lixin Gao Department of ECE, University of Massachusetts, Amherst, MA jqiu@ecs.umass.edu, lgao@ecs.umass.edu Abstract BGP is the cornerstone of the Internet. However, the implicit trust assumption in BGP s design destines its inherited vulnerability. Prefix hijacking is one of the large-scale BGPspecific routing anomalies that are able to paralyze the Internet. This calls for a hijack-proof security solution. By putting the protection against prefix hijacking the top priority, we design a lightweight hijack-proof BGP system Hi-BGP. Hi-BGP utilizes the existing BGP system to distribute the relevant route validation information and use the information to prevent various prefix hijacking. In addition, we propose a transition scheme of Hi- BGP so that it can be incrementally deployed. At the same time, we show that Hi-BGP is lightweight and can be deployed in the Internet. Fig. 1. AS D AS E AS A AS B AS F peer-to-peer AS C provider-to-customer An example of redistribution hijacking I. INTRODUCTION The Internet is divided into tens of thousands of Autonomous Systems (AS), each of which is an independently administrated domain. The routing information within an AS is maintained by Interior Gateway Protocols (IGPs) while the Border Gateway Protocol (BGP) [28] is employed to maintain and exchange inter-domain routing information. BGP is the only Internet-wide routing protocol. Its performance and reliability is fundamental and vital to the Internet. However, BGP is designed based on the assumption that there is implicit trust among the participants in the system. The standard BGP does not employ any explicit security measure [28] until MD5- based TCP encryption was introduced to protect the peering sessions between BGP routers [19]. Nevertheless, there is no efficient measure taken to prevent bogus routing information from being disseminated in the routing system. This potential hole could be exploited to carry out an Internet-wide attack and paralyze the network. A notorious example of BGP security threat is the AS7007 incident [27] in 1997, in which AS7007 announced thousands of /24 prefixes that were not allocated to it. The fake routes were propagated throughout the Internet and misled the traffic to these prefixes to AS7007 instead, which interrupted the connectivity of a large portion of the Internet for more than two hours. However, even though more than 8 years have passed, the situation has little change. A recent incident posted on the NANOG [8] mailing list reported that AS26210 originates routes to several /8 prefixes, including /8, /8 and /8 on September 9th, 2005 [25]. Even worse, some tier-1 providers did not take any measure to prevent these bogus routes from leaking into backbone routing tables. From these incidents, we conclude how easily the bogus routing information can get into the inter-domain routing system and how fragile the system is. Roughly, a BGP route is a tuple of a prefix, which represents the address space of the destination network, and an AS- Path, which is a AS sequence from the local AS to the origin-as of this route. Prefix hijacking is a BGP routing anomaly that injects false routes into global routing tables, which can be initiated by either malicious attackers or careless misconfigurations. The traffic destined to the victim prefixes will be misled to some detouring paths, which might expose the traffic content to the malicious attackers, cause extreme congestion or delays, or even interrupt the reachability of the destination prefixes. A straightforward way to carry out prefix hijacking is to announce a route whose origin-as is not the legitimate one. We refer to this kind of hijacking as origin-as hijacking. The origin-as hijacking could be exploited by the malicious attackers to borrow others address spaces to carry out DDoS attacks or send spam mails. In addition, without spoofing the origin-as, the malicious attackers can also trap the traffic to the victim prefixes by announcing a route with a bogus AS-Path which seemly destine to the legitimate origin-as but actually through some non-exiting AS links. We refer to this kind of hijacking as AS-Path hijacking. The most imperceptible prefix hijacking is redistribution hijacking, in which the attacker announces the routes learned from a provider (or peer) to another provider (or peer). In this case, although the malicious routes contain neither spoofed origin-ass nor bogus AS-Paths, they still mislead the traffic to go through unwanted paths. While origin-as hijacking and AS-Path hijacking have been well addressed in the literature [14], redistribution hijacking

2 is not. However, it does take place in the Internet and be as dangerous as other two hijacking methods. One of the real examples of redistribution hijacking occurred on Dec 7, 2000 [21]. A broadband retailer in Texas, which is the customer of Sprint (AS1239) and Level 3 (AS3356), redistributed the routes learned from Sprint to Level 3, including routes to /8 (GE) and /8 (AT&T). Level 3 in turn picked these routes and distributed them to its neighbors. Moreover, under certain settings, redistribution hijacking is able to hijack any prefix in the Internet and cause unexpected results. Figure 1 illustrates an example. Suppose that two peering AS A and B are providers of a malicious AS C and AS A always prefers customer router to peer routes. Then C can redistribute AS B s routes to A to hijack the traffic between A and any other prefix it wants. Prefix hijacking not only does harm to the individual prefixes but also hurts the common health of the Internet it can cause widespread performance degradation and reachability issues in the Internet. The AS7007 incident has persuasively demonstrated the detrimental impact. However, we find that the existing BGP security solutions cannot provide simple and efficient protection against the redistribution hijacking. Our survey on the prefix hijacking on the Internet also shows that the Internet is in great need of a simple and practical secure BGP solution against prefix hijacking. As a result, we put the prevention of prefix hijacking, especially the redistribution hijacking, the top priority and design a lightweight hijackproof BGP Hi-BGP. Hi-BGP is designed on top of the standard BGP. It relies on the route validation information explicitly announced by the relevant ASs, to detect and filter out prefix hijacking routes. Hi-BGP can prevent not only origin-as and AS-Path hijacking, but also redistribution hijacking. Specifically, Hi-BGP requires each AS to explicitly declare the AS relationships with its neighboring ASs so that the redistribution hijacking can be prevented. In addition to Hi-BGP, we also propose a transition scheme pre-hi-bgp to facilitate the incremental deployment of Hi-BGP. During the transition period, pre-hi-bgp enables each AS to infer reliable route validation information from historical BGP data and use it as a supplementary to the partial information got from Hi-BGP-enabled ASs. The mechanism transitions the inter-domain routing system to a fully deployed Hi-BGP system seamlessly without losing protection against prefix hijacking. At the same time, we minimize the overhead and complexity of Hi-BGP so that it is feasible and affordable to be deployed in the Internet. We leverage several techniques employed in the existing BGP security solutions. For instance, we harness the system architecture proposed by so-bgp to disseminate routing validation information within the BGP system, minimize the usage of computation intensive cryptographic operations and utilize the decentralized Web-of-Trust to distribute the maintenance overhead of route validation information. The rest of the paper is organized as follows. The following two sub-sections survey the status of prefix hijacking in the Internet and the related work. Section 2 describes the system architecture of Hi-BGP. Section 3 elaborates the design of pre- TABLE I THE CLASSIFICATION OF THE NANOG ROUTING ANOMALIES Category #Events Prefix Origin-AS 22 Hijacking AS-Path 0 Redistribution 13 Others Erroneous Filtering 37 Erroneous Leakage 28 Total 100 Hi-BGP. We also evaluate the overhead of Hi-BGP and pre- Hi-BGP in the paper. Finally, section 4 concludes the paper. A. Survey of Prefix Hijacking in the Internet In order to have a pragmatic idea on to what extent the BGP system suffers from large-scale BGP-specific attacks and what kind of routing anomalies impact the BGP system most in reality, we carry out a survey on the routing anomalies posted on the NANOG mailing list [8] since Note that we concentrate on the large-scale anomalies pertaining to the propagation of routing information in the inter-domain routing system. The routing outages causing local connectivity issues, such as fiber cuts or electricity failures, are out of our concerns. We find that prefix hijacking frequently occurred in the Internet. As shown in Table I, 100 large-scale BGP routing anomalies are found in total. 22 of them are origin-as hijacking and 13 of them are redistribution hijacking. Although mis-configuration might be the major reasons for most of the cases [13], they do show that BGP is vulnerable to prefix hijacking in the real world. Because of the detrimental global impact that prefix hijacking potentially could have, a BGP security solution should and has to be hijack-proof. The rest of the anomalous events fall into two classes. 37 anomalies are due to erroneous filtering, which is the event that the routes of the legitimate prefixes cannot be disseminated throughout the Internet. We find that too strict route filtering is usually the causes. Ironically, the remaining 28 routing anomalies are the erroneous leakages due to too loose filtering or no filtering. The seemingly contradicting observation shows the embarrassed dilemma that network operators are facing. On one hand, the increasing threat of large-scale routing anomalies is pushing them to employ strict filtering to prevent the propagation of anomalous routes; on the other hand, they are lacking of appropriate information support to perform up-to-date and thorough filtering. An adequately secure and practically feasible BGP security solution is the solution. B. Related Work BGP is vulnerable to two general categories of attacks [14]. First, each BGP router, as an ordinary network node, might suffer from peering attacks that any network node would experience, such as DoS attacks and man-in-the-middle eavesdrop. These attacks aim at the security holes in the peering sessions between BGP routers. Existing end-to-end security solutions such as IPSec, SSL/TSL or MD5-based TCP encryption [19] can be employed to prevent such attacks. The other attacks are BGP-specific. These attacks exploit BGP s 2

3 implicit trust assumption and inject false routing information into the system. The malicious information might be propagated throughout the Internet and trigger Internet-wide routing anomalies. These attacks aim at the security vulnerabilities in the whole routing infrastructure. The security issues cannot be addressed by the traditional security solutions. However, they could cause much more detrimental and significant impact. Several complete and systematic BGP security architectures are proposed [14] [35]. S-BGP [23] [26] suggests a modification of BGP which completely relies on the computationally intensive cryptographic operations to secure BGP. SPV [20] is in the same flavor but uses less resource consuming encryption system. On the contrary, the Inter-domain Route Validation (IRV) [18] neither revises BGP nor relies on cryptography, but constructs an overlay system outside of the BGP system to coordinate and authenticate the routing information among ASs. Secure Origin BGP (sobgp) [34] adopts a tradeoff between S-BGP and IRV. It proposes an extension of BGP and uses the existing BGP system to distribute and coordinate route validation information. At the same time, the decentralized Web-of-Trust methodology is explored in [34], [32] and [31]. For example, the Pretty Secure BGP (psbgp) [32] utilizes the consistency checking among the distributed prefixorigin certifications to authenticate the prefixes origin-ass. In [31], the consistency between the route advertisements to the same destination is exploited to ensure the integrity of the routing information. The above solutions can provide the protection against origin-as and AS-Path hijacking. However, they cannot efficiently prevent redistribution hijacking. Although IRV provides the mechanism to protect redistribution hijacking, it costs excessive communication overhead since it needs to query the routing policy of every AS along the AS- Path hop by hop for every single route. Different from above approaches, which either deploy a new system or modify the BGP, Kruegel et al [24] proposes to utilize the passive measurement of BGP routing traffic to gather enough route validation information to secure BGP. The authors propose to use core ASs to detect the redistribution hijacking. However, the protection is limited to the routes traversing the core ASs and depends on the accuracy of the inferred core ASs. In addition to above undergoing research proposals, some efforts have been made in the operational field to secure the BGP system. Team Cymru [7] seeds a bogon filter list. The CIDR-report [1] reports the possible bogon prefixes in the backbone routing tables while CompleteWhois [2] is monitoring possible origin-as hijackings in the Internet. Hi-BGP is well nourished by the virtues of the existing BGP security proposals and practices. The sobgp [34] lends us a concise and efficient system architecture in which the route validation information is disseminated and maintained in the BGP system itself. From sobgp [34] and psbgp [32], we borrow the idea of Web-of-Trust to maintain the route validation information in a decentralized way so as to distribute the maintenance overhead. The passive measurement methodology adopted in [24] inspires us to utilize the historical BGP information to provides basic security guarantees during the transition period. As a result, Hi-BGP is not only Fig. 2. Maintenance server AS A RIR server (ARIN) AS B AS D Maintenance server The system architecture of Hi-BGP RIR server (APNIC) AS E AS C RIR server (RIPE) lightweight but also be able to be deployed incrementally with adequate protection against prefix hijacking. More importantly, the equipment of AS relationship information [17] endows Hi-BGP the unique ability to prevent redistribution hijacking, which distinguish Hi-BGP from other BGP security solutions. II. HI-BGP Figure 2 shows the architecture of the Hi-BGP system over the existing BGP system. Besides the standard BGP processes, each Hi-BGP router maintains the relevant route validation information that this AS is responsible for maintaining and announcing, stores a route validate information database of the Internet and use the information to verify routes before they enter the standard BGP process. In order to reduce the administrative overhead that coordinates the information maintained by several BGP routers, an ISP may set up a dedicated maintenance server to maintain all its responsible route validation information and inject the information into the BGP system. In addition, in order to provide the certification information for the prefixes assigned by the Regional Internet Registries, such as ARIN, RIPE, APNIC, AfriNIC and Lac- NIC, each registry sets up a RIR server connecting with the BGP system. The route validation information is propagated within the BGP system. The following four features endow Hi-BGP the unique hijack-proof ability with its lightweight architecture. First, Hi-BGP requires each AS to announce its relevant route validation information explicitly. Each router uses the collected validation information to perform mandatory filtering to prevent prefix hijacking. The accuracy and completeness of the route validation information guarantees the efficient protection against prefix hijacking. Second, Hi-BGP properly divides the route validation information into pieces and distributes the maintenance tasks to individual ASs. The decentralized approach makes it feasible to maintain a coherent Internet-wide route validation database distributedly. At the same time, we allow the redundancy of the route validation, which makes the route validation information more reliable and consistent. Third, Hi-BGP utilizes the existing BGP system to propagate route validation information, which is encapsulated in a BGP SECURITY message. The mature system ensures the dissemination simple, fast and reliable. 3

4 Last, Hi-BGP routers store a local route validation information database collected from the entire Internet, which reduces the communication overhead and makes the hijacking detection simple and fast. A. Route Validation Information Maintenance Hi-BGP utilizes the complete and accurate validation information of prefix ownerships, AS links and AS relationships of the entire Internet to prevent origin-as hijacking, AS-Path hijacking and redistribution hijacking. We design mechanisms to let each AS maintain appropriate amount of information but also leave enough redundancy to ensure the consistency of the information. 1) Prefix Ownerships: A prefix ownership indicates the legitimate origin-as of a prefix. A prefix should represent the original address block that this AS obtained from the relevant provider or Regional Internet Registry. The AS should not segregate the address space when announcing the prefix ownership. An AS is responsible to maintain and announce the prefix ownerships of its own prefixes. At the same time, the AS must find a referee to maintain and announce the same prefix ownership for each of its prefixes. If this prefix is allocated from the address space owned by another AS, i.e. its supernet belongs to another AS. The supernet AS must be the referee. Otherwise, the prefix should be assigned directly by the Regional Internet Registries (RIRs). The corresponding RIR server must be the referee. Each BGP router checks the consistency between the announcements from the origin-as and the relevant referee to ensure the authentication of the prefix ownership. Note that any prefix ownership must have two and only two announcements, one from the origin-as and the other from the referee. If the prefix ownership is authenticated by checking the consistency between the origin-as s and the supernet AS s announcements, the supernet s ownership must be first validated. The maintenance of the prefix ownership does not impost excessive administrative cost to the network operators. In operation, once an AS is assigned or allocated a new address space, the address issuer is responsible to maintain and announce one copy of the prefix ownership. Although RIRs usually assign addresses to an ISP, which in turn decides which of its ASs announces the prefixes if it owns more than one AS, RIRs should require the ISP to specify the origin-as information. The maintenance of the prefix ownership can be part of the services provided by the address issuer to its customers. The inconsistency of announcements would disable the prefix. Both the prefix users and issuers benefit from the maintenance of the prefix ownership. Thus, they have the incentive to keep the information accurate and up-to-date. In addition, in order to prevent the leakage of the morespecific internal routes, each prefix ownership may carry a longest prefix length indicator, which suggests the longest prefix length that this prefix are allowed to be de-aggregated. The indicator should be carried in the origin-as s copy. The indicator provides a flexible threshold for the prefix-lengthbased inbound filtering and can be leveraged to prevent the leakage of the de-aggregated internal routes. 2) AS Links: An AS link indicates the existence of the peering sessions between two relevant ASs, which determines whether they exchange routing information and traffic along the peering sessions. An AS is responsible to maintain the route validation information of the AS links that are directly connected to it. The authentication of an AS link is provided by checking the consistency between the AS link announcements from its two end ASs. Obviously, the maintenance of AS link information also has low administrative cost since this information is ready for both end ASs when they decide to establish the BGP sessions. The two ASs also have incentive to keep the announcements of this AS link consistent. Otherwise, any route that traverses this link will be discarded at all BGP routers. 3) AS Relationships: An AS relationship [17] indicates the routing policies that the two peering ASs apply to each other, which determines how they exchange routes and traffic. The AS relationships are the most concise abstraction of the complex commercial agreements between ISPs in the real world and have been widely accepted and practiced in the Internet [33]. From the perspective of an AS, its neighbors in the AS topology are typically classified into three categories based on the commercial agreements between them: the providers, the peers, and the customers. A provider sells the transit service to its customers. A customer buys the transit service provided by its providers. If two ASs provides the private transit service for each other s customers, they are peers for each other. Accordingly, there are two typical AS relationships: the undirected peer-to-peer relationship and the directed provider-to-customer relationship. As shown in Table II, the AS relationship between two neighboring ASs characterizes the import/export routing policies that an AS applies to its counterpart. For its providers and peers, an AS needs to apply outbound filtering to ensure that it exports its customer routes only. On the other hand, for its customers and peers, an AS needs to apply inbound filtering to ensure that it imports their customer routes only. In addition, if the import/export routing policies between two ASs cannot be precisely classified into any of the above two relationships, their relationships can be a sibling-to-sibling relationship. The sibling-to-sibling relationship is usually between small edge ISPs, in which two small ISPs provide reciprocate backup connections to each other. In case the primary up-link of one of them breaks, the failure AS will temporarily switch to the backup connection to access the Internet. The other cases of sibling-to-sibling relationship can be found among the ASs belonging to the same ISP, in which they do not precisely define commercial agreements. Sibling relationship allows more flexible routing policies between neighboring ASs. In fact, according to [17], which shows that around 1 2% AS relationships are sibling-to-siblings, around 6 8% are peer-to-peers and the rest are provider-customer relationships, the peer-to-peer and provider-to-customer relationships can describe the majority of the import/export routing policies between neighboring ASs. 4

5 AS relationship between ASs is usually specified articulately in the peering agreement. However, there might be some cases where no explicit commercial agreements exist. One example is the peering between research and educational institutes and other non-profit departments. Another example is a layer 3 public exchange point that owns an independent AS number. In these cases, we should analyze the import/export routing policies between the ASs and classify them into provider-to-customer or peer-to-peer relationships first. By default, the sibling-to-sibling relationship can be applied. Meanwhile, we should minimize the usage of sibling-to-sibling relationships since it loosens the constraints for redistribution hijacking protection. Since routes from providers or peers cannot be exported to other providers or peers, the import/export routing policies specified by AS relationships enforce each policy-conforming AS-Path in the Internet to be valley-free, i.e. regardless of sibling-to-sibling AS links, the provider-to-customer or peer-to-peer AS links have to be followed by provider-tocustomer AS links only and an AS-Path contains at most one peer-to-peer AS link. The valley-free property rules out the redistribution hijacking paths. With the valley-free checkiing, a customer would not be able to redistribute routes from its providers or peers to its other providers or peers. Similar to AS links, the authentication of the AS relationship information can be performed by the consistency checking. The maintenance of the AS relationship information is also lightweight. As described before, the AS relationships with the relevant neighboring ASs can be clearly identified and configured by both sides before the relevant sessions are established. At the same time, the inconsistency of the announcements would disable any route across this AS link. The investment in the peering sessions drives the two ASs to keep the validation information of the AS relationship consistent and up-to-date. Thus, both ASs have incentives to do the maintenance. In implementation, if we add a fifth relationship that indicating whether or not the two ASs have peering relationship, say non-existing relationship, the route validation information for AS links and AS relationships can be combined and announced together. One concern of the AS relationship model is whether it is accurate enough to describe the routing policies in the Internet. Our point is that the model is accurate enough for a practical BGP security solution. The AS relationship model achieves the best balance between flexibility and conciseness in terms of representation of routing policies. Although there are other alternatives to describe routing policies, such as RPSL [10], compared with AS relationship model, RPSL is so complicated and detailed that it would impose significant overhead on the security protocol. On the contrary, the AS relationship model is concise and is proved to fit with the practice in the Internet. Moreover, the model leaves large flexibility for ASs to play with. For example, although an AS is allow to announce all its customer routes to its providers, it can choose to announce part of the customer routes to some providers. At the same time, an AS can redistribute some peer routes to another peers. However, in order to do so, it should announce the relevant links as sibling-to-sibling relationships to allow the flexibility. Also, as far as we know, the provider-to-customer and peerto-peer models are widely applied in the economic analysis in both the Internet access [29] and transit [11] market. The models are largely determined by the telecommunication technologies, pricing policies and competition in the market. In the foreseeable future, these factors should not change significantly. Thus, the model should still be applicable to the Internet. Another concern is that whether the AS relationship and valley-free rule is adequate to prevent any redistribution hijacking. Our answer still lies in the tradeoff between practical feasibility and system overhead. By applying the AS relationship and valley-free rule, the majority of the redistribution hijacking, i.e. the hijacking cases that a customer redistribute its provider routes to other providers or peers and a peer redistributes its peer routes to other peers or providers are eliminated. Other redistribution hijacking cases, which exactly follows the valley-free rule but does not match with the specific routing policies of an AS, might not be prevented. For example, an AS redistributes the routes of its sibling neighbors, but these routes should not be redistributed until the sibling neighbors primary routes fail. These hijacking cases are rare and also has only local impact. A finer representation and checking of routing policies might be able to eliminate these minor redistribution hijacking. However, the security gain is far less than the additional overhead introduced. B. Prefix Hijacking Detection In Hi-BGP, the route verification based on the route validation information is mandatory for each BGP router. A route cannot enter the normal BGP route processing procedure until it passes the verification. A Hi-BGP router stores the route validation information of all AS in the Internet. It use these information to detect prefix hijacking. At first, origin-as hijacking is prevented by using prefix ownership validation information to detect false prefix ownerships. Second, AS-Path hijacking can be avoided by using AS link validation information to detect non-existing AS links. Finally, redistribution hijacking can be detected with AS relationship validation information by applying the valleyfree rule checking. The valley-free rule can prevent redistribution hijacking. The commercial incentive dictates that an AS cannot and ought not play as a transit AS between its peers and providers. That is, an AS can distribute its customer routes to any of its neighbors but cannot export its peer or provider routes to other peer or providers. This results in the valley-free property of a legitimate AS-Path. The property enforces that in an AS-Path, the customer-to-provider links can be followed by any types of links while the provider-to-customer or peerto-peer AS links have to be followed by provider-to-customer AS links only. By explicit annotating AS relationships to AS links and applying the valley-free rule, we can rule out the redistribution hijacking cases in which an AS redistributes routes between its peers or providers. Note that other hijacking 5

6 TABLE II THE AS RELATIONSHIPS AND THE RELEVANT IMPORT AND EXPORT POLICIES AS A AS B A exports to B A imports from B B exports to A B imports from A Provider Customer Any route Any customer route Any customer route Any route Customer Provider Any customer route Any route Any route Any customer route Peer Peer Any customer route Any customer route Any customer route Any customer route Sibling Sibling Any route Any route Any route Any route cases, which exactly follows the valley-free rule but does not match with specific routing policies of an AS, might not be prevented. For example, an AS exports its sibling s routes to its peers, while the routes are not supposed to be exported according to its agreements with the sibling AS. However, unlike the redistribution hijacking between providers or peers, these hijacking cases are rare and also limited to the scope between an AS and its siblings or customers. Besides prefix hijacking, our system can be leveraged to prevent other large-scale routing anomalies found in Table I. First, the route validation information provides the complete information of prefix ownerships and AS links in the Internet. Thus, the illegal prefixes can be filtered out due to their absence in the route validation of prefix ownerships. Similarly, the routes that have anomalous AS numbers can be disclosed due to their absence in the route validation of AS links. The leakage of the more-specific prefixes can be prevented with the aid of the maximal prefix length indicator. Second, a prefix ownership is proved legitimate throughout the Internet if and only if the prefix ownership information announced by its origin AS and the relevant address issuer is consistent. Since the information is disseminated in BGP messages, which can be propagated as fast as the ordinary routing updates, once the origin AS and the relevant referee settle down the announcement of the route validation information for this prefix, the rest of the Internet could learn this prefix in no time. Thus, the erroneous filtering of the newly assigned prefixes can be eliminated. At the same time, the filtering of the fragmental prefixes can be ameliorated with the aid of the origin-as s maximal prefix length indicator. C. Route Validation Information Dissemination Like sobgp, Hi-BGP is built on top of BGP and we use BGP SECURITY messages to distribute the route validation information within the BGP system. Each BGP router is able to generate, relay and process the SECURITY message and maintain a complete and up-to-date database that contains all the route validation information collected from the Internet. We exploit the PKI-based authentication to ensure the integrity of SECURITY messages during the dissemination process. In order to reduce the overhead for public key distribution and maintenance, a 2-tier PKI system is utilized. There are several designated certificate authorities (CAs), which can be the existing CAs such as VeriSign or the RIRs. The public keys of the CAs are assumed to be known by all the BGP routers. Every AS and RIR server that maintains and generates SECURITY messages should acquire a certification issued from CAs, which authenticate the public keys and the relevant identities. When a SECURITY message is generated, the announcer must use its private key to sign the message. At the same time, the public key, identity, and the relevant certificate of the announcer should go along with the message. When a BGP router relay the message to its neighbors, the message should remain intact. When a BGP router receives a SECURITY message, it first uses CAs public key to authenticate the announcer s identities and then verifies the integrity of the message content with the attached public key and digital signature. Meanwhile, we assume a secured underlying communication infrastructure between the BGP routers, which can be provided by IPsec or MD5-based TCP encryption. Hi-BGP employs different strategies to distribute various route validation information. An AS broadcast its prefix ownership information into the Hi-BGP system with simple flooding but announces its AS relationship information with extra caution. In order to avoid disclosing its peer-to-peer connections to the irrelevant ASs, an AS announces the peerto-peer AS links, which belong to itself or its providers, to its customers or siblings only but not its providers or peers. According to valley-free rule, any route traversing the peerto-peer links of an AS ought not be exported to this AS s providers and peers or its customers providers and peers. That is, these ASs should not receive any route traversing the peerto-peer links. If they do, the routes must not be valley-free and should be invalid. Therefore, an AS can choose not to announce peer-to-peer links to its providers and peers since there is no difference whether they are aware of these links. It is debatable whether the ISPs are willing to to publish their business relationships. First of all, we believe Hi-BGP provides enough incentives to persuade majority of ASs to announce their AS relationship validation information because AS relationship information enable Hi-BGP to effectively prevent redistribution hijacking, which has been proved to be very dangerous to the Internet. Besides, Hi-BGP provides certain degree of confidentiality: an AS can use sibling-tosibling relationships to mask any kinds of relationships and also can hide its peer-to-peer connections from irrelevant ASs with selective announcements. At the same time, for those ASs who are reluctant to announce their relationships, Hi- BGP can infer their relationships based on BGP routing data instead. The functionality is included in Hi-BGP s transient scheme pre-hi-bgp, which will be discussed in Section IV. Meanwhile, note that AS-Path is composed of several AS links. In most times, the AS relationship information of parts of them is enough to tell whether it is valid or not. For example, even if only tier-1 ASs announce their providerto-customer relationships, a large portion of redistribution hijacking can be prevented. 6

7 #Changes Monthly Number of Changes v.s. Time Prefix Ownerships AS Links and Relationships Months since 6/2004 Fig. 3. Monthly Updates of Prefix Ownerships, AS Links and AS Relationships from 6/2004 through 12/2005 D. System Overhead Estimation Compared with the standard BGP, each Hi-BGP router needs more memory to store the route validation information database and the additional processing power to process the SECURITY messages and validate the routes. Besides, the network operators need to maintain the relevant route validation information. We will evaluate the overhead caused by these additional functionalities. In fact, the possible memory consumption of the route validation information for the current Internet is acceptable. Each BGP router needs to maintain a complete prefix ownership list. According to the statistics on cidr-report [1], there are about 110k non-aggregatable prefixes in the backbone routing tables. Assume the ownership information of each prefix consume 10 Bytes. The prefix ownership will consume around 1.1 MBytes memories. The AS topology and AS relationships comprise an AS topology with around 20k AS nodes with an average degree of 4 [15]. Assume that we use an adjacency list to represent the graph and on average each node uses 4 10 bytes to store its neighbor list and the AS relationships. The AS topology totally costs around 0.8 MBytes. Therefore, besides the additional memory for maintaining the relevant data structures, each BGP router consumes around 2 MBytes memories to store the route validation information. Besides, since we use a PKI system similar to that of SSL. Every router needs to store the public keys of a few CAs only, which is negligible. All in all the memory consumption is acceptable nowadays in terms of technical constraint and financial cost. Besides, the overhead to process SECURITY messages is negligible. The SECURITY messages are triggered by the changes of prefix ownerships, AS links and AS relationships. Compared with BGP routing updates, which are triggered by routing dynamics, the traffic of BGP SECURITY messages should be far smaller. To estimate the possible workload caused by SECURITY messages, we investigate the relevant changes observed in the BGP routing tables of routeviews.oregon-ix.net [5]. We choose one BGP routing table every month from 5/2004 through 12/2005. The prefix ownerships, AS links and AS relationships of each routing tables are extracted. The aggregation of prefix ownerships are performed. Then we compare every two consecutive months. By examining how many of these three objects changed every month, we get the idea how many SECURITY messages would be generated. As shown in Figure 3, during a period of one month, no more than 15,000 prefix ownerships and 5,000 AS links and AS relationships experience changes. For simplicity, suppose all the objects shown in a routing table are permanent and each SECURITY message conveys the change of a single object only, the monthly number of SECURITY message that a BGP router need to handle is no more than 20,000, which equals to around 27 messages per hour. At the same time, we measure the routing updates received by ROUTEVIEWS EQIX server (route-views.eqix.routeviews.org) [5] during November 10 and 15, The average arrival rate of routing updates is more than 50,000 per hour. Compared with the giant volume of BGP routing updates, we believe the workload for processing the SECURITY messages is almost negligible to a BGP router. Given that each BGP security message should traverse every link no more than twice, the average hourly bandwidth consumption for the SECURITY messages on each AS link does not exceed several thousand bytes. Note that our estimation is very conservative since we count all the changes in the routing tables as permanent changes and limit each message to convey one object only. Therefore, the overhead for processing and propagating the BGP SECURITY message is extremely low. At the same time, the overhead for route validation is moderate. Note that Hi-BGP does not use computational intensive cryptographic operations for route validate. The cryptographic operations are performed only for authenticating route validation information, which is almost negligible compared with the volume of routing updates. Thus, compared with the cryptographic BGP security solutions, Hi-BGP is far more lightweight. In addition, for each route, we need to perform O(1) prefix ownership verification and O(k) AS relationship/link verification for a route with an AS-Path of length k. The validation can be performed very fast depending on the implementation of the data structures storing the prefix ownerships and AS relationships. Finally, the administrative cost for the maintenance of the route validation information is reasonable. As described before, the relevant route validation information that each AS needs to maintain is always instantly available to the network operators. The maintenance workload is far less than the complex router configurations. Besides, part of the route validation information even can be automatically derived from the corresponding router configurations. At the same time, each AS, including the RIR servers, has the incentive to maintain their route validation information. Otherwise, the relevant resource could not be used. Due to the cooperate nature of the inter-domain routing system, the economic bind between the two neighboring ASs drives the neighboring ASs to do the necessary maintenance services for its counterpart. Meanwhile, for each individual AS, the change of prefix ownerships, neighboring ASs and their relationships normally does not happen frequently. Thus, the possible workload to keep updating the information within each AS is very low. 7

8 Primary Verification Server Backup Verification Server AS D g(x)=α/t s e αx/t s α/t s g(x)=α/t s e αx/t s α/t s BGP Router AS A AS B AS C T ld t lw t la (a) t lw <t la t 0 t T ld t lw (tla ) (b) t lw >t la t 0 t Fig. 4. The system architecture of pre-hi-bgp Fig. 5. The aging function of an route validation object III. PRE-HI-BGP THE TRANSITION SCHEME The basis of Hi-BGP is the complete route validation information from all the ASs in the Internet. However, during the incremental deployment period, only part of the ASs announce their route validation information into the Internet and support the relay of the SECURITY messages from their neighbors. The Hi-BGP-enabled ASs might be partitioned by the legacy ASs into several isolated islands. Only the route validation information of the Hi-BGP-enabled ASs within each island is available, which limits Hi-BGP to protect the routes involving these ASs only. In this section, we design a transition scheme of Hi-BGP pre-hi-bgp to bootstrap each AS into Hi-BGP era without the validation information support from the other ASs (including RIR servers). We will discuss how to infer the route validation information based on the historical BGP data and the feasibility of pre-hi-bgp. according to the partial validation information learned from Hi-BGP-enabled ASs, a copy of the update will be forwarded to the verification server(s). The route is used to update the inference database. Once the change of the certification database is detected, the server will send out the relevant BGP SECURITY messages to inform all the BGP routers in the AS. Another task of the verification server is to temporarily store the routes that cannot be verified with the available route validation information and need further out-of-band verifications. In order to avoid single point failure, an AS can set up more than one verification server. One of them is appointed as the primary server and the rest are the backups. In this case, the BGP routers need to send a copy of the relevant routing updates to each of the verification servers. After the fully deployment of Hi-BGP in the Internet, the Hi- BGP system becomes completely independent of verification servers. A. System Architecture of pre-hi-bgp During the transition period, each AS has to collect the necessary route validation information by itself. The basic idea of pre-hi-bgp is that each AS utilizes the historical BGP routing information to infer the reliable information of prefix ownerships, AS links and AS relationships. In this stage, a route will go through a three-stage verification process at each BGP router. First, each BGP router exploits the received partial route validation information to validate the route. If the information is insufficient to verify the route, it will further combine the inferred route validation information to validate the route. Finally, if the route still cannot be verified, an out-of-band verification procedure will start. However, with the increasing deployment of Hi-BGP, more and more route validation information becomes available and a route will have less and less chance to go through the last two stages. Figure 2 shows the system architecture of pre-hi-bgp. One of the major differences between Hi-BGP and its transition scheme is that each AS sets up one or more verification server that fully connects with its BGP routers. A verification server has two basic functionalities. One is to infer the route validation information based upon the historical BGP data. A verification server maintains a route validation information inference database, which stores the primitive information for inferring the route validation information. As shown in Figure 4, when a BGP router receives a BGP routing update from its neighbors, if and only if the route cannot be verified B. Inferring Route Validation Information A verification server maintains an inference database, which stores the necessary primitive entries for the inference of the route validation information. We design data structures to infer the route validation information of prefix ownerships, AS Links and AS relationships. We infer the route validation information based on the heuristic that if an object exhibits stable historical behavior it should be reliable and legitimate. The similar idea has been exploited in [24], [16], [22], and [13]. In this section, an aging function and the inference algorithms based upon it will be introduced. 1) Aging Function Measure of Stability: Because we utilize the historical BGP routing information, each entry needs necessary fields to record its historical behaviors. In the inference database, each entry is associated with three chronological attributes to describe its historical behaviors: T d, t w and t a. T d represents the duration of the object before its last withdrawal. t w and t a record the most recent time point when the object was withdrawn and announced respectively. A weighted aging function is used to evaluate the stability of an object. As shown in Figure 5, we use an exponential function y = α T s e αx/ts to weight the history of an object. T S is a predefined threshold that controls the length of the period that a stable object should last in the most recent past. The larger T S is, the longer the required stable duration is. The best value of T S is empirically determined. According 8

9 to the discussion in [22] and [16], we use three days as the default value of T S. α is a parameter that control the weight of the most recent history in computing an object s age. The larger α is, the more significance the most recent history has. As shown in Figure 5, assume that the current time point is t 0, the age of an object is the shadowed areas under the curve, which is calculated with the following formulas, 1 f(t a t 0 )+f(t w t 0 ) f(t w t 0 + T d ), Age(o) = (t a >t w ) f(t w t 0 ) f(t w t 0 + T d ), (t a t w ), where f(x) = exp(αx/t S ). If the age of an object is larger than Threshold =1 f( T S )=1 exp(α), the object is believed to have a stable history and can be used for validation. A typical value of Threshold is 0.5, i.e. α = ln(0.5) = 0.693, which implies the most recent history of length T s is as important as the entire history before t = t 0 T S. In this aging function, the recent history, which is relatively more important, is represented precisely with t w and t a while the past history, which has less significance in calculating the object s age, is approximately represented with a total duration T d. The aging function achieves a tradeoff between the required accuracy and the representation overhead. At the same time, the data structure is easy to update and ensures the fast update of the entries. 2) Inferring Prefix Ownerships: A database entry representing a prefix ownership has the following fields: (p, AS o, #c, T d,t w,t a ), where p is the prefix, AS o denotes the origin-as of p, #c is the counter for this record. The relevant fields are updated in the following way. When an announcement of the prefix ownership arrives, the counter #c is increased by 1 and t a is set to be the current time if this is the first announcement. When a withdrawal of the prefix ownership, the counter #c is decreased by 1 and if #c =0, t w is set to be the current time and T d = T d + t w t a. 3) Inferring AS Links and AS Relationships: An AS link is associated with two entries in the database: (AS 1 AS 2, #c, T d,t w,t a ) and (AS 2 AS 1, #c, T d,t w,t a ), where the arrow implies the AS on the left is the provider of the one on the right. The corresponding route validations of AS Link and AS relationship are inferred based upon the two entries. In this paper, we utilize a simplified algorithm proposed by Gao [17] to infer the AS relationships, in which we do not infer the peer-to-peer relationship. The modification allows the algorithm to infer the AS relationship in the fly based on the real-time BGP routing updates. The contents of the two entries are updated with BGP routing updates in the following way. Suppose a BGP announcement with AS-Path (v k,...,v 0 ) arrives, after AS v t, which has the highest degree among all the ASs in the path, is identified, the AS links between v k and v t are supposed to be on the uphill and the entries for v i v i+1 are updated, where i = t 1,...,k 1,k. Similarly, the AS links between v t and v 0 are supposed to be on the downhill and the entries for v j v j 1 are updated, where j =1,...,t. The relevant history-related fields are updated similar to the prefix ownership entries. Given an AS link between A and B, the AS relationship is inferred based upon the two associate entries. If Age A B < threshold and Age B A threshold, B is said to be the provider of A; ifage A B threshold and Age B A < threshold, A is the provider of B; ifage A B threshold and Age B A threshold, A and B are supposed to be siblings; otherwise, this AS link shows no stable historical record in either direction, and will be inferred as nonexisting link. Although we omit the peer-to-peer relationship, the valleyfree property of a policy-conforming AS-Path still holds. Because, in our algorithm, the peer-to-peer relationship algorithm will be inferred as one of the provider-to-customer, customerto-provider or sibling-to-sibling relationships, a valley-free path with peer-to-peer link is still valley-free no matter which relationship the peer-to-peer link is inferred as. Given the above three data structures in the inference database, entries in the database are initialized and updated as follows. At the beginning, the certification database needs an initial AS topology. From then on, the inference database can be updated in the fly with the real-time routing updates sent by BGP routers. However, the inference database cannot be used immediately at the very beginning. We need to wait for certain time such that the entries in the database become mature, i.e. until the entries in the database show stable historical records and can be used for validation. This period can help remove those instable entries during the initialization period. By the end of the maturing period, the route validation information is inferred and forwarded to the BGP routers. After that, once the inference database is updated and the relevant route validation information changes, the relevant SECURITY message will be sent to the BGP routers. 4) Further Protection Based on Operational Knowledge: Besides the inferred route validation information, some known information in the operational field can be exploited to provide further protection against prefix hijacking. For example, the bogon list provided by Team Cymru [7] can be utilized in our system. At the same time, the knowledge of the backbone ASs in the Internet can help us identify the redistribution hijacking involving them [24]. Although the Internet backbone is comprised of a few ASs, they are the hub of the Internet and the majority of the inter-domain routes traverse them. Correspondingly, majority of the redistribution hijacking occurs in the AS-Paths traversing the backbone ASs. However, it is challenging to obtain a complete list of backbone ASs. Although several heuristics have been explored to identify the backbone ASs in the Internet [30] [24], these algorithms are mainly based on the graphic properties of the AS topologies while neglecting the operational meanings of the backbone ASs. So the backbone AS lists identified by these algorithms highly depending on the dataset they use. On the other hand, a few backbone ASs that belong to some prestigious tier-1 ISPs are well known in the Internet community. Our basic idea is that, although we cannot get a complete list of backbone ASs, we can identify a subset of the backbone ASs based on these well-known backbone ASs. We call the subset the core AS list. Atfirst, we combine 9

10 TABLE III CORE AS LIST Name ASN Name ASN AT&T 7018 Cogent 174 Internap 6993 Level Qwest 209 Savvis 3561 SBC 7132 Sprint 1239 UUNet 701 Verio 2914 XO 2828 AOL-TimeWarner 4323 GlobalCrossing 3549 AboveNet 6461 COLT 8220 Abilene the backbone ASs from several sources [3], [9], and [6] into the initial core AS list. Then we use the following heuristics to expand the list. A backbone AS should be able to reach any other core AS directly or through other backbone ASs, i.e. the backbone AS set is close in terms of AS-Path level connectivity. According to this heuristic, we extract all possible path segments that begin and end with the ASs in the core AS list. Then we verify whether these path segments are close in the given core AS list. If not, we will check whether the transit ASs between the core ASs seem reasonable. For example, it is possible that the core ASs use other international or national large ISPs or their sibling ASs for transit. But it looks strange that small ISPs or content providers act as the transit ASs between the core ASs. In the former situation, we add those large ASs into the core AS list. Then we verify the new AS list again with the same procedure. The process will continue until there is no new AS added into the core AS list. Based on the routing tables on 11/1/2005, 12/1/2005 and 1/1/2006, we always get a core AS list shown in Table III. An exception of the above heuristic is Abilene (AS11537), which is the transit network of Internet2 [4]. It acts as the exchanging point of the global education and research network [12]. In the language of AS relationship, Abilene acts as the provider of all its neighbors. However, the above heuristics will exclude AS11537 from the core AS list since Abilene is separated from the commercial network. Therefore, we add AS11537 into the above core AS list. We use the core AS list to identify the redistribution hijacking initiated by the customers between core ASs. At the same time, the core AS list can be exploited in the AS relationship inference to eliminate some noisy AS-Paths. C. Filtering or Warning? Unlike Hi-BGP, where an invalid route will be definitely filtered, pre-hi-bgp may treats an invalid route in two ways, i.e. to filter the route or to raise an alarm only. Because the route validation information is inferred based upon the historical BGP routing information and is not 100% accurate, an invalid route is not necessarily malicious. We cannot completely rely on the inferred information to perform route filtering. For example, a large portion of small ISPs choose to multi-home to several providers. They usually use the primary providers to access the Internet in most of the time while the backup links are used during the failure of the primary links only. As a result, the backup links are short lived in the eyes of a remote AS. Suppose the inferred validation information is used to perform filtering, in case the primary links fail, although the multi-homed AS is multi-homed, it is still unavailable because the routes through backup links are filtered due to the short-lived records. Therefore, in order to avoid the unwanted reachability interruption, we have to be careful to perform the filtering. In pre-hi-bgp, a suspicious route is filtered in two situations. One is that the route is invalidated based on the precise route validation information, such as the validation information provided by Hi-BGP-enabled ASs, the core AS links or the bogon lists. The other situation is that the filtering of the route does not cause significant cost. For example, if a route is invalidated due to the prefix ownership checking, it will be filtered. Since a prefix that lacks a stable record might not serve for the important duties, to filter its route less likely bring about high cost. On the other hand, the inference of prefix ownership is relatively accurate because a prefix, unlike an AS link, should be globally visible if it is in use. If a suspicious route is not filtered, it will enter the standard BGP process but an alarm is raised at the same time. The situation can be that a route is invalidated due to missing AS links or violating valley-free rule based on the inferred validation information. D. Out-of-band Verification Mechanism At the verification server, no matter whether an invalidated route is filtered or warned, it will be forwarded to the out-ofband verification procedure for further inspection. However, the verification will not start immediately but be delayed for a probation period T P. During the probation period, the route waits in a probation queue. If a new announcement or withdrawal of the same prefix arrives from the same BGP router, this route will be removed from the queue. The purpose of the probation period is to eliminate the premature routes and reduce the verification overhead. The premature routes might be the temporary routes caused by routing convergence or persistence routing oscillations. At the same time, after the probation period, if several routes enter the out-of-band verification process due to the same cause, such as the same uncertified prefix ownership, AS link or AS relationship, they should be clustered into one verification group. In this way, the verification of one group can release multiple routes, which can further reduce the verification overhead. In addition, at the end of the verification process, the result needs to be feedback to the source BGP router to update its routing tables. If a route is filtered but proved to be valid, an announcement will be sent to install the route in the appropriate routing tables; if the route is warned but proved to be invalid, an withdrawal need to be sent to invalidate the route in the relevant tables. E. System Overhead Estimation The key difference between Hi-BGP and pre-hi-bgp lies in the verification server. We have discussed the system overhead of Hi-BGP before. This section focuses on the estimation of the verification servers overhead. 10

11 #Verification Group Per Hour m #Verification Groups Generated Per Hour 1h 6h 1/2d 1d 2d 3d Probing Period (seconds) Fig. 6. The average number of verification groups in out-of-band verification procedure per hour v.s. T P A verification server runs on a dedicate server within an AS. Except the out-of-band verification, all the other tasks can be performed automatically without human interference. Thus, the out-of-band verification process is the bottleneck. The question is whether the workload of the out-of-band verification process is too high to handle in the case that the verification is made manually. Our experiment result shows that a feasible workload can be achieved if we choose a proper probation period. We use the BGP updates from ROUTEVIEWS EQIX server [5] to verify the workload of the out-of-band verification process. The parameter setting is the default value. We first use the routing updates from October 1st through November 9th, 2005 to initialize the database. Then the routing updates during November 10 through 14 are fed to the verification server. We record the average number of verification groups generated in every hour during the four days with different probing period T P. The curve in Figure 6 shows that the marginal utility of T P in terms of reducing the number of verification groups declines when T P grows. After T P > 1/2 day, the average number of verification group decreases smoothly. Thus, a proper probing period, say T P =1/2 day, not only significantly reduces the workload but also does not introduce excessive delays. Another concern about the certification server is that whether it is able to handle the real-time BGP routing updates from all the BGP routers within an AS. We implement a demo of pre-hi-bgp with python. We run the program on a PC equipped with Pentium IV 3.06G CPU /w Hyperthreading and 1G RAM. The program is able to process the BGP routing updates from ROUTEVIEWS EQIX server during November 10th through 16th in about 14 hours. Notice that the processing time is linearly proportional to the number of peers. EQIX connects with 11 BGP routers. Suppose that every BGP router generate the routing update in the same rate. As a rule of thumb, this program could support up to 113 BGP routers simultaneously. Since the estimation is based on the performance of a demo written in a script language, we believe the verification server be more efficient and support higher workload in practice. At the same time, the estimation is based on the extreme scenario that there is no any Hi-BGP-enabled AS in the network. With the increasing deployment of Hi-BGP, the route validation information will become increasingly complete while the overhead of the verification server will continue declining. IV. CONCLUSIONS In this paper, we propose a lightweight hijack-proof BGP proposal and its transition scheme. The design goals and the techniques adopted endow our system the following distinguished features. First, the system is able to prevent prefix hijacking, which utilizes the route validation information of prefix ownerships, AS links, and AS relationships of the entire Internet to prevent the origin-as, AS-Path and redistribution hijacking respectively. Second, the transition scheme, which introduces an independently operated verification server to protect the BGP system against prefix hijacking during the transition period, ensures the seamless deployment of Hi- BGP. Finally, we combine the advantages in the existing BGP security solutions to ensure the simplicity and efficiency of our system. REFERENCES [1] cidr report. [2] Hijacked IPs. [3] Internet Health Report. [4] Internet2. [5] Route Views Project Page. [6] Russ Haynal s ISP Page. [7] Team Cymru, [8] The North American Network Operators Group, [9] Tier 1 carrier. 1 carrier. [10] C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, and M. Terpstra. Routing Policy Specification Language (RPSL). RFC 2622, June [11] N. Badasyan and S. Chakrabarti. A Simple Game Theoretic Analysis of Peering and Transit Contracting Among Internet Access Providers. In Telecommunications Policy Research Conference, [12] S. Banerjee, T. G. Griffin, and M. Pias. The Interdomain Connectivity of PlanetLab Nodes. In PAM2004, Antibes Juan-les-Pins, France, April [13] P. Boothe, J. Hiebert, and R. Bush. How Prevalent is Prefix Hijacking on the Internet?, February [14] K. Butler, T. Farley, P. McDaniel, and J. Rexford. A Survey of BGP Security Issues and Solutions. Technical report, AT&T Labs - Research, Florham Park, NJ, February [15] M. Faloutsos, P. Faloutsos, and C. Faloutsos. On Power-law Relationships of the Internet Topology. In SIGCOMM 99, pages , [16] N. Feamster, J. Jung, and H. Balakrishnan. An Empirical Study of Bogon Route Advertisements. ACM SIGCOMM Computer Communications Review, January [17] L. Gao. On Inferring Autonomous System Relationships in the Internet. IEEE/ACM Transactions On Networking, 9(6), December [18] G. Goodell, W. Aiello, T. Griffin, J. Ioannidis, P. McDaniel, and A. Rubin. Working Around BGP: An Incremental Approach to Improving Security and Accuracy of Interdomain Routing. In ISOC NDSS 03, San Diego, CA, USA, [19] A. Heffernan. Protection of BGP Sessions via the TCP MD5 Signature Option. RFC 2385, August [20] Y.-C. Hu, A. Perrig, and M. Sirb. SPV: Secure Path Vector Routing for Securing BGP. In Proceedings of ACM SIGCOMM, pages , Portland, Oregon, USA, [21] jamie rishaw. man filters, [22] J. Karlin, S. Forrest, and J. Rexford. Pretty Good BGP: Protecting BGP by Cautiously Selecting Routes. Technical report, University of New Mexico, October

12 [23] S. Kent, C. Lynn, and K. Seo. Secure Border Gateway Protocol (Secure- BGP). IEEE Journal on Selected Areas in Communications, 18(4): , April [24] C. Kruegel, D. Mutz, W. Robertson, and F. Valeur. Topology-based Detection of Anomalous BGP Messages. In Proceedings of the 6th Symposium on Recent Advances in Intrusion Detection (RAID), [25] D. Linsalata. 12/8 problems?, [26] C. Lynn, J. Mikkelson, and K. Seo. Secure bgp (s-bgp). IETF Internet draft draft-clynn-s-bgp-protocol-01.txt, June [27] S. A. Misel. Wow, AS7007!, [28] Y. Rekhter, T. Li, and S. Hares. A Border Gateway Protocol 4 (BGP-4). RFC 4271, January [29] S.-J. Shin, H. Correa, and M. Weiss. A Game Theoretic Modeling and Analysis for Internet Access Market. In ITS-14 World Conference, Seoul, Korea, August [30] L. Subramanian, S. Agarwal, J. Rexford, and R. H. Katz. Characterizing the Internet Hierarchy from Multiple Vantage Points. In Proceedings of IEEE INFOCOM, June [31] L. Subramanian, V. Roth, I. Stoica, S. Shenker, and R. H. Katz. Listen and Whisper: Security Mechanisms for BGP. In First Symposium on Networked Systems Design and Implementation, San Francisco, CA, USA, [32] T. Wan, E. Kranakis, and P. van Oorschot. Pretty Secure BGP (psbgp). In ISOC, San Diego, CA, USA, [33] F. Wang and L. Gao. On Inferring and Characterizing Internet Routing Policies. In ACM SIGCOMM Internet Measurement Conference 2003, [34] R. White. Architecture and Deployment Considerations for Secure Origin BGP (sobgp). IETF Internet draft, draft-white-sobgp-architecture- 01, May [35] M. Zhao, S. W. Smith, and D. M. Nicol. The Performance Impact of BGP Security. IEEE Network, special issue on Interdomain Routing and the Border Gateway Protocol, 19(5):42 48, November/December