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  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]
Date:	Tue, 11 Dec 2012 14:04:29 -0800
From:	Yuchung Cheng <>
To:	Ketan Kulkarni <>
Subject: Re: [Query] TCP TFO Query

Hi Ketan,

On Tue, Dec 11, 2012 at 9:29 AM, Ketan Kulkarni <> 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


> Thanks,
> Ketan
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to
> More majordomo info at
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists