From owner-freebsd-net@FreeBSD.ORG Wed Sep 13 20:31:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D9F316A47C for ; Wed, 13 Sep 2006 20:31:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75DDC43D76 for ; Wed, 13 Sep 2006 20:31:41 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 24414 invoked from network); 13 Sep 2006 20:15:21 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Sep 2006 20:15:21 -0000 Message-ID: <45086AAF.108@freebsd.org> Date: Wed, 13 Sep 2006 22:31:43 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Igor Sysoev References: <44FAE332.4010209@freebsd.org> <20060913190241.S13138@is.park.rambler.ru> <45085472.5040903@freebsd.org> <20060913230748.P14337@is.park.rambler.ru> In-Reply-To: <20060913230748.P14337@is.park.rambler.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, silby@freebsd.org Subject: Re: Improved TCP syncookie implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2006 20:31:46 -0000 Igor Sysoev wrote: > On Wed, 13 Sep 2006, Andre Oppermann wrote: > >> Igor Sysoev wrote: >>> 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 >> >> If the client sent ACK it will retry again after the normal retransmit >> timeout. > > Well, suppose protocol similar to SSH or SMTP: > > 1) the client calls connect(), it sends SYN; > 2) the server receives SYN and sends SYN/ACK with cookie; > 3) the client receives SYN/ACK and sends ACK; > 4) the client returns successfully from connect() and calls read(); > 5) the ACK is lost; > 6) the server does not about this connection, so application can not > accept() it, and it can not send() HELO message. > 7) the client gets ETIMEDOUT from read(). > > Where in this sequence client may retransmit its ACK ? Never. You're correct. There is no data that would cause a retransmit if the application is waiting for a server prompt first. I shouldn't write wrong explanations when I'm tired, hungry and in between two tasks. ;) This problem is the reason why we don't switch entirely to syncookies and still keep syncache as is. >> If our SYN-ACK back to client is lost we won't resend it with syncookies. >> The client then has to try again which is does after the syn retransmit >> timeout. > > Yes. -- Andre