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

Message-ID: <20251018233433.891423-1-kuniyu@google.com>
Date: Sat, 18 Oct 2025 23:34:17 +0000
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: jgh@...mail.org
Cc: davem@...emloft.net, edumazet@...gle.com, horms@...nel.org, 
	kuba@...nel.org, kuni1840@...il.com, kuniyu@...gle.com, ncardwell@...gle.com, 
	netdev@...r.kernel.org, pabeni@...hat.com, willemb@...gle.com, 
	ycheng@...gle.com
Subject: Re: [PATCH v1 net-next 1/4] tcp: Make TFO client fallback behaviour consistent.

From: Jeremy Harris <jgh@...mail.org>
Date: Sat, 18 Oct 2025 22:17:12 +0100
> 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.
> 
> 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.

Actually, even FreeBSD does not read like that, and it delays
SYN+ACK only when SYN has "non-zero length data" (tlen > 0) in
tcp_do_segment().

---8<---
	tfo_syn = ((tp->t_state == TCPS_SYN_RECEIVED) &&
	    (tp->t_flags & TF_FASTOPEN));
	if ((tlen || (thflags & TH_FIN) || (tfo_syn && tlen > 0)) &&
	    TCPS_HAVERCVDFIN(tp->t_state) == 0) {
...
			if (DELAY_ACK(tp, tlen) || tfo_syn)
				tp->t_flags |= TF_DELACK;
			else
				tp->t_flags |= TF_ACKNOW;
			tp->rcv_nxt += tlen;
---8<---