Fixing RFC's WAS Re: SMURF amplifier block list

Michael Dillon michael at
Mon Apr 13 02:21:20 UTC 1998

On Sun, 12 Apr 1998, Forrest W. Christian wrote:

> My opinion is that we need to fix some RFC's to help eliminate the SMURF
> problem and other problems.

Look closely. I already posted this mentioning RFC 2267

   If anyone at an educational institution tells you that send them to
   or Simon Fraser University
   or the RFC archive at USC's Information Sciences Institute
   or the Computer Emergency Response Team at Carnegie Mellon University

Here's an excerpt from a message I posted to another list with a good URL:

> I'm STILL lost.  How am I going to "localize the effect" of my downstream -
> who have not set "no ip directed broadcast" - being used as a SMURF
> amplifier?  As for helping them fix it, how does that relate to "DEMANDING"
> the upstream fix the upstream's config?

Here is a URL with some info      

Here is what I mean.
                        -------------*-*-*-*- * - * - * * the void... :-)
 FFF    UUUUU   OBOBOB  |   F = Fred's Network
 FFF----UUUUU---OBOBOB--     P = Patrick's Network
 FFF    UUUUU   OBOBOB     U = Upstream provider for Fred and Patrick
          |        |       OB = Other Backbone provider
         PPP      VVV      V = Victim of the Smurf attack
         PPP      VVV
         PPP      VVV

Now some mean guy out there in the void decides to attack the poor victim
network by sending spoofed source packets to the broadcast address of
Fred's network. The spoofed source address is that of the victim so that
all the echo replies from the machines on Fred's network go to the
victim's network.

Now why should Patrick care? Why should he be demanding that his upstream
do something about it? Because if the Upstream does nothing, people out
there on the net may well start to block all of Upstream's address blocks.
So Patrick can demand that his upstream take action to make sure that no
SMURF amplifiers are downstream of them. Patrick has no business
relationship with Fred but both have a business relationship with the
Upstream. The Upstream could remind Fred that he must fix his routers
according to their TOS or AUP. Or they could help Fred fix his routers.
Or they could disconnect Fred. Or they could block all traffic to
?.?.?.255 in Fred's network. In fact, Upstream could regularly scan all of
its address space to find misconfigured routers and help them fix this
problem. If you have some time for code hacking maybe you could hack smurf
or fraggle to create a program that does this.

> Is there a review of the Router and Host requirements RFC's in the works?
> Specifically, to review those areas which could be changed to fix some of
> these problems.

RFCs take a long time to change, especially standards track RFCs. But it
isn't that hard to get an informational RFC like 2267 published.

> For example, the directed broadcast stuff should be written to basically
> say that the DEFAULT must be for the directed broadcasts to be off.

There are no guns in the IETF. Basically the RFCs should say exactly what
they do say because that's the best consensus that people could reach.
Maybe you could convince them to revise the RFC but you'll need to fully
understand the entire scope of the protocol design, not just current
operational issues. But that's something that needs to be discussed

Might be worthwhile for someone to spend a half hour explaining the
directed broadcast issues at the next NANOG meeting?

Michael Dillon                   -               Internet & ISP Consulting             -               E-mail: michael at

More information about the NANOG mailing list