Solution: Re: Huge smurf attack

Craig A. Huegen chuegen at
Tue Jan 12 15:41:35 UTC 1999

I think it's time to do a technical refresh for those of you
who think routing, 10/8, 172.16/12, 192.168/16, etc. to
null0 will solve the smurf problem.

Not so.

Routing in the Internet is done on a DESTINATION basis.

The reason you see and/or devices
in a smurf is that many times there are IP-capable network
devices never configured within some networks which will
respond with their default IP address ( or

I have  Let's say I put some manageable hub
on the wire, but never configure it -- its default IP address
remains at  Remember that the spoofed echo-request
packet is sent to  If directed broadcasts are
on, the router sending the packet onto the wire will send it
to the broadcast MAC address.  Because it was a broadcast, this
device then responds to the originally spoofed source address,
with a *source* IP address of  Unless you're using a
feature such as unicast RPF checking, a router doesn't care
what source address you're using -- it gets the packet to its

RFC 2267 gives informative guidelines on how to configure
networks to prevent source-spoofed addresses from exiting the
network.  This has limited scalability, though, as you move
closer to the core -- as you stack a few service providers
together, it gets pretty difficult to manage those filters.

Unicast RPF-checking is a very good way to automatically filter
source spoofs; however, it only works at the edge of the network,
because multi-homing can cause traffic to be dropped if this
check is enabled in the wrong place.

Now, with that said, I agree that providers should be filtering
routing announcements, whether it be through static routes or
distribute-lists; however, it will not keep packets with source
addresses of or from being delivered to you.


On Mon, Jan 11, 1999 at 08:23:44PM -0800, Dan Hollis wrote:
==>On Mon, 11 Jan 1999, Daniel Senie wrote:
==>> > Then we need to re-classify having an open broadcast amplifier as an
==>> > abuse.  If we can get upstreams and backbones to give a formal 30 day
==>> > notice, then start cutting lines ...
==>> I think this could easily be classified as abuse or abuse through
==>> negligence (reckless endangerment?). Provider contracts should specify
==>> that downstreams must deal with ingress filtering and must ensure their
==>> networks will not respond to directed broadcasts from outside.
==>Speaking of negligence, I am disappointed at the backbones who continue to
==>route rfc1918 addresses, and wacko addresses like and
==>It is REALLY all that much to ask you guys to null0 route these networks?

More information about the NANOG mailing list