ietf
[Top] [All Lists]

Re: Security of BGP Re: Status of the 16-bit AS Number space

2009-05-26 10:12:30
On 25 mei 2009, at 19:34, Phillip Hallam-Baker wrote:

But I think we need to restate the problem. We don't need to prove
that the information is valid so much as determine whether it is
likely to break things or not.

Not simple. One approach that seems attractive is to still allow routes that don't pass the authentication steps, but prefer ones that do by giving them a higher local preference. Ideally, we would reject routes that don't authenticate, but the problem with that is that today, none do, so at the very least there needs to be a transition period. But we all know what happens to transition periods... If we can get around that there's the issue of different kinds of failures in the authentication chain. People forgetting to install new certificates before the old ones expire is rather common. If that breaks your network, good luck getting that new certificate. But the "prefer authentic over unprovable" mechanism still has the issue that an attacker can inject false information and then do a DoS against the authentic information so eventually, the false information is used.

This looks much more like a spam filtering type problem to me than
pure access control.

I really don't want false positives in my route filtering...

So a first cut we might make on the data is to identify route
advertisements that are within previously established 'normal' bounds.

But how do you accommodate for normal failure conditions that routing should solve in that case?

Having reduced the volume of routes to those that represent
'surprises' we have a problem that cannot be solved for the individual
route announcement in isolation. Like the spam problem we can only
evaluate routes by bringing in additional information to bear.

Today, RFC 4271 tells us:

   The function that calculates the degree of preference for a given
route SHALL NOT use any of the following as its inputs: the existence
   of other routes, the non-existence of other routes, or the path
   attributes of other routes

So in summary, I think that to solve the BGP issue we need to look up
the stack as well and work out methods that allow for reliable
reporting of attack conditions.

I don't have all the answers, but it seems to me like the model that would be most appropriate for BGP would be more like SSH (everyone manages their own trust) and a PGP web of trust than a root-anchored PKI.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf