Date: Wed, 13 Sep 2006 23:21:45 +0400 (MSD) From: Igor Sysoev <is@rambler-co.ru> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org, silby@freebsd.org Subject: Re: Improved TCP syncookie implementation Message-ID: <20060913230748.P14337@is.park.rambler.ru> In-Reply-To: <45085472.5040903@freebsd.org> References: <44FAE332.4010209@freebsd.org> <20060913190241.S13138@is.park.rambler.ru> <45085472.5040903@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ?
> 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.
Igor Sysoev
http://sysoev.ru/en/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060913230748.P14337>