All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: David Laight <David.Laight@aculab.com>
Cc: "netdev@vger.kernel.org" <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" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net 6/7] tcp: increase source port perturb table to 2^16
Date: Wed, 27 Apr 2022 10:19:14 +0200	[thread overview]
Message-ID: <20220427081914.GA1724@1wt.eu> (raw)
In-Reply-To: <7372f788762140d496c157813b0173e5@AcuMS.aculab.com>

On Wed, Apr 27, 2022 at 08:07:29AM +0000, David Laight wrote:
> From: Willy Tarreau
> > Sent: 27 April 2022 07:53
> > 
> > Moshe Kol, Amit Klein, and Yossi Gilad reported being able to accurately
> > identify a client by forcing it to emit only 40 times more connections
> > than there are entries in the table_perturb[] table. The previous two
> > improvements consisting in resalting the secret every 10s and adding
> > randomness to each port selection only slightly improved the situation,
> > and the current value of 2^8 was too small as it's not very difficult
> > to make a client emit 10k connections in less than 10 seconds.
> > 
> > Thus we're increasing the perturb table from 2^8 to 2^16 so that the the
> > same precision now requires 2.6M connections, which is more difficult in
> > this time frame and harder to hide as a background activity. The impact
> > is that the table now uses 256 kB instead of 1 kB, which could mostly
> > affect devices making frequent outgoing connections. However such
> > components usually target a small set of destinations (load balancers,
> > database clients, perf assessment tools), and in practice only a few
> > entries will be visited, like before.
> 
> Increasing the table size has a bigger impact on anyone trying
> to get the kernel to run in a limited memory footprint.
> 
> All these large tables (often hash tables) soon add up.

We know, and the initial approach that required a significantly larger
table and an extra table per namespace was a no-go. All these are part
of the reasons for the effort it took to refine the solution in order
to avoid such unacceptable costs. The way it was made here makes it easy
to patch the value for small systems if needed and leaves the door open
for a configurable setting in the future if that was estimated necessary
for certain environments.

Willy

  reply	other threads:[~2022-04-27  8:19 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
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 [this message]
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=20220427081914.GA1724@1wt.eu \
    --to=w@1wt.eu \
    --cc=David.Laight@aculab.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=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.