On Mon, 17 Jan 2011 12:55:53 -0700, Shane Amante
<[email protected]> wrote:
Thomas,
On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote:
The point being, an attacker doesn't have to guess the actual Flow
Labels that are being in use, but just come up with way to generate
traffic that ECMP maps onto the target path. That suggests that
having
Flow Label values themselves be "pseudo random" doesn't buy a whole
lot.
Or am I missing something?
I'm a bit stuck on this point, because both of the current flow
label
document continue to say flow labels should be generated SHOULD be
psuedo-random, and I'm not convinced this is necessary, required, or
buys us anything. What compelling argument am I missing?
Fernando Gont (and, Steve Blake) have been proposing using the
flow-label as a security mechanisms for hosts to prevent off-path
spoofing attacks. However, to successfully implement/deploy this,
you
need the pseudo-random flow-labels:
Therefore, the Flow Label should be obfuscated so that
the chances of an off-path attacker of guessing the Flow Label of
future flows are reduced.
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-01
So, why not take the opportunity to use the flow-label to reduce the
attack surface of IPv6, (compared to v4)?
I am not pushing the flow label nonce proposal anymore.
I understand that there is a lot of deployed gear that uses CRC16 or
CRC32 to compute ECMP/LAG hashes. To the extent that this gear can be
configured to use flow labels in the hash key (rather that
protocol/ports), I also understand that these CRC algorithms are not
great hash functions (i.e., they lack an avalanche effect), although I
haven't examined this myself.
Setting the flow label using a non-repeating PRNG (*) makes it
(slightly?) more likely that one's traffic will experience a good load
split. I can't think of a reason at the moment why this should be
mandatory, though.
(*) This can be achieved using an array of maximum-sequence 20-bit
LFSRs, rather than an array of 20-bit counters as in Fernando's draft.
Regards,
// Steve
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
