netdev - Re: [Query] TCP TFO Query

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK6E8=edgWX1Ye3a6UrqfAaOUG0r=9N8ss39nqRbw8F3UA83Cw@mail.gmail.com>
Date:	Tue, 11 Dec 2012 14:04:29 -0800
From:	Yuchung Cheng <ycheng@...gle.com>
To:	Ketan Kulkarni <ketkulka@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [Query] TCP TFO Query

Hi Ketan,

On Tue, Dec 11, 2012 at 9:29 AM, Ketan Kulkarni <ketkulka@...il.com> wrote:
> Hi,
> I am testing tcp tfo behavior with httping client and polipo server on 3.7rc-8
>
> One observation from my TFO testing  -If for a connection server sends
> a cookie to client, client always does TFO for subsequent connections.
> This is ok.
>
> If for some reason, server stops supporting TFO (either because server
> got restarted without TFO support (in my case) or because path changed
> and the nw node is dropping packet with unknown syn option or
> stripping the option), client does not clear up its cookie cache. It
> always sends data in syn and server never acks the syn-data and client
> retransmits.
>
> As per kernel code -if syn-data is not acked it is retransmitted
> immediately - with the assumption first syn was dropped (but the
> assumption server stopped supporting TFO might not have been
> considered)
>
> Will it be better to flush the cookie for this server and re-attempt
> the cookie "negotiation" on subsequent connection than to retransmit
> the data every time?
>
> Your thoughts?

In our initial design the client actually removes the cookie of the
particular server
(!= flush the entire cache though). Later on we changed to the current
behavior because
it does not have a performance penalty. It falls back to regular handshake:

SYN/cookie/data -> SYN-ACK acking ISN -> ACK(data).

It may happen frequently when a large server farms are upgrading to support TFO.

However there are always more options:
1) Server can selectively instrument to delete old cookies by sending a SYN-ACK
   acking initial sequence with a null TFO option (== caching a null cookie ==
   removing the older one).
2) another client-side flag in sysctl_tcp_fastopen to remove cookie if SYN-ACK
   only acks the syn sequence.
3) combination of 1 and 2.

More ideas are welcome :)

NOTE: I've checked in a patch so that syn-data not acked is not treated as a
network-drop.
http://patchwork.ozlabs.org/patch/171978/

Yuchung

>
> Thanks,
> Ketan
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html