Date: Thu, 14 Sep 2006 17:23:49 +0200 From: Andre Oppermann <andre@freebsd.org> To: Igor Sysoev <is@rambler-co.ru> Cc: freebsd-net@FreeBSD.org, silby@FreeBSD.org, Ruslan Ermilov <ru@FreeBSD.org> Subject: Re: Improved TCP syncookie implementation Message-ID: <45097405.80304@freebsd.org> In-Reply-To: <20060914143059.T16483@is.park.rambler.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45097405.80304>