North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: No one behind the wheel at WorldCom

  • From: Frank Scalzo
  • Date: Mon Jul 15 09:01:12 2002

The problem with doing that is you do not get fine grained control. You
can only say only send me 50k routes, and things not from other peers.
The really nifty part about prefix-limiting your peers is when they
deaggregate toward you, you drop all your bgp sessions to them at once,
completely depeering. You still cannot prevent announcement of weird
routes like 63/8. Do not be fooled into believing that just because a
network is big they know what they are doing. Some of the 63/8
announcements I have seen came by way of sprint. Let's step back and
think about this on a security front, anyone with access to a tier 1
ISPs router can dos anyone in the internet, just by throwing in a null
route for the block that is more specific then the one they have
advertised. Granted not easily done, but just the same I like to be the
only one who can break my network.

Unfortunately Majdi is correct, we do not have sufficient functionality
in today's routing software to fix the problem. Oh well I guess it has
worked for this long.

-----Original Message-----
From: Stephen J. Wilcox [mailto:[email protected]] 
Sent: Monday, July 15, 2002 8:39 AM
To: Majdi S. Abbas
Cc: Frank Scalzo; [email protected]
Subject: Re: No one behind the wheel at WorldCom

There are different types of filter tho and I'd suggest they are
suitable in
different circumstances.

eg 
small peer < 100 prefixes - build prefix filter list, as path list
middle peer - either depending on requirement (eg cust, peer)
large peer > 1000 prefixes - as path filter plus max prefix

I'm not implementing the above so the numbers and suggestions are a
little
arbitrary but I'm making the point that you can filter smaller peers who
are
less experienced and more likely to give an error and for larger peers
you have
to be less granular but can still impose failsafes without increasing
CPU.

Steve


On Mon, 15 Jul 2002, Majdi S. Abbas wrote:

> 
> On Mon, Jul 15, 2002 at 01:58:44AM -0400, Frank Scalzo wrote:
> > See now we are back to the catch 22 that is IRR. No one will use it
because 
> > the data isnt there, and no one will put the data into it because no
one 
> > uses it.
> 
> 	[CC: list trimmed]
> 
> 	Actually, I think you'll find that bad data is only a small part
> of the problem; even with good data, there isn't enough support from
> various router vendors to make it worthwhile; it's effectively
impossible
> to prefix filter a large peer due to router software restrictions.  We
> need support for very large (256k+ to be safe) prefix filters, and the
> routing process performance to actually handle a prefix list this
large,
> and not just one list, but many.
> 
> 	IRR support for automagically building these prefix lists would
> be a real plus too.  Building and then pushing out filters on another 
> machine can be quite time consuming, especially for a large network.
> 
> > I think the way to get IRR into the real world production realm, is 
> > to really drive home the issue w/IPV6.
> 
> 	This still doesn't solve the scaling issue.  This is no
different
> than running your own RR, which many ISPs already do -- and they still

> have to exempt many of their peers.  Typically, RR derived prefix
filtering
> is something reserved for only their transit customers.
> 
> 	If it were that easy, everyone (well, some people) would be 
> doing it.
> 
> 	--msa
>