North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Fixing RFC's WAS Re: SMURF amplifier block list
- From: Michael Dillon
- Date: Sun Apr 12 22:54:11 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 http://www.quadrunner.com/~chuegen/smurf.cgi
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
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
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
http://www.memra.com - E-mail: email@example.com