North American Network Operators Group

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

Re: dsl providers that will route /24

  • From: Greg A. Woods
  • Date: Fri Mar 30 02:07:12 2001

[ On Thursday, March 29, 2001 at 19:46:44 (-0800), Steve Noble wrote: ]
> Subject: Re: dsl providers that will route /24
>
> Other then software limitations, routers and switches which can't handle
> this kind of load, the inability to always know what packets are spoofed.

Well, some can, actually.  There are even machines designed almost
specifically for this kind of thing, though I'm not sure if you could
deploy them cost effectively.  The Juniper folks laughed at me for being
so pessimistic to even question their ability to do such filtering at
wire speed (though I guess I'll see in real life real soon :-).  Of
course connecting a Juniper at the edge is a rare thing, and even the
one I'll get to play with isn't going to stay there long....

> Now that's a very broad statment that's just not true.  There are reasons
> that packets with a source address not assigned to an ISP may come across
> the link and be valid, look at DirectPC.

>From what I know of DirectPC the end user must dial into a provider
that's made arrangements for their access to DirectPC ergo the user's
packets are not spoofed in that case.

Any other bad/broken/incorrect examples to show us?

> Past that if the customer has customers who have blocks assigned from other
> providers, this becomes a huge and almost impossible to manage real-time
> list.

If the customer is another ISP who has blocks assigned from one of their
other upstream providers and they're sending the wrong packets down the
wrong pipes then they've got their routing all messed up and they need
to fix it anyway.  The sooner you block their packets and make them see
the error in their ways the sooner their performance and reliability
will return to the levels it should be at and the happier they'll be.

>  Big filter lists hit router cpu's, and cost human time.

Big filter lists?  How many connections do you have on any given edge
router?  How many network blocks are assigned to those customers?  I'll
bet when you do the math it's not that big of a list (relatively
speaking).  How many packets per second do your edge routers handle
anyway?

As for CPU time, well demand better from your hardware vendors.  Given
what's available now (and been available for some time now), there's no
excuse for a router doing such basic filtering in it's main CPU any
more.  Like I said too you might even be able to justify separate
wire-speed filter boxes to sit just in front of edge routers too (I
don't know -- I've no idea how the costs work out vs. the costs of
managing spoof-based DoS attacks).

>  And remember
> this isn't like filtering BGP customers where if the route doesn't get 
> through it's not always a big deal, you are _dropping_ packets that may
> be valid.

No packet with an invalid source address is valid.  Period.  That's the
definition!

> I'm guessing you talk to a lot of router vendors and listen to their
> half-truths about their filtering abilities.  It's one thing to filter
> one customer, it's another to filter hundreds of customers utilizing
> hundreds or thousands of blocks on a single device,

Given the numbers you spout I think you're talking core here.  I'm
talking edge.  Any edge provider that's got a customer with hundreds or
thousands of netblocks has that customer connected at the wrong place.

> just the looking 
> at the configuration becomes a nightmare.

What, don't you have a provisioning system that would automate this kind
of thing?  If not and if it's a nightmare then you're well beyond being
in dire need of having a real provisioning system!

>  Also there's a big difference
> between an edge device pushing a few megs and one pushing many gigs
> when it comes to any type of packet filtering. 

Ah ha!  You are talking core.  I never suggested trying to do any
filtering in the core.  The filtering must be done at the edge!  Why do
"you people" keep jumping to the wrong assumptions?!?!?!?!?

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <[email protected]>      <robohack!woods>
Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>