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). >> If you include protocol/src_port/dst_port in the hash, there is >> nothing preventing two flows from the same <src_add, dst_addr> from >> sharing the same FL value, due to a hash collision. > > I'm not sure I understand. > > I thought that, as you pointed out above, the "counter" was the > method to prevent/reduce collisions of FL values? The counter prevents a flow-label to be reused too quickly for a given (src addr, dst addr). The hash provides for a random "offset" value such that, while an attacker knows that flowlabels are generated linearly, he doesn't know where that line starts. Think of the function as: y = a * x + b Where y: Flow Label a: is "1" in this case x: the counter b: the result of the hash function The expression above is that of a line. However, since it's impossible (*) for an off-path attacker to know "b", it's impossible to predict the value of "y". (*) Clearly this depends on the secret, and the hash algorithm, etc. > 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? 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.... 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 --------------------------------------------------------------------
