| 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
| ||
|
Message-ID:
<PAXPR07MB798462C646FC75E9AB54E666A3D7A@PAXPR07MB7984.eurprd07.prod.outlook.com>
Date: Wed, 19 Nov 2025 10:32:42 +0000
From: "Chia-Yu Chang (Nokia)" <chia-yu.chang@...ia-bell-labs.com>
To: Paolo Abeni <pabeni@...hat.com>, "edumazet@...gle.com"
<edumazet@...gle.com>, "parav@...dia.com" <parav@...dia.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "corbet@....net"
<corbet@....net>, "horms@...nel.org" <horms@...nel.org>, "dsahern@...nel.org"
<dsahern@...nel.org>, "kuniyu@...gle.com" <kuniyu@...gle.com>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "dave.taht@...il.com" <dave.taht@...il.com>,
"jhs@...atatu.com" <jhs@...atatu.com>, "kuba@...nel.org" <kuba@...nel.org>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>, "jiri@...nulli.us"
<jiri@...nulli.us>, "davem@...emloft.net" <davem@...emloft.net>,
"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "donald.hunter@...il.com"
<donald.hunter@...il.com>, "ast@...erby.net" <ast@...erby.net>,
"liuhangbin@...il.com" <liuhangbin@...il.com>, "shuah@...nel.org"
<shuah@...nel.org>, "linux-kselftest@...r.kernel.org"
<linux-kselftest@...r.kernel.org>, "ij@...nel.org" <ij@...nel.org>,
"ncardwell@...gle.com" <ncardwell@...gle.com>, "Koen De Schepper (Nokia)"
<koen.de_schepper@...ia-bell-labs.com>, "g.white@...lelabs.com"
<g.white@...lelabs.com>, "ingemar.s.johansson@...csson.com"
<ingemar.s.johansson@...csson.com>, "mirja.kuehlewind@...csson.com"
<mirja.kuehlewind@...csson.com>, cheshire <cheshire@...le.com>,
"rs.ietf@....at" <rs.ietf@....at>, "Jason_Livingood@...cast.com"
<Jason_Livingood@...cast.com>, Vidhi Goel <vidhi_goel@...le.com>
Subject: RE: [PATCH v6 net-next 10/14] tcp: accecn: retransmit SYN/ACK without
AccECN option or non-AccECN SYN/ACK
> -----Original Message-----
> From: Paolo Abeni <pabeni@...hat.com>
> Sent: Tuesday, November 18, 2025 2:59 PM
> To: Chia-Yu Chang (Nokia) <chia-yu.chang@...ia-bell-labs.com>; edumazet@...gle.com; parav@...dia.com; linux-doc@...r.kernel.org; corbet@....net; horms@...nel.org; dsahern@...nel.org; kuniyu@...gle.com; bpf@...r.kernel.org; netdev@...r.kernel.org; dave.taht@...il.com; jhs@...atatu.com; kuba@...nel.org; stephen@...workplumber.org; xiyou.wangcong@...il.com; jiri@...nulli.us; davem@...emloft.net; andrew+netdev@...n.ch; donald.hunter@...il.com; ast@...erby.net; liuhangbin@...il.com; shuah@...nel.org; linux-kselftest@...r.kernel.org; ij@...nel.org; ncardwell@...gle.com; Koen De Schepper (Nokia) <koen.de_schepper@...ia-bell-labs.com>; g.white@...lelabs.com; ingemar.s.johansson@...csson.com; mirja.kuehlewind@...csson.com; cheshire <cheshire@...le.com>; rs.ietf@....at; Jason_Livingood@...cast.com; Vidhi Goel <vidhi_goel@...le.com>
> Subject: Re: [PATCH v6 net-next 10/14] tcp: accecn: retransmit SYN/ACK without AccECN option or non-AccECN SYN/ACK
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> On 11/14/25 8:13 AM, chia-yu.chang@...ia-bell-labs.com wrote:
> > From: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
> >
> > For Accurate ECN, the first SYN/ACK sent by the TCP server shall set
> > the ACE flag (see Table 1 of RFC9768) and the AccECN option to
> > complete the capability negotiation. However, if the TCP server needs
> > to retransmit such a SYN/ACK (for example, because it did not receive
> > an ACK acknowledging its SYN/ACK, or received a second SYN requesting
> > AccECN support), the TCP server retransmits the SYN/ACK without the
> > AccECN option. This is because the SYN/ACK may be lost due to
> > congestion, or a middlebox may block the AccECN option. Furthermore,
> > if this retransmission also times out, to expedite connection
> > establishment, the TCP server should retransmit the SYN/ACK with
> > (AE,CWR,ECE) = (0,0,0) and without the AccECN option, while
> > maintaining AccECN feedback mode.
> >
> > This complies with Section 3.2.3.2.2 of the AccECN specification (RFC9768).
> >
> > Signed-off-by: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
> >
> > ---
> > v6:
> > - Use new synack_type TCP_SYNACK_RETRANS and num_retrans.
> > ---
> > include/net/tcp_ecn.h | 20 ++++++++++++++------
> > net/ipv4/tcp_output.c | 4 ++--
> > 2 files changed, 16 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/net/tcp_ecn.h b/include/net/tcp_ecn.h index
> > a709fb1756eb..57841dfa6705 100644
> > --- a/include/net/tcp_ecn.h
> > +++ b/include/net/tcp_ecn.h
> > @@ -649,12 +649,20 @@ static inline void tcp_ecn_clear_syn(struct sock
> > *sk, struct sk_buff *skb) }
> >
> > static inline void
> > -tcp_ecn_make_synack(const struct request_sock *req, struct tcphdr
> > *th) -{
> > - if (tcp_rsk(req)->accecn_ok)
> > - tcp_accecn_echo_syn_ect(th, tcp_rsk(req)->syn_ect_rcv);
> > - else if (inet_rsk(req)->ecn_ok)
> > - th->ece = 1;
> > +tcp_ecn_make_synack(const struct request_sock *req, struct tcphdr *th,
> > + enum tcp_synack_type synack_type) {
> > + // num_retrans will be incresaed after tcp_ecn_make_synack()
>
> Please use /* */ for comments
>
> > + if (!req->num_retrans) {
>
> It's unclear you this function receives a `synack_type` argument and don't use it. Should the above be
>
> if (synack_type != TCP_SYNACK_RETRANS) {
>
> ?
>
> Or just remove such argument.
>
> /P
Hi Paolo,
You are right, and I will use both "synack_type != TCP_SYNACK_RETRANS" || "!req->num_retrans".
Because this ACE field fallback will only happen from the 2nd retansmitted SYN/ACK.
Chia-Yu
Powered by blists - more mailing lists