Re: New Denial of Service Attack ...
From: Barney Wolff <barney@databus.com> To: nanog@merit.edu Cc: vjs@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@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@sgi.com
participants (1)
-
vjs@mica.denver.sgi.com