North American Network Operators Group

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

Re: Smurf tone down

  • From: R.P. Aditya
  • Date: Sat May 01 02:51:41 1999

Alex,

I've asked our transit providers to do this, and one out of three is CARing
ICMP.

One said, sorry, can't do it on our router for "technical reasons" (think very
large national provider).

Another said, since we have lots and lots of customers (implying that there is
no "normal ICMP flows" level), and we're carrying it over our network to you,
your router might as well do the work of discarding the packets (think very
savvy colocation provider).

To attack the problem in a different way, why aren't more providers (esp. the
colocation providers) using RPF on the edges? There seems to be a general
feeling that RPF is broken (bugids please? operational experiences with
routing/network diagrams) -- yes, it can't be used everywhere (ie. not on
core/backbone routers), but then again, it shouldn't. Yet, it has very good
use at the edge.

Adi

In message <[email protected]>, [email protected] writes:
> 
> 
> Hello,
> 
> To help quench the effects of smurf attacks on our network, we CEF-CAR all
> ICMP on our egress points to about 200% of normal ICMP flows.
> 
> However, when a upstream becomes full of ICMP (even though we dump most of
> it), it still affects our external connectivity.
> 
> My question is, why don't larger upstream providers use CEF-CAR (assuming
> that most use this) do the same to limit the effect of smurf attacks on
> thier (and subsequently, thier customers') networks?
> 
> The floor is open for flames.
> 
> 
> 
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>      Atheism is a non-prophet organization. I route, therefore I am.
>        Alex Rubenstein, [email protected], KC2BUO, ISP/C Charter Member
>                Father of the Network and Head Bottle-Washer
>      Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834
>  Don't choose a spineless ISP; we have more backbone!  http://www.nac.net
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 
>