Hi Fernando,
Apologies for the delay.
On Sep 8, 2010, at 16:29 MDT, Fernando Gont wrote:
> 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.
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.
[--snipping parts we agree on--]
>> 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.
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.
>> 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.
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).
> 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, 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).
>>>> 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.
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. :)
>>> 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!
Thank you!
-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
