Date: Sun, 22 Sep 1996 09:36:56 -0600 From: Warner Losh <imp@village.org> To: "David E. Tweten" <tweten@frihet.com> Cc: newton@communica.com.au (Mark Newton), spfarrel@midway.uchicago.edu, security@FreeBSD.org Subject: Re: comments on the SYN attack Message-ID: <199609221536.JAA02004@rover.village.org> In-Reply-To: Your message of "Sun, 22 Sep 1996 00:05:19 PDT." <199609220705.AAA10695@ns.frihet.com> References: <199609220705.AAA10695@ns.frihet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199609220705.AAA10695@ns.frihet.com> "David E. Tweten" writes: : B tries to connect to A using TCP, and B's connect(2) call decides it is : successful because it received SYN/ACK (and has sent the final ACK). Yes. That's why you don't want to drop things unless you can help it. That's what would make the random drop strategy generally a lose, despite its better extreme cases. : Unfortunately, I read the rcmd(3) code (which I used to check conventional : connect(2) usage), but not closely enough on the first pass to notice that : the 5-time retry doesn't apply to the SYN flood case. Rcmd(3) doesn't : regard an immediate connection reset as being worthy of a retry(!). Yes. That's one of the many protocols that can't cope with that situation. : be closed at first use as equivalent to a failed connect(2) would make : connection a more reliably obtainable thing, and coincidently enable : stochastic SYN flood resistance measures. Too bad. Yes. That is a flaw in TCP. :-(. I had the thought this morning that a stochastic process could work, but only if you did the following: 1) When not under attack, do nothing special 2) When under attack (you know this because the queues get full): Never ACK a SYN, but put it on a queue. Unless, however, that SYN is already on that queue, then ack it normally, remove it from the queue and place it in the insipient connection list. Drop from this list the oldest if you have to. At the cost of a slow connection while under attack, this would allow one to recover by the fact that SYNs are retransmitted. However, one could easily defeat this sort of thing with a bomber that sends out two SYN packets identically either in a row, or 1-5s apart to make it look even more like a legitimate connection. Given the easy counter counter measures, I think this idea will also not fly. I present it in case it inspires others to have one that would :-). Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609221536.JAA02004>