netdev - Re: [PATCH v1 net-next 1/4] tcp: Make TFO client fallback behaviour consistent.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAVpQUBD5nozg1azwi9tBHXVWgcXBSV+BXSgpt455Y+CweevYw@mail.gmail.com>
Date: Sat, 18 Oct 2025 13:56:21 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Jeremy Harris <jgh@...mail.org>
Cc: Neal Cardwell <ncardwell@...gle.com>, "David S. Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Yuchung Cheng <ycheng@...gle.com>, Willem de Bruijn <willemb@...gle.com>, 
	Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org, 
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH v1 net-next 1/4] tcp: Make TFO client fallback behaviour consistent.

On Sat, Oct 18, 2025 at 11:41 AM Jeremy Harris <jgh@...mail.org> wrote:
>
> On 2025/10/16 5:10 PM, Eric Dumazet wrote:
> > On Wed, Oct 15, 2025 at 9:02 PM Kuniyuki Iwashima <kuniyu@...gle.com> wrote:
> >>
> >> In tcp_send_syn_data(), the TCP Fast Open client could give up
> >> embedding payload into SYN, but the behaviour is inconsistent.
> >>
> >>    1. Send a bare SYN with TFO request (option w/o cookie)
> >>    2. Send a bare SYN with TFO cookie
> >>
> >> When the client does not have a valid cookie, a bare SYN is
> >> sent with the TFO option without a cookie.
> >>
> >> When sendmsg(MSG_FASTOPEN) is called with zero payload and the
> >> client has a valid cookie, a bare SYN is sent with the TFO
> >> cookie, which is confusing.
>
> > I am unsure. Some applications could break ?
> >
> > They might prime the cookie cache initiating a TCP flow with no payload,
> > so that later at critical times then can save one RTT at their
> > connection establishment.
>
> In addition, a client doing this (SYN with cookie but no data) is granting
> permission for the server to respond with data on the SYN,ACK (before
> 3rd-ACK).

As I quoted in patch 2, the server should not respond as such
for SYN without payload.

https://datatracker.ietf.org/doc/html/rfc7413#section-3
---8<---
   Performing TCP Fast Open:

   1. The client sends a SYN with data and the cookie in the Fast Open
      option.

   2. The server validates the cookie:
...
   3. If the server accepts the data in the SYN packet, it may send the
      response data before the handshake finishes.
---8<---