Hi, Shane,
>>> Thus, for a given {src_ip, dst_ip} pair, the only thing providing
>>> uniqueness to the output of that hash is the secret key.
>> I don't know what you mean by "uniqueness" here. If you mean "the
>> secretkey is what makes it hard for an off-path attacker to predict
>> the result of the hash function", then I fully agree.
>
> By "uniqueness", I meant that the flow-label contained enough entropy
> (i.e.: was a substantially unique value, not just a linearly
> increasing value) that it would result in very good load-spreading if
> it were used as an input-key for flow-based load-balancing over LAG &
> ECMP paths.
As noted by Steven, this can be easily fixed. Even then, I don't think a
router can rely on the entropy of the flow-label (besides that of a
linear change) for achieving good load-sharing. The hash algorithm at
the router has to be good enough. That's it.
>> If anything, change the key when the system has been idle for quite
>> a while, and that's it.
>
> While that may be OK from a security POV, that likely means the
> flow-label value won't contain enough entropy for it to be useful as
> an input-key for load-spreading on LAG & ECMP paths at intermediate
> routers along the path.
Can a router actually rely on this?
Anyway, Steven suggested how to fix this, if this is deemed as an
important issue.
>> There's a refined algorithm that uses multiple counters rather than
>> a single counter. That algorithm should address your concerns.
>
> I'm not sure it does. At the moment, I like Steve's suggestion (in a
> subsequent e-mail) of either a Linear Feedback Shift Register or,
> better yet, using a PRNG. In theory, with a 20-bit space and a
> "good" PRNG the risk of choosing the same flow-label value is likely
> infinitesimally small, which is good enough (for me).
The requirement in RFC 3697 is for "MUST" be unique not "SHOULD". So a
simple PRNG does not seem to be enough.
>> ANyway, I cant see how the usual 5-tuple would have more entropy:
>> src and dst ip are the same as for my algorithm. protocol is most
>> likely tcp or udp. dst port probably has only a few values (80,
>> 110, etc.), and src port is generated in some stacks with the same
>> algorithm I'm proposing for the flow label (see
>> draft-ietf-tsvwg-port-randomization)
>
> I haven't looked at that draft you mention before; however, from a
> cursory glance, there are a variety of algorithms in there at least
> two of which appear to use a PRNG. So, if PRNG is good enough for
> port-randomization,
They are not ;-), but the port-randomization was produced by a standards
body, and hence everybody had to be pleased :-(
FWIW, FreeBSD had implemented the trivial PRNG approaches, and had to
implement a hack later due to problems arising from collisions of the
port numbers....
> why isn't a PRNG good enough for the flow-label?
> (If anything, there's a substantially larger output space in a
> flow-label, compared to the ephemeral port range).
Agreeed. But RFC3697 has a "MUST" requirement for avoiding collisions.
(not a "SHOULD")
>>> and, b) the counter? To reduce the risk of collision I would
>>> assume you'd decrease the the interval at which the secret key is
>>> rolled over and/or increase the size of the counter.
>> I don't follow.
>>
>> Decreasing the key rollover frequency actually *increases* the
>> probability of collisions -- hence the advice in my I-D as to when
>> (if ever) that should be done.
>
> Err, sorry. I meant the shorter/smaller the time interval at which
> you're rolling over keys, the less risk of collision you have. So,
> we agree. :)
Sorry. The shorter/smaller the interval, the higher the chances of
collisions. -- Ideally, you would never roll-over the keys (for lowest
chances of collisions)
Thanks!
Kind regards,
--
Fernando Gont
e-mail: [email protected] || [email protected]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
