Re: Pseudorandom Flow Labels

[Shane Amante <[e-mail]>]

Thomas,

On Apr 5, 2011, at 13:58 MDT, Thomas Narten wrote:
[--snip--]
> I take it as a given that doing ECMP on the src/dst address gets you
> 80% of what you need today. Adding in the Flow Label (if set) will
> take you much further. I am not convinced you need real "pseudo
> randomness" in the Flow Label to get the benefits being called for.

As I pointed out below, we already have pseudorandom distribution of flows today, given that most host implementations use RFC 6056 and (IPv4) load-balancing routers/switches use the 5-tuple as input-keys ... included in those input-keys is a "pseudorandom ephemeral port".  In short, if you remove the pseudo-random requirement from flow-labels, (and I can only load-balance on just the 3-tuple), I guarantee I will end up with less efficient load-balancing.

Second, the economic results of what you suggest would be bad.  IOW, operators need to pack all links, in a LAG and/or ECMP group, as _efficiently_ as (reasonably) possible, particularly over Inter-City and especially over Inter-Continental links where costs are substantial.  In summary, "good enough" is not adequate, hence the reqm't for pseudorandom-ness in flow-labels (originated by hosts!) to provide the a very, very high probability that flows will be "uniformly distributed".


>> 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.
> 
> Understood. But what you need for this is not (necessarily) pseudo
> randomness. Just sufficient variability (when combined with the
> src/dst) to get good distribution on the output side of the hash.

I'll state it a bit differently: I need flow-labels as close to the [pseudo-random] properties provided by RFC 6056.


>> 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.
> 
> I think we can assume that if we use both the src/dst, we will get a
> good degree of distribution in the values. Adding the Flow Label gives
> more. I am just not convinced that to get good distribution we need to
> *require* (or strongly suggest) psuedo randomness in the Flow
> Lable. We know that by simply incrementing the Flow Label by 1 for
> each flow, we get sufficient distribution. That is *way* easier to
> implement than something else.

Unfortunately, if:
a)  All hosts at a site start off selecting "1" for their flow-labels; or,
b)  Don't cycle through the full-range of flow-label values; or,
c)  a [large] set of hosts experience synchronization of flow-label values; or,
d)  Reset back to flow-label "1" after some short time period
... then you nullify the claim of having "sufficient distribution" of flow-labels and, consequently, flows.  Instead, if we tell implementers to select a pseudorandom value, using an O/S and/or API's random() function, we're much more likely to get "sufficient 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.
> 
> This takes me back to an earlier point. Then suggest that if the port
> numbers are pseudo random, provide me with a simple algorithm for
> mapping that into a good Flow Label value.

draft-gont-6man-flowlabel-security-01?  Which is already referenced from draft-ietf-6man-flow-3697bis-02.


>> 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.
> 
> I'm less convinced that there are real significant DOS attacks that
> using a pseudo-random flow label can address.
> 
> Now. What about TEPs? They have no way of knowing whether the port
> numbers being used provide proper randomness. That implies if they are
> going to generate pseudo-random Flow Labels, they have a *lot* more
> work to do. And to be sure that all packets from a given "flow" are
> given the same Flow Label, they may have to maintain state. i.e., so
> that subsequent packets from the same flow get assigned the same Flow
> Label value. I doubt you are suggesting that.

You are correct.


> But the current
> documents leave this all to the reader. Again, I think some concrete
> recommendations are in order. If you think TEPs will, in fact, just
> produce a Flow Label value based on whatever ports the packets being
> tunneled contain, then just say so and be done with it.

OK.  I think I understand where you are coming from with respect to draft-ietf-6man-flow-ecmp-01.  Hopefully the above comment(s) will allow us to craft text that will resolve your concerns with that draft once and for all.  However, that still leaves draft-ietf-6man-flow-3697bis-02 open for discussion.


> But don't
> require that they produce "pseudo random" values if in fact, we are
> pretty sure TEPs won't actually implement this.

Understood.

-shane