Pseudorandom Flow Labels

[Shane Amante <[e-mail]>]

Thomas,

With respect to your comments on, both at the mic at the 6MAN WG and on the list:
draft-ietf-6man-flow-3697bis-02
draft-ietf-6man-flow-ecmp-01
draft-ietf-6man-flow-update-04

You seem to take issue with a recommendation for creating/selecting a flow-label that is "pseudo-random".  Can you clarify the reason(s) you take issue with creating/selecting a flow-label that is "pseudo-random"?  (IMO, the current 'SHOULD' in the draft provides enough leeway that if implementations have good reason(s) to not select pseudo-random values for flow-labels they can choose to do so, but would hopefully have good reasons for that).

The reason I ask is as follows:
1)  RFC 6056: Recommendations for Transport Protocol Randomization, in particular Appendix A.  In short, a lot of [deployed] implementations are already computing a pseudo-random value for a transport protocol port (within the ephemeral port range), today, so IMHO the implementation "burden" of choosing a pseudo-random value must be quite low and, in theory, there should be good re-use of that code/logic for selecting flow-labels.
2)  If we expect that if a intermediate router or switch is using *just* the 3-tuple of {src_ip, dst_ip + flow_label} as input-keys to compute a load-balancing hash algorithm, then the more random the flow-label, the better load-distribution of /all/ traffic will be across the LAG and/or ECMP paths.  Here's a few cases in point:
    a)  As a network operator I have no control over the number of IP addresses used by content farms or residential networks.  Furthermore, it's not clear that as more & more machines (and, smartphones!) ship that support multiple CPU's and/or multiple cores that each of those discrete computing units will (or, should?) receive their own IP address.  With IPv6 that's at least a possibly, but perhaps due to "ease of development", that won't happen often, or at all.  If we strongly recommend a pseudo-random flow-label and a device is only capable of load-balancing using a 3-tuple, then I've at least got a [relatively] unique flow-label in the packet header to provide load distribution.
    b)  The reason that we observe in today's production networks very good load-distribution over LAG and/or ECMP paths is most likely the result of, first, hosts selecting a pseudo-random value for their ephemeral ports (based on RFC 6056) and, second, the ability for intermediate routers/switches to use the traditional 5-tuple for input-keys for load-distribution on those paths.  Since we would like to move in a direction of LAG/ECMP load-balancing based on just the 3-tuple of {src_ip, dst_ip, flow_label}, then we should not take a step backwards from where we are today wrt pseudorandom-ness of individual flows.
3)  Finally, if we expect that the flow-label may (or, hopefully will) get used as a lightweight method of detecting and, possibly, preventing 3rd-party DoS or traffic injection attacks, (i.e.: draft-gont-6man-flowlabel-security), then it depends on generation of pseudo-random values for flow-labels in order that off-path attackers have a reasonably low chance of guessing a valid flow-label.

Thanks,

-shane