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 for Android: free password hash cracker in your pocket

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

Message-ID: <CANn89i+-ZH+4-64ZHJBGU8_x8BdEg5-OaWqkT8C7ZA=1bOwCeQ@mail.gmail.com>
Date: Thu, 16 Oct 2025 10:54:53 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
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
Subject: Re: [PATCH v1 net-next 1/4] tcp: Make TFO client fallback behaviour consistent.

On Thu, Oct 16, 2025 at 10:20 AM Kuniyuki Iwashima <kuniyu@...gle.com> wrote:
>
> On Thu, Oct 16, 2025 at 9:11 AM Eric Dumazet <edumazet@...gle.com> 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.
> > >
> > > This also happens when tcp_wmem_schedule() fails to charge
> > > non-zero payload.
> > >
> > > OTOH, other fallback paths align with 1.  In this case, a TFO
> > > request is not strictly needed as tcp_fastopen_cookie_check()
> > > has succeeded, but we can use this round to refresh the TFO
> > > cookie.
> > >
> > > Let's avoid sending TFO cookie w/o payload to make fallback
> > > behaviour consistent.
> > >
> >
> > 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.
>
> For that RTT purpose, we send the TFO request in all fallback
> cases unless the client sets the no cookie option.
>
> I think this is better than sending TFO cookie w/o payload because
> when a cookie in SYN is valid, we do not generate SYN+ACK
> w/ a cookie unless the received cookie is the secondary one.
>
> Also, errno is not changed in all paths.

I am not that familiar with TFO code, maybe Yuchung can have some time
to review/comment your patches.