This is the final post in my series on BGPSEC — I will probably follow this up, at some point, with a couple of posts on some alternatives to BGPSEC, and the larger issue of the evolution of BGP.
In this final post, I want to consider two types of leaks — route leaks and information leaks — and then wrap up this little series on BGPSEC. The first type of leak is a route leak, described in this expired draft from the GROW working group. Returning to our little network diagram…
Assume, for a moment, that AS65002 is actually a client of AS65000 and AS65003. In order to provide optimal routing, AS65000 and AS65003 both advertise a full default free zone (DFZ) Internet routing table to AS65002 (or even a set of partial routes and a default route will work). AS65002 fails to filter these routes correctly, and readvertises at least some of the routes it receives from AS65000 towards AS65003. Now AS65003 has a route to, say, AS65001 through what should be a nontransit customer peer.
Which route will AS65003 choose to reach AS65001? The route through AS65002. Why? Because service providers almost always prefer routes from their customers over routes learned from peers (see these two posts on service provider policy, part 1 and part 2, to better understand why this the way providers normally configure their policy).
The only way to resolve this problem is to somehow allow AS65003 to “see” AS65000’s policy towards AS65002, and to allow AS65000 to “see” AS65003’s policy towards AS65002. However — because this is an explicit policy implementation, BGPSEC’s designers have taken this problem off the table (see the slides here for an example of this statement).
What’s interesting about this statement is the “man in the middle attack” described in the slides, and earlier in this series on BGPSEC, is also, in fact, a policy violation issue, just a different variation of the same situation — and yet BGPSEC still claims to be a protection against this attack. That aside, however…
BGPSEC doesn’t have any mechanism to prevent this sort of route leak.
The second sort of leak we need to pay attention to with BGPSEC relates to the way the signatures are built and implemented. Again, referring back to an earlier post in this series, and to the slides linked just above, BGPSEC expects operators to build a certificate hierarchy within their AS. The AS itself receives a certificate from an RIR (or, potentially, some other authority). The operator generates a private/public key pair for each edge router (eBGP speaker) in its AS, and signs the public key of the pair using the private key from the certified assigned by some outside authority. These individual router keys are then, in turn, used to actually sign the updates. The figure below illustrates, just for clarity.
If you’ve been paying attention, the first thing that should cross your mind is — the database of certificates I need to look through to validate any given route just increased by at least 100 fold… If every router signs every route with a different certificate, then you need to not only find the AS through which the route passed, but also the router through which the route passed. This adds a huge amount of complexity to the processing of BGP updates.
But there’s another problem hidden here that’s not so obvious. If each eBGP speaker uses a different certificate, I can now map out every eBGP speaker in every AS in the entire world. Not only have you given me a massive new DDoS attack vector by piling a ton of processing onto the BGP protocol, you’ve also handed me a map of every eBGP speaker in the Internet, and how to reach them. Very nice.
It’s actually worse than this, though (or worser, as some of us southern folks like to say). For not only do I now know about each eBGP speaker in every AS throughout the entire Internet, I also know what they’re connected to — in other words, I not only know that AT&T is peering with Level 3, but also how often, and what other providers are connected at those same peering points. I can effectively build a map of every peering point in the entire Internet with this kind of information.
So, in the end — from my perspective, at least — BGPSEC creates problems that are worse than what it was designed to solve.
- Carrying updates is much slower because of the added data.
- Carrying updates is yet even slower because of the removal of the internal compression technique BGP uses today.
- Processing updates is much slower because I must validate a cryptographic signature for each AS hop in the AS Path.
- Processing updates is yet even slower because I must consult a database containing a signature per eBGP speaker in the entire Internet.
- I’ve exposed the entire structure of peering points throughout the Internet.
- I’ve exposed the entire infrastructure of the Internet to DDoS attacks against processing overloads through bogus signatures.
So, what are our alternatives? More on that later.