|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: In case anyone hadn't seen this
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: <[email protected]> > TELEGLOBE CANADA | > 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257 > Montreal, QC H3B 4X5 | > Canada | fax: +1-514-868-8446 > > > - - - - - - - - - - - - - - - - -
|