Securing Internet Applications from Routing Attacks

Yixin SunUniversity of Virginia

Maria ApostolakiETH Zurich

Henry Birge-LeePrinceton University

Laurent VanbeverETH Zurich

Jennifer RexfordPrinceton University

Mung ChiangPurdue University

Prateek MittalPrinceton University

ABSTRACTAttacks on Internet routing are typically viewed through

the lens of availability and confidentiality, assuming an ad-versary that either discards traffic or performs eavesdrop-ping. Yet, a strategic adversary can use routing attacks tocompromise the security of critical Internet applications likeTor, certificate authorities, and the bitcoin network.

In this paper, we survey such application-specific routingattacks and argue that both application-layer and network-layer defenses are essential and urgently needed. Whileapplication-layer defenses are easier to deploy in the shortterm, we hope that our work serves to provide much neededmomentum for the deployment of network-layer defenses.

1. INTRODUCTIONThe Internet is a “network of networks” that interconnects

tens of thousands of separately administered networks. TheBorder Gateway Protocol (BGP) is the glue that holds theInternet together by propagating information about how toreach destinations in remote networks. However, BGP isnotoriously vulnerable to misconfiguration and attack. Theconsequences range from making destinations unreachable(e.g., Google’s routing incident caused widespread Internetoutage in Japan [7]), to misdirecting traffic through unex-pected intermediaries (e.g., European mobile traffic routedthrough China Telecom due to improper routing announce-ments from a Swiss datacenter [10]), to impersonating le-gitimate services (e.g., traffic to an Amazon DNS serverrerouted to attackers who answered DNS queries with fraud-ulent IP addresses [8]). Efforts to secure the Internet routingsystem have been underway for many years [20,21,23,26,28,29], but the pace of progress is slow since many parties mustagree on solutions and cooperate in their deployment.

In the meantime, more and more users rely on the Inter-net to access a wide range of services, including applicationswith security and privacy concerns of their own. Applica-tions such as Tor (The Onion Routing) allow users to browseanonymously, certificate authorities provide certificates forsecure access to web services, and blockchain supports se-cure cryptocurrencies. However, the privacy and securityproperties of these applications depend on the network todeliver traffic; Figure 1 illustrates the cross-layer interac-tion between Tor and the underlying network. Applicationdevelopers abstract away the details of Internet routing, butBGP does not provide a sufficiently secure scaffolding forthese applications. This gap leaves the vulnerabilities due torouting insecurity significantly underestimated. While rout-ing attacks are well known, they have been viewed primarily

Figure 1: BGP routing affects who can observe Tor traffic.

as affecting availability (when misdirected traffic is dropped)and confidentiality (when data is not encrypted). This pa-per provides a new perspective by showing that routing at-tacks on Internet applications can have even more devastat-ing consequences for users—including uncovering users (suchas political dissidents) trying to communicate anonymously,impersonating websites even if the traffic uses HTTPS, andstealing cryptocurrency.

This paper argues that the security of Internet applica-tions and the network infrastructure should be consideredtogether, as vulnerabilities in one layer lead to broken as-sumptions (and new vectors for attacks) in the other. Wefirst give an overview of routing security. Then, we discusshow cross-layer interactions enable routing attacks to com-promise popular applications like Tor, certificate authori-ties, and the bitcoin network. Given the slow adoption ofsecure routing solutions, we discuss how applications cantake into account the underlying routing properties and em-ploy application-layer defenses to mitigate routing attacks.We believe that application-layer and network-layer solu-tions are interconnected and both are essential to secureInternet applications. While application-layer defenses aremore easily deployable, we hope to motivate the communityto redouble efforts on secure routing solutions and tackleBGP’s many security problems once and for all.

2. ROUTING ATTACKSRouting attacks occur in the wild, and are getting increas-

ingly prevalent and more sophisticated. We dissect routingattacks from the perspective of an attacker, and review ex-isting defenses. In particular, the ability to divert targeted

arX

iv:2

004.

0906

3v3

[cs

.NI]

11

Aug

202

0

Figure 2: AS4 routes traffic to AS1 via AS3 for destinationIPs within 140.180.0.0/24 based on longest matching prefix.

traffic via routing attacks is an emerging threat to Internetapplications. We further demonstrate how routing attackscompromise three applications in Sections 3, 4, and 5.

2.1 How BGP WorksThe Internet consists of around 67,000 Autonomous Sys-

tems (ASes) [12], each with an AS number (ASN) and a setof IP prefixes.Neighboring ASes exchange traffic in a varietyof bilateral relationships that specify which traffic should besent and how it is paid for. Such agreements can generally beclassified into two types: a customer-provider relationship,where the customer pays the provider to send and receivetraffic to and from the rest of the Internet, and a peer-to-peer relationship, where no money is exchanged but trafficmust be destined for the peer or its customers.

Routing among the ASes is governed by the Border Gate-way Protocol (BGP), which computes paths to destinationprefixes. ASes choose one “best” route to a prefix based ona list of factors, with the top two generally being: (1) LocalPreference: a path via a customer is preferred over path viaa peer, which is preferred over a provider; (2) Shortest Path:a path with the fewest AS hops is preferred. The AS willthen add the route into its local Routing Information Base,and further propagate the route to its neighbors based onrouting policies after prepending itself in the path.

ASes forward packets using the path to the longest match-ing prefix of the destination IP. In Figure 2, AS1 announces140.180.0.0/22 via neighbor AS2, and 140.180.0.0/24 via neigh-bor AS3. AS4 forwards packets to 140.180.0.0/24 via AS3based on the longest prefix match. Note that, in general,the longest prefix that can be successfully propagated is /24;many ASes filter prefixes that are longer than /24 by default.

2.2 Goals of Routing AttacksBy default, ASes trust routing announcements from other

ASes. Routing attacks happen when an AS announces an in-correct path to a prefix, causing packets to traverse throughand/or arrive at the attacker AS. We discuss the goals of theattacker from two perspectives: whom to affect and what toachieve.

2.2.1 Whom to AffectRouting attacks affect two groups of victims: (1) destina-

tions, whose prefixes are announced by the attacker, and (2)senders, who send packets to the attacked prefixes.

Destinations. YouTube was the targeted destination ofa hijacking incident in 2008, where Pakistan authorities triedto block access to YouTube [6]. Pakistan Telecom (AS17557)announced the prefix 208.65.153.0/24, which was a subnetof 208.65.152.0/22 announced by YouTube (AS36561).

Senders. The attacker can divert global traffic from allsenders on the Internet, or selectively target only traffic from

certain senders. In the YouTube incident above, the goal wasto target only senders within Pakistan; however, the attackunintentionally affected all senders around the globe.

2.2.2 What to AchieveHistorically, the most visible effect of routing attacks is

outage, where attackers drop packets and make the destina-tions unreachable. This type of attack that “blackholes” thetraffic is also characterized as a hijack attack. However, theattacker’s goals can be more sophisticated.

Surveillance. Authorities may use routing attacks toperform surveillance and target traffic from senders in cer-tain regions. Intelligence agencies such as NSA could launchrouting attacks to make certain traffic easier to intercept forsurveillance [3]. Traffic from the targeted region would bererouted to the authorities, who forward the traffic to thedestinations while monitoring the activities. This type of at-tack is usually characterized as an interception attack, wherethe legitimate destinations still receive the traffic. Intercep-tion attacks are much harder to notice than hijack attackssince they do not interrupt the communication, though per-formance may degrade due to more circuitous paths. Fur-thermore, authorities could exploit routing attacks to sur-pass legal restrictions by diverting domestic traffic (e.g.,emails between Americans) to foreign jurisdictions to con-duct surveillance [24].

Impersonation. Attackers can impersonate destinationsto deceive the senders by intercepting packets via eitherhijack or interception attacks and replying with forged re-sponses. These attacks can have damaging consequences. In2018, attackers used routing attacks to impersonate Ama-zon’s authoritative DNS service [8] and answered DNS queriesfor a cryptocurrency website with Russian IP addresses. Theusers were then directed to a fraudulent site which they be-lieved was their real cryptocurrency service. Consequently,cryptocurrency was stolen. Attackers may also imperson-ate large number of IP addresses to originate spam or othermalicious traffic [9].

Cross-layer attacks on applications. Attackers mayfurther exploit the diverted traffic to perform more sophisti-cated attacks on networked systems and applications. Thespecific goals vary depending on the functionalities of theapplications. In this paper, we demsontrate routing attackson three applications: deanonymizing Tor users via trafficanalysis on the Tor network (Section 3), obtaining bogusdigital certificates for websites from certificate authorities(Section 4), and preventing blockchain systems from reach-ing consensus (Section 5).

2.3 Attack MethodologyAttackers need to decide (1) which prefix to announce, (2)

which path to announce, and (3) which ASes should receivethe announcement.

2.3.1 Which Prefix to AnnounceAttackers can announce either (1) a sub-prefix (i.e., more-

specific prefix) of the target prefix, or (2) an equally-specificprefix same as the target prefix. Note that a less-specificprefix would not be used in packet forwarding and hencewould not constitute a successful attack.

Affecting global traffic by announcing sub-prefixes.Since forwarding is based on longest prefix match, sub-prefixattacks are highly effective at hijacking traffic from all senders.

Figure 3: AS2 (attacker) announces an equally-specific pre-fix as AS1 (legitimate destination). AS4 prefers the pathto AS2, while AS3 prefers the path to AS1. Only AS4 isaffected by the attack.

Figure 4: AS2 (attacker) “poisons” the path by appendingAS3 and AS1 (legitimate destination) in the path, whichpreserves a legitimate route from AS2 to AS1.

However, since most ASes filter announcements for prefixeslonger than /24, sub-prefix attacks on /24 prefixes would notbe effective.

Targeting selective traffic by announcing equally-specific prefixes. An AS that receives both the legitimateannouncement and the attacker’s announcement would pickone based on routing preferences. Note that some ASes mayonly receive one announcement. In Figure 3, AS2 (attacker)announces the same /24 prefix as the destination AS1, andAS4 prefers the path to AS2 while AS3 still prefers the pathto AS1. This attack generally affects only parts of the Inter-net and does not have global impact. However, it is stealth-ier due to its local impact and enables targeted attacks oncertain senders.

2.3.2 Which Path to AnnounceThe attacker may put itself as the origin of the prefix,

which naturally constitutes a hijack attack. Yet, a moresophisticated attacker has a range of other options.

Evading detection by forging the victim AS. Theattacker can add the legitimate destination AS to the end ofits path, so the announcement has the same “last hop” (i.e.,“origin”) AS as a legitimate announcement. This makes theattack stealthier since some defenses (e.g., monitoring sys-tems and RPKI) only check the origin AS of the announce-ment instead of the full path. Note that the path now ap-pears one hop longer, which may reduce the number of ASesthat pick the attacker’s route over the legitimate route.

Interception attack via AS path poisoning. A so-phisticated attacker can append a set of carefully-selected

ASes at the end of the path. These ASes should constitutea legitimate path from the attacker to the destination AS.The appended ASes will ignore the attacker’s announcementbecause of BGP loop prevention, which consequently helpspreserve legitimate routes from the attacker AS to the desti-nation AS. This attack is known as the “AS path poisoningattack” (Figure 4). This attack is very stealthy and effec-tive at performing interception attack while announcing asub-prefix.

2.3.3 Which ASes Should Receive the AnnouncementInstead of sending the announcement to all neighbors, a

strategic attacker may attempt to control who can receivethe announcement to increase attack stealthiness, performan interception attack, or target certain senders. We discusstwo techniques to limit announcement propagation.

Announcing to certain neighbors. Attackers mayexploit routing policies to control attack propagation byonly announcing to certain peers and customers. These an-nouncements will only be propagated “down” to the peer’scustomers, but not to its providers. Consequently, only se-lected ASes will hear the announcements.

BGP communities. BGP communities are optional at-tributes that can be added to an announcement to controlrouting policies in upstream ASes, for purposes such as traf-fic engineering. Attackers may exploit BGP communities tostrategically control attack propagation such that selectedASes will never hear or will not prefer the bogus announce-ments, and thus increase the effectiveness and viability ofinterception attacks [19].

2.4 Routing DefensesDefending against routing attacks is challenging due to

the lack of “ground truth” to inform whether a path is “cor-rect”. Seemingly suspicious announcements could be legiti-mate paths used by ASes to optimize network performance.Many solutions have been proposed that rely on differentsources of information as “ground truth”.

Anomaly detection via BGP monitoring. BGP mon-itoring systems detect anomalous routing announcements byusing historical routing data to infer the “expected” originASes or paths for prefixes [25, 27, 30, 34, 39, 40]. They typ-ically do not require changes to the routing protocol andhence are highly deployable. However, many early efforts onmonitoring systems focused on catching “easy” attacks (e.g.,mismatched origin ASes), but failed to detect more sophis-ticated attacks such as interception attacks. Furthermore,relying on historical data to infer ground truth is prone tofalse positives (flagging legitimate routes) and false negatives(missing real attacks).

Defensive filtering via preset knowledge. ASes of-ten perform prefix filtering on announcements received fromdirect customers. It is effective against attacks launched bycustomer ASes, but does not prevent ASes from attackingtheir direct or indirect customers. A more advanced filter-ing technique is AS path filtering, which uses a whitelist ofpaths for announcements received from peering ASes basedon prior information exchange [35]. It extends the knowl-edge base further from the sole knowledge of an individualprovider on its customers (as in prefix filtering), to a collec-tive knowledge base exchanged and built among a networkof trusted peers. The MANRS project [13] has outlined best

practices for using filtering techniques to protect the routinginfrastructure.

Origin validation. The Resource Public Key Infras-tructure (RPKI) is a public key infrastructure that storescryptographic attestations, known as Route Origin Autho-rizations (ROAs), indicating which ASes are authorized tooriginate which prefixes [21]. Upon receiving an announce-ment, ASes perform Route Origin Validations (ROV) to fil-ter routes originated from invalid ASes. RPKI utilizes cryp-tographic primitives to make the knowledge base availableto all ASes as opposed to only direct neighbors in defensivefiltering. Even though ROV only validates the origin ASinstead of the full path, it can already be effective at pre-venting many attacks. However, currently less than 20% ofthe prefixes have valid ROAs [4] and even fewer ASes arecorrectly performing ROV [31].

Path validation. BGPsec uses cryptographic primitivesto validate the whole AS path [28]. It is an online pro-tocol, as opposed to a separate offline lookup (like ROV).Each AS in the path generates a cryptographic signaturewhich is added to the path as the announcement propagatesthrough the network. While BGPsec provides validation ofthe full path, it places a heavy burden on BGP routers. Italso requires all ASes along a path to participate, makingincremental deployment challenging. We have yet to seereal-world deployment of BGPsec.

In this paper, we provide a new angle into building de-fenses — in addition to network-layer defenses, applicationscan build their own application-layer defenses by taking intoaccount the underlying routing properties. We also highlightthe importance of deploying defenses against sophisticatedattacks, which are stealthier and effective at compromisingInternet applications.

3. THE TOR NETWORKTor is the most widely used anonymity system [22]. It

carries terabytes of traffic every day and serves millions ofusers [5]. However, network-level adversaries can deanonymizeTor users by launching routing attacks to observe user trafficand subsequently performing correlation analysis. Further-more, the attacks have broad applicability to low-latencyanonymous communication systems beyond Tor (e.g., I2Panonymous network or even VPNs).

3.1 How Tor WorksTo prevent an adversary from associating a client with

a destination server, Tor encrypts the network traffic andsends it through a sequence of relays (proxies) before goingto the destination. The client selects three relays (entry,middle, exit), and constructs a circuit through them withlayered encryption by repeatedly encrypting the next hopwith the keys of the current hops (Figure 5). Each relayonly learns the previous and next hops, and no relay or localnetwork observer can identify both the source and destina-tion.

However, Tor is known to be vulnerable to network-leveladversaries who can observe traffic at both ends of the com-munication, i.e., between client and entry, and between exitand server. By default, Tor does not obfuscate packet tim-ings, so the traffic entering and leaving Tor are highly cor-related. An adversary on the path at both ends can thenperform traffic correlation analysis on the packet traces todeanonymize the clients.

Figure 5: The Tor network.

3.2 Routing Attacks on Anonymity SystemsTraditional attacks from network-level adversaries focus

on passive adversaries who are already on the paths to ob-serve Tor traffic. However, adversaries can exploit activerouting attacks to strategically intercept Tor traffic, enablingon-demand and targeted attacks [37].

Figure 6 illustrates the attack. AS3 (adversary) only seestraffic between the exit and the web server, and needs tointercept the traffic between the client and the entry relay.It also needs to keep the connection alive in order to capturesufficient traffic for the correlation analysis, i.e., perform aninterception attack. AS3 announces an equally-specific pre-fix of the target prefix which covers the entry relay, whilemaintaining a valid path (via AS5) to the victim AS1. Con-sequently, traffic from the client gets routed to the adversaryAS3, which forwards the traffic to AS1 to keep the connec-tion alive. Similar attacks can be performed to intercept theexit-server connection as well, if the adversary is not alreadyon the path.

The attacks become more threatening given that seeingeither direction of the traffic is sufficient, which opens thedoor to more adversaries. Figure 7 illustrates the scenariowhere the user downloads a file from the web server. Theadversary performs an interception attack on the entry relayand only sees one direction of the traffic (client to entryrelay), which are mostly TCP ACK packets. The adversariesthen use the sequence and acknowledgment numbers fromthe TCP header (unencrypted) to determine the sizes of thedata packets traveling in the other direction.

The attack was successfully demonstrated on the live Tornetwork (ethically), by having 50 Tor clients download filesfrom 50 web servers via an entry relay under a prefix con-trolled by the researchers [37]. Routing announcements werepropagated through the PEERING testbed [33], and an in-terception attack was launched on the prefix covering theentry relay. No real user was affected during the attack.The attack deanonymized 90% of the clients in less thanfive minutes.

3.3 Defenses to Protect AnonymityMany existing defenses cannot sufficiently detect or pre-

vent such interception attacks. Recent works have proposedapplication-layer defenses for Tor [36,38].

Proactive defense via relay selection. Sun et al. [36]proposed a new relay selection algorithm to protect the con-nection between a Tor client and the entry relay. This algo-rithm defends against equally-specific prefix attacks on entryrelays, where the effect is localized and only clients in cer-tain locations will get affected The localized effect opens upthe possibility for clients to stay unaffected by choosing therelay wisely and proactively before any attack happens. The

Figure 6: An adversary (AS3) launches an interception attack on the entry relay in AS1 and consequently observes theclient-entry traffic in addition to exit-server traffic.

Figure 7: The adversary may only see one direction of thetraffic but can still perform asymmetric traffic analysis todeanonymize users.

algorithm maximizes the probability of clients being unaf-fected by attacks based on the topological locations of theclients and the relays. It successfully improves the proba-bility by 36% on average (up to 166% for certain Tor clientlocations).

Reactive defense via monitoring. To complement theproactive defense, Sun et. al. proposed a monitoring sys-tem on routing activities for Tor relays. The system usesnew detection techniques such as time-based and frequency-based heuristics, specifically tuned for Tor. The authorsshowed that most BGP updates involving a Tor relay areonly announced by a single AS (across all updates), effec-tively differentiating the announcements made by adversaryASes who never announced the prefix in the past. Tan etal. [38] also proposed a data-plane detection approach thatperiodically runs traceroute to detect longest-prefix attacksand update Tor relay descriptors upon anomaly detection,so that Tor clients can pick entry relays correspondingly.

4. CERTIFICATE AUTHORITIESThe Public Key Infrastructure is the foundation for se-

curing online communications. Digital certificates are is-sued by trusted certificate authorities (CAs) to domain own-ers, verifying the ownership of a domain. Internet userstrust a domain with encrypted communications, such asbank websites, only if a valid certificate signed by a CAis presented. This mechanism effectively prevents Man-In-The-Middle (MITM) attacks that can have disastrous con-

Figure 8: BGP attack on domain control verification.

sequences, such as stealing users’ financial information.However, the certificate issuance process is itself vulnera-

ble to routing attacks, allowing network-level adversaries toobtain trusted digital certificates for any victim domain [18].These attacks have significant consequences for the integrityand privacy of online communications, as adversaries can usefraudulently obtained digital certificates to bypass the pro-tection offered by encryption and launch man-in-the-middleattacks against critical communications.

4.1 How Certificate Authorities WorkDomain control verification is a crucial process for domain

owners to obtain digital certificates from CAs. Domain own-ers approach a CA to request a digital certificate, and theCA responds with a challenge that requires the owners todemonstrate control of an important network resource (e.g.,a website or email address) associated with the domain. Fig-ure 8 illustrates HTTP verification where the CA requiresthe domain owner to upload a document to a well-known di-rectory on its web server and verify the upload over HTTP.Upon completion of the challenge, the CA issues the digitalcertificate to the domain owner.

4.2 Routing Attacks on Digital CertificatesThe domain control verification process creates a vulner-

ability to adversaries who can fake control of the network

Let’sEncrypt

GoDaddy Comodo Symantec GlobalSign

Timeto issuecertificate

35s <10min 51s 6min 4min

HumanInterac-tion

No No No No No

MultipleVantagePoints

No1 No No No No

ValidationMethodAttacked

HTTP HTTP Email Email Email

Table 1: Five CAs were attacked and obtained certificatesfrom. All were automated and none had any defenses againstBGP attacks.

resources. Network-level adversaries can use routing at-tacks to hijack or intercept the traffic to the victim’s do-main such that the CA’s request is routed to the adversariesinstead [18] (step (5) in Figure 8). Adversaries can then an-swer the CA’s HTTP request in step (6) and subsequentlyobtain a signed digital certificate from the CA for the victimdomain. The attacks were successfully demonstrated in thereal world, ethically [18]. The attacked domains were runon IP prefixes controlled by the researchers and had no realusers or services. The adversary successfully obtained cer-tificates for the victim domain from five top CAs in as littleas 35 seconds (Table 1).

This work highlights the significant damage of routing at-tacks that can compromise the foundation of secure onlinecommunications, and shows the urgent need for practical de-fenses. Furthermore, the attacks also apply to other systemsthat require demonstration of control on certain resourcesvia verification requests, such as email verifications. Thecommunication with the mail server can be hijacked or in-tercepted, and there is still a non-negligible amount of emailsthat are unencrypted (e.g., less than 20% of the emails from“icicibank.com”, a bank website, are encrypted [2]).

4.3 Defenses to Protect Digital CertificatesMany currently deployed defenses do not sufficiently pro-

tect digital certificates. Given the relatively short time re-quired to obtain a fraudulent certificate, adversaries can geta certificate before the attack is mitigated, even if it is de-tected by monitoring systems. In addition, adversaries canpotentially obtain a malicious certificate using only local-ized routing attacks that do not affect a large portion ofthe Internet. If a domain does not have a CAA DNS record(which is currently true of the vast majority of domains [32]),any CA is authorized to sign a certificate for that domain.Thus, adversaries only need to affect the route between one(of several hundred) CAs and the target domain to obtain afraudulent certificate.

Birge-Lee et al. [18] recently proposed two practical application-layer defenses. (1) Multiple Vantage Point Verification: build-ing on the key insight that routing attacks may be localized,CAs can significantly decrease their vulnerability to attacksby performing domain verification from multiple vantagepoints and suspend certificate issuance in the case of in-

1No vantage points were deployed at time of attack. Let’sEncrypt has since deployed multiple vantage point verifica-tion [14].

consistent validation results. By adding only one additionalvantage point, the probability of catching a localized routingattack on a domain increases from 61% to 84%. By havingtwo additional vantage points, the probability of catchingthe attack reaches over 90% for 74% of the 1.8 million do-mains in the study. (2) BGP monitoring with route ageheuristics: building on the key insight that anomalous andsuspicious routing announcements are usually short-lived,CAs can require the routes to the domains to be active fora minimum time threshold before signing a certificate. Thisdefense would force attacks to be active for over a day beforethe routes can be used to obtain a bogus certificate. Bothdefenses only require minimal deployment effort by the CAswith no change needed from domain owners or the routinginfrastructure.

Multiple vantage point verification has gained significanttraction. Let’s Encrypt, the world’s largest CA, has de-ployed multiple vantage point verification [14]. Furthermore,the prominent CDN CloudFlare has developed an API forCAs to perform multiple vantage point verification using itsnetwork [11].

5. THE BITCOIN NETWORKBitcoin is the most widely-used cryptocurrency to date

with over 42 million users [15]. However, network-level ad-versaries can launch routing attacks to partition the bit-coin network, effectively preventing the system from reach-ing consensus [17]. Besides Bitcoin, this attack is generallyapplicable to many peer-to-peer networks and is particularlydangerous against blockchain systems.

5.1 How Bitcoin WorksBitcoin is a peer-to-peer network in which nodes use con-

sensus mechanisms to jointly agree on a (distributed) log ofall the transactions that ever happened. This log is calledthe blockchain because it is composed of an ordered list(chain) of grouped transactions (blocks).

Special nodes, known as wallets, are responsible for orig-inating transactions and propagating them in the networkusing a gossip protocol. A different set of nodes, known asminers, are responsible for verifying the most recent trans-actions, grouping them in a block, and appending this blockto the blockchain. To do so, the miners need to solve a pe-riodic puzzle whose complexity is automatically adapted tothe computational power of the miners in the network.

Every time a miner creates a block, it broadcasts it to allthe nodes in the network and receives freshly-mined bitcoins.Besides the most recent transactions, the block contains aproof-of-work (a solution to the puzzle) that each node canindependently verify before propagating the block further.In Figure 9a, node n “mines” a block which is then broad-casted hop-by-hop in the network.

As miners work concurrently, several of them may find ablock at nearly the same time. These blocks effectively cre-ate “forks” in the blockchain, i.e., different versions of theblockchain. The conflicts are eventually resolved as subse-quent blocks are appended to each chain and one of thembecomes longer. In this case, the network automaticallydiscards the shorter chains, effectively discarding the corre-sponding blocks together with the miner’s revenues.

5.2 Routing Attacks on ConsensusNetwork-level adversaries can perform routing attacks on

(a) New blocks mined by bitcoin nodes in different ASes arepropagated to the whole network.

(b) The attacker hijacks all prefixes pertaining to bitcoinnodes in the gray zone. Consequently, blocks mined by nodesin the gray zone won’t be propagated further, which effectivelyisolates the gray zone.

Figure 9

bitcoin to partition the set of nodes into two (or more) dis-joint components [17]. Consequently, the attacks disrupt theability of the entire network to reach consensus. The adver-sary must divert and cut all the connections connecting thevarious components together. To do so, the adversary canperform an interception attack by hijacking the IP prefixesof each component and selectively dropping the connectionscrossing the components, while leaving the internal connec-tions (within a component) untouched.

In Figure 9b, the adversary hijacks all prefixes pertainingto bitcoin nodes in the gray zone. Having gained controlover the traffic towards these nodes (red lines), the adversarydrops the connections between the clients that are within thegray zone and outside it, effectively creating a partition.

The impact of partition attacks is worrying. First, a par-tition attack can act as a denial-of-service attack: clientscan neither properly propagate the corresponding transac-tions, nor verify the ownership of funds. Second, a partitionattack can lead to high revenue loss for the miners: once thenetwork reconnects, the shortest chain(s) will be discarded,permanently depriving miners of their rewards.

5.3 Defenses to Protect the Bitcoin ConsensusApostolaki et al. [16] recently proposed SABRE to pro-

tect bitcoin from partition attacks. SABRE is an overlaynetwork, composed of a small set of special bitcoin clients(relays) that receive, verify, and propagate blocks. Regularbitcoin clients can connect to one or more relays in addi-tion to their regular connections. During a partition attack,SABRE relays stay connected to each other and to manybitcoin clients, allowing block propagation among the other-wise disconnected components. In Figure 10b, while clientsin the gray zone are isolated from the rest of the network,a block mined by node n is propagated via the relay nodes(colored in orange) to the rest of the network.

SABRE achieves this by strategically choosing the ASesin which to host relay nodes. The key insight is that someASes, such as those without customers, are naturally pro-tected against routing attacks. By hosting relays in theseASes, SABRE can therefore maintain its connectivity andits ability to propagate blocks on behalf of bitcoin clients,even in the presence of routing attacks. Note that a bitcoin

client only requires one unhindered connection to a SABRErelay to be protected.

In the SABRE network shown in Figure 10a, three ASes(ASB, ASC, ASD) are selected to host the relay nodes,which directly peer with each other and have no customerASes. During routing attacks, the relay nodes stay con-nected to each other. For instance, if ASG (provider ofASC) announces the prefix of ASB, ASC would still pre-fer the route to ASB since it’s via a peer. Additionally, allbitcoin clients keep at least one connection to the relay net-work during the attack. Even nodes such as node q whichloses one of the connections to the relay network due to theattack, stays connected via another relay node.

6. CROSS-LAYER SOLUTIONSWe demonstrated the emerging threats of routing attacks

to critical applications. Next, we outline lessons learnedfrom the three applications, and discuss the importance ofdeveloping solutions at both the application and networklayers.

6.1 For Application DevelopersThe most important takeaway is the significant impact of

routing (in)security on Internet applications. When securingthe application layer in isolation becomes hard to achieve,we should think about cross-layer solutions that take intoaccount routing properties at the network layer.

We outline two routing properties that are the key insightsin building application-layer defenses: (i) localized attack :attack announcements may not be propagated and visibleto the whole Internet, and stealthy adversaries can carefullycraft announcements to control propagation and only targetcertain regions; (ii) attack resilience: some ASes that receivethe attack announcement may not be affected, i.e., not fa-voring the malicious path and hence being “resilient” to theattack. This depends on the routing preferences, e.g., if anAS receives the attack announcement from a provider whilethe legitimate path is through a peer, the AS will still preferthe legitimate path.

These two simple routing properties lead to three gener-alizable application-layer defenses shown in Figure 11.

(a) Relay nodes are hosted in ASes that have no customerASes and compose connected graph of direct peering links.Bitcoin clients connect to at least one relay node.

(b) While routing attacks isolate the gray zone from the restof the bitcoin network, blocks mined in the gray zone arepropagated via relay nodes in the overlay SABRE network.

Figure 10

Figure 11: Two routing properties serve as the key insightsin developing application-layer defenses.

Deploy multiple vantage points. Initiating connec-tions from multiple vantage points increases the likelihood ofdetecting and circumventing a localized attack. CertificateAuthorities can perform domain control verification frommultiple vantage points to ensure that routes to the desti-nation are consistent. This approach generalizes to a broadset of verification processes, where verifications from multi-ple sources would help lower the success of an attack andsignificantly increase the cost to an adversary. BGP moni-toring systems also benefit from having more comprehensivedata through multiple vantage points to detect stealthy at-tack.

Choose resilient nodes. Applications can strategicallychoose nodes/servers that are the most resilient to attacks.Tor clients may choose an entry relay that maximizes theprobability of being resilient given the AS locations of theclient and the relay. Bitcoin may choose relay nodes in cer-tain ASes (e.g., peer AS without customers) to avoid beingaffected by attacks. The specific implementation can varybased on the need of the applications, and may even bringin RPKI as a criteria in choosing resilient nodes.

Build an overlay network. This approach can helpmitigate some effects of routing attacks, e.g., partitioningBitcoin nodes, by providing alternative routes. It can bemore effective when combined with“choosing resilient nodes”,where the nodes in the overlay are carefully chosen to max-imize the resilience to attacks. Bitcoin is an example appli-cation that benefits from an overlay to mitigate partitioningattacks, but the approach is generally applicable to manypeer-to-peer networks.

6.2 For Network OperatorsWhile application-layer defenses can provide immediate

protections, we should also push for large-scale deploymentof general defenses against sophisticated routing attacks. Werecommend that ASes (i) adopt best practices outlined in theMANRS [13] project, (ii) accelerate the adoption of RPKI bypublishing ROAs and performing Route Origin Validation(ROV), and (iii) build consensus on a pathway to solvingrouting security issues (including full path security) onceand for all. Furthermore, we outline two ways that synergizenetwork operators with application developers.

Applications as starting points. Securing all 800Kprefixes and 67K ASes [12] seems like an impossible task.However, only a small portion of the prefixes play a heavyrole in each application. For instance, only around 1100ASes have Tor relays hosted on their prefixes, and one ASalone carries 23% of all Tor traffic [36]. Furthermore, in dig-ital certificate issuance, a handful of certificate authoritiesissue the vast majority of certificates, and the domains arelargely hosted on a few cloud and CDN providers (e.g., fiveASes including SquareSpace and Amazon host nearly half ofthe domains [18]). Finally, only 5 ASes host one third of allBitcoin clients [1], while 50% of all mining power is hostedin less that 100 prefixes [17]. If a few thousand ASes cantake major steps to deploy routing security, the applicationswill receive tremendous benefits.

Applications as incentives. Popular applications—andtheir users—can help incentivize the deployment of routingsecurity solutions by the actions they take, while ensuringthe applications’ security/privacy goals. For instance, Torcould favor certain relays that are hosted on authenticatedprefixes, and domain owners could favor cloud hosting ser-vices that provide origin validations and favor certificate au-thorities hosted on authenticated prefixes. Similarly, minerscould prefer hosting their infrastructure in ASes that provideorigin validation, while regular client could prefer to connectto peers hosted on authenticated prefixes. These steps mayhelp motivate network operators to validate their prefixes tooffer better service to their customers, and eventually leadto a more secure routing infrastructure.

7. CONCLUSION

Often times, we focus on individual system layers in iso-lation. In neglecting routing (in)security, application de-velopers underestimate the risks for their users. In focusingon availability threats, network operators underestimate therisks to Internet applications. By demonstrating the direconsequences of routing attacks on Internet applications, westress the importance of cross-layer awareness and the needto deploy both application-layer and network-layer solutions.

8. REFERENCES[1] Bitnodes. https://bitnodes.io/dashboard/.

[2] Google Transparency Report.https://transparencyreport.google.com/safer-email/.

[3] Network Shaping 101.https://www.documentcloud.org/documents/2919677-Network-Shaping-101.html.

[4] RPKI Deployment Monitor.https://rpki-monitor.antd.nist.gov/.

[5] Tor metrics. https://metrics.torproject.org/.

[6] Pakistan hijacks YouTube.https://dyn.com/blog/pakistan-hijacks-youtube-1/,2008.

[7] Google leaked prefixes – and knocked Japan off theInternet.https://www.internetsociety.org/blog/2017/08/google-leaked-prefixes-knocked-japan-off-internet/, 2017.

[8] AWS DNS network hijack turns MyEtherWallet intoThievesEtherWallet. https://www.theregister.co.uk/2018/04/24/myetherwallet dns hijack/, 2018.

[9] Shutting Down the BGP Hijack Factory.https://blogs.oracle.com/internetintelligence/shutting-down-the-bgp-hijack-factory, 2018.

[10] BGP event sends European mobile traffic throughChina Telecom for 2 hours.https://arstechnica.com/information-technology/2019/06/bgp-mishap-sends-european-mobile-traffic-through-china-telecom-for-2-hours/,2019.

[11] Securing Certificate Issuance using Multipath DomainControl Validation. https://blog.cloudflare.com/secure-certificate-issuance/,2019.

[12] CIDR Report. http://www.cidr-report.org/as2.0/,2020.

[13] MANRS Project. https://www.manrs.org/, 2020.

[14] Multi-Perspective Validation Improves DomainValidation Security.https://letsencrypt.org/2020/02/19/multi-perspective-validation.html, 2020.

[15] Number of Blockchain wallet users worldwide.https://www.statista.com/statistics/647374/worldwide-blockchain-wallet-users/, 2020.

[16] M. Apostolaki, G. Marti, J. Muller, and L. Vanbever.SABRE: Protecting Bitcoin against Routing Attacks.In Network and Distributed System SecuritySymposium (NDSS), 2019.

[17] M. Apostolaki, A. Zohar, and L. Vanbever. HijackingBitcoin: Routing Attacks on Cryptocurrencies. InIEEE Symposium on Security and Privacy, 2017.

[18] H. Birge-Lee, Y. Sun, A. Edmundson, J. Rexford, andP. Mittal. Bamboozling Certificate Authorities with

BGP. In USENIX Security Symposium, 2018.

[19] H. Birge-Lee, L. Wang, J. Rexford, and P. Mittal.SICO: Surgical Interception Attacks by ManipulatingBGP Communities. In ACM Conference on Computerand Communications Security (CCS), 2019.

[20] A. Boldyreva and R. Lychev. Provable security ofS-BGP and other path vector protocols: Model,analysis and extensions. In ACM Conference onComputer and Communications Security (CCS), 2012.

[21] R. Bush and R. Austein. The Resource Public KeyInfrastructure (RPKI) to Router Protocol. RFC 6810,RFC Editor, January 2013.

[22] R. Dingledine, N. Mathewson, and P. Syverson. Tor:the second-generation onion router. In USENIXSecurity Symposium, 2004.

[23] P. Gill, M. Schapira, and S. Goldberg. Let the marketdrive deployment: A strategy for transitioning to BGPsecurity. In ACM SIGCOMM, 2011.

[24] S. Goldberg. Surveillance without borders: The“traffic shaping” loophole and why it matters. TheCentury Foundation, 2017.

[25] X. Hu and Z. M. Mao. Accurate real-timeidentification of IP prefix hijacking. In IEEESymposium on Security and Privacy, 2007.

[26] S. Kent, C. Lynn, and K. Seo. Secure border gatewayprotocol (S-BGP). IEEE Journal on Selected areas inCommunications, 18(4):582–592, 2000.

[27] M. Lad, D. Massey, D. Pei, Y. Wu, B. Zhang, andL. Zhang. PHAS: A prefix hijack alert system. InUSENIX Security Symposium, 2006.

[28] M. Lepinski and K. Sriram. BGPsec ProtocolSpecification. RFC 8205, RFC Editor, September2017.

[29] R. Lychev, S. Goldberg, and M. Schapira. BGPsecurity in partial deployment: Is the juice worth thesqueeze? In ACM SIGCOMM, 2013.

[30] J. Qiu, L. Gao, S. Ranjan, and A. Nucci. Detectingbogus BGP route information: Going beyond prefixhijacking. In SecureComm, 2007.

[31] A. Reuter, R. Bush, I. Cunha, E. Katz-Bassett, T. C.Schmidt, and M. Wahlisch. Towards a rigorousmethodology for measuring adoption of RPKI routevalidation and filtering. ACM SIGCOMM ComputerCommunication Review, 48(1):19–27, 2018.

[32] Q. Scheitle, T. Chung, J. Hiller, O. Gasser, J. Naab,R. van Rijswijk-Deij, O. Hohlfeld, R. Holz,D. Choffnes, A. Mislove, and G. Carle. A first look atcertification authority authorization (CAA).SIGCOMM Comput. Commun. Rev., 48(2):10–23,May 2018.

[33] B. Schlinker, T. Arnold, I. Cunha, andE. Katz-Bassett. PEERING: Virtualizing BGP at theedge for research. In ACM SIGCOMM CoNEXTConference, Dec. 2019.

[34] X. Shi, Y. Xiang, Z. Wang, X. Yin, and J. Wu.Detecting prefix hijackings in the Internet with Argus.In Internet Measurement Conference (IMC), 2012.

[35] J. Snijders. Practical everyday BGP filtering withAS PATH filters: PeerLocking. NANOG-67, Chicago,June, 2016.

[36] Y. Sun, A. Edmundson, N. Feamster, M. Chiang, and

P. Mittal. Counter-RAPTOR: Safeguarding Toragainst Active Routing Attacks. In IEEE Symposiumon Security and Privacy, 2017.

[37] Y. Sun, A. Edmundson, L. Vanbever, O. Li,J. Rexford, M. Chiang, and P. Mittal. RAPTOR:Routing Attacks on Privacy in Tor. In USENIXSecurity Symposium, 2015.

[38] H. Tan, M. Sherr, and W. Zhou. Data-plane defenses

against routing attacks on Tor. In Privacy EnhancingTechnologies Symposium (PETS), 2016.

[39] Z. Zhang, Y. Zhang, Y. C. Hu, Z. M. Mao, andR. Bush. iSpy: Detecting IP prefix hijacking on myown. In ACM SIGCOMM, 2008.

[40] C. Zheng, L. Ji, D. Pei, J. Wang, and P. Francis. Alight-weight distributed scheme for detecting IP prefix

hijacks in real-time. In ACM SIGCOMM, 2007.