Fixing RFC's WAS Re: SMURF amplifier block list

Mon Apr 13 12:42:15 UTC 1998

Anyway, does there exists some proposals about adding trace capability to 
the routers? I mean - I'd like to ask the chain of routers _who does 
generate the packets with the SRC address A1 and DST address A2.

Remember, the smurf problem was caused not due to amplification of the 
traffic but because the intruders are not traced usially.

On Sun, 12 Apr 1998, Michael Dillon wrote:

> Date: Sun, 12 Apr 1998 19:21:20 -0700 (PDT)
> From: Michael Dillon <michael at memra.com>
> To: nanog at merit.edu
> Subject: Re: Fixing RFC's WAS Re: SMURF amplifier block list
> 
> 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
>    UCLA  http://www.math.ucla.edu/misc/smurf.html
>    or Simon Fraser University
>    http://www.cs.sfu.ca/CC/Hypermail/cmpt-471/0008.html
>    or the RFC archive at USC's Information Sciences Institute
>    ftp://ftp.isi.edu/in-notes/rfc2267.txt
>    or the Computer Emergency Response Team at Carnegie Mellon University
>    http://www.cert.org/advisories/CA-98.01.smurf.html
> 
> 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
>          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
> elsewhere. http://www.ietf.org
> 
> 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: michael at memra.com
> 
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)