Hi, Shane,
> 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.
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.
> Assuming
> the secret key doesn't roll-over [very frequently], won't the output
> of the hash function be constant?
Exactly. That's the intention! See the tables in draft-gont for
possible sample outputs.
> 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).
Agreed.
> 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.
IMO, it's shouldn't be necessary to roll-over the key frequently. After
all, what's gained by guessing the key or the like is not worth the
effort that would be required.
If anything, change the key when the system has been idle for quite a
while, and that's it.
> 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}.
There's a refined algorithm that uses multiple counters rather than a
single counter. That algorithm should address your concerns.
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)
>>> 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;
The secret key is asumed to not roll-over frequently.
> 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.
>> 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?
The flow label spec requires the tuple (src addr, dst addr, flow label)
to be unique at least for 120 seconds since the last packet of the flow
was seen.
Identical flow labels are okay as long as the tuple (src addr, dst addr,
flow label) changes. i.e., you can reuse the same flow label value *if*
the src addr and/or the dst addr change.
Thanks!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
