> > Crypto = more overhead. Less priority to crypto plus DDoS = routing > > update issues. > > I don't think there's an update issue here. The crypto verification is > probably > going to be deferred in addition to being low priority. If I understand it > correctly, this means that a route can be passed along right away without > waiting for the crypto checks.
I don't think this quite fits with Postel's law... There's also the size of the table and the ability to pack (compress) the information to consider. > > One can infer peering relationships in a way not possible before. > > How? The keys are per router, not per AS. You could use a single private/public key pair across the entire AS -- but that's not good security hygiene. There's no way to sign an update without exposing the signer; if you sign at anything below the AS level, you're exposing new information. What about the per NLRI timer? The timer is essentially the amount of time you'd like someone to be able to advertise a route once the peering session is broken. How long are you comfortable with someone advertising your routes after you've taken down your peering with them? What's the performance impact of forcing every route in the table to expire, say, every 24 hours? Given your cost of setting your timers to a few minutes or hours is nil (you're transferring the cost of your increased security onto "everyone else"), why not set it lower? Tragedy of the commons? I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying it's is too heavyweight given the tradeoffs, and that we probably started with the wrong questions in the first place. What's needed is to spend some time thinking about what questions really need to be answered, the lowest cost way to answer those questions, and a complete examination of the tradeoffs involved. Is "what path did this update travel," or "are the BGP semantics being properly followed," really questions that want asking? Or are there other, more pertinent questions available? :-) Russ
