Improved TCP syncookie implementation

[Andre Oppermann]

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