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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf