In my last post on the subject of BGPSEC, I explained the basic operation of the modifications to BGP itself. In this post, I’ll begin looking at some of the properties — both good and bad — of these extensions to BGP. To being, we’ll look at the simple network illustrated here, and see what BGPSEC gaurds against.
Assume, for a moment, that AS65003, on the far right, originates a route for some network, say 192.0.2.0/24. For policy reasons, AS65003 advertises this destination to AS65001, in the top center of the diagram, and not to AS65002, in the bottom center of the diagram. AS65001, in turn, advertises 192.0.2.0/24 to AS65000, on the far left.
The owner of AS65002, however, would like to transit traffic to 192.0.2.0/24 for some reason — why isn’t really important. It could be that someone in AS65002 would like to monitor this traffic, or attempt to launch a man in the middle attack against the flow, or perhaps they would just like to disturb the peering relationship between AS65001 and AS65003 by diverting traffic off the connection in a way that causes AS65001 financial harm. In the “natural state of things,” AS65002 can originate a new advertisement with the AS Path [65003,65002], and advertise it towards AS65000. From AS65000’s perspective, this advertisement would look no different than a real advertisement. Traffic drawn from AS65000 by AS65002 could then be forwarded on to AS65003, or it could even be black holed.
If, however, BGPSEC were in operation on this network, the “false advertisement” built by AS65002 could not be built with a valid signature across the AS Path. In theory, then, AS65003 could compare the two advertisements, one from AS65001 with a fully signed path, the other from AS65002 with no signature, and prefer the fully signed path over the unsigned path — thus thwarting AS65002’s attack.
There are several points worth noting here, however. First, this isn’t really an attack in the traditional sense — on the actual traffic flowing between two hosts directly. Rather, it is an attack on AS65003’s policy of not using AS65002 for transit. Whatever the reason for this policy, an attack on a peer’s policy isn’t quite the same thing as an attack on the actual traffic flowing between two hosts, either in scope or in detail. The path traversing AS65002 is, in routing terms, a valid path — it is loop free, and it actually reaches the destination. If the traffic being intercepted by AS65002 is protected through some form of strong encryption (as it should be), then redirecting the traffic no more exposes information than non-redirected traffic.
Let’s leave these objections over terminology aside, though, and consider another set of problems. What if BGPSEC isn’t fully deployed in this network? For this to work, every router in all four autonomous systems must be running BGPSEC, and every route towards 192.0.2.0/24 AS65000 receives must be signed other than the one transmitted by AS65002. Without this, the entire scheme collapses, as there is no way for AS65003 to determine what the lack of a signature actually means. Does it mean there’s a router or AS along the way that doesn’t support the signatures? Does it mean the router that should have signed the AS Path attribute is not doing so because of some defect, or because it’s currently overloaded, and not processing these signatures? Does it mean the route is incorrectly advertised? There’s no way to know because there’s no direct communication line between AS65003 and AS65000. Any system that relies on transitive trust of this sort is susceptible to Byzantine attacks — there are no known defenses against these types of attacks.
Or perhaps the path through AS65002 is so much better than the path through AS65000 that AS65000 would naturally prefer that path if it were available. What incentive does AS65000 have, in this case, to follow the signed path rather than the unsigned one? Should AS65000 sacrifice its local policy, designed to provide the highest return possible on its operations, for the sake of AS65003’s peering arrangements with AS65001?
So BGPSEC does provide a way to insure an AS doesn’t randomly generate an advertisement for a destination it hasn’t received a route for — what is commonly called a “man in the middle” attack by those who work on BGPSEC.
Next week we’ll look at replay attacks and performance.