Re: Pseudorandom Flow Labels

[Fernando Gont <[e-mail]>]

On 05/04/2011 04:58 p.m., Thomas Narten wrote:
> At the core, my concern with "pseudo random" is that I (as an
> implementor) do not know what I have to do do satisfy that requirement
> and I think in some cases that cost is higher than justified by the
> benefit. The current documents do not provide enough concrete
> guidance, IMO. If we want folk to actually set the Flow Label to a
> good value, tell them what to do. Don't make them think too
> hard. Provide them with a suggested algorithm. Don't just say "make it
> psuedo random".

draft-gont-6man-flowlabel-security aims at addressing this issue.



> More to the point, if this could be done in a "stateless" manner,
> e.g., by the routine that sends IP datagrams, that would be
> nice. I.e., if the IP "send" routine could easily set the Flow Label
> whenever it was zero, in a "stateless" manner, that would almost
> guarantee we'd get wide spread implementation.

FWIW, all of the algorithms in the port randomization RFC (including the
hash-based ones) are stateless.



> 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.

I think that for this sort of ting, "pseudo-random numbers" are your
friend. There have been a variety of cases in recent history in which
predictable values have been used (TCP ISNs, IP IDs, TCP port numbers,
etc.), and only later we realized that there were implications to that.
-- which then lead to patches such that pseudo-random values were used,
instead.


>> 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.

Agreed. For instance, the hash-based algorithm recommended in
draft-gont-6man-flowlabel-security results in a linear function for each
(src IP, dst IP) (that has a random offset...)




>> 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.

What we want is unpredictable flow numbers, with a low frequency of FL
reuse. A typical call to random() would be just *one*¨way to do it. But,
as noted, there are others.

For hash-based algorithms, you only compute the hash once for each flow.
Then you simply increment the FL for each packet you send for that flow.




> 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. 

Not necessarily: hash functions are your friend (whether you might or
might not want to implement this (e.g., for performance reasons) is a
different issue)

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1