> From: Barney Wolff <barney(a)databus.com>
> To: nanog(a)merit.edu
> Cc: vjs(a)sgi.com
(note that I'm not on the nanog mailing list)
> Ok, I'm confused. Quoting from Vernon's message:
>
> > Date: Wed, 18 Sep 1996 14:32:14 -0600
> > From: vjs(a)mica.denver.sgi.com (Vernon Schryver)
> > Subject: SYN bombing defense
> >
> > 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.
> > ...
> > 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.
>
> Because the queue is always full, you must have been doing 1200 random-
> drops per second, also. A telnet client 250ms away is therefore on
> average exposed to 300 random-drops, each of which has a chance of 1/383
> of killing it. Its probability of survival is (1-1/383)^300, or .456,
> not so good. It would be different if it were oldest-drop, but random-
> drop is what's stated.
>
> Lacking evidence, I won't argue with the experimental finding that the
> problem goes away - but if so, what's wrong with my computation?
I don't see anything wrong with your computation.
In subsequent experiements I did see losses consistent with that
computation, varying the SYN rate R between 100 and 2700 SYNs/sec and
the RTT between <10 and 500 ms. I don't know why I didn't see any
losses in my first experiments. It's hard (and boring) to test the
((L-1)/L)^(RTT*R) formula, but it seems to fit. I guess I should have
written a program to mechanize the testing.
>From what I've been told, the bombing rates have been what you would
expect from a v.34+v.42+v.42bis modem or a single B channel without
compression, 100-150 SYNs per second, instead of what you can get over
a single B channel with compression, 300-500 SYNs/sec.
At R=100 SYNs/sec, RTT=250, and L=382, ((L-1)/L)^(RTT*R) = 93%, which
is not so bad. Drop-oldest is better with those three numbers, since
it works 100% (modulo ordinary problems), but its performance falls off
the cliff to 0% at R=L/RTT. If you have a short queue and care about
long RTT's, random drop is better than drop-oldest.
Since the weekend, I've been pushing code that switches from
drop-oldest to random-drop as the bombing rate increases. That might
be overkill, but hey!, its only a handful of lines of code and the
problem is fun to think about.
Also since the weekend, I've been told FreeBSD and Linux have some kind
of queue pruning code.
Vernon Schryver, vjs(a)sgi.com
