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: > >> Hi Fernando, >> >> I have a question on: >> http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00 >> >> Unless I misunderstand something, you're proposing that a flow-label be >> constructed using the IPv6 Source & Destination values as input-keys to > a >> hash function as follows: >> Flow Label = counter + F(Source Address, Destination Address, Secret >> Key) >> If you do the above, then intermediate routers that are performing LAG >> and/or ECMP load-balancing will not be able to use the flow-label as an >> input-key for calculating a load-balancing hash. Instead, intermediate >> routers will have to fetch a 5-tuple of {Source IP, Destination IP, >> Protocol, Source Port, Destination Port} from the IPv6 header to > calculate >> a load-balancing hash (and, at the same time, completely ignore the >> flow-label as an input-key for its flow-based load-balancing hash, since >> it's redundant). > > Shane, > > I don't think your conclusion follows. One thing you want for LAG/ECMP is > for each flow from a given <src_addr, dst_addr> to have a unique FL value. > Fernando's algorithm achieves this by incrementing counter for each new > flow from that address pair.
OK, thanks for the clarification. IMHO, that (last part) wasn't clear in my reading of the draft. > 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. >> 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(). -shane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
