From owner-freebsd-security Fri May 14 13:18:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from gw.whitefang.com (calnet11-70.gtecablemodem.com [207.175.234.70]) by hub.freebsd.org (Postfix) with SMTP id 999B914D34 for ; Fri, 14 May 1999 13:18:27 -0700 (PDT) (envelope-from shadows@whitefang.com) Received: (qmail 6317 invoked from network); 14 May 1999 20:18:25 -0000 Received: from rage.whitefang.com (shadows@192.168.1.3) by gw.whitefang.com with SMTP; 14 May 1999 20:18:25 -0000 Date: Fri, 14 May 1999 13:17:26 -0700 (PDT) From: Thamer Al-Herbish To: security@FreeBSD.ORG Subject: Re: Forwarded from BUGTRAQ: SYN floods against FreeBSD In-Reply-To: <4.2.0.37.19990514133829.0461e220@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 14 May 1999, Brett Glass wrote: > One question about "the Linux way of doing it" as described > below. What happens if the secret just happens to be modified > right after the SYN-ACK? Could be you'd drop a connection or > two that was legitimate. Seems like you'd need to test against > an old AND a new secret to avoid the race condition, especially > in the presence of congestion. There were a few "trade offs" with the implementation. I have a copy of the syn-cookies mailing list archive. Forgot where I originally got it from: http://www.whitefang.com/syn-cookies.txt Oh and here's the obligatory question: has anyone already attempted to write a cookie mechanism for fbsd? -- Thamer Al-Herbish PGP public key: shadows@whitefang.com http://www.whitefang.com/pgpkey.txt [ The Secure UNIX Programming FAQ http://www.whitefang.com/sup/ ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message