Subject: Pseudorandom Flow Labels

From: Shane Amante <[email-masked]>
Date: Tue, 5 Apr 2011 13:22:16 -0600

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Apr 2011 15:58:36 -0400

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

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

This is good stuff. For originating hosts (not TEPs) then, the
documents should reference RFC 6056 (they currently do not), point out
that ports following the recommendation have the necessary property
already, and suggest a way of mapping the port numbers (and whatever
other info would be good) into the Flow Label to be used.

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.

The problem I have with "pseudo random" is that it has properties that
I am not convinced the Flow Label necessarily needs to have. And the
complexity of getting real pseudo randomness in a simple
implementation may be too high.

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

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

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

> 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. 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. But don't
require that they produce "pseudo random" values if in fact, we are
pretty sure TEPs won't actually implement this.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Apr 2011 16:36:50 -0400

Case in point about how we are being *extremely* loose in using the
term "pseudo random".

If you look at draft-gont-6man-flowlabel-security-01, it proposes two
different algorithms for generating Flow Label values.

Unless I'm missing something, neither of them actually provides
"pseudo randomness". Both have subsequent Flow Label values simply
increment a counter to get to the next value. What these algorithms do
do is make it very hard for an off-site attacker to guess what Flow
Label values are being used. That is probably a good thing. But that
is not the same thing as saying that the Flow Labels that are
generated are "pseudo random", which is what the current Flow Label
documents are saying we need.

Part of my objection to the term "pseudo random" is that the term has
not been defined within the context of the Flow Label.

RFC 4086 "Randomness Requirements for Security" talks quite a bit
about pseudo randomness. I don't think we need that for the Flow
Label. But without carefully defining terms, that is what is
presumably being required...

Thomas

---

From: Shane Amante <[email-masked]>
Date: Tue, 5 Apr 2011 15:23:40 -0600

Thomas,

On Apr 5, 2011, at 13:58 MDT, Thomas Narten wrote:
[--snip--]
> 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".

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

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

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

> Label value. I doubt you are suggesting that.

You are correct.

> But the current
> 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

Understood.

-shane

---

From: james woodyatt <[email-masked]>
Date: Tue, 05 Apr 2011 14:44:25 -0700

On Apr 5, 2011, at 13:36 , Thomas Narten wrote:
> 
> Case in point about how we are being *extremely* loose in using the term "pseudo random".

I share your concern.  Would replacing "pseudo-random" with "low discrepancy" address your concerns?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Apr 2011 17:48:22 -0400

>  discrepancy" address your concerns?

Replacing the term with another would be fine. That said, the real
issue is we need to define what we mean by whatever term we use.

Thomas

---

From: james woodyatt <[email-masked]>
Date: Tue, 05 Apr 2011 15:49:24 -0700

On Apr 5, 2011, at 14:48 , Thomas Narten wrote:
> [I wrote:]
> Replacing the term with another would be fine. That said, the real issue is we need to define what we mean by whatever term we use.

Discrepancy is a measure of the deviation of a point set from a uniform distribution.  Or, so Wolfram MathWorld tells me.  <http://mathworld.wolfram.com/Discrepancy.html>   A low discrepancy sequence would be one that has *approximately* uniform distribution [though, not necessarily *exactly* uniform], which is what seems to be the object of the game here.

There are many excellent well-known low discrepancy sequences to choose from, and I'm not sure IETF needs to specify a standard one, but it's possible one could be found if we really tried hard.  If you want to get hideously pedantic, you could specify a maximum discrepancy; I'm sure Timothy Winters and his crew would just melt if you did that.

Note: another term for "low discrepancy" is "quasi-random" but I'm not sure we want to go there.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Apr 2011 20:08:24 -0400

> Discrepancy is a measure of the deviation of a point set from a
>  uniform distribution.

Actually, the core issue is that we do not need the Flow Label to be
uniformly distributed.

In an ideal world, that would be a nice property to have. And all
things equal, better to have that propert than not.

But for ECMP and other types of things being discussed, such a
property is simply *not* required to get perfectly fine results.

What is *required* is that the hash function (or whatever function
that is used) on the router maps the tuples in a *uniform* way across
the range of possible outputs.

If you have 10 links, and all your Flow Labels are clustered around
low ten values, but in an approximately uniform way, a simple modulo
hash will get you the kind of distribution you need.

The range of values of the flow label itself does not need to be
uniformly distributed.

That is why incrementing a counter for each new flow provides adequate
properties. I remain unconvinced that we need to require that they
exhibit pseudo randomness, or even be uniform.

If that is a requirement, I'd like to see the justification, not just
hand waiving.

Thomas

---

From: John Leslie <[email-masked]>
Date: Tue, 5 Apr 2011 20:31:52 -0400

> The range of values of the flow label itself does not need to be

   I'm strongly in favor of stating the requirement this way (though
perhaps more wordsmithing can make it even better).

   AFAICT, this is our actual concern -- that an Equal Cost Multipath
router can do a simple hash function to distribute flows across multiple
links without endangering in-order delivery of the individual flows
identified in the Flow Label.

   (I'd also like a statement to that effect, or whatever it is we
actually mean to accomplish.)

> If that is a requirement, I'd like to see the justification, not just

   Me too.

--
John Leslie <[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Tue, 05 Apr 2011 17:44:25 -0700

> the range of possible outputs.

Then it seems like "Equidistributed Sequence" is the precise term you want.

I too would like to see the case for Low Discrepancy vs. Equidistributed made more clear.  One of the arguments I suppose could be made for Low Discrepancy is that it would provide a guarantee that *any* substring of the full 20-bit flow label could be taken as an input to a function that maps with low discrepancy to a particular load-sharing element.  Equidistributed does not provide any such guarantee and requires A) that the domain of the function be the full label, and B) the function to map an equidistributed domain to a low discrepancy codomain.  Are those functions any cheaper?  I doubt it.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 Apr 2011 20:15:18 -0500

Snipped from RFC 4193 is this text.  "pseudo-randomly allocated global
ID".  If pseudo-random was accepted in this RFC, why are we discussing
pseudo-random again?  One reason is acceptable to me that over the years
we learn to be more precise or more audience read the documents and thus
more folks can ask for a better choice for a term.  I agree with Thomas
that we can pick a term but then the term has to be defined clearly.
Here is some text from RFC 4193 one could use.  This way we avoid the
IETF specifying what pseudo-random algorithm to use but still get a as
precise as possible definition that has been accepted in other RFCs such
as RFC 4193.

[Locally assigned Global IDs MUST be generated with a pseudo-random
algorithm consistent with [RANDOM].]  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
james woodyatt
Sent: Tuesday, April 05, 2011 6:49 PM
To: Thomas Narten
Cc: 6MAN Working Group
Subject: Re: Pseudorandom Flow Labels

Discrepancy is a measure of the deviation of a point set from a uniform
distribution.  Or, so Wolfram MathWorld tells me.
<http://mathworld.wolfram.com/Discrepancy.html>   A low discrepancy
sequence would be one that has *approximately* uniform distribution
[though, not necessarily *exactly* uniform], which is what seems to be
the object of the game here.

There are many excellent well-known low discrepancy sequences to choose
from, and I'm not sure IETF needs to specify a standard one, but it's
possible one could be found if we really tried hard.  If you want to get
hideously pedantic, you could specify a maximum discrepancy; I'm sure
Timothy Winters and his crew would just melt if you did that.

Note: another term for "low discrepancy" is "quasi-random" but I'm not
sure we want to go there.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 Apr 2011 20:34:53 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Narten
Sent: Tuesday, April 05, 2011 8:08 PM
To: james woodyatt
Cc: 6MAN Working Group
Subject: Re: Pseudorandom Flow Labels

>If that is a requirement, I'd like to see the justification, not just

How about something like the text below:

A property of the flow label is that when the flow label is used a key
to a hash function the function produces a uniform distribution of hash
values.  Thus, incrementing a counter for each new flow is one means to
achieve the property described in the previous sentence. 

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 19:18:45 +1200

I have a quite strongly held belief that trying to be mathematically
precise (not to say pedantic) has never worked well in IETF protocols.
(OK, there is one possible exception, namely NTP.) Our implementors
are not going to understand subtleties such as 'low discrepancy'.
IMHO, arguing about the correct mathematical formulation is not quite the
point.

We do seem to agree that the important point is that the final output
of the hash function used to select between alternate routes is
uniformly distributed. Asking for flow label values that are reasonably
well distributed as input to that hash function is enough. Any stateless
method that provides this will do. Frankly I don't care whether we all
it pseudo-random, quasi-random, or mashed potato. (Counting from 1 will
not do, because it's stateful.)

Regards
   Brian Carpenter

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 Apr 2011 09:24:44 -0400

> precise (not to say pedantic) has never worked well in IETF

Agree completely. :-)

> well distributed as input to that hash function is enough.

Right. But now let me flip-flop a bit. In order to understand what
"reasonably well distributed as input" actually means, we need to
understand what algorithms are being used by routers when doing ECMP
and the like. If we had data about what algorithms are actually used
(or are reasonable to implement) we can talk about the distribution
properties that are needed on the input side of the hash.

Is there any such data? What do the router implementor say to this?

I feel like much of the discussion so far about what kind of
distribution is needed has been handwaving.

To be clear, what I'd like is simple rules on how to set the Flow
Label, but no simpler than is necessary to make the ECMP stuff work
well in practice.

Thomas

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 14:35:40 -0300

Hi, Shane,

On 05/04/2011 04:22 p.m., Shane Amante wrote:
> 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. 

And even if they had to implement this support "from scratch", the code
would be very small -- see e.g. the recent patch for port randomization
that was posted to freebsd-net.

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

+1 for pseudo-random Flow Labels :-)

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 15:01:10 -0300

> hard. Provide them with a suggested algorithm. Don't just say "make it

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

> guarantee we'd get wide spread implementation.

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

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

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

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

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 15:22:10 -0300

Thomas,

> Case in point about how we are being *extremely* loose in using the
[....]
> not been defined within the context of the Flow Label.

You raise a very good point, indeed. For instance, when we talk about
e.g. "port randomization", we're really talking about "producing port
numbers that are unpredictable by off-path attackers".

To make this terminology issue worse, it has been argued a few times (by
some mathematician IETFers) that the properties that we need for the
"hash" functions in the hash-based algorithms are really that of PRFs
(Pseudo Random Functions) (i.e., hash functions being a specific example).

In summary, I agree with the terminology issue that you've raised. I'd
probably argue that the best way to go is to specify which properties we
want for Flow Labels, such as they have been specified for port numbers
in RFC 6056. Namely:

* We want Flow Labels that unpredictable by off-path attackers (history
has taught us that this is a good proactive measure)
* We want an algorithm for generating FL that produces FLs that do not
repeat with a high frequency (i.e., they are distributed normally)

One possible algorithm for achieving these properties is calling a
random()-like function. But there are others, such as the hash-based
algorithms specified in draft-gont-6man-flowlabel-security.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 15:34:19 -0300

Shane,

On 05/04/2011 06:23 p.m., Shane Amante wrote:
> 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".

Note that e.g. Linux implements the hash-based algorithm in RFC 6056,
rather than the random()-based algorithms. -- FWIW, see my response to
Thomas wrt the terminology that we are using.

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

We should have already learned the lesson that this is a really bad choice.

> or, b)  Don't cycle through the full-range of
> flow-label values; 

This would be an implementation bug.

> or, c)  a [large] set of hosts experience
> synchronization of flow-label values; 

Given that the FL field is large enough, and that the offset itself is
random, I deem this as *very* unlikely. Also, for synchronization to
occur, all those hosts would need to have the same frequency of
flows/time. -- and since the src IP would be also used for ECMP/LAG,
then I don't think that this would be a big deal, either.

> or, d)  Reset back to
> flow-label "1" after some short time period ... 

This would be a really dumb thing to do, btw.

Note: I'm not arguing that a random()-based algorithm would be a bad
idea. I'm arguing that such an algorithm is not necessarily the only
possible one, and not necessarily the best possible option, either.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 15:47:30 -0300

Hi, Hermant,

On 05/04/2011 10:15 p.m., Hemant Singh (shemant) wrote:
> pseudo-random again?  

Because the requirements are different. For RFC 4193, the IIDs must be
unpredictable to any host in the Internet. For FLs, they only need to be
unpredictable by off-path attackers.

For RFC4193, it wouldn't make sense to select them with a hash-based
approach such as the one in draft-gont-6man-flolabel-security, as while
you get incremental addresses, you could still be tracked. But this does
not apply to FLs -- see the et of requirements in one of my other posts.

Thanks,

---

From: John Leslie <[email-masked]>
Date: Wed, 6 Apr 2011 16:44:24 -0400

>   has taught us that this is a good proactive measure)

   I'm afraid I don't follow: what sort of attack could an off-path
attacker mount by correctly guessing the Flow Label?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 18:22:05 -0300

John,

> attacker mount by correctly guessing the Flow Label?

Play with ECMP/LAG. And, it's clear you could never implement something
like draft-blake-ipv6-flow-label-nonce-02 if FLs are predictable.

Thanks,

---

From: Shane Amante <[email-masked]>
Date: Wed, 6 Apr 2011 15:44:33 -0600

Fernando, Thomas,

> repeat with a high frequency (i.e., they are distributed normally)

I like your (attempt at) a more precise definition that Thomas has been asking for.

I would think another desirable property of (host-generated?) flow-labels might be that, by default, they strive to preserve privacy of the transmitter.  IOW, flow-labels cannot be used to track individuals (over time), because they are traceable back to a particular implementation or, worse, a specific device.

> algorithms specified in draft-gont-6man-flowlabel-security.

Right.

-shane

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 19:16:12 -0300

Hi, Shane,

On 06/04/2011 06:44 p.m., Shane Amante wrote:

>> * We want Flow Labels that unpredictable by off-path attackers
>> (history has taught us that this is a good proactive measure) * We
>> want an algorithm for generating FL that produces FLs that do not 
> I would think another desirable property of (host-generated?)
> flow-labels might be that, by default, they strive to preserve
> privacy of the transmitter.  IOW, flow-labels cannot be used to track
> individuals (over time), because they are traceable back to a
> particular implementation or, worse, a specific device.

While I agree with this, this seems to be like a requirement for
psedu-randomness.

That is, if all hosts in my local network set the FL with random(), and
only my hosts implements the hash based scheme in e.g.
draft-gont-flowlabel-security, then you might argue that the FL could be
exploited to track me (or well, actually identify my host in my local
network, even if I'm using privacy addresses).

But this is already the case for virtually all protocol parameters on
which there's some room for choice. (From TCP's initial window to IPv6
Hop Limit value, etc.)

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2011 19:32:40 +1200

Setting the flow label by calling random() cannot be a stateless
method - it would mean storing the value for use on future packets
of the same flow. We need a stateless method.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Apr 2011 05:20:19 -0300

> of the same flow. We need a stateless method.

Oops, you're right. (Although for FLs set by end nodes this shouldn't
matter much)

Anyway, you have two stateless methods in
draft-gont-6man-flowlabel-security.... :-)

Which raises the question ;-) about whether we should work on this I-D.
FWIW, IIRC the wg had been polled about adoption of this document as a
wg item, but I think only one folk (you?) responded.

Thanks!

Best regards,

---

From: John Leslie <[email-masked]>
Date: Thu, 7 Apr 2011 08:10:25 -0400

Fernando Gont <[email-masked]> wrote:
> Play with ECMP/LAG.

   I'm afraid you'll need to be more specific: I still don't see an
attack against the sender here.

> And, it's clear you could never implement something like
> draft-blake-ipv6-flow-label-nonce-02 if FLs are predictable.

   I did think of that, but decided I'd never want to use such a thing.
There are quite a few better ways to accomplish the goal, and far too
many opportunities for middleboxes to screw it up.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Apr 2011 14:13:29 -0300

> Then you simply increment the FL for each packet you send for that flow.

Sorry. Please let me correct myself:

The hash is computed only once for each flow. And every time a new flow
is created, a global counter is incremented.

When a new flow is created, the FL is selected by the expresion:
FL = hash(src ip, dst ip) + counter
and the counter is incremented

So, the FL of successive Flow Labels between the same set of IPv6
addresses will have monotonically-increasing FLs.

The table in
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-01
illustrates this much better.

Thanks,