Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Sep 1996 00:05:19 -0700
From:      "David E. Tweten" <tweten@frihet.com>
To:        Warner Losh <imp@village.org>
Cc:        newton@communica.com.au (Mark Newton), spfarrel@midway.uchicago.edu, security@freebsd.org
Subject:   Re: comments on the SYN attack 
Message-ID:  <199609220705.AAA10695@ns.frihet.com>

next in thread | raw e-mail | index | archive | help
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).

Werner Losh picks up the naritive:
>Meanwhile, A is under SYN attack.  A is forced to discard the 
>insipient connection to B due to a resource shortage.  Then, the ACK 
>ACK comes in.  The code in FreeBSD will now say, "Hmmm, where did I 
>put that pcb... Can't find it, send a RST." and the connection will 
>reset, if I read the code correctly.  This will cause B to die with a 
>connection reset by peer, which many protocols won't retry. 

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(!).  That 
means that whenever the final ACK gets lost on the net, the connection is 
lost with it.  The occasional mysteriously non-functional rsh over the 
Internet makes more sense to me now.  Treating a connection discovered to 
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.

Incidently, for completeness, my original posting had a trivial algebraic 
error.  The formula for t should have been:

	t = ceil(log(1 - c) / log(1 - p));

My original used "c" instead of "1 - c".  Fortunately, when I ran the 
numbers I used c = 0.5, which is the solution to "c = 1 - c".  Lets see, 
wrong method yields right answers to wrong question.  Amazing.

I did my homework.  Unfortunately, I did it wrong.  Fair is fair, though.  
To quote the late great Emily Litella, "Never mind."

Step, limp, step, limp, ...                         [exits, stage left]
-- 
David E. Tweten         | 2047-bit PGP Key fingerprint: | tweten@frihet.com
12141 Atrium Drive      |    E9 59 E7 5C 6B 88 B8 90    |    tweten@and.com
Saratoga, CA 95070-3162 |    65 30 2A A4 A0 BC 49 AE    |    (408) 446-4131
Those who make good products sell products; those who don't, sell solutions.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609220705.AAA10695>