From owner-freebsd-security Sun Sep 22 00:06:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA03644 for security-outgoing; Sun, 22 Sep 1996 00:06:11 -0700 (PDT) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA03614 for ; Sun, 22 Sep 1996 00:06:06 -0700 (PDT) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.7.6/8.6.12) with ESMTP id AAA10695; Sun, 22 Sep 1996 00:05:19 -0700 (PDT) Message-Id: <199609220705.AAA10695@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: Warner Losh cc: newton@communica.com.au (Mark Newton), spfarrel@midway.uchicago.edu, security@freebsd.org Subject: Re: comments on the SYN attack Date: Sun, 22 Sep 1996 00:05:19 -0700 From: "David E. Tweten" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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.