Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 29 Apr 2022 16:37:12 +0200
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
Message-ID: <Ymv4GAezJlA1+Vfs@zx2c4.com>
References: <20220428124001.7428-1-w@1wt.eu>
 <20220428124001.7428-4-w@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220428124001.7428-4-w@1wt.eu>
Precedence: bulk

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