Home page logo

nanog logo nanog mailing list archives

Re: Fixing RFC's WAS Re: SMURF amplifier block list
From: "Alex P. Rudnev" <alex () Relcom EU net>
Date: Mon, 13 Apr 1998 16:42:15 +0400 (MSD)

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 () memra com>
To: nanog () 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
   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
         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 () 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)

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]