All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Stephen Hemminger <stephen@networkplumber.org>
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 net 3/7] tcp: resalt the secret every 10 seconds
Date: Wed, 27 Apr 2022 18:21:58 +0200	[thread overview]
Message-ID: <20220427162158.GC3488@1wt.eu> (raw)
In-Reply-To: <20220427085621.5f2d1759@hermes.local>

Hi Stephen,

On Wed, Apr 27, 2022 at 08:56:21AM -0700, Stephen Hemminger wrote:
> On Wed, 27 Apr 2022 08:52:29 +0200
> Willy Tarreau <w@1wt.eu> 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
> > without causing particular issues.
> > 
> > Cc: Moshe Kol <moshe.kol@mail.huji.ac.il>
> > Cc: Yossi Gilad <yossi.gilad@mail.huji.ac.il>
> > Cc: Amit Klein <aksecurity@gmail.com>
> > Tested-by: Willy Tarreau <w@1wt.eu>
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > ---
> >  net/core/secure_seq.c | 12 +++++++++---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
> > index 2cdd43a63f64..200ab4686275 100644
> > --- a/net/core/secure_seq.c
> > +++ b/net/core/secure_seq.c
> > @@ -22,6 +22,8 @@
> >  static siphash_aligned_key_t net_secret;
> >  static siphash_aligned_key_t ts_secret;
> >  
> 
> Rather than hard coding, why not have a sysctl knob for this?
> That way the tinfoil types can set it smaller.

It's a legit question. First I think that there's no good value; before
it used to be infinite, and now we're trying to figure a reasonable value
that make the attack impractical without going too close to the risk of
occasionally failing to establish a connection. I'm really not convinced
that there's any benefit in fiddling with that, except for breaking one's
stack by resalting too often and complaining about stupid network issues
with ACK or RST being sent in response to a SYN.

And stupidly, dividing jiffies by a constant known at build time is
slightly cheaper than dividing by a variable. I know it's a detail but
we tried hard to limit the accumulation of details here :-/

Just my two cents,
Willy

  reply	other threads:[~2022-04-27 16:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27  6:52 [PATCH net 0/7] insufficient TCP source port randomness Willy Tarreau
2022-04-27  6:52 ` [PATCH net 1/7] secure_seq: return the full 64-bit of the siphash Willy Tarreau
2022-04-27  9:56   ` kernel test robot
2022-04-27 10:07     ` Willy Tarreau
2022-04-27 10:07       ` Willy Tarreau
2022-04-27 16:35       ` Willy Tarreau
2022-04-27 16:35         ` Willy Tarreau
2022-04-27 16:50         ` Eric Dumazet
2022-04-27 16:50           ` Eric Dumazet
2022-04-27 16:56           ` Willy Tarreau
2022-04-27 16:56             ` Willy Tarreau
2022-04-27 17:18   ` Jason A. Donenfeld
2022-04-27 20:19     ` Willy Tarreau
2022-04-28  1:59   ` kernel test robot
2022-04-27  6:52 ` [PATCH net 2/7] tcp: use different parts of the port_offset for index and offset Willy Tarreau
2022-04-27  6:52 ` [PATCH net 3/7] tcp: resalt the secret every 10 seconds Willy Tarreau
2022-04-27 15:56   ` Stephen Hemminger
2022-04-27 16:21     ` Willy Tarreau [this message]
2022-04-27  6:52 ` [PATCH net 4/7] tcp: add small random increments to the source port Willy Tarreau
2022-04-27  6:52 ` [PATCH net 5/7] tcp: dynamically allocate the perturb table used by source ports Willy Tarreau
2022-04-27  6:52 ` [PATCH net 6/7] tcp: increase source port perturb table to 2^16 Willy Tarreau
2022-04-27  8:07   ` David Laight
2022-04-27  8:19     ` Willy Tarreau
2022-04-27  6:52 ` [PATCH 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=20220427162158.GC3488@1wt.eu \
    --to=w@1wt.eu \
    --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=stephen@networkplumber.org \
    --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 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.