All of
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Willy Tarreau' <>,
	"" <>,
	"" <>
Cc: David Miller <>,
	Jakub Kicinski <>,
	Alexey Kuznetsov <>,
	Hideaki YOSHIFUJI <>,
	Amit Klein <>,
	Eric Dumazet <>
Subject: RE: [PATCH net-next] ipv6: use prandom_u32() for ID generation
Date: Mon, 31 May 2021 10:41:18 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: Willy Tarreau
> Sent: 29 May 2021 12:08
> This is a complement to commit aa6dd211e4b1 ("inet: use bigger hash
> table for IP ID generation"), but focusing on some specific aspects
> of IPv6.
> Contary to IPv4, IPv6 only uses packet IDs with fragments, and with a
> minimum MTU of 1280, it's much less easy to force a remote peer to
> produce many fragments to explore its ID sequence. In addition packet
> IDs are 32-bit in IPv6, which further complicates their analysis. On
> the other hand, it is often easier to choose among plenty of possible
> source addresses and partially work around the bigger hash table the
> commit above permits, which leaves IPv6 partially exposed to some
> possibilities of remote analysis at the risk of weakening some
> protocols like DNS if some IDs can be predicted with a good enough
> probability.
> Given the wide range of permitted IDs, the risk of collision is extremely
> low so there's no need to rely on the positive increment algorithm that
> is shared with the IPv4 code via ip_idents_reserve(). We have a fast
> PRNG, so let's simply call prandom_u32() and be done with it.
> Performance measurements at 10 Gbps couldn't show any difference with
> the previous code, even when using a single core, because due to the
> large fragments, we're limited to only ~930 kpps at 10 Gbps and the cost
> of the random generation is completely offset by other operations and by
> the network transfer time. In addition, this change removes the need to
> update a shared entry in the idents table so it may even end up being
> slightly faster on large scale systems where this matters.
> The risk of at least one collision here is about 1/80 million among
> 10 IDs, 1/850k among 100 IDs, and still only 1/8.5k among 1000 IDs,
> which remains very low compared to IPv4 where all IDs are reused
> every 4 to 80ms on a 10 Gbps flow depending on packet sizes.

The problem is that, on average, 1 in 2^32 packets will use
the same id as the previous one.
If a fragment of such a pair gets lost horrid things are
likely to happen.
Note that this is different from an ID being reused after a
count of packets or after a time delay.

So you still need something to ensure IDs aren't reused immediately.


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2021-05-31 10:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-29 11:07 [PATCH net-next] ipv6: use prandom_u32() for ID generation Willy Tarreau
2021-05-31 10:41 ` David Laight [this message]
2021-05-31 11:19   ` Willy Tarreau
2021-05-31 19:27 ` Eric Dumazet
2021-06-01  5:20 ` patchwork-bot+netdevbpf

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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.