From: "Jörg Sommer" <joerg@jo-so.de>
To: Eric Dumazet <edumazet@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Neal Cardwell <ncardwell@google.com>, Willy Tarreau <w@1wt.eu>,
netdev@vger.kernel.org, eric.dumazet@gmail.com,
Zhouyan Deng <dengzhouyan_nwpu@163.com>,
Florian Westphal <fw@strlen.de>
Subject: Re: [PATCH net] tcp: secure_seq: add back ports to TS offset
Date: Tue, 3 Mar 2026 08:39:32 +0100 [thread overview]
Message-ID: <aaaL81V4GWUPEajE@jo-so.de> (raw)
In-Reply-To: <20260302205527.1982836-1-edumazet@google.com>
[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]
Eric Dumazet schrieb am Mo 02. Mär, 20:55 (+0000):
> This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")
>
> tcp_tw_recycle went away in 2017.
>
> Zhouyan Deng reported off-path TCP source port leakage via
> SYN cookie side-channel that can be fixed in multiple ways.
>
> One of them is to bring back TCP ports in TS offset randomization.
>
> As a bonus, we perform a single siphash() computation
> to provide both an ISN and a TS offset.
This sounds great! I was questioning myself if the grace period for
tcp_tw_recycle isn't over.
> @@ -118,33 +99,30 @@ EXPORT_SYMBOL(secure_ipv6_port_ephemeral);
> #endif
>
> #ifdef CONFIG_INET
> -u32 secure_tcp_ts_off(const struct net *net, __be32 saddr, __be32 daddr)
> -{
> - if (READ_ONCE(net->ipv4.sysctl_tcp_timestamps) != 1)
> - return 0;
> -
> - ts_secret_init();
> - return siphash_2u32((__force u32)saddr, (__force u32)daddr,
> - &ts_secret);
> -}
> -
> /* secure_tcp_seq_and_tsoff(a, b, 0, d) == secure_ipv4_port_ephemeral(a, b, d),
> * but fortunately, `sport' cannot be 0 in any circumstances. If this changes,
> * it would be easy enough to have the former function use siphash_4u32, passing
> * the arguments as separate u32.
> */
> -u32 secure_tcp_seq(__be32 saddr, __be32 daddr,
> - __be16 sport, __be16 dport)
> +union tcp_seq_and_ts_off
> +secure_tcp_seq_and_ts_off(const struct net *net, __be32 saddr, __be32 daddr,
> + __be16 sport, __be16 dport)
> {
> - u32 hash;
> + u32 ports = (__force u32)sport << 16 | (__force u32)dport;
> + union tcp_seq_and_ts_off st;
>
> net_secret_init();
> - hash = siphash_3u32((__force u32)saddr, (__force u32)daddr,
> - (__force u32)sport << 16 | (__force u32)dport,
> - &net_secret);
> - return seq_scale(hash);
> +
> + st.hash64 = siphash_3u32((__force u32)saddr, (__force u32)daddr,
> + ports, &net_secret);
Sorry, if this is a dump question, but does this make the ts_off unique per
connection or only per quadruple (saddr, sport, daddr, dport), i.e. the same
remote port gets the same ts_off. The documentation says ‘per connection’
and it might be helpful to say it gets the same ts_off if the addresses and
ports are the same.
Kind regards, Jörg
--
“Computer games don't affect kids. If Pacman would have affected us as
children, we would now run around in darkened rooms, munching yellow
pills and listening to repetetive music.”
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-03-03 7:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 20:55 [PATCH net] tcp: secure_seq: add back ports to TS offset Eric Dumazet
2026-03-02 21:47 ` Kuniyuki Iwashima
2026-03-03 1:41 ` Florian Westphal
2026-03-03 7:39 ` Jörg Sommer [this message]
2026-03-05 2:00 ` patchwork-bot+netdevbpf
2026-06-06 11:04 ` xietangxin
2026-06-08 8:51 ` Eric Dumazet
2026-06-08 9:42 ` Willy Tarreau
2026-06-08 12:51 ` xietangxin
2026-06-08 13:14 ` Jiayuan Chen
2026-06-08 15:06 ` Willy Tarreau
2026-06-08 11:30 ` Pablo Neira Ayuso
2026-06-08 12:11 ` Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaaL81V4GWUPEajE@jo-so.de \
--to=joerg@jo-so.de \
--cc=davem@davemloft.net \
--cc=dengzhouyan_nwpu@163.com \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.