Skip to main content

RPKI brings security, reliability to BGP routing

Border Gateway Protocol, which sets paths by which networks connect to each other, is an accident waiting to happen. The addition of digital signatures to the routing infrastructure will make it less dangerous.

In November 2017, a routing configuration error by one of the largest telecom networks in the world caused a massive disruption in Internet traffic. It was a mistake and was fixed fairly quickly, but for a couple hours, users in the United States, Brazil, Argentina, and the United Arab Emirates couldn’t watch Netflix, update inventories, or kill other game players.

In April 2018, the same technique was used intentionally by attackers to redirect traffic meant for real DNS servers in order to hijack transactions on MyEtherWallet.com, a cryptocurrency site. As a result, users who thought they were logging into MyEtherWallet were, in fact, logging into a scam site in Russia. The site took their credentials and stole $320,000 from a total of 198 victims.

The error, really an attack in the latter case, is a so-called Border Gateway Protocol (BGP) leak. Such incidents expose one of the greatest vulnerabilities in networks, on and off the Internet. It’s been known to experts for a long time as a problem with catastrophic potential, but an effective means by which to defeat it is only now spreading widely. That answer is Resource Public Key Infrastructure (RPKI), defined in RFC 6480 ("An Infrastructure to Support Secure Internet Routing").

Routing, advertising, leaking

The Internet is a “network of networks.” When you need to connect to an IP address on another network, the router on your network looks at its routing table for the network that contains the address you seek. The router finds the best path through the networks of the Internet to the network you want.

The protocol for configuring routers and the addresses they contain is BGP. BGP is one of those major developments that has an incongruently casual origin: Two engineers having lunch at an IETF conference in 1989 sketched it out on a couple of napkins.

As with all the early Internet protocols, little or no thought was given to security and not a whole lot to reliability. Internet routing runs on the honor system. Everyone just agrees not to make mistakes or maliciously change someone else’s routes.

These networks are called autonomous systems; here is a complete list. For example, there is AS203211 (“HEWLETT_PACKARD_ENTERPRISE, CH”). It is a European network, and it connects to the Internet through a couple of European telecom providers. The AS203211 report shows what routes the network advertises and to whom. This is all out in the open; it has to be for the Internet to work. There are more than 700,000 IPv4 routes and 40,000 IPv6 routes announced by all Internet actors.

Erroneous BGP leaks

Assume that engineers for company A make a mistake and program their routers to publish a route for company B’s addresses to a network where they don’t belong. These routes would be accepted and incorporated into routing tables of other organizations’ routers, and some traffic seeking company B’s systems would end up on the route mistakenly specified by company A. The network where the traffic ends up may not be able to handle a flood of erroneous traffic. Company B and its customers and partners will have trouble communicating with each other.

This sort of mistake happens all the time, although not usually at the level where real problems result.

Malicious BGP leaks

In theory, the malicious leaking of BGP routes, a.k.a. BGP spoofing, is the ultimate attack technique. You can spoof anything on the Internet and it would be very hard for a user to tell. You can set up a fake website for Faceless National Bank that appears to be located at the IP address of Faceless National Bank. If you check the TLS certificate for the website, it checks out OK because you have spoofed the facilities of the relevant certificate authorities.

The MyEtherWallet attack was less sophisticated than the CIA-level stuff of theory, but it was still enough to fool unsophisticated users. In that case, the fake website used a self-signed certificate, so users likely saw what was unmistakably an error message (here is an example) and had to click past it. Yet many did just that. Once past that point, if the user was already logged in, the browser would send the login information in the cookie. Game over.

This is all possible, and it’s the sort of thing a well-resourced nation-state attack would do. That’s not just an educated guess: Along with a fair number of non-malicious screw-ups, a list of public BGP hijacking incidents has many large ISPs owned by or under the thumb of repressive governments, using the technique for censorship and profit—and those are just the ones that weren’t successfully covered up.

Popular mitigation techniques

One technique widely used, especially by ISPs, is route filtering. The filters allow the router to selectively identify routes advertised by and received from neighboring routes, according to policy in the form of lists of prefixes, route maps, and similar data, depending on the router manufacturer. By ensuring that only customer routes are advertised to peers, an ISP can prevent a customer from routing outside traffic. In the case of the MyEtherWallet attack, the attacker’s ISP announced a route to a subnet it did not own. Compounding the error, transit providers did not check the announcement before relaying it to other ISPs, which also did not check it.

Innovation in your in-box. Sign up for our weekly newsletter.

There are several organizations, mostly unofficial agreements between network providers, for sharing route leak information. One example is BGPStream, a service of OpenDNS. Its event details pages show fascinating time-lapse animations of the effects of leak events on network maps.

Of course, many bad routes may be mistakes—or not. In December 2017, 80 address ranges normally announced by Google, Microsoft, Apple, Facebook, and similar large tech companies were announced by AS of 39523 (DV-LINK-AS), a Russian network created only weeks before.

RPKI

The PKI in RPKI stands for the same sort of public key infrastructure used by certificate authorities to authenticate entities such as web browsers and websites across a network. In the case of RPKI, routes may be checked using a digital signature of the route signed by the entity that owns the network to which the route points.

The architecture of RPKI, defined in RFC 6840, was published way back in 2012. It attempts to reuse existing PKI features and functions, such as X.509 certificates, wherever possible. The certificates, called Resource Certificates in RPKI, state the possession of IP addresses and AS numbers. They contain public keys and digital signatures from the issuing authority.

Routing software uses the private key to sign route origination authorizations and other items to be announced. RPKI also creates a distributed repository system that stores these signed objects so that ISPs can use them in routing decisions. Using standard cryptography algorithms, a routing entity on the Internet can determine that a route origin was actually created by the entity that has authority for those addresses and networks. The certificates don’t identify the owner of the network or address; they just prove that whoever owns them issued the routing information.

The Certificate Authority role in RPKI, the authority through which one can determine whether a published route was published by the authorized entity, is performed by the Internet Assigned Numbers Authority (IANA) and the regional Internet registries (RIRs). The five RIRs are:

The RIRs are part of a series of organizations, under the authority of the IANA, that allocate defined Internet resources—primarily IP addresses and AS designations—to ISPs and larger end-user organizations (such as governments, universities, and large corporations).

Network services provider Cloudflare has published several informative blogs on the subject of BGP leaks and RPKI:

The RIRs hold the root certificates. They generate signed certificates for local Internet registries (LIRs), which are network operators like Cloudflare, containing all the resources (IPs and ASNs) assigned to that operator. A worldwide network like Cloudflare’s has resources stored with all five RIRs. The LIR signs the prefix containing the origin AS it intends to use, creating a Route Origin Authorization (ROA), which is an X.509 certificate. This is closely analogous to SSL/TLS in the web world, with ROAs performing the same role as SSL certificates.

Is it in the real world?

Cloudflare is one of the few companies actively promoting RPKI. Even given RPKI’s importance, it’s not a topic with really broad appeal or awareness. Even major BGP leak events, to the extent that they are in the news, don’t get into the weeds of what went wrong and what can be done about it.

Even so, RPKI is out there and growing, and there is a widespread understanding that it, or at least something that accomplishes the same thing, is necessary. NIST has a live RPKI monitor that shows the number of routes with valid RPKI configurations (IPv4 only). It’s at less than 10 percent as I write this, but it’s increasing long term. You can also find good live information about public RPKI use at The RPKI Observatory and RIPE’s RPKI Validator.

Cloudflare says Internet exchange points, which are data center facilities at which different networks meet and peer, have been adopting RPKI aggressively, after years of being among companies aggressive with route filtering. Many large networks, including Cloudflare, KPN (Netherlands), and NTT (Japan) have implemented it as well as some smaller, nerd-operated networks.

The insecurity of BGP is arguably the most important systemic Internet vulnerability. As the occasional incidents demonstrate, it has the potential to cause widespread outages and breathtaking fraud. As usual, the standards are well ahead of the capacity of major network providers to adopt an effective solution, but with RPKI, a solution does finally seem to be available and successful.

If you keep an eye on this space over the next year, or even sooner, you may see an acceleration of adoption. Software development is underway, which would make real-world adoption and operation of PKI by networks easier.

Securing BGP: Lessons for leaders 

  • This is something you need to talk to your ISP about.
  • Keeping track of BGP hacks and the behavior of nation states that are known to be manipulating BGP to censor and restrict Internet behaviors can keep you out of trouble.
  • RPKI monitoring tools allow IT staff to keep an eye on things.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.