Securing BGP: we can do it!

▼ In this month's edition of The ISP Column Why is Securing BGP just so Damn Hard? Geoff Huston asks himself exactly this question. He lists ten reasons. I don't agree with most of them: this is a solvable problem.

I think Geoff's main point is that BGP allows for arbitrary policies, which may lead to conflicting policies in different ASes and non-deterministic results.

And then, should we come up with new security mechanisms, it's hard to get them deployed because the business case for security (or business continuity in general, see IPv6) is hard: you need to spend money to keep what you already have.

So basically, BGP gives operators too much rope so they may end up hanging themselves. Interestingly, BGP's predecessor EGP was made to explicitly support the then (early 1980s) existing topology of the internet/ARPANET: a central backbone that all networks connect to in some way. In the early 1990s, the US government wanted to get out of the business of running the internet backbone, and BGP, which was created around that time, no longer makes any assumptions about the structure of the network.

This allows for conflicting policies, such as A trying to reach C through B, while B is trying to reach C through A. Obviously A and B can't both get what they want at the same time here.

Another ten years later, the work by Lixin Gao and Jennifer Rexford showed that if all networks apply a set of simple BGP policies that encode four different types of (business) relationships between networks, then BGP will reach a stable state. Hence their aptly titled paper Stable internet routing without global coordination.

Finally, in recent years we've realized that many unintended internet routing disruptions (route leaks) are caused by networks failing to properly translate their business relationships into BGP policies. See RFC 7908 types 1 - 4.

If we were to create BGP from scratch today, it would make sense to have baked-in policies for the four possible relationships between networks rather than expect every network operator to reinvent the wheel. The protocol can then check whether both sides of a BGP session agree on the type of relationship and alert the operators if that's not the case rather than let bad things happen. This would take care of most accidental route leaks.

However, that's not the BGP we have today. So what we need to do instead is detect those route leaks and filter out the affected routing information, see my blog post on fixing route leaks for an idea on how to extend RPKI to do this. With such an extension in place, RPKI can fix all six types of route leaks mentioned in RFC 7908.

That leaves the intentional BGP hijacks, that manipulate the BGP AS path to avoid the RPKI checks. BGPsec can fix this, but unfortunately that protocol is very heavy weight and it doesn't provide many benefits in partial deployment, so it's hard to see how the whole internet is going to adopt BGPsec.

But as more networks apply stringent (extended RPKI-based?) checks, there will be fewer and fewer places where rogue networks will be able to inject false AS paths and get away with it. Contiguous parts of the internet that perform these checks will thus be protected. That last part is crucial, because "boil the ocean" type solutions, which require the entire internet to adopt the solution before we gain any benefits, are a non-starter.

However, there is one last thing we should look at: rogue networks connecting to other networks using another network's AS number. That's a hefty investment in time and money for an attacker to be able to inject false information into BGP, but with other avenues closed this could start happening.

In conclusion: after more than two decades of experience and research, we understand BGP much better and we have a good idea of what needs to be improved. RPKI is a relatively successful example of a BGP security mechanism, while BGPsec is an example of something that's on the one hand too ambitious and on the other hand doesn't fix any immediate problems (i.e., route leaks). So I think we're in a good position to improve BGP security significantly over the next few years.

Permalink - posted 2019-09-20