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: <CAK6E8=d1GjRLVuB0zmydAepvnZs3M1w+2tCVwdhAzL6rtseJ1g@mail.gmail.com>
Date: Mon, 20 Oct 2025 09:30:26 -0700
From: Yuchung Cheng <ycheng@...gle.com>
To: Jeremy Harris <jgh@...mail.org>
Cc: Kuniyuki Iwashima <kuniyu@...gle.com>, 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>, 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 2:17 PM Jeremy Harris <jgh@...mail.org> wrote:
>
> On 2025/10/18 9:56 PM, Kuniyuki Iwashima wrote:
> >> 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<---
>
> In language lawyer terms, that (item 3 above) is a permission.  It does
> not restrict from doing other things.  In particular, there are no RFC 2119
> key words (MUST NOT, SHOULD etc).
>
>
> I argue that once the server has validated a TFO cookie from the client,
> it is safe to send data to the client; the connection is effectively open.

Thanks for the patch. But indeed this was the intentional design (i.e.
empty MSG_FASTOPEN call triggers server immediate accept and send
before final ACK in 3WHS). It's allowing more application scenarios
for TFO. Now some applications may have taken advantage of this design
so this patch set may break them.

But the RFC could be more specific about this edge case so revising
the RFC as an errata?

>
> For traditional, non-TFO, connections the wait for the 3rd-ACK is required
> to be certain that the IP of the alleged client, given in the SYN packet,
> was not spoofed by a 3rd-party.  For TFO that certainty is given by the
> cookie; the server can conclude that it has previously conversed with
> the source IP of the SYN.
>
>
> Alternately, one could read "the data" in that item 3 as including "zero length data";
> the important part being accepting it.
> --
> Cheers,
>    Jeremy