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).
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.
Thanks,
-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
