Hi Fernando,
On Sep 8, 2010, at 12:18 MDT, Fernando Gont wrote:
> Hi, Shane,
>
>>> With that said, I don't think this algorithm is necessarily ideal.
>>> The FL value for any two flows from a <src_addr, dst_addr> pair may
>>> only vary by a few bits, so if a switch/router uses a poor hash
>>> algorithm for LAG/ECMP, you may not get a good load spread.
>>
>> Agreed, I share your concern that the "counter" is a linear sequence.
>
> Well, this is actually a feature ;-). i.e., the hash provides the
> randomness. the counter provides for the linear increase, such that the
> chances of collisions are reused (you only reuse a given flowlabel once
> you have already use all the other flowlablel values).
I respectfully disagree that "the hash provides the randomness" suitable for a
flow-label to be used as an input-key for flow-based load-balancing. In your
draft, you've defined the calculation of a Flow Label value as follows:
Flow Label = counter + F(Source Address, Destination Address, Secret Key)
Thus, for a given {src_ip, dst_ip} pair, the only thing providing uniqueness to
the output of that hash is the secret key. Assuming the secret key doesn't
roll-over [very frequently], won't the output of the hash function be constant?
Only the linearly increasing "counter" is providing **entropy** to a "flow" in
the flow-label value. (Note, I'm looking at this from the perspective of using
the above flow label value as an input-key for flow-based load-balancing over
LAG/ECMP paths).
Although Section 4 of your draft provides some very high level guidance on when
a secret key roll-over /may/ occur, it's unclear what this frequency would (or,
should?) boil down to in practice, IMHO.
>From what I can tell, your algorithm appears to be OK for providing a unique,
>"unguessable" flow-label value (given the combination of the "secret-key" and
>"counter" in your algorithm) that could prevent off-path attacks. However,
>(unless I'm misunderstanding something), it would likely provide very poor
>entropy to the flow-label value for it to be used as an input-key, i.e.:
>{src_ip, dst_ip, flow-label}, for flow-based load-balancing on LAG and ECMP
>paths, instead of the usual 5-tuple of: {src_ip, dst_ip, protocol, src_port,
>dst_port}.
[--snip--]
>> From my original
>> e-mail:
>>>> Flow Label = counter + F(Source Port, Destination Port,
>>>> [Protocol], Secret Key)
>>
>> If anything, I would think with new transport connections, using
>> ephemeral ports, being opened all the time, a combination of
>> F(src_port, dst_port, [protocol], secret key) _and_ the counter would
>> provide more entropy to the FL values vs. just using the IPv6
>> addresses in F().
>
> How do you prevent this function from throwing the same value for the
> same pair (src addr, dst addr) in a short period of time?
Wouldn't that be a function of: a) how often the "secret key" is rolled over;
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.
> You want uniqueness on a per (srd addr, dst addr) basis. -- hence the
> "offset" (resulting from the hash function) has to be based on the
> addresses....
Why? Or, said differently, shouldn't the requirement be that there is a very
low probability that a given receiver will experience a collision of identical
flow-labels?
Thanks,
-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
