Let’s return to our simple four AS network to look at a number of issues with BGPSEC — the bits you won’t often hear discussed in just about any forum.
Assume, for a moment, that AS65000 advertises some route, say 192.0.2.0/24, to AS65001, and not to AS65002. For whatever reason, a few days pater, the folks who run AS65000 change their mind and decide to withdraw the route from AS65001, advertising it through AS65002 instead. At the time of withdrawal, AS65001 still has a route advertised by AS65000 with valid signatures, so it can continue advertising 192.0.2.0/24 towards AS65003, and AS65003 will continue to believe this route is valid (it is properly signed and attested, including the AS Path signatures attached through BGPSEC along the path). The basic problem is there is no authenticated withdraw in BGP. In fact, there’s no way for AS65003 to determine what withdraws AS65000 has sent to any of its peers — and why would there be? BGP is founded on the concept of transitive trust in an open environment. The only information you have, in a path vector protocol, is what your peers tell you about (much like a distance vector protocol).
How can AS65000 stop AS65001 from advertising 192.0.2.0/24 towards AS65003? There aren’t any easy answers here — the one BGPSEC has settled on is to include a timer in the BGP update. The originating AS sets a timer in any updates it originates that tells downstream AS’es how long the update is good for. Suppose AS65000 sets the timer to 24 hours — AS65001 is limited to replaying the still valid advertisement that AS65000 has withdrawn for 24 hours. Whether or not this is acceptable is up to AS65000 — if a shorter time is desired, then AS65000 can simply originate the route to 192.0.2.0/24 with a shorter timer.
Or… Maybe not. Let’s look at the side effect of such a shortened timer. If the timer on every route in the Internet is set to 24 hours, then every route in the Internet must be refreshed at least once every 24 hours. If there are 500,000 routes in the default free zone (DFZ), this comes out to a steady update rate of around 6 updates per second. 24 hours a day, 7 days a week, 52 weeks each year, every router participating in the DFZ will — if every AS sets their valid time to 24 hours — receive 6 updates per second. Note that each of these updates is signed, and hence takes quite a bit more processing than existing BGP operation (more on this in a future post), and you quickly get the sense of what this means.
Remember that it’s not the number of routes that matter — you can push thousands of routes into a link state protocol, so long as they are all at the edge of the SPF tree. What matters is the rate of change times the amount of work required to process each change. The base level of work due to timers becomes, in effect, a multiplier on real work due to topology changes.
This leaves anyone who deploys BGPSEC in a difficult dilemma — do I configure my timers to do what’s best for the Internet, or do I configure them to reduce the impact of replaying old, valid, signed routing information? I can either do what’s good for the community, or I can do what’s good for me and my business.
And here we run smack into the tragedy of the commons. We all know what providers will do in this situation — they will find the smallest number the “community at large,” will accept, the lowest number they will not be “shamed” for, and stick with that number. There’s no way to deduce what that number will eventually be, nor what the final impact on the performance of BGP will actually be.
Next time, we’ll talk about the second performance problem hidden in BGPSEC — those signatures.