Network Operators and smurf

Rusty Zickefoose rusty at
Fri Apr 24 19:19:23 UTC 1998


Hi all,

	If were reading this list on a professional basis, we should be a
little clued, or at least attempting to get there.  We're in the big
leagues now, read up on CIDR, figure out classless subnetting.  To
advocate breaking legitimate routing because we, as an industry, don't want
to put in the time and effort to educate our end users is just a little

	Had to get that off my chest.  

	Anyway, it's been said here several times before, but I'll say it

	To end the smurf type exploits, we need to do 2 things.

1.  Routers/Gateways should be configured to prevent the transmission of
echo-request packets, out an interface, to a destination address identical
to the broadcast address of that interface, except in those cases where
specifically required. 

	This means getting vendors to give us a knob, and having it
default to off.

This is the easy one folks, figuring out net-masks aren't that hard.  The
transit providers might have problems with implementing this due to
hardware meltdown, but that's not where it needs to be implemented.

	!!Educate your (our) users!!

2.	Routers/Gateways should be configured to drop all packets with
invalid source addresses.

	This is a little bit more difficult, particularly if your
multi-homed, but again, it's not the transit providers that are need to
implement this, its the end user.

	once more

	!!Educate your (our) users!!

No. 2 has the benefit of fixing all manner of ills.

The problem is us.  This isn't a research network run and maintained by
the knowledgable.  This is a business.  We're selling a product, and if we
expect it to operate as advertised, it's up to us to educate those we sell
it to. 

This is Mr. Pot, saying so long to all you kettles out there.

- -- 
Rusty Zickefoose  |  The most exciting phrase to hear in science,
rusty at     |  the one that heralds new discoveries, is not
                  |  "Eureka!", but "That's funny ..."
                  |  -- Isaac Asimov

Version: 2.6.2


More information about the NANOG mailing list