3. Routing and Border Gateway Protocol

3.1 How the BGP works

The Border Gateway Protocol communicates potential paths that Internet packets can take from their origin to their destination. It’s the Internet’s “GPS” for traffic and a key part of the Internet’s digital rules. There are multiple physical routes available to send an email from Washington, D.C., to a user in Berlin, because the Internet is made up of these meshed Autonomous Systems. But one of these paths must be picked and used. The BGP allows ASes like those operated by ISPs like Verizon, CDNs like Cloudflare, and cloud providers like Amazon and Google to communicate possible routes to each other. Then, for each packet which must be forwarded, each AS makes a routing decision—selecting a possible path it learned via the BGP from its neighboring ASes. These routing decisions typically prioritize the least-expensive or highest-performance routes.

FIGURE 2: Visual of BGP use between interconnected Autonomous Systems

Core to BGP routing is trust. ASes implicitly trust routing information received from neighboring ASes²⁸ K. Sriram et al., “Problem Definition and Classification of BGP Route Leaks,” Internet Engineering Task Force, RFC 7908, June 2016, https://tools.ietf.org/html/rfc7908#page-3. because like many of the Internet’s early protocols the BGP wasn’t designed for security. Each time a packet moves from one AS to another (say, Verizon to Amazon), the sender assumes its own routing table (based on information from its neighbors, received via the BGP) reasonably approximates the actual topology of the Internet.²⁹ J. Mauch, J. Snijders, and G. Hankins, “Default External BGP (EBGP) Route Propagation Behavior without Policies,” Internet Engineering Task Force, RFC 8212, July 2017, https://tools.ietf.org/html/rfc8212. This blind trust problem explains the BGP’s many malfunctions and exploitations.

3.2 How the BGP malfunctions and gets exploited

ASes semi-regularly announce incorrect or inefficient paths—potentially forming a “route leak,” where bad BGP data causes Internet traffic to move through unintended places, over highly inefficient routes, or to the wrong destination.³⁰ Sriram, “Problem.” Companies may quickly correct them (shaping the Internet’s behavior through real-time policy changes), but route leaks still disrupt traffic and produce unintended, sometimes disastrous, results. Human mistakes, like BGP misconfiguration, are a frequent cause of BGP routing errors.³¹ Barry Greene, “BGP Route Hijacking,” Akamai Blog, November 5, 2018, https://blogs.akamai.com/2018/11/bgp-route-hijacking.html. And many ASes use BGP optimizers, which try to override other ASes’ policies by taking advantage of their preference for specific routes—what one network engineer compared to prioritizing the destination “Buckingham Palace” over “London.”³² Tom Strickx, “How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today,” Cloudflare, June 24, 2019, https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-Internet-offline-today/. The problem is, this means that if any AS passes along a BGP route that’s inefficient or incorrect but more specific, other ASes will typically blindly accept it.

These BGP errors occur daily, and they are not always innocuous. Route leaks can be malicious, where attackers abuse the BGP to hijack data along an unintended path or to an incorrect destination—allowing traffic to be blocked, modified, stolen, or spied upon. Attackers could break into an AS and change its BGP table’s routing data. There’s a good chance this maliciously designed route (i.e., sending traffic through a compromised midpoint) will be blindly accepted by neighboring ASes, leading to a propagation of the reroute. Alternatively, the legitimate operator of an AS could carelessly edit its routing information or policies, or could be compromised via an insider threat, achieving the same rerouting effects. The entire AS could also be malicious, set up for the sole purpose of injecting bogus routes.

The National Institute of Standards and Technology identifies five possible consequences of these hijacks: (1) denying access to Internet services; (2) redirecting Internet traffic through midpoints, either for eavesdropping at the midpoint or for adding in malicious code to attack the destination endpoint; (3) redirecting Internet traffic to the wrong endpoint; (4) undermining Internet Protocol-based reputation and filtering systems; and (5) undermining the Internet’s routing stability.³³ Haag et al., Protecting, 6. The first and the third consequences are often connected, as delivering traffic to the wrong place is a way to deny a user access to services. The fourth and fifth consequences occur when incorrect or inefficient routes are propagated, as errors in and exploitations of the BGP undermine trust in the BGP itself and, more broadly, the Internet’s ability to safely and reliably route data. In all cases of BGP route leaks, companies such as ISPs, CDNs, and cloud services providers using the BGP in an unsafe manner can undermine security across the global Internet.

TABLE 2: Snapshot of major BGP misrouting incidents, 2015–20

Route leaks occur with unsettling frequency. Data from BGPStream (an open-source BGP monitoring tool) indicates that in May 2020 alone, there were hundreds of BGP errors impacting ASes around the world.⁴⁴ Data from BGPStream. See: https://bgpstream.com/. These kinds of BGP events have impacted major technology firms like Facebook and Google, banking and financial services firms like MasterCard, and even US government agencies like the Department of Defense, a particularly frequent victim of inadvertent hijackings as a consequence of its broad holdings of IP addresses.⁴⁵ Justin Sherman, “Hijacking the Internet Is Far Too Easy,” Slate, November 16, 2018, https://slate.com/technology/2018/11/bgp-hijacking-russia-china-protocols-redirect-Internet-traffic.html. BGP route leaks can also vary in duration. Some last for hours and crash small companies’ websites with misdirected traffic, like the second June 2019 incident in Table 2, or they could last for mere minutes but affect millions more people, compromising data from the likes of Google or Microsoft by routing traffic through a Russian state-owned telecom, as happened in April 2020.

These BGP incidents can have several, often overlapping effects, as noted using NIST’s consequences of BGP events to code Table 2. Just one BGP routing error, like Google’s traffic getting rerouted in November 2018 through MainOne Cable Company in Nigeria, can redirect traffic through an unanticipated midpoint, and undermine IP-based filtering systems and routing stability. BGP redirections, like Amazon user traffic going to a phishing website in April 2018, can send data to the wrong endpoint and compromise users’ access credentials and identities. Malfunctions and exploitations of the BGP often go beyond just slightly delaying the delivery of traffic from one point to another. But again, these “major events” (Table 2) are just a snapshot; these protocol malfunctions and potential manipulations occur all the time.  Global BGP incidents from January 1 through May 31 of 2020 can be seen in Figures 3 and 4.

FIGURE 3: Global BGP incidents, January 1, 2020–May 31, 2020 (count)

Source: BGPStream⁴⁶ Data from BGPStream. See: https://bgpstream.com/.

FIGURE 4: Global BGP incidents, January 1, 2020–May 31, 2020 (ratio)

Source: BGPStream

Using the open-source BGPStream, data on BGP incidents from January 1, 2020, through May 31, 2020, show thousands of individual outages, BGP leaks, and possible BGP hijacks (Figure 3). The data are incomplete as different BGP monitoring tools have different perspectives on and visibility of the global network infrastructure, but BGPStream’s data are a representative sample of the whole. Sixty-five percent of these events were outages, where BGP data transmission stopped working, but that still leaves 12 percent of incidents as BGP leaks (638 of them) and 23 percent as possible hijacks (1,193 of them). Many of these individual incidents may be collectively perceived by the media or analysts as one “event,” but the data go to show that a single BGP malfunction or exploitation can impact numerous government agencies, companies, or end users.

There are many BGP routing incidents with difficult-to-establish causes, thus making them hard to sort into the category of malicious hijack or accident, and BGPStream’s qualifying of hijacks as “potential” goes exactly to that point. Because of the implicit trust many ASes place in BGP route announcements, changes can propagate quickly and without malicious assistance.⁴⁷ Criticisms of existing attributions of BGP incidents as “hijacks” have focused on this difficulty. See, for example, Brenden Kuerbis, “The Folly of Treating Routing Hijacks As a National Security Problem,” Internet Governance Project, November 29, 2018, https://www.Internetgovernance.org/2018/11/29/the-folly-of-treating-routing-hijacks-as-a-national-security-problem/. It can be very difficult to discern intent. For example, in June 2019, traffic from multiple European networks was routed through China Telecom, the Chinese state-owned telecom, for two hours.⁴⁸ Doug Madory, “Large European Routing Leak Sends Traffic Through China Telecom,” Oracle Internet Intelligence, June 6, 2019, https://blogs.oracle.com/Internetintelligence/large-european-routing-leak-sends-traffic-through-china-telecom. The BGP “route leak” occurred at Safe Host, a Swiss data colocation firm. It was possible for China Telecom to correct the BGP error once it received the traffic. Instead, China Telecom accepted the incorrect routes and began receiving traffic from European networks in the Netherlands, Switzerland, France, and more. “If any other ISP would have caused this incident, it would have likely been ignored,” one journalist wrote.⁴⁹ Cimpanu, “For Two.” But China Telecom’s previous entanglement with BGP hijacks of long durations⁵⁰ Chris C. Demchak and Yuval Shavitt, “China’s Maxim – Leave No Access Point Unexploited: The Hidden Story of China Telecom’s BGP Hijacking,” Military Cyber Affairs 3(1) Article 7 (2018): 1-9, https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca; and Doug Madory, “China Telecom’s Internet Traffic Misdirection,” Oracle Internet Intelligence, November 5, 2018, https://blogs.oracle.com/Internetintelligence/china-telecoms-Internet-traffic-misdirection. meant this event raised some eyebrows.

TABLE 3: Five Autonomous Systems (global) with most involvement in BGP incidents, January 1, 2020–May 31, 2020

TABLE 4: Five Autonomous Systems (global) with most involvement in potential BGP hijacks, January 1, 2020–May 31, 2020

The suspicion of China Telecom is not unique, as the BGP has been abused by a handful of serial offenders over the past decade. China Telecom has already been the source of a dozen unique BGP incidents (leaks and possible hijacks) between January 1 and May 31 of 2020 alone. Russian state-owned telecommunications giant Rostelecom has been the source of numerous events over the past few years, including an April 2020 hijack that was one “incident” overall but encompassed the hijacking of dozens of different ASes’ traffic (Table 2). AS operators in Angola, the Netherlands, and Hong Kong, and CenturyLink in the United States, were also detected by BGPStream as origins of numerous potential BGP hijacks in 2020 (Tables 3 and 4). Turla, widely believed to be a Russian state-sponsored espionage group,⁵¹ United States Computer Emergency Readiness Team, “NSA and NCSC Release Joint Advisory on Turla Group Activity,” October 21, 2019, https://www.us-cert.gov/ncas/current-activity/2019/10/21/nsa-and-ncsc-release-joint-advisory-turla-group-activity. has used BGP hijacks in tandem with other tools to deliver malware.⁵² Diplomats in Eastern Europe Bitten by a Turla Mosquito, ESET, January 2018: 8-9, https://www.welivesecurity.com/wp-content/uploads/2018/01/ESET_Turla_Mosquito.pdf. The Iranian government is no stranger to the BGP either, hijacking routes to target Iranian users of Instagram and the encrypted messaging app Telegram.⁵³ Danny Adamatis et al., “Persian Stalker Pillages Iranian Users of Instagram and Telegram,” Cisco Talos, November 5, 2018, https://blog.talosintelligence.com/2018/11/persian-stalker.html. All this begs the question: if companies like AT&T and Verizon, Akamai and Cloudflare, Amazon and Google see BGP route leaks on the Internet every day, what can these Internet infrastructure operators do about it?

3.3 Influencing the BGP’s security

There are tools readily available to protect the BGP. One such tool is Resource Public Key Infrastructure (RPKI) for Route Origin Validation, used to sign and filter BGP origin data.⁵⁴ Others include, for example, RPSL, BCP-38, and uRPF. RPKI, examined here, is merely one protection. RPKI highlights the potential for the private sector to shape the Internet’s digital rules for security and the reasons firms may not do so.⁵⁵ NIST lays out RPKI, BGP origin validation, and prefix filtering separately, but insofar as the last two leverage RPKI, I discuss all three at once here. Kotikalapudi Sriram and Doug Montgomery, Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation, NIST Special Publication 800-189, National Institute of Standards and Technology (2019): 2, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf. This makes it an exemplary case study for how the US government can help shape incentives—though just as the BGP is just one protocol that illustrates the private sector’s influence on global Internet security, RPKI is just one mechanism for adding safeguards around the BGP.

RPKI is a way to cryptographically sign records that link IP addresses to their originating AS.⁵⁶ Martin J Levy, “RPKI – The Required Cryptographic Upgrade to BGP Routing,” Cloudflare, September 19, 2018, https://blog.cloudflare.com/rpki/. A regional Internet registry (RIR)—a nonprofit which manages Internet address space in different regions of the world—cryptographically signs assertions of IP address ownership. Then, the owner of said IP addresses signs a set of AS operators who can originate routes to those addresses. An AS operator like Amazon can download a local copy of the signed information.⁵⁷ Depending on its size, an AS operator may locally store one or multiple copies of a cached route. R. Bush and R. Austein, “The Resource Public Key Infrastructure (RPKI) to Router Protocol,” Internet Engineering Task Force, RFC 6810, January 2013, https://tools.ietf.org/html/rfc6810. Then, whenever Amazon receives new route announcements from neighboring ASes, it can check against this signed information to discard bad routes.⁵⁸ R. Bush, “Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI),” Internet Engineering Task Force, RFC 8481, September 2018, https://tools.ietf.org/html/rfc8481; and P. Mohapatra et al., “BGP Prefix Origin Validation,” Internet Engineering Task Force, RFC 6811, January 2013, https://tools.ietf.org/html/rfc6811. RPKI for Route Origin Validation only verifies legitimate destinations, not legitimate paths, but it builds more trust into Internet routing⁵⁹ Levy, “RPKI.” and makes it easier for AS operators like Google and Cloudflare to route Internet data correctly.

It’s up to the private sector to make these changes. AS operators can implement these protections to help secure Internet traffic routing at scale—improving security and resilience for every Internet user that needs traffic routed via the BGP, and protecting economic and national security in the process. The point is to raise costs: companies that put these safeguards around the BGP, the Internet’s “GPS,” make it harder for malicious actors to hijack the BGP and make it harder for those that still hijack the BGP to do so without detection. Keeping in mind that RPKI for Route Origin Validation is just one safeguard (just as the BGP is just one protocol), many other efforts, like machine learning to detect hijack patterns,⁶⁰ Liam Tung, “MIT: We’ve Created AI to Detect ‘Serial Internet Address Hijackers,’” ZDNet, October 9, 2019, https://www.zdnet.com/article/mit-weve-created-ai-to-detect-serial-Internet-address-hijackers/; and Cecilia Testart et al., “Profiling BGP Serial Hijackers: Capturing Persistent Misbehavior in the Global Routing Table,” Internet Measurement Conference, October 21-23, 2019, http://people.csail.mit.edu/ctestart/publications/BGPserialHijackers.pdf. can further supplement Internet routing security.

This one illustrative solution isn’t perfect; precisely because the Internet is human-made, from hardware cables to phone apps, it will always contain imperfections of human origin. Cryptographically signed routing tables can be compromised, pattern detection systems can make errors, and malicious actors could pose as authorized AS operators to pass bad BGP routes to Google, for example, even with RPKI, hijacking content bound for a government service or large company.⁶¹ Jérôme Fleury and Louis Poinsignon, “RPKI and BGP: Our Path to Securing Internet Routing,” Cloudflare, September 19, 2018, https://blog.cloudflare.com/rpki-details/. But the private sector implementing these protections at scale would contribute massive improvements over the status quo. As one network engineer put it, “only a small specific group of densely connected organizations” needs to deploy RPKI on top of those already doing it “to positively impact the Internet experience for billions of end users.”⁶² Job Snijders of NTT Communications, quoted in: Madory, “BGP / DNS.” More AS operators like AT&T or Verizon or Google or Cloudflare checking their BGP routes means a lower frequency of routing failures. This shapes the Internet’s digital rules to improve security.

Yet, many have not signed and filtered routes with RPKI. Implementation of this protection on a regional basis—broken down by the five regional Internet registries which manage Internet address space for respective regions—varies as well, with the highest rate of adoption in Europe and the rate of adoption lagging within the North American region served by the American Registry for Internet Numbers (ARIN) (Figure 5).

FIGURE 5: Regional Internet Registries and RPKI implementation

Source: RIPE⁶³ Downloaded from RIPE’s Network Coordinate Centre, accessed July 7, 2020, https://certification-stats.ripe.net/.

Note: Total number of resource certificates created under regional Internet registry trust anchor.

FIGURE 6: American Registry for Internet Numbers (ARIN) and RPKI implementation (through May 31, 2020)

Source: RIPE

Note: Total number of resource certificates created under regional Internet registry trust anchor. 

Routing security is a collective action problem; it takes more than one company to shape the Internet’s digital rules. Benefits scale with the number of AS operators which implement routing security improvements. Marginal costs of implementation for one operator—including time and resources, concern about complexity and malfunctions, and concern about liability for those malfunctions—can outweigh perceived benefits if deployment is not widespread. And, clearly, deployment is not as widespread as it could be, though RPKI protections implemented by operators within ARIN have been rising (Figure 6). Firms might only partially employ this BGP safeguard,⁶⁴ This is indicated by data such as that from Cloudflare’s IsBGPSafeYet dataset, downloaded from Cloudflare’s IsBGPSafeYet.com, accessed on May 26, 2020, https://github.com/cloudflare/isbgpsafeyet.com/blob/master/data/operators.csv. Also based on IPinfo’s list of AS operators in the United States. Accessed on May 26, 2020. https://ipinfo.io/countries/us. But classification isn’t just a matter of considering the number of IP addresses in a single AS, for example, but considering other factors like AS interconnectedness. and a lack of action at the global level illuminates the need for better government-private sector cooperation on this issue set. This is especially true in North America, where technology companies have an outsized influence on global Internet security.

Companies face several important disincentives to RPKI adoption which policymakers can help to address:

1. Coordination: RPKI must be implemented at scale, across many different AS operators, for it to effectively improve routing security. Telecommunications companies may privately say they support improvements to BGP security, for instance, but will not act if other companies won’t either—the risks are not worth it. Coordinating this action at scale is difficult. Policymakers can help by putting RPKI into federal procurement rules, which is a way to incentivize security best practices in the industry without legislative regulation (see Recommendation 1). Policymakers can also invest more in cyber diplomacy to develop norms around the protection of and noninterference with the BGP (see Recommendation 5).
2. Cost: While many ISPs, CDNs, and cloud services providers are investing much more in security today than they were ten years ago, that investment has not focused on networking as heavily as other areas. Many companies still favor fast and resilient systems over deployment of more secure routing. Competition among firms, particularly for large operators, is a key part of the calculus as well. Policymakers could leverage public-private partnerships to explore other ways to incentivize firms and lower costs (see Recommendation 2). Policymakers can also push for RPKI protections on government systems to add another set of large AS operators to the list of those using RPKI (see Recommendation 3). Firms themselves can also share threat data from their insights into the Internet infrastructure (see Recommendation 4).
3. Uptime: BGP routing is key to the Internet’s infrastructure. Network operators worry about RPKI causing even temporary errors in routing (or slightly slower routing), especially when scaled up for large operators where technical problems could have broader effects. This uptime issue affects other critical infrastructure, for example, delays in patching electrical power generation and distribution equipment which is operating near constantly. Industry and policymakers cultivating communities of knowledge among RPKI operators could help lower these risks (see Recommendation 2), as could pushing firms to implement protections at the same time via federal procurement rules (see Recommendation 1).
4. Liability: US network operators and ARIN, the regional Internet registry for North America, have conflicting risk tolerances for liability in the event of an RPKI malfunction. In other words, these entities have different stances on who should be liable for possible damages if an RPKI implementation malfunctions. Presently, many network operators maintain that they cannot or will not sign onto using RPKI with ARIN because of indemnification language in ARIN’s services agreement, which they assert is too broad in its shielding of ARIN from liability.⁶⁵ Two legal scholars note that “our interviews with legal personnel have corroborated the view that indemnification is not typically an automatic deal-breaker, but rather acts as a weight on the scale.” Christopher S. Yoo and David A. Wishnick, “Lowering Legal Barriers to RPKI Adoption,” Faculty Scholarship at Penn Law, 2035, 2019, 14, https://scholarship.law.upenn.edu/cgi/viewcontent.cgi?article=3037&context=faculty_scholarship. ARIN, which recently made some revisions to the indemnification language, maintains that this language is necessary for an entity with a critical role in the global Internet and a significantly smaller budget than many network operators. This remains, in the words of one observer, a “logjam.” The government can thus use its public-private partnerships and convening power to push further dialogue on this issue (see Recommendation 2).

AS operators can modify their processes to integrate RPKI and other routing security methods to better protect the Internet from routing attacks and errors. These operators wield tremendous influence over this infrastructure. But routing is just one example of poor incentives for firms to do as much as they can to shape the Internet for security, just as RPKI as discussed here is merely one protection for the BGP. The following section examines similar issues in another key Internet protocol—the DNS—to frame the paper’s five recommendations in the final section.

4. Addressing the Domain Name System

4.1 How the DNS works

Before networks can route traffic around the world for Netflix or Skype or Facebook or Google Drive, they must know its address. The source of these addresses is the Domain Name System, often referred to as “the Internet’s phone book,” which translates domain names (i.e., atlanticcouncil.org) typed into a browser, or included in the right-hand side of an email address, to their respective Internet Protocol (IP) address (i.e., 104.20.20.178) to direct Internet traffic to its proper destination.⁶⁶ See, for example, “Public DNS,” Google Developers, accessed May 20, 2020, https://developers.google.com/speed/public-dns. Like the BGP, the DNS is a protocol that is both critical to the Internet’s digital rules and quite vulnerable to hacking and manipulation—and illustrates the potential for better government-private sector coordination on securing the Internet. It is again just one case study, and the protections for DNS integrity discussed within are only one protection available, like years-long government and industry efforts around DNS confidentiality.⁶⁷ See, for example, Communications Security, Reliability, and Interoperability Council’s work on DNS security, or IETF’s work on the aforementioned DNS over TLS (DoT) versus DNS over HTTPS (DoH) issue.

Similar to the BGP, the DNS can be run internally to a network, like a firewalled corporate intranet, but the discussion here focuses on its use on the global Internet.”

FIGURE 7: DNS in operation

Speed and resilience were priorities for the Internet’s design, and the DNS is no exception. The DNS does provide numerous benefits; users only have to remember website names, not IP addresses, and when IP addresses change, as when Google or Amazon physically relocate servers supporting their cloud services, website names stay the same while being mapped to new IP addresses. The DNS’s abstraction layer also allows companies to link a single domain name to multiple IP addresses, and multiple domain names to single IP addresses, allowing a company like Verizon or Akamai to route data to users from the closest or fastest available server and to distribute the impact of large denial-of-service (DoS) attacks.⁷⁰ J. Klensin, “Role of the Domain Name System (DNS),” Internet Engineering Task Force, RFC 3467, February 2003, https://tools.ietf.org/html/rfc3467.

4.2 How the DNS gets exploited

The DNS is vulnerable to manipulation, and here this focuses on integrity (as opposed to, say, confidentiality). Attackers can intercept and maliciously edit DNS queries and responses to send users to malware-laden websites instead of their intended destination. Users might expect their banking website but instead be disclosing their banking credentials to a visually indistinguishable but malicious imposter. This could happen on the user’s device, between the user and their recursive resolver, within the recursive resolver itself or, most commonly, between the recursive resolver and authoritative servers. This last attack is most broadly effective as it can change Internet packet addressing for all downstream devices.⁷¹ Scott Fulton, “Top 10 DNS Attacks Likely to Infiltrate Your Network,” NetworkWorld, February 20, 2015, https://www.networkworld.com/article/2886283/top-10-dns-attacks-likely-to-infiltrate-your-network.html; and Imperva, “Domain Name Server (DNS) Hijacking,” accessed May 21, 2020, https://www.imperva.com/learn/application-security/dns-hijacking-redirection/.

The DNS is also vulnerable because of a process called caching. Because it’s costly (in time and resources) for computers to repeatedly request the same information from upstream servers, they store copies of the answers they receive in a local cache, thereby speeding up subsequent queries and vastly reducing demand on the network and servers. But cache maintenance requires many rules and policies, and this is another “attack surface” subject to exploitation. Using “DNS tunneling,” hackers can also use channels of DNS communication between a computer and a DNS server to exfiltrate information or facilitate malware command-and-control through firewalls, which may not be able to validate DNS traffic.⁷² Jeff Petters, “What Is DNS, How It Works + Vulnerabilities,” Inside Out Security Blog, Varonis, March 29, 2020, https://www.varonis.com/blog/what-is-dns/. It’s a way to covertly steal data.

There have been numerous DNS hijacks over the past few years, including a notable global DNS hijack campaign—dubbed “DNSpionage”—by actors with apparent links to Iran, that illustrate this problem. In November 2018, Cisco’s Talos unit reported on “a new campaign targeting Lebanon and the United Arab Emirates” which impacted .gov domains and a Lebanese airline. The attackers also compromised the DNS of legitimate .gov and private domains in target countries, potentially redirecting traffic.⁷³ Warren Mercer and Paul Rascagneres, “DNSpionage Campaign Targets Middle East,” Cisco Talos, November 27, 2018, https://blog.talosintelligence.com/2018/11/dnspionage-campaign-targets-middle-east.html. Yet this is hardly the only large-scale DNS hijacking incident. In April 2019, Cisco Talos published a report detailing another DNS hijacking campaign with public and private targets, “including national security organizations.” Talos dubbed the operation, likely beginning as early as January 2017 and continuing into 2019, “Sea Turtle.” It expressed concern that the operation’s success would “lead to actors more broadly attacking the global DNS system.”⁷⁴ Danny Adamitis et al., “DNS Hijacking Abuses Trust in Core Internet Service,” Cisco Talos, April 17, 2019, https://blog.talosintelligence.com/2019/04/seaturtle.html. However, these hijacks are not always as related to geopolitical and state security interests; other separate DNS hijacks have targeted individuals as well. For instance, cryptocurrency service MyEtherWallet was hit with a DNS hijack in August 2018 that stole more than $150,000 in cryptocurrency from the site’s users.⁷⁵ CoinDesk, “$150K Stolen From MyEtherWallet Users in DNS Server Hijacking,” April 24, 2018, https://www.coindesk.com/150k-stolen-myetherwallet-users-dns-server-hijacking. In total, these incidents underscore poor security on the part of the DNS.

4.3 Influencing the DNS’ security

DNS hijacks and abuse hurt users and civil society organizations, businesses, and governments. Like other human-designed Internet rules, the DNS is not set in stone; in fact, companies with infrastructural influence over the Internet are rapidly reshaping the DNS protocol suite. To protect the DNS, AS operators, website hosts, and other companies or institutions that connect their constituents’ systems to the Internet (e.g., for corporate and university networks) can implement DNS Security Extensions (DNSSEC). This is but one protection for the DNS, which is again one protocol—but collectively a valuable case study for private sector Internet influence.

DNSSEC uses public key cryptography to create a trust model for DNS records—it yields records that are verifiable by anyone receiving them.⁷⁶ Verisign, “How DNSSEC Works to Provide the Protocol for a Secure Internet,” accessed May 27, 2020, https://www.verisign.com/en_US/domain-names/dnssec/how-dnssec-works/index.xhtml. This beneficially separates the data’s integrity from the security of the servers and networks which handle it,⁷⁷ R. Arends et al., “DNS Security Introduction and Requirements,” Internet Engineering Task Force, RFC 4033, March 2005, https://tools.ietf.org/html/rfc4033. the equivalent of a detective sealing evidence in a tamper-evident bag.⁷⁸ Credit goes to Bill Woodcock for this analogy. A court can still verify the integrity of the evidence inside, regardless of whose hands it passed through between the detective and the court. Like RPKI, to implement DNSSEC, users must both create signatures and verify them.⁷⁹ Ramaswamy Chandramouli and Scott Rose, Secure Domain Name System (DNS) Deployment Guide, NIST Special Publication 800-81-2, Gaithersburg: National Institute of Standards and Technology, 2013, 9-1, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf. One party signing the data is a necessary precursor to another party using the signature to verify the data’s integrity—but the system as a whole is not secure until and unless both steps have been completed.

FIGURE 8: DNSSEC in operation

Just as the DNS is one protocol that highlights the private sector’s overlooked, vital impact on global Internet security, DNSSEC is just one DNS protection. It doesn’t solve all DNS security problems by itself. DNSSEC data is signed but not encrypted: computers can check a DNS record’s authenticity (e.g., a user can verify the IP address they received for atlanticcouncil.org is the correct one), but the transaction’s confidentiality is not protected (e.g., someone could see the user wants to connect to atlanticcouncil.org).⁸² Archana Kesavan, “Introduction to DNSSEC Monitoring,” ThousandEyes, March 31, 2017, https://blog.thousandeyes.com/introduction-dnssec-monitoring/. DNSSEC can also be implemented incorrectly,⁸³ Site24x7, “DNSSEC Validation Results and Troubleshooting Tips,” accessed June 22, 2020, https://support.site24x7.com/portal/en/kb/articles/dnssec-validation. and DNSSEC cannot protect users from mistyping domain names; “typosquatting” is a frequent form of attack—for example, catching users who type “atlanticouncil.org”⁸⁴ Jesus Vigo, “Why Your Company Should Consider Implementing DNS Security Extensions,” TechRepublic, March 2, 2018, https://www.techrepublic.com/article/why-your-company-should-consider-implementing-dns-security-extensions/. or “atlanticcouncil.com” instead of “atlanticcouncil.org.” It’s up to the private sector to act, but that action is not widespread.

FIGURE 9: DNSSEC validation across Internet users (global)

Source: APNIC⁸⁵ Downloaded from APNIC’s DNSSEC Validation Rate dataset, accessed on May 26, 2020, https://stats.labs.apnic.net/dnssec. Also see methodology: Geoff Huston, “DNSSEC Validation (Revisited),” ISP Column, Potaroo.net, February 2020, https://www.potaroo.net/ispcol/2020-02/validating.html.

Note: Users using DNSSEC-validating resolvers.

Globally, 65.7 percent of end users are neither performing DNSSEC validation nor trusting a recursive resolver to do it for them (Figure 9); they are still reliant on the DNS in its original and less-secure form. Once again, North America trails much of the world with only 28.5 percent of users seeing validated DNSSEC connections relative to 38.5 percent in Oceania and 29.5 percent in Europe. North America also lags in partial DNSSEC validation, with partial validation⁸⁶ Partial validation describes when some of the user’s resolvers validate and others do not. Thanks to Geoff Huston for providing this clarification. much higher in Africa and Asia (Figure 10). Private industry plays a major role in this, underscoring an urgent need for government action and government-private sector coordination on poor market incentives, collective action problems, and a lack of available tools, particularly for small firms. But even on the government side, North America is behind: for instance, the United Kingdom’s National Cyber Security Centre offers up a Protective Domain Name System (implemented by Nominet UK, the .uk domain name registry) to make DNS protections easier in the UK,⁸⁷ United Kingdom National Cyber Security Centre, “Protective DNS (PDNS),” accessed June 22, 2020, https://www.ncsc.gov.uk/information/pdns. whereas US government agencies are still lagging in DNSSEC adoption despite existing requirements for its implementation.⁸⁸ NIST (National Institute of Standards and Technology), “Estimating IPv6 & DNSSEC External Service Deployment Status: Background and Methodology,” accessed June 22, 2020, https://fedv6-deployment.antd.nist.gov/.

FIGURE 10: DNSSEC validation across Internet users (regional, graph)

Source: APNIC⁸⁹ APNIC’s DNSSEC Validation Rate dataset.

Note: Users using DNSSEC-validating resolvers.

Protections for the DNS, a key Internet protocol, are an example of a strong opportunity for the private sector to use its influence over the Internet to improve security for all. Yet, there are several barriers to wider action and adoption:

1. Collective Action: Like RPKI, the benefits of DNSSEC scale with the number of entities using it. Implementing DNSSEC does take work, yet more companies and individuals doing that work to implement DNSSEC measures on their end devices could add pressure on domain name server operators to implement DNSSEC themselves.⁹⁰ Nikolai Hampton, “Why Isn’t Everyone Using DNSSEC?” APNIC, June 28, 2017, https://blog.apnic.net/2017/06/28/isnt-everyone-using-dnssec/. Policymakers could introduce federal procurement requirements here to encourage protections among large private sector operators (see Recommendation 1). They could also push the government to implement protections on its systems (see Recommendation 3).
2. Cost: Implementation of DNSSEC requires time and resources, like configuring signed addresses for one’s domains. This is an obstacle for network operators and DNS providers in a constant race to maintain and improve network speed and stability.⁹¹ See, for example, Matt Torrisi, “Is DNSSEC Adoption Worth It for Enterprises?,” Dyn, September 18, 2018, https://dyn.com/blog/is-dnssec-adoption-worth-it-for-enterprises/. Deploying protections at scale, like with many protocol protections, can also yield its own challenges and technical side effects. Policymakers can thus use the government’s coordinating functions to convene public-private dialogues on this Internet protocol security challenge (see Recommendation 2).
3. Stability: DNSSEC implementations fail safe, by design. When anything goes wrong, the user cannot proceed because doing so would leave them open to compromise. For instance, nameservers might incorrectly sign records and thus prevent users from accurately validating DNSSEC-signed addresses.⁹² Cloudflare, “Troubleshooting DNSSEC,” last updated 2019, https://support.cloudflare.com/hc/en-us/articles/360021111972-Troubleshooting-DNSSEC. Policymakers can use the government’s coordinating and best-practice-sharing functions to help address stability issues when firms shape the Internet for security (see Recommendation 2). Policymakers can also invest in norm development for protecting and not interfering with the DNS (see Recommendation 5).
4. Tough to DIY: Many users depend on third-party nameservers, like a cloud provider, to operate their website and resolve the DNS. This means relying on these third parties to adopt DNSSEC and to maintain it over time, including the necessary cryptographic signing process.⁹³ Taejoong Chung, “Why DNSSEC Deployment Remains So Low,” APNIC, December 6, 2017, https://blog.apnic.net/2017/12/06/dnssec-deployment-remains-low/. Policymakers can help lower barriers through convenings and public-private partnerships, for instance, like the UK’s resources for DNSSEC implementation (see Recommendation 2).

5. Recommendations and conclusions

The Internet’s shape and behavior are not set in stone. The private sector continuously revises the Internet’s topology and policies, changing its behavior for users, businesses, and governments across the world. Resulting effects on personal, economic, and national security are enormous, for these are not just decisions about a single database used by one company but about physical infrastructure and digital rules that impact millions if not billions of Internet users every day. The COVID-19 pandemic has underscored society’s fundamental reliance on the Internet, and Internet dependence and connectivity will only grow in the years to come as more of the global population comes online; as the cloud market continues to expand in offering services to individuals and enterprise; as more work and learning becomes virtual; as government agencies turn to the cloud and to artificial intelligence for government functions; and as emerging technologies like 5G telecommunications empower the Internet of Things and autonomous vehicles to constantly connect and communicate data. Securing the addressing and routing of all of that data—making sure it arrives quickly, safely, securely, and via the right paths—is vital.

The US government has an opportunity to better integrate the unique influence the US private sector has on the Internet’s topology and behavior, and thus its security, into a national policy for securing cyberspace. Yet, private firms must also recognize the opportunities and responsibility their influence gives them to improve Internet security and resilience at scale. Consequently, there is an urgent need not just for better government-introduced incentives for the private sector to act to the benefit of Internet security, but also for better government-private sector cooperation and coordination on these issues.

The BGP and the DNS show the poor pace of progress in driving these more secure Internet protocols to wide adoption—and underline the disconnect between private sector firms’ influence and incentive to change. However, they are only two protocols, and the safeguards discussed in this report’s case studies are only two of many safeguards for bolstering those protocols’ security. Questions about BGP security have grown over the past few years, and the coming years will only bring new issues to the fore that will take on their own urgency. This is where leveraging this report’s case studies on the BGP and the DNS—on the protocols, their vulnerabilities, the barriers to action—will help the government and the private sector build policy and strategy around incentives and coordinated action to tackle the next set of challenges. The United States should be looking ahead when building a strategy to secure the Internet with an appreciation of the private sector’s influence.

To this end, this report makes the following five recommendations:

1. The US government should place Internet protocol security best practices in federal procurement rules. Incentivizing a few big players to change their behavior, especially ones in the United States with an outsized influence on Internet infrastructure, can have significant consequences for the Internet ecosystem and lower the barrier to collective action on the part of small and medium-sized network operators. This would compel ISPs, CDNs, cloud services providers, and other Internet infrastructure operators vying for federal contracts to adopt these safeguards. Those implementing these procurement rules should include the Departments of Defense, Veterans Affairs, Homeland Security, and Health and Human Services, which are the four biggest IT spenders in the US government. Looking beyond the case studies in this report, these rules could also draw from other security best practices for Internet addressing and routing, like those enumerated in Mutually Agreed Norms for Routing Security (MANRS),⁹⁴ See: “Mutually Agreed Norms for Routing Security,” https://www.manrs.org/. or those laid out in previous work by the NIST.⁹⁵ See, for example, Sriram and Montgomery, Resilient.
2. The US government should convene public and private stakeholders to tackle the next set of challenges on Internet protocol security. The US private sector’s outsized influence on Internet infrastructure means the US government must better understand its security challenges and the incentives around them—which also presents an opportunity to be forward-looking. The key for any convening is to be voluntary, to have a well-defined scope, and to involve representatives with subject matter expertise as well as global stakeholders. Interagency buy-in from the government side is also essential for driving consensus on potentially coordinated or collaborative activities, and the involvement of a technical-expert agency like the NIST can help with the optics of a public-private convening on protocol modifications. Additionally, bringing operators to the table—those who technically work on these challenges that have business, policy, and geopolitical effects—could help drive substantive conversation at a convening spanning problems, how they can be addressed, and barriers to those solutions. There is also an educational role here insofar as some security issues with the Internet’s digital rules come back to network operators’ “hygiene” practices. Ensuring trust in a route’s path, not just its origin, is one example of a “next big challenge.”
3. The US government should require federal agencies to implement these Internet protocol security best practices in their own systems. While the US private sector has key influence on Internet topology and behavior worldwide, the US government maintains its own domestic networks that also should be secured. Government agencies, especially the Department of Defense, operate large networks that use many of the same digital rules as private operators. Policymakers should promote security best practices within these agencies,⁹⁶ Legacy IP space maintained by government agencies may be one explanation for lagging best practices. such as through the Office of Management and Budget,⁹⁷ This OMB recommendation is borrowed from Yoo and Wishnick, “Lowering,” 33. in coordination with the NIST. This can also include producing reports on the status quo within government agencies, building on previous work.
4. Large, private sector network operators should share and then leverage data on Internet protocol attacks. The US private sector’s influence on global Internet topology and behavior provides key and unique insights into security threats around the world, such as attacks on the Internet’s core digital rules. Some corporate aversion to naming and shaming is understandable, but ISPs, CDNs, and cloud services providers collectively have a depth and breadth of insight into the infrastructure that researchers cannot find elsewhere—meaning they also have insight into attacks and repeat offenders for, say, traffic routing malfunctions. Much like the public-private convening on future challenges in Internet protocol security, data sharing here would need buy-in not just from business leadership but also from operator-level personnel at those companies. A convening discussion about this issue should also address operator concerns about liability for increased data sharing, including with researchers who would greatly benefit from data on protocol attacks. This could occur through any number of existing private sector efforts to share threat information, such as through sector-specific information-sharing analysis centers (ISACs) or through nonprofit efforts like the Shadowserver Foundation.
5. The US government should invest more in the State Department’s cyber diplomacy efforts to develop norms against manipulating core Internet protocols. Not only does the US private sector have enormous influence over global Internet infrastructure, but the United States has historically played a key leadership role in promoting and protecting practices around a relatively free and global Internet—which also means security is a critical issue. Existing intergovernmental and nongovernmental efforts to push these protections, like the Global Commission on the Stability of Cyberspace’s “Call to Protect the Public Core of the Internet,” already focus on this issue—developing norms around state and nonstate noninterference in Internet traffic addressing and routing protocols key to the Internet’s functionality.⁹⁸ Global Commission on the Stability of Cyberspace, Definition of the Public Core, to Which the Norm Applies, May 2018, https://cyberstability.org/wp-content/uploads/2018/07/Definition-of-the-Public-Core-of-the-Internet.pdf. This could also involve the leveraging of private sector data on incidents like BGP hijacks. The United Nations Group of Governmental Experts (UN GGE) and UN Open-Ended Working Group (OEWG) are two forums through which this investment could occur, in addition to bilateral and multilateral engagements with allies and partners who share an interest in better securing the global Internet.

These recommendations are not a silver bullet. But they zoom out far beyond the illustrative case studies on the BGP and the DNS in this report and recommend the US government reassess its current strategy toward and relationship with the private sector with respect to Internet security. The private sector’s role in Internet geopolitics on the infrastructural level cannot be ignored or sidelined any longer. Further, challenges that have plagued Internet routing and addressing security in the past can provide valuable lessons for the future.

On both of these points, Internet name resolution and packet routing protocols are exemplary case studies. The BGP and the DNS show how private sector influence over Internet infrastructure gives firms leverage to better protect Internet packet addressing and routing at scale—in ways that better protect personal, economic, and national security, as well as the overall resilience of the global Internet. This matters for global cybersecurity as well as for growing “cyber sovereignty” measures around the world, including the so-called fragmentation of the global Internet, which are driven in part by concerns about cybersecurity threats. Working to better secure the Internet will promote confidence in its continued viability as a global network of networks and, perhaps, slow the decline toward a fragmented and tribal information ecosystem.⁹⁹ Justin Sherman, Strengthening Democratic Internet Governance: The West Needs a Plan or Risks Getting Left Behind, Atlantic Council, working draft; and Daskal and Sherman, Data Nationalism on the Rise.

About the author

Fellow

Justin Sherman

Nonresident Fellow

Cyber Statecraft Initiative Digital Forensic Research Lab

China Cybersecurity

Acknowledgements

The author would like to thank Trey Herr, Bill Woodcock, Stewart Scott, Tianjiu Zuo, Martin Levy, Jennifer Daskal, Megan Stifel, David Hoffman, Matthew Kroenig, and several other reviewers who requested anonymity for their feedback on earlier versions of this document. The author would also like to thank David Hoffman, Bill Woodcock, Frederick Douzet, Kavé Salamatian, Loqman Salamatian, Alissa Starzak, Josephine Wolff, Martin Levy, Louis Poinsignon, Jesse Sowell, Robert Morgus, Christopher Yoo, John Curran, and several others who requested anonymity for valuable discussions about the issues. Finally, the author would like to thank Simon Handler, Trey Herr, Nancy Messieh, and the broader Atlantic Council team for their support.

The Atlantic Council’s Cyber Statecraft Initiative, under the Digital Forensic Research Lab (DFRLab), works at the nexus of geopolitics and cybersecurity to craft strategies to help shape the conduct of statecraft and to better inform and secure users of technology.

learn more

Cybersecurity Internet Technology & Innovation