my point is that right now authentication is mntner-based and most access-list generation depends on an as-macro. so what's to stop me from changing my as-macro to contain a few thousand ASs and then config'ing my router to announce a zillion prefixes? filtering as we know it today doesn't protect against this .. the upstream provider would have to manually intervene. even if the access-list generation depended on as-in/as-out policy instead of just as-macros, and the tools had some knowledge of what ASs were downstream to allow for AS-path filtering as well as prefix-based, then i could still just register zillions of prefixes with appropriate origins and config my router to announce those zillions of prefixes with appropriate AS-paths all i'm saying is that parts of the system are fragile and registries can't be viewed as a silver bullet /jws
On Fri, 25 Apr 1997, John W. Stewart III wrote:
> The solution to this problem is filtering, which has been known for > a long time. > > The provoders that have been filtering on the customer edge seem to > have done much better in terms of providing sanitized routes. I am > wondering how many such major outages need to occur in order to > convince some providers to do customer filtering?
i'd argue that filtering is protection against misconfigurations. in practice, the way that filtering is done, it does not protect us from malice; hopefully such attacks would be short-lived because the immediate provider(s) would cut the person off, but even short problems on the scale we're talking about are serious. fortunately most of the wide-scale attacks we've seen have not been within the routing system itself (though some have pounded its infrastructure .. e.g., the low UDP port number attack), but there's always that possibility. in order for filtering to protect us from malicious attacks within the routing system we need a lot more in the way of authentication for registries and tools built on top of them
Using the of RAWhoisd extended queries(*) it is very easy to build an accurate access list and an as-path filter as well.
(*) see http://www.ra.net/RADB.tools.docs/rawhoisd.8.html
It is equally simple for anyone having access to a router receiving the full BGP table to check the consistency of informations found in routing registries with the actual BGP entries *before* putting a new access list in action.
Nothing else is required to inject sound routing information in the BGP mesh.
of course that means a lot of work, so people have to first recognize how fragile some of this stuff is. today's excitement is a very good example of that fragility
to be clear, i am a fan of registries and filtering as they are currently used .. there is no alternative other than chaos. i just think it's a mistake to think that filtering as we know it now is equivalent to a necessarily robust routing system
All sorts of malicious attacks can give us headaches, but BGP annoucements, is just like crossing the street: carefully watch for what is already there and you will be safe.
/jws
__
Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA> TELEGLOBE CANADA | 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257 Montreal, QC H3B 4X5 | Canada | fax: +1-514-868-8446