From owner-freebsd-net@FreeBSD.ORG Thu Sep 14 15:23:49 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 87ABD16A407 for ; Thu, 14 Sep 2006 15:23:49 +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 B80FF43D78 for ; Thu, 14 Sep 2006 15:23:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 34803 invoked from network); 14 Sep 2006 15:07:19 -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 ; 14 Sep 2006 15:07:19 -0000 Message-ID: <45097405.80304@freebsd.org> Date: Thu, 14 Sep 2006 17:23:49 +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> <45086AAF.108@freebsd.org> <20060914093006.GE26261@rambler-co.ru> <20060914143059.T16483@is.park.rambler.ru> In-Reply-To: <20060914143059.T16483@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, Ruslan Ermilov 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: Thu, 14 Sep 2006 15:23:49 -0000 Igor Sysoev wrote: > On Thu, 14 Sep 2006, Ruslan Ermilov wrote: > >> On Wed, Sep 13, 2006 at 10:31:43PM +0200, Andre Oppermann wrote: >>> Igor Sysoev wrote: >>>> 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. >>> >> Perhaps it would be a good idea to remove net.inet.tcp.syncookies_only >> then? In any case, please don't forget to update the syncache(4) manpage >> to reflect your changes, and if you decide not to remove this sysctl, >> please add a warning of its potential to break a protocol. > > I think that setting syncookies only not globally, but on per port basis, > say, for HTTP would be helpfull. Setting it for other protocols, e.g, SSH, > rsync, SMTP, IMAP, POP3 may break them. Syncookies are optional anyway and syncache is still there. I'm not going to over-engineer this whole thing. The primary purpose of syn- cookies is to be able to handle a large number of (potentially bogus) connection attempts. With syncookies you are able to serve more legitimate connections out of the bogus ones than with syncache only. -- Andre