Improved TCP syncookie implementation

[Andre Oppermann]

Igor Sysoev wrote:
> On Wed, 13 Sep 2006, Andre Oppermann wrote:
> 
>> Igor Sysoev wrote:
>>> On Sun, 3 Sep 2006, Andre Oppermann wrote:
>>>
>>>> I've pretty much rewritten our implementation of TCP syncookies to get
>>>> rid of some locking in TCP syncache and to improve their functionality.
>>>>
>>>> The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK
>>>> optional feature information.  This means that a FreeBSD host may run
>>>> with syncookies only and not degrade TCP connections made through it.
>>>> All important TCP connection setup negotiated options are preserved
>>>> (send/receive window scaling, SACK, MSS) without storing any state on
>>>> the host during the SYN-SYN/ACK phase.  As a nice side effect the
>>>> timestamps we respond with are randomized instead of directly using
>>>> ticks (which reveals out uptime).
>>>
>>> As I understand syncache is used to retransmit SYN/ACK.
>>> What would be if
>>>
>>> 1) a client sent SYN,
>>> 2) we sent SYN/ACK with cookie,
>>> 3) the client sent ACK, but the ACK was lost
>>
>> If the client sent ACK it will retry again after the normal retransmit
>> timeout.
> 
> 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.

>> If our SYN-ACK back to client is lost we won't resend it with syncookies.
>> The client then has to try again which is does after the syn retransmit
>> timeout.
> 
> Yes.

-- 
Andre