Date: Wed, 13 Sep 2006 19:19:04 +0400 (MSD) From: Igor Sysoev <is@rambler-co.ru> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org, silby@freebsd.org Subject: Re: Improved TCP syncookie implementation Message-ID: <20060913190241.S13138@is.park.rambler.ru> In-Reply-To: <44FAE332.4010209@freebsd.org> References: <44FAE332.4010209@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Sep 2006, Andre Oppermann wrote: > I've pretty much rewritten our implementation of TCP syncookies to get > rid of some locking in TCP syncache and to improve their functionality. > > The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK > optional feature information. This means that a FreeBSD host may run > with syncookies only and not degrade TCP connections made through it. > All important TCP connection setup negotiated options are preserved > (send/receive window scaling, SACK, MSS) without storing any state on > the host during the SYN-SYN/ACK phase. As a nice side effect the > timestamps we respond with are randomized instead of directly using > ticks (which reveals out uptime). As I understand syncache is used to retransmit SYN/ACK. What would be if 1) a client sent SYN, 2) we sent SYN/ACK with cookie, 3) the client sent ACK, but the ACK was lost ? I suppose the client will see timed out error. Igor Sysoev http://sysoev.ru/en/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060913190241.S13138>