Bgp’s Security Problems Are Notorious. Attempts To Fix That Are A Work Inprogress

Systems Approach I’ve been working on a chapter about infrastructure security for our network security book.

The core of the Internet is notoriously vulnerable to attacks, with Border Gateway Protocol (BGP) and DNS being particular weak points. So I set out to learn enough about what has been done to secure these components of the Internet’s “core infrastructure” to be able to write something useful for our book.

For this post I am going to limit myself to talking about BGP security, where it’s fair to say that the results have been mixed. This seems to be the case for Securing DNS as well, although “mixed” might actually be too positive a word in that case.

A good place to start to understand BGP security (and the lack of it) is Sharon Goldberg’s article Why Is It Taking So Long to Secure Internet Routing? from 2014. The fact that the article remains timely after more than a decade is a sign of just how hard the problem is. This paper from Testart and Clark on the state of routing security in 2020 shows how little things improved in subsequent years. I see this as the confluence of three hard problems: BGP is famously complex; security is hard to get right and you never get to declare success; and the core of the Internet suffers from ossification. So it’s hardly a surprise that improving the security of BGP has proved challenging.

But there is at least some good news. One aspect of routing security has dramatically improved since 2014: there is now meaningful deployment of Route Origin Validation (ROV) backed by the Resource Public Key Infrastructure (RPKI). Let’s take a look at what these technologies entail and what impact they have on routing security.

RPKI provides a means by which entities involved in routing, such as the operator of an autonomous system (AS), can make assertions related to routing. These assertions take various forms depending on which part of the problem they aim to solve. In the case of ROV, an AS can assert that it is authorized to originate routing advertisements to specific address prefixes. A Route Origin Authorization (ROA) contains a certificate, an AS number, and a set of prefixes that the AS is authorized to advertise. The ROA is cryptographically signed by an entity that is itself trusted to provide this authorization, generally the AS to which this address prefix has been allocated.

BGP is famously complex, security is hard to get right, and you never get to declare success

Address allocation is a hierarchical process. For example, a Regional Internet Registry (RIR) can allocate a chunk of address space to an ISP, and the ISP can sub-allocate from that chunk to one of its customers. A hierarchy of certificates can then be created to follow this hierarchy of address allocation. The RIRs form “trust anchors” from which chains of trust can be built, much the way a modern browser comes with a set of trusted root certification authorities (CAs) so that the certificates issued by web sites, which are signed by CAs, can be checked for validity.

The difference here is that we’re not certifying web sites, we are certifying address allocations. Address prefixes are the “resources” in the RPKI in this case. A chain of such certificates might proceed from the root (an RIR),  to a local Internet registry (LIR), then to an ISP. That ISP can certify that one of their customers has been allocated a certain prefix and may originate advertisements of that prefix in BGP.

Click to enlarge

One interesting aspect of the RPKI system is that it operates completely separately from BGP and requires no modifications to the protocol itself. Address allocation is quite low-churn compared to routing, so the RPKI doesn’t need the same sort of dynamic updates as routing. RPKI certificates are stored in repositories, which are run by entities such as RIRs, and there are RPKI protocols for retrieving and caching the contents of the repositories.

A router that participates in BGP can read the contents of the local cache and use that to determine a priori which ASes are authorized to advertise various prefixes. When that router receives a BGP advertisement, it can then see whether the originating AS matches what has been authorized in the RPKI.

Notably, there is no cryptographic computation performed at the time of BGP message processing, thus limiting the impact on core router implementation. You can find a readable description of how the RPKI and ROV work in practice here, complete with instructions on how to configure it in Cisco’s and Juniper’s BGP implementations.

Measurable progress

According to a tracking site run by NIST, of the one million-plus routes that are passed around by BGP in the Internet core, about 56 percent now have a valid ROA associated with them, with less than 2 percent invalid and the remainder (42 percent) “not known”, meaning there is no ROA for the relevant prefix. Whether this is a glass half-full or half-empty depends on your perspective. My view, especially given the continued growth of the valid percentage, is that this is a remarkable achievement to be celebrated.

Security is hard; changing the behavior of ISP routing (including the capabilities of Cisco and Juniper gear) is arguably harder. So making significant progress on backbone routing security feels to me like a real win.

While the big router vendors have added necessary features to their BGP stacks to enable ROV deployment, it is worth noting that the RPKI itself is largely being built out of open source components. This may be a factor that has eased the path to deployment.

ROV means that it’s no longer easy to hijack traffic to a prefix by simply claiming that you own that prefix, which has repeatedly been done both deliberately and accidentally in the past. But there remain plenty of ways to attack BGP that are not prevented by ROV, mostly entailing the advertisement of bogus paths. Over the last couple of decades there have been multiple efforts to address this rather harder problem by adding cryptographic signatures to BGP itself. The BGPsec standard applies cryptographic signatures at every AS along a path advertised in BGP. A BGP advertisement with K ASes in the path will have K signatures. Each signature covers the ASes in the path to this point and the target AS for this advertisement, thus ensuring that an AS can only add itself to an existing path if it was the intended recipient of the advertised path.

This prevents a reasonably large set of attacks, although still not by any means all. Furthermore, the cost is high compared to ROV, since now we have inserted multiple cryptographic operations into the processing and generation of BGP advertisements. 

ASPA actually catches some routing problems that are not caught by the more heavyweight BGPsec

As noted in “BGP Security in Partial Deployment”, the incremental benefits of all this cryptographic work compared to ROV are rather modest. And, as with ROV, there is a collective action problem, but it’s even worse for path validation. The first ISP to implement BGPsec pays the price of added complexity and upgrades to routers, while reaping essentially no benefits (since no-one else has yet implemented the same upgrades, which need to be in place on the entire path to be beneficial). Hence, BGPsec implementation is seemingly going nowhere (just like in 2014).

More recent efforts are focused on “AS Provider Authorization” (ASPA). Here is a helpful 2023 ASPA presentation from NANOG. ASPA shares an attractive property with ROV: no cryptographic operations are added to BGP itself.

Just as ROV builds a database (in the RPKI) of who is allowed to originate an advertisement, ASPA builds a database showing which ASes provide transit to other ASes. This, too, uses the RPKI, but with different types of certificates. Suppose you learn from ASPA that AS X is a provider for AS Y, and not vice versa. If you then start to see routes advertised where Y is claiming to be a provider for X, you know something is wrong and can drop the advertisements.

Interestingly, ASPA actually catches some routing problems (such as accidental leakage of routes) that are not caught by the more heavyweight BGPsec. It is early days, but the momentum seems to be favorable for this approach to catch on.

There is plenty more to say on this topic, which we will do when we finish off the book chapter. I am feeling more optimistic about the state of routing security than I was when I started this project. I’m impressed that ROV deployment has exceeded 50 percent and ASPA shows promise. It’s safe to say that we won’t ever get BGP to be completely immune to attacks and misconfigurations but there seems to be real progress in making it much more robust than it was just a few years ago. ®

Original Source