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