From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Willy Tarreau <w@1wt.eu>, edumazet@google.com
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Moshe Kol <moshe.kol@mail.huji.ac.il>,
Yossi Gilad <yossi.gilad@mail.huji.ac.il>,
Amit Klein <aksecurity@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 net 3/7] tcp: resalt the secret every 10 seconds
Date: Fri, 29 Apr 2022 16:37:12 +0200 [thread overview]
Message-ID: <Ymv4GAezJlA1+Vfs@zx2c4.com> (raw)
In-Reply-To: <20220428124001.7428-4-w@1wt.eu>
Hi Eric,
On Thu, Apr 28, 2022 at 02:39:57PM +0200, Willy Tarreau wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> In order to limit the ability for an observer to recognize the source
> ports sequence used to contact a set of destinations, we should
> periodically shuffle the secret. 10 seconds looks effective enough
Nit: "periodically re-salt the input".
> without causing particular issues.
Just FYI, moving from siphash_3u32 to siphash_4u32 is not free, as it
bumps us up from siphash_3u32 to siphash_2u64, which does two more
siphash rounds. Maybe this doesn't matter much, but just FYI.
I wonder, though, about your "10 seconds looks effective enough without
causing particular issues." I surmise from that sentence that a lower
value might cause particular issues, but that you found 10 seconds to be
okay in practice. Fine. But what happens if one caller hits this at
second 9 and the next caller hits it at second 0? In that case, the
interval might have been 1 second, not 10. In other words, if you need
a certain minimum quantization for this to not cause "particular
issues", it might not work the way you wanted it to.
Additionally, that problem aside, if you round EPHEMERAL_PORT_SHUFFLE_PERIOD
to the nearest power of two, you can turn the expensive division into a
bit shift right.
Regards,
Jason
next prev parent reply other threads:[~2022-04-29 14:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-28 12:39 [PATCH v2 net 0/7] insufficient TCP source port randomness Willy Tarreau
2022-04-28 12:39 ` [PATCH v2 net 1/7] secure_seq: use the 64 bits of the siphash for port offset calculation Willy Tarreau
2022-04-29 14:38 ` Jason A. Donenfeld
2022-04-28 12:39 ` [PATCH v2 net 2/7] tcp: use different parts of the port_offset for index and offset Willy Tarreau
2022-04-28 12:39 ` [PATCH v2 net 3/7] tcp: resalt the secret every 10 seconds Willy Tarreau
2022-04-29 14:37 ` Jason A. Donenfeld [this message]
2022-04-29 15:29 ` Willy Tarreau
2022-04-29 14:48 ` Jason A. Donenfeld
2022-04-29 15:30 ` Willy Tarreau
2022-04-28 12:39 ` [PATCH v2 net 4/7] tcp: add small random increments to the source port Willy Tarreau
2022-04-28 12:39 ` [PATCH v2 net 5/7] tcp: dynamically allocate the perturb table used by source ports Willy Tarreau
2022-04-28 12:40 ` [PATCH v2 net 6/7] tcp: increase source port perturb table to 2^16 Willy Tarreau
2022-04-28 12:40 ` [PATCH v2 net 7/7] tcp: drop the hash_32() part from the index calculation Willy Tarreau
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=Ymv4GAezJlA1+Vfs@zx2c4.com \
--to=jason@zx2c4.com \
--cc=aksecurity@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=moshe.kol@mail.huji.ac.il \
--cc=netdev@vger.kernel.org \
--cc=w@1wt.eu \
--cc=yossi.gilad@mail.huji.ac.il \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).