Incremental Deployment Strategies for EffectiveDetection and Prevention of BGP Origin Hijacks

Joseph GerschSecure64 Software Corporation

Fort Collins, CO, USAjoe.gersch@secure64.com

Dan MasseyColorado State UniversityFort Collins, CO, USA

massey@cs.colostate.edu

Christos PapadopoulosColorado State UniversityFort Collins, CO, USA

christos@cs.colostate.edu

AbstractA variety of solutions have been proposed fordetecting and preventing IP hijack attacks. Despite potentiallyserious consequences these solutions have not been widely de-ployed, partially because many ISPs do not view their risk aslarge enough to warrant investment. Nevertheless, a number oforganizations such as critical national infrastructure are at a veryhigh risk level and require a deployed solution. Is it possible forthese sites to be protected despite the majority apathy, given thata critical mass of ISPs is generally required to participate in thesolution?

We examine this conict by presenting an approach which de-termines AS vulnerability based on topological location. We nextexamine the effectiveness of incremental security deployment. Weseparately examine BGP hijack detection which, if improperlypeered, may completely miss a hijack. Finally, we address apessimistic view with respect to deployment and propose anapproach in which an autonomous system can act in its own self-interest to determine a minimal threshold for hijack detection orprevention.

I. INTRODUCTION

A large body of work regarding BGP security has beenpublished over the past several years that dene and scope theproblem, propose detection techniques, defensive mitigation,preventive solutions, protocol changes, etc. BGP Securitytechnologies have been developed that address origin hijackdetection and prevention, as well as full BGP path protection.These technologies include S*BGP, RPKI, ROVER, and AR-GUS, to name a few. Yet regardless of all this work, one starkreality remains: despite sixteen years of ongoing IP hijacks,the problem still hasnt really been solved.

IP hijacks continue to occur, either maliciously, or byaccident (witness the popular press articles about a smallISP temporarily hijacking Google [21]). Malicious attacks canbe used to blackhole address space, send anonymous spam,impersonate or eavesdrop on organizations or be employed incyber-terrorism and warfare. Consequences of IP hijacks havebeen exposed in both academic and trade press articles; forexample, an article in the December 2013 issue of WIRED[30] describes the work conducted by Renesys to expose therecent use of BGP hijacking for spying purposes. The risk tocritical national infrastructure has prompted action from theUS Federal Communication Commission to raise IP hijackingas one of its top three concerns, and spawn CSRIC committeesto make recommendations [19].

But back in the real world, where there are no mandates, nofree funding, and no prot models, the glacial pace continues.Most autonomous system owners make a quick assessment:how probable is it that I or my customers will be the target ofan attack? If I am attacked, will my loss outweigh the costs Imust bear to implement a solution?

Based on the amount of action to date, the answer appearsto be no. But in some cases the risk is very real andsomething needs to be done. This situational conict has realconsequences. Will the inaction of the majority prevent thedeployment of a working solution for those with a real need?

This paper examines this conict, its technological under-pinnings, and possible options and outcomes. In particular weexamine the effectiveness of various deployment strategies re-garding technologies that detect or prevent BGP origin hijacks.If these technologies were to be deployed in small increments,how much can they be relied on? How much critical mass isnecessary? And if deployment progresses too slowly, can anindividual AS owner act independently to protect their ownself-interests?

Using simulation, we analyze the baseline vulnerability ofautonomous systems with respect to their topological posi-tion in the internet mesh. We expose wide variance in ASvulnerability (how many ASes are polluted on average whenattacked by another AS). We introduce new correlation metricsand measure how rapidly vulnerability increases as the metricchanges. The vulnerability charts are a new and practicalcontribution.

We next examine incremental deployment of origin hijackprevention mechanisms and measured the level of improve-ment over the baseline case. We show that there is a non-linear threshold in which small security improvements shiftinto large security gains when high-degree ASes are addedincrementally into the mix.

Unfortunately, it is very likely that hijack prevention meth-ods will roll out too slowly before this cross-over occurs. Thenext best option is to have reliable IP hijack detection. Weexamine several detector deployment congurations, and ndwide diversity in their accuracy depending on the number andlocation of detector vantage points.

We then use our ndings to propose a general approach thatan AS owner may use to step-wise improve their own securitysituation.

2014 IEEE 34th International Conference on Distributed Computing Systems

1063-6927/14 $31.00 2014 IEEEDOI 10.1109/ICDCS.2014.74

670

The remainder of paper is organized as follows. Section IIdescribes background and related work. Section III describesthe simulation model and routing policies used in our analy-sis. Section IV gives measurements showing the variance inattack vulnerability among topologically different ASes andthe general metrics which correlate with vulnerability. SectionV and VI analyze incremental deployment scenarios for hijackprevention and hijack detection. Section VII then proposes anapproach in which an AS can act in self-interest given thelikelihood of slow adoption for BGP security. Finally, sectionVIII concludes the paper.

II. BACKGROUND AND RELATED WORK

A general overview describing BGP security issues andmethods for addressing them are available in the surveyarticles by Butler [2] and Huston [15].

A variety of systems have been proposed over the pastyears to address IP hijack attacks. These solutions can be cat-egorized into three classes: detection, reactive mitigation, andproactive prevention. Papers addressing detection within theBGP control plane include PHAS, BGPMON, and CYCLOPS[17], [28], [27], [26]. Hijack detection systems augmentedby data plane methods include ngerprinting, reference pathdisagreement, LOCK, I-SPY and ARGUS [13], [33], [22],[32], [23]. Out-of-band methods used for hijack detectioninclude IRV and DNS-based lookups [15], [1].

Reactive mitigation systems minimize the effects of anattack once it has been detected. An example is routepurge/promote [31]. In contrast, proactive prevention systemsblock attacks from propagating in the rst place. The mostwidely-used techniques for prevention are route ltering andthe use of internet routing registries. A non-cryptographic tech-nique is described in the paper on PGBGP (Pretty Good BGP)[16]. Most preventive techniques, however, use cryptographicmethods to authenticate secure routing information. PKI basedsystems include BGPSEC, S-BGP, So-BGP and RPKI [14],[29]. Non-PKI systems include LISTEN/WHISPER [24] andROVER [7], [8], [10], [9] which is a cryptographically pro-tected DNSSEC method that may be used for prevention aswell as detection.

This paper is most closely related to the work by Goldberget al [12] and to Lychev et al [18]. [12] examines trafcattraction attacks and the effectiveness of various securerouting protocols and export policies. Our work is related tothe simulation results in [12], but our objectives and emphasisare fundamentally different. Rather than examine secure BGPprotocol effectiveness, we analyze incremental secure BGPdeployment strategies with respect to measured variations intarget vulnerability. We then propose a general approach inwhich an autonomous system can act in its own self-interestto determine a minimal threshold for hijack detection orprevention.

Incremental BGP security deployment is discussed in [11],[5], [25], [18]. Two of these papers present arguments re-garding tipping points on BGP security adoptability based oneconomic and risk factors. [25], on the other hand, gives a

numerical analysis of random BGP security deployment vsa methodical deployment that progresses from high-degreeASes to lower-degree ASes. The paper by Lychev et al [18],Partial Deployment of BGP Security (Is the Juice Worth theSqueeze?) describes various deployment strategies for S*BGPand the impact of policy decisions such as security 1st vscheapest route as well as partial deployment. In contrast, thispaper focuses not on S*BGP, but on the impact of blockingor detecting route origin hijacks and corroborates section 4 of[18].

This paper is based on simulations rather than on an analyticapproach. Simulation results are cited in several other BGPpapers, including the previously referenced [12]. Additionally,a paper on PBGP [16] also uses simulation, stating that 97%of ASs from can be protected from malicious prex routeswhen PGBGP is deployed only on the 62 core ASes. Ourmeasurements show that while this result is possible, thegeneral case requires wider security deployment to reach thisgoal.

III. SIMULATION MODEL

To analyze IP hijacks and defenses, we extended an object-oriented BGP simulator developed for an earlier work [6].The simulator is based on topology information obtainedfrom CAIDA. and implements static general policy behaviorsincluding local preference and valley-free routing.

There are limits to simulation, of course. No simulatorcan match the complex behaviors of individual ASes withindividual policy, but will give insight to behaviors for themodeled system. We compared the routes generated by thesimulator with real routes obtained from RIBs stored in theOregon RouteViews project [20] and determined that 62% ofthe simulation routes matched exactly, or were topologicallyequivalent (one provider substituted for another) to the realworld. One could argue that 62% RIB accuracy will notcompletely reect behaviors in the real internet, but that isnot the point. In fact, we could have modeled a completelyarticial topology. To a limited extent, however, basing thissimulator on CAIDA data and static BGP policy, we canmake general inferences to behaviors in the real internet.Nevertheless, the exact numbers should not be viewed as literalmatches with what the real internet will do.

Here are several details on the simulation model. Onstartup the simulator constructs a topology of 42,697 in-terconnected router objects as it reads a list of 139,156provider/customer/peer relationships obtained from CAIDA[3]. Each router object has methods to send and receive prexannouncements with its neighbors. Each object also enforcespolicy as follows:

MESSAGE PRIORITY: LOCAL PREF is set such thatcustomers are preferred over peers, and peers are preferredover transit providers. If a router already has an announce-ment in its RIB and a new announcement arrives with equalLOCAL PREF, then the new announcement is accepted onlyif has a shorter path length than the previously acceptedannouncement. Tier-1 routers always accept shortest path

671

(this increased the percentage of real-world matches withRouteViews).

PROPAGATION POLICY: valley-free routing is enforced: customer to provider: export all prexes except those of

its providers and peers provider to customer: export all routes peer to peer: export customer and sibling only sibling to sibling: uses a community string to create the

equivalent of one AS out of multiple sibling ASes, thenpropagates messages according to the rules above.

BGP Announcements are propagated to neighboring ASesin step-wise fashion. An AS originating an announcement willsend a message to its appropriate neighbors based on policy.In the next simulated clock tick, these routers will propagatethe message to subsequent neighbors. Generation after gen-eration of message propagation continues until convergenceis reached. Convergence is generally reached within 5 to 10generations. Resulting statistics are written into a database.

Data can be visualized with graphs and tables. The graphswere inspired by the CAIDA website of internet topologyvisualizations [4] except we plot radius according to the depthof an AS (described in section IV) rather than by degree. Thepolar graphs in gure 1, for example, illustrates a sequenceof BGP announcements over time in which AS4 aggressivelyattacks a very vulnerable AS55857. These two ASes werechosen because they illustrate a case in which an attack canpropagate very widely. In the rst generation only a fewmessages are sent from the attacking AS to its neighbors. Thesecond generation continues the fan-out of BGP messages, andthese continue until the announcement converges. In the end,40,950 ASes have been polluted with a bogus path and 96% ofthe IP address space no longer reaches the correct destination.

IV. ATTACK VULNERABILITYBefore we can analyze the effectiveness of BGP defenses

(i.e. ltering, blocking or detection), we must rst understandhow IP hijacks propagate in the absence of any lters orblocking techniques. This provides a baseline for comparisonswhen defensive measures are applied.

We dene a target AS as vulnerable if a large number ofother ASes are polluted with a bogus path when an attackingAS makes an announcement hijacking the targets addressspace. Conversely, a target is resistant when relatively fewerASes are polluted. Likewise, an attacker is considered to beaggressive if it can pollute many ASes compared to the averagecase.

The number of polluted ASes produced by an IP hijack canvary widely depending on the specic target and attacker ASesinvolved. Measurements of this variation were performed bysequentially attacking a target AS by each of the 42,696 otherASes and recording the number of polluted ASes. Resultsare shown in gures 2 and 3. These graphs display thecomplementary cumulative sum of compromised systems foreach target AS. The curve for AS 98 in gure 2, for example,shows that attacks from 11,384 ASes create a minimum of6000 polluted ASes, and that the count of attackers drops as

Fig. 2: Vulnerability analysis graph the faster a curveapproaches zero, the more resistant the AS is to attack. TheTier-1 AS curve shows high attack resistance. There is lessresistance by a stub at depth 1. Multi-homing shows a veryslight improvement over single-homing. The depth-2 stubshows a very large increase in vulnerability as reected inthe change in concavity, and the depth-5 AS is even morevulnerable to attack.

the minimum pollution count goes up. The faster a curve goesto zero, the more resistant an AS is to attack.

The ASes in gure 2 were chosen because they were allisolated within a tier-1 hierarchy. Each AS graphed is at adifferent depth, where depth is dened to be the number ofhops to the nearest tier-1 AS. The depth metric was introducedin [6] and correlates with path length.

The rst observation is that vulnerability increases withincreasing depth, and that the concavity of the curve actuallyips between depth 1 and 2. A stub attached to a transit ASattached to a tier-1 AS is much more vulnerable than a stubattached directly to a tier-1 AS.

The next observation is that vulnerability is not constantfor a target AS. The attacking ASes can be strong or weak; infact attacker aggressiveness has a strong negative correlationwith attacker depth. Simply put, shorter paths are preferredover longer paths. A secondary factor affecting aggressivenessis the reach and overlap of the tier-1 ASes involved in theattacks where reach is dened to be the number of ASes thatcan be independently reached from AS without the aid of peerASes [6]. There is also a very slight improvement in attackresistance when comparing ASes that are multi-homed ratherthan single-homed, as seen in the curves for AS 98 and AS35.

We performed the same experiments with ASes attached tolarge tier-2 providers. The results are shown in gure 3. Thesecurves are very similar to the tier-1 cases, and in fact whenoverlaid show only minor differences. The tier-2 curve lines upwith the tier-1 curve, and the remaining curves also show the

672

Fig. 1: Polar graphs showing a sequence of BGP announcements propagating over time during an origin attack from aggressiveAS 4 against a very vulnerable AS 55857. Generation 1 (upper left) shows the initial announcements from AS4 to its immediateneighbors. Generation 2 (upper right) shows the announcements from these rst neighbors to their subsequent neighbors. Redlines indicate that the bogus announcement is accepted, polluting the AS. Green lines indicates an announcement that isrejected because the AS already has a preferred path. The remaining graphs show further propagation for generations 3 and6. Propagation stopped after 7 generations. This attack results in 40,950 polluted ASes in which 96% of the internet addressspace can no longer teach the target. The polar graphs are constructed such that an ASs longitude is plotted along the graphperimeter, and the AS depth is plotted along the radius. This results in 7 concentric circles, 1 for each value of depth with highestdepth in the center of the graph. (Note the communication between neighboring bands depending on provider/peer/customerrelationship). The size of an AS circle indicates the amount of address space an AS owns. AS degree is shown by scatteringwithin a concentric circle. Higher degree ASes are towards the center. These visualizations are useful for gaining insights onattack propagation, especially when comparing before & after scenarios to see the effect of prex lters and where attacks arestill getting through.

673

Fig. 3: A comparison of attack vulnerability for ASes con-nected to tier-2 ASes. There is similar behavior as before withrespect to depth, and in fact there is a direct correspondencewith the curves in gure 2 when the two graphs are overlaidwith each other.

same concavity as their counterparts. Normally a stub attachedto a tier-2 AS would be considered to be at depth 2. Howeverexperiments show it behaving the same as a depth 1 AS. Thiscauses us to re-dene depth to be the number of hops froman AS to its nearest tier-1 or tier-2 provider.

Figures 2 and 3 display worst-case vulnerability. Anotherscenario could argue that transit suppliers should know theprexes announced by their direct customers and defensivelylter any bogus announcements from them. In reality, thisdoesnt always happen, but we analyze this as an optimisticcase. Attacks now originate only from the 6318 transit ASes(14.7% of the total ASes). Figure 4 shows the curves for AS 98(depth 1) and AS 55857 (depth 5), with and without defensivestub lters. As can be seen, the ltered curves simply scaledown but keep their general shape. We shall continue using theoptimistic scenario in the remainder of this paper, but remainmindful of the fact that the general situation scales back uptowards worst case.

As a nal observation, we have found the simulation andassociated graphics to be a useful method for gaining insightwith specic attacker vs target scenarios. They were especiallyuseful when we ran experiments with defensive lters andobserved the changed behavior and saw which ASes stillbecame polluted.

V. INCREMENTAL DEFENSE DEPLOYMENT

Attack prevention implies that something exists to prevent arouter from accepting and propagating a bogus announcement.Examples include prex lters, PGBGPs use of historicaldata, and router rmware or other device that comparesannouncements to a list of authoritative route origins obtainedfrom a secure repository such as RPKI and ROVER. RPKI

Fig. 4: Vulnerability of AS 98 (depth 1) and AS 55857 (depth5) with and without ltering of attacks from stubs. Filteringsimply scales the graph down; the curves retain their generalshape.

uses a set of repositories for storing authorized route originsand protects them with a PKI-based certicate chain. ROVERis a method for publishing route origins in the reverse-DNS and cryptographically protecting the information withDNSSEC.

Given a mechanism for checking BGP origin security andrejecting bogus routes, how many ASes must implement thismechanism to achieve a high probability of stopping or at leastminimizing an attack? Can the ASes be chosen at random ormust they be methodically chosen? To address this questionwe ran a series of experiments against two of the typicalstub ASes: AS 98, which is at depth 1 and relatively attackresistant, and AS 55857, which is at depth 5 and is veryvulnerable. The experiments varied the location and numberof ASes executing a mechanism for bogus route blocking. Theresults are graphically displayed in gures 5 and 6.

We make the following observations regarding various in-cremental deployment strategies for BGP security.

Random Deployment: This experiment was run to sim-ulate the real-world situation where various random ASesare motivated to deploy BGP security on their own. Overtime, more and more ASes will be added to the mix.Although acting independently is commendable, this isnot a very good strategy in general. As can be seen fromthe two charts, deploying bogus route blocking with 100(1.6% ) or even 500 (8%) of the transit ASes barelymoves away from the baseline case where there are noprotections. It is much more effective and certainly lesscostly to simply deploy to the 17 tier-1 ASes.

lter 17 tier-1 ASes: This scenario was run under theassumption that the tier-1 ASes can act on their own,to everyones benet. As it turns out, ltering at thetier-1 ASes does improve the situation somewhat, but

674

not enough. The average number of polluted ASes fora successful attack on AS 98 is 5084 (12% of thetotal ASes). Only 162 attackers are capable of pollutemore than 15,000 ASes. The situation is worse for veryvulnerable AS 55857. The average number of pollutedASes for a successful attack is 22,018 (52%). Only70 attackers pollute more than 34,000 ASes. The nextstrategy is to add BGP security to successively more tier-2 ASes.

lter 62 ASes with degree 500: Filtering just 62 coreASes does give a signicant gain. The average numberof polluted ASes for a successful attack on AS98 is 1076(2.5% of the total ASes which agrees with the resultsfrom [16]). However 60 attackers can still pollute morethan 8000 ASes and, as expected, AS55857 is still quitevulnerable. The average attack pollutes 8562 ASes (20%)but only 42 attackers can pollute more than 22,000 ASes.As can be seen in gure 6, the concavity of this curvehas just ipped to form a better defensive rate.

lter 124 ASes with degree 300: Better. Attacks onAS98 have an average pollution count of 378 and only24 attackers can pollute more than 4000 ASes. Attackson AS55857 have an average pollution count of 2716 andonly 41 attackers can pollute more than 12,000 ASes.

lter 166 ASes with degree 200: Even better. Attackson AS98 have an average pollution count of 228 and only13 attackers can pollute more than 3000 ASes. Attackson AS55857 have an average pollution count of 1576 andonly 53 attackers can pollute more than 8,000 ASes.

lter 299 ASes with degree 100: Excellent. Attacks onAS98 have an average pollution count of 66 and only only36 attackers can pollute more than 500 ASes. Attacks onAS55857 have an average pollution count of 163 andonly 23 attackers can pollute more than 1,500 ASes. Weobserve, however, that despite the much improved resultsfor AS 55857 it is likely more cost-efcient to changethis target AS to be less vulnerable by connecting to alower-depth transit AS than it is to add security to anadditional, possibly reluctant, 133 transit ASes.

Although the situation has been drastically improved it isstill not perfect. A clever attacker may be limited on whereattacks can be initiated and which ASes will be polluted, butcan still cause some damage. Which attacks are capable ofslipping by these defenses? Consider the case with 299 attackblockers deployed. For AS98, the top 5 still-potent attacks are:

ASN Name Pollution Degree Depth11537 Abilene-Internet2 1025 87 125560 RHTEC backbone 895 94 120965 GEANT 839 61 120080 AMPATH Florida U 763 61 127750 Cooperacin 761 22 2

and for the vulnerable AS55857, the top 5 still-potentattacks are:

Fig. 5: Comparison of defensive ltering for AS98 (depth=1,relatively attack resistant). Random deployment of 100 or 500lters has negligible to minor effect. Filtering at Tier-1 Asesgives the rst real gain, however ltering the core 62 ASeswith degree 500 shows the most marked improvement.Continuing gains are made by adding more lters.

Fig. 6: Comparison of defensive ltering for AS 55857(depth=5, very vulnerable). The same effects as in gure 5 areseen, but starting from a much more vulnerable starting point.In this case the 62 core lters show a great improvement,and begin changing the concavity of the curve. However itstill leaves the target quite vulnerable. In this case we have toincrease to 299 lters before the curve shows major effect.

ASN Name Pollution Degree Depth237 Merit 1822 37 1

46595 PVTN 1819 4 218592 U Desarrollo 1785 21 140498 NM LambdaRail 1779 13 13912 NMSU 1760 6 1

675

Thus, an attacker armed with the same tools and knowledgeof which ASes have deployed BGP security can, within thelimits of the simulation, plot the viability and value of aspecic attack.

These attack simulations have enabled us to quantitativelyanalyze gains in security and also show the remaining vulner-abilities. However, the question remains: will 300 or 200 oreven 100 strategic ISPs implement BGP security? This couldbe like Waiting for Godot, who never shows up (apologiesto playwright Samuel Beckett). Given this possibility, we mustconsider another strategy, attack detection, which is discussedin the next section.

VI. DEPLOYMENT STRATEGIES FOR HIJACK DETECTION

IP Hijack Detection implies the existence of a mechanismwhich monitors BGP messages from a variety of world-widevantage points and compares BGP prex announcements toknown good data. Bogus announcements caught by a detectorwill cause an alert to be issued.

IP hijack detectors are only as good as the quantity, topo-logical diversity, and geographical dispersion of the vantagepoints (probes) they have available. Detectors are also lim-ited by the accuracy of their comparison data. For example,detectors that use historical data can issue false alerts due tochanging AS connectivity. Once again, it is prudent for ASesto securely publish their route origins so that detectors canhave an accurate source of data.

Detector effectiveness can vary dramatically; some detectorswith many diverse probes will capture most attacks. But wewill see other detector congurations that can fail to detectlarge numbers of incidents, even missing some attacks thatcapture 25% or more of the internet.

IP hijack detectors work by collecting real-time BGP datasources by peering with routers in multiple ASes and/or bystreaming data feeds from BGP data collectors such as CSUsBGPmon service [28]. The data streams are examined tocompare their announced BGP prex origins with data from arepository of trusted authoritative origins (e.g. ROVER usingDNSSEC) [7] or with historical data augmented with dataplane verication (e.g. ARGUS [23]). If a mis-match occurs,an origin or sub-prex hijack is detected and operators arealerted to take corrective actions. Any particular attack maybe seen (i.e. received and propagated onwards) by one,multiple, or possibly none of the BGP data sources whichact as probes.

To analyze the effectiveness of hijack detectors, we con-ducted experiments on three different detector congurations.The rst conguration has data probes consisting of all 17tier-1 ASes. This was done under the assumption that a tier-1s position in the internet topology would give them widevisibility across the mesh of ASes. The second congurationwas a real-world example: we used the 24 ASes monitoredby CSUs BGPmon which is in turn used by several hijackdetectors. The nal conguration we studied has probes con-sisting of all 62 AS routers with degree 500. These large

Fig. 7: Comparison of three detector congurations, each usingdifferent source probes. Each conguration is subject to 8000random attacks. The 0 bar indicates the number of attackscompletely escaping detection (0 probes were triggered). Oth-erwise 1 or more probes detected the attack. In general, themore probes triggered, the larger the attack, as indicated by theline graph. In the three examples shown, case 1 surprisinglyfails to detect 34% of the attacks, case 2 misses 11%, and case3 is the best, missing only 3% of the attacks.

backbone networks are highly inter-connected and should alsogive good visibility to attempted hijacks.

Each of these congurations was subject to 8000 randomsimulated IP hijacks. Attackers and targets were chosen fromthe 6318 transit ASes. The results are graphed in gure 7.The bar charts indicate how many attacks were detected byzero, one, or multiple probes. For example, the graph for case1 shows 425 of the 8000 attacks were seen by all 17 of thecongured detectors. The line chart shows the average attacksize vs number of probes seeing the event. This slope of theline conrms intuition; the larger the attack extent, the morecollectors triggered.

The non-intuitive results we found were more intriguing,

676

however. We make the following are case-by-case observa-tions:

Case 1: 17 Tier 1 ProbesSurprisingly, this conguration gives very weak detection.2,717 (34%) of the the 8,000 random attacks completelyescape detection. Undetected attacks had an average ASpollution count of 2,344 and a maximum of 20,306,(almost 50% of the internet). These are very large attacksto have escaped detection. The top 5 undetected attacksare:

Attacker Target Pollution Count6450 7314 2030621287 17228 181158492 50993 1787942429 14307 171305715 7066 16908

Case 2: 24 CSU BGPmon ProbesThis conguration is better. However, 879 (11%) of thethe 8,000 random attacks still completely escape detec-tion. The average pollution count for these invisibleattacks is 1,521 with the maximum at 12,542. This is asurprisingly large attack size (almost 25% of the internet)to have escaped detection. The top 5 undetected attacksare:

Attacker Target Pollution Count16253 4758 1254233902 9614 1189119806 335336 11724197017 24228 1110625531 132045 10769

Case 3: 62 ASes with degree 500 ProbesThis is a much more effective conguration, but still notperfect. Only 239 (3%) of the the 8,000 random attackscompletely escape detection. The average pollution countfor attacks escaping detection is 202 and the maximumis 2804 (attack extent at 6% of the internet). The top 5undetected attacks are:

Attacker Target Pollution Count11014 34243 280428135 26210 247817696 12895 22862153 198704 188647602 56247 1792

How is it that AS 6450 can hijack AS 7314s addressspace, pollute over 20,000 autonomous systems, and still notbe detected by the 17 tier-1 probes congured in case 1?AS7314 is at depth 1 and is multi-homed to tier-1 provider7018 and a medium sized depth-2 provider, AS 12083. Thisresults in all of the tier-1 ASes having a path length of 2 to AS7314 (with the exception of AS 7018 having a path length of1). The simulators policy for tier-1 ASes is to prefer shorter

path regardless of whether the connection is from a peer orcustomer. Attacker AS 6450 is at depth 2 so it cant replacethe existing paths at the tier-1 ASes. Furthermore, AS 6450sproviders are AS 6939, AS 4436 and AS 22822, all whichpeer to thousands or hundreds of other ASes. This causes highattack propagation. If tier-1 policy were different, then someof them may have detected the attack.

The smaller undetected attacks observed in congurationthree are not straightforward to analyze. Animations of thepolar graphs showing the attack propagation give some insight,but basically all we can say at this point is that the smallamount of trafc during the attack propagation never hits oneof the probes. This is an area of future research.

Again, the numbers from the simulation should not be takenverbatim, but do provide general guidance and insight. Fromthis set of experiments it is logical to recommend that BGPdetectors peer with as many high-degree, non-overlappingASes as possible, rather than with random ASes, in order tomaximize their effectiveness. The currently available coveragewith BGPmon by itself is insufcient for good detection, andwe encourage more effective peering relations be established.

VII. PRAGMATIC SELF-INTEREST ACTIONSBruce Schneier states, Security is a process, not a product.

BGP security will not happen in a single step, it will take aseries of actions over time. But how much time? Rather thansit and wait, responsible organizations can start to take pro-active actions immediately that improve their own security andhelp others move this process along.

We next propose an approach that can help an organizationreduce risk with respect to IP hijacks. The process could beused by a concerned AS for increasing security for importantcustomers or by a regional advisory board to make recommen-dations regarding security of critical infrastructure.

The general approach is to execute the following steps: analyze the relevant AS topology reduce vulnerability publish route origins and recruit other ASes to publish incorporate lters based on published data use detectionAnalysis: The rst step is examine the subset of relevant AS

topology, listing end-point ASes between users and services.Prioritize goals, dont try to solve everything at once. Asan example, a bank may have world-wide customers whoseinternet trafc traverses multiple ASes, but the bulk of thetrafc is isolated to one geographic region. Start with thatregion and map the ASes involved. Measure depth to assesspotential vulnerability.

Reduce Vulnerability: The depth analysis may reveal someASes to be more vulnerable than others. If possible, increaseresistance to attack by re-homing and multi-homing theseASes to reduce depth , and to increase non-overlapping reach.If the AS is out of immediate direct control, at least informthe AS of their potential vulnerability.

Publish route origins: This is a critical step. Publish-ing authoritative route origins in ROVER and other secure

677

repositories will enable accurate real-time detection as well asprovide good data for building prex lters. Eventually thispublished data will be used in new routers and devices to blockbogus routes in real-time. But in the meantime, The simpleact of publishing creates leverage: as more organizations usedetectors and lters based on published data, the more accurateand comprehensive they will become.

Filter: Build prex lters. Filtering is one of the onlypractical blocking technologies available today. Filters shouldbe based on authoritative data. Block the known prexesof immediate customers and set egress lters for your ownaddress space. Add lters from securely published route originsources; initially these can be chosen based on the AS topologyanalysis. The list could grow to include all published data Atsome point, however, this process may no longer scale andthis will encourage the incremental adoption of other hijackblocking technologies.

Use detection: Subscribe to a service or run a local IP hijackdetection program. But be an active participant. Understand theset of probes used in the detector and run simulations to seeif there are any blind spots regarding relevant AS endpoints.If necessary, determine new probes that can improve detectionaccuracy. Have an operational plan if an alert is generated.

Several experiments were conducted to validate these rec-ommendations. We again used AS 55857 as an attack targetbecause of its vulnerability. This AS is located in NewZealand, along with 186 other ASes. We wanted to see if IPhijacking could be reduced just within the NZ region. The rstexperiment re-homed AS55857 up two levels. In the secondexperiment we added a single prex lter to VOCUS, at AS4826, based on the AS topology.

In the re-homing experiment, we reduced the average num-ber of compromised NZ ASes from 113 (60%) to 46 (25%)based on attacks generated from each of the 187 ASes withinthe region. We also ran a sample of 200 attacks from outsidethe region. In this case the average number of compromisedNZ ASes dropped from 28 (15%) to 12 (6%). In the l-tering experiment we reduced the number of compromisedASes caused by regional NZ attacks to 74 (40%). Attacksfrom outside the region resulted in an average of 26 (14%)compromised NZ ASes.

Many more experiments could be conducted to determineif further improvements are possible. This is an area of futurework.

VIII. CONCLUSION AND FUTURE WORK

This paper presented an analysis of the effectiveness ofincremental rollout of BGP security mechanisms. An em-pirical analysis using simulation enabled us to characterizeAS vulnerability to route origin hijacks. Wide variance ofattack resistance and attack aggressiveness was observed. Thisvariance most strongly correlated with the depth of an AS. Wethen demonstrated that prevention and detection technologycan be effective with incremental rollout. The ability toblock IP hijacks increases non-linearly when more blockingmechanisms are deployed, however a small critical mass is

required to enable a reasonable level of protection. We alsodemonstrated that hijack detection can be highly effective, butthat once again a critical mass of probes must be present toavoid blind spots, Finally, we proposed a set of short-termactions that could be taken to initiate incremental BGP securityrollout. This approach would have immediate benets to self-interested AS organizations and help build towards the criticalmass needed in general.

Future work is required to understand the behavior of theinternet topology with respect to the holes still present in anincremental deployment. Some origin and sub-prex attackswill still get through, and possibly remain undetected. Ananalysis is desirable to understand these attacks, to determinehow they remain invisible, and what can be done short ofcomplete global deployment of BGP security at every AS.

REFERENCES[1] T. Bates, R. Bush, T. Li, and Y. Rhekter. DNS-based

NLRI origin AS verication in BGP. draft, IETF, July 1998.http://tools.ietf.org/html/draft-bates-bgp4-nlri-orig-verif-00.

[2] K. Butler, T. Farley, P. McDaniel, and J. Rexford. A survey of bgpsecurity issues and solutions. In Proceedings of the IEEE, volume 98,pages 100122, January 2010.

[3] CAIDA. AS Relationships. http://www.caida.org/data/active/as-relationships/index.xml.

[4] CAIDA. Visualizing IPv4 and IPv6 Inter-net Topology at a Macroscopic Scale in 2011.http://www.caida.org/research/topology/as core network/.

[5] H. Chan, D. Dash, A Perrig, and H Zhang. Modeling Adoptability ofSecure BGP Protocols. In SIGCOMM 06: Proceedings of the 2006conference on Applications, technologies, architectures, and protocolsfor computer communications, October 2006.

[6] J. Gersch and D. Massey. Characterizing Vulnerability to IP HijackAttempts. In IEEE-HST 13: IEEE International Conference on Tech-nologies for Homeland Security, November 2013.

[7] J. Gersch and D. Massey. ROVER: Route Origin Verication UsingDNS. In ICCCN 2013: International Conference on Computer Commu-nications and Networks, July 2013.

[8] J. Gersch, D. Massey, M. Glenn, and C. Garner. ROVER: BGP routeorigin vericaton via DNS. In NANOG 55, June 2012.

[9] J. Gersch, D. Massey, C. Olschanowsky, and L. Zhang. DNS Re-source Records for BGP Routing Data. draft, IETF, February 2012.http://tools.ietf.org/html/draft-gersch-grow-revdns-bgp-01.

[10] J. Gersch, D. Massey, and E Osterweil. Reverse DNS NamingConvention for CIDR Address Blocks. draft, IETF, February 2012.http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03.

[11] P. Gill, M. Schapira, and S. Goldberg and. Let the market drivedeployment: a strategy for transitioning to BGP security. In Proceedingsof the ACM SIGCOMM 2011 conference, 2011.

[12] S. Goldberg, M. Schapira, P. Hummon, and J. Rexford. How Secure areSecure Interdomain Routing Protocols? In SIGCOMM 10: Proceedingsof the ACM SIGCOMM 2010 Conference on Data Communication, June2010.

[13] X. Hu and Z. M. Mao. Accurate real-time identication of ip prexhijacking. In Proceedings of IEEE Symp. Security and Privacy, May2007.

[14] G Huston and R Bush. Securing BGP with BGPsec. The ISP Column,July 2011.

[15] G. Huston, M. Rossi, and G. Armitage. Securing BGP - a literaturesurvey. IEEE Communications Surveys and Tutorials, 2011.

[16] J Karlin, S Forrest, and J Rexford. Pretty good BGP: improving BGPby cautiously adopting routes. In Proceedings of IEEE Intl Conf onNetwork Protocols (ICNP), 2006.

[17] M. Lad, D. Massey, D. Pei, Y. Wu, and B. Zhang. PHAS: a prex hijackalert system. In Proceedings of 15th USENIX Security Symposium,August 2006.

[18] R. Lychev, S. Goldberg, and M. Schapira. BGP Security in PartialDeployment, Is the Juice Worth the Squeeze? In Proceedings of theACM SIGCOMM 2013 Conference, August 2013.

678

[19] PC Magazine. ISPs Agree to FCC Rules on Anti-Botnet, DNSSEC,Internet Routing. http://securitywatch.pcmag.com/security/295722-isps-agree-to-fcc-rules-on-anti-botnet-dnssec-internet-routing.

[20] University of Oregon. Route Views Project. http://www.routeviews.org.[21] T. Paseka. Why Google went ofine today.

http://blog.cloudare.com/why-google-went-ofine-today-and-a-bit-about.

[22] T. Qiu, L. Ji, D. Pei, J.Wang, J. Xu, and H. Ballani. Locating prexhijackers using LOCK. In Proceedings of 18th Conference on USENIXSecurity Symposium, 2009.

[23] X. Shi, Y. Xiang, Z. Wang, X. Yin, and J.Wu. Detecting prex hijackingsin the Internet with Argus. In Proceedings of the 2012 ACM InternetMeasurement Conference (IMC12), November 2012.

[24] L. Subramanian, V. Roth, I. Stoica, S. Shenker, and R. Katz. Listenand Whisper: security mechanisms for BGP. In Proceedings of Symp.Networked Systems Design and Implementation (NSDI), March 2004.

[25] M. Suchara, I. Avramopoulos, and J. Rexford. Securing BGP Incre-mentally. In CoNEXT 07 Proceedings of the 2007 ACM CoNEXTconference, 2007.

[26] A. Toonk. BGPmon.net: a BGP monitoring and analyzer tool.http://bgpmon.net.

[27] UCLA. Cyclops: a network audit tool. http://cyclops.cs.ucla.edu.[28] Colorado State University. BGPmon: Next generation BGP Monitor.

http://bgpmon.netsec.colostate.edu.[29] M. Wahlisch, O. Maennel, and T. Schmidt. Toward detecting BGP route

hijacking using the RPKI. In Proceedings of Sigcomm 12, August 2012.[30] K. Zetter. Someones Been Siphoning Data Through a

Huge Security Hole in the Internet. Wired, December 2013.http://http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/.

[31] Z. Zhang, Y. Zhang, Y.C. Hu, and Z.M Mao. Practical defenses againstBGP hijacking. In Proceedings of ACM CoNext Conference, 2007.

[32] Z. Zhang, Y. Zhang, Y.C. Hu, Z.M. Mao, and R. Bush. ISPY: detectingIP prex hijacking on m own. IEEE/ACM Transactions on Networking(TON), 2010.

[33] C. Zheng, L. Ji, D. Pei, J. Wang, and P. Francis. A lightweight distributedscheme for detecting IP prex hijacking in realtime. In Proceedings ofACM SIGCOMM, 2007.

679