On Wed, 2010-09-08 at 11:22 -0600, Shane Amante wrote: > Steve, > > On Sep 7, 2010, at 14:17 MDT, Steven Blake wrote: > > On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante <sh...@castlepoint.net> > > wrote:
[snip] > > 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. That is easily fixed. Replace counter with a 20-bit, maximum-length sequence linear feedback shift register (e.g., x^20 + x^17 + 1 or x^20 + x^19 + x^16 + x^14 + 1). Initialize it with the 20-bit output of F(src_addr, dst_addr, Secret_Key). The LFSR will only repeat after 2^20 - 1 iterations. > >> Why couldn't (or, shouldn't) the hash function instead use the > > following: > >> Flow Label = counter + F(Source Port, Destination Port, [Protocol], > >> Secret Key) > >> > >> If you did this, then intermediate routers & switches that were > > performing > >> LAG and/or ECMP load-balancing could easily use the following > >> /fixed-offset/ header fields as input-keys to the load-balancing hash: > >> Load Balancing Hash = F(Source IPv6 Address, Destination IPv6 > > Address, > >> "draft-gont" Flow Label) > >> IMHO, this would allow draft-gont-6man-flowlabel-security to > >> nicely/peacefully co-exist with widely deployed/used flow-based > >> load-balancing schemes for LAG and ECMP. > > > > 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? 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(). It would provide more entropy (depending on how you define "entropy"), but it introduces the possibility that two flows from the same <src_addr, dst_addr> pair could share the same FL value, due to a hash collision. That can't happen if you hash on only src_addr/dst_addr as long as counter doesn't wrap. draft-gont-6man-flowlabel-security assumes that you keep track of every allocated <src_addr, dst_addr, FL> tuple (the "if(three-tuple is unique) return flowlabel;" pseudo-code). If you are going to the trouble of doing this, there is really no reason not to just use a good PRNG to generate the FL value, and retry upon a 3-tuple collision. Regards, // Steve -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
