Smurf tone down

R.P. Aditya aditya at dnai.com
Sat May 1 06:49:39 UTC 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 <Pine.BSF.4.05.9905010211070.5195-100000 at iago.nac.net>, alex at nac.net 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, alex at nac.net, 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
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 
> 




More information about the NANOG mailing list