Re: resistance to swamping attacks.

Robert Moskowitz <rgm3@chrysler.com> Fri, 20 September 1996 11:59 UTC

Received: from cnri by ietf.org id aa24727; 20 Sep 96 7:59 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa07622; 20 Sep 96 7:59 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa21468; 20 Sep 96 7:31 EDT
Date: Thu, 19 Sep 1996 17:24:26 -0400
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>, ipsec@tis.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: resistance to swamping attacks.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609200725.aa21463@neptune.TIS.COM>

At 12:30 PM 9/19/96 -0400, Bill Sommerfeld wrote:
>
>There have been a number of press reports about swamping attacks on
>TCP using forged source addresses.  Some of these press reports have
>suggested that IPv6 will solve all this by requiring authentication.
>
This is from the End-to-End list:

Date: Wed, 18 Sep 1996 14:32:14 -0600
From: vjs@mica.denver.sgi.com (Vernon Schryver)
To: end2end-interest@ISI.EDU
Subject: SYN bombing defense
Sender: owner-end2end-interest@ISI.EDU

As reported here, in article <vxjiv9hkmcb.fsf_-_@dominator.eecs.harvard.edu>
in comp.protocols.tcp-ip, Robert Morris  <rtm@dominator.eecs.harvard.edu>
wrote:

>Perhaps TCP's listen queue should use random early drop (RED), a
>technique used by routers to prevent any one source from monopolizing
>a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or
>rfc1254.
> ...

I've just hacked IRIX 6.3 to do random-drop when sonewconn() in
tcp_input.c fails.  It works great!  An IP22 receiving 1200 bogus
SYN's per second directed to port 23 continues to answer requests
for new telnet as if nothing is happening.

I don't think that random <<Early>> drop is necessary or desirable.
It is not as if we're trying to drop packets early to trigger
slow start in the sources.

As I figure it, as long as the length of the queue is longer than RTT
of the real telnet client times the rate of bogus SYNs, the real
clients have an excellent probability of getting through on their
first attempt.  For example, at 1200 bogus SYNs/sec and the IRIX 6.3
telnet listen queue of 383, there should be no trouble with peers
with RTT up to about 300 milliseconds.  I've tested with a telnet
client 250 milliseconds away while simultaneously bombing the machine
from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions.


Vernon Schryver,  vjs@sgi.com



Robert Moskowitz
Chrysler Corporation
(810) 758-8212