Improved TCP syncookie implementation

Ruslan Ermilov ru at FreeBSD.org
Thu Sep 14 02:30:11 PDT 2006


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.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20060914/5c16257f/attachment.pgp


More information about the freebsd-net mailing list