[8829] in North American Network Operators' Group
Re: In case anyone hadn't seen this
daemon@ATHENA.MIT.EDU (John W. Stewart III)
Fri Apr 25 17:07:54 1997
To: Pierre Thibaudeau <prt@teleglobe.ca>
cc: Enke Chen <enkechen@cisco.com>, nanog@merit.edu
In-reply-to: Your message of "Fri, 25 Apr 1997 16:14:38 EDT."
<Pine.HPP.3.94.970425154421.27852C-100000@alpha.Teleglobe.CA>
From: "John W. Stewart III" <jstewart@isi.edu>
Date: Fri, 25 Apr 1997 16:31:26 -0400
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
>
>
>