Subject: Question about the Flow Label in Node Req (RFC6434)

From: Fernando Gont <[email-masked]>
Date: Wed, 10 Feb 2016 13:55:28 -0300

Folks,

Section 5.1 of the aforementioned RFC says:

   All nodes SHOULD support the setting and use of the IPv6 Flow Label
   field as defined in the IPv6 Flow Label specification [RFC6437].
   Forwarding nodes such as routers and load distributors MUST NOT
   depend only on Flow Label values being uniformly distributed.  It is
   RECOMMENDED that source hosts support the flow label by setting the
   Flow Label field for all packets of a given flow to the same value
   chosen from an approximation to a discrete uniform distribution.

What does "MUST NOT depend only on Flow Label values being uniformly
distributed" really mean? Does it mean that if we're using the FL as
input to a hash function fr ECMP, we should also include the src and dst
addresses, or does it mean that we should also include e.g. upper
protocol type and port numbers as input of such hash function?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Feb 2016 13:25:20 +1300

Hi Fernando,
On 11/02/2016 05:55, Fernando Gont wrote:
> distributed" really mean? 

That's a direct quotation from RFC 6437, included here because
it's important. In RFC 6437 there is more explanation:

   o  Forwarding nodes such as routers and load distributors MUST NOT
      depend only on Flow Label values being uniformly distributed.  In
      any usage such as a hash key for load distribution, the Flow Label
      bits MUST be combined at least with bits from other sources within
      the packet, so as to produce a constant hash value for each flow
      and a suitable distribution of hash values across flows.
      Typically, the other fields used will be some or all components of
      the usual 5-tuple.  In this way, load distribution will still
      occur even if the Flow Label values are poorly distributed.

It's a precaution against a flow label having a value with very
little entropy (such as zero, or a small integer).

> Does it mean that if we're using the FL as

That was intentionally underspecified, because (as some of the discussion
here has shown) the exact description of the hash tends to be proprietary
and not something the operators want to see in the newspaper, because
it might help somebody to tailor an attack.

Hope that helps,

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2016 08:15:37 -0300

On 02/10/2016 09:25 PM, Brian E Carpenter wrote:
> That's a direct quotation from RFC 6437,

Ooops, my bad, I should have checked (but assumed it wasn't a quote from
RFC6437).

> included here because

mm.. then... should the requirement on the FL setting/geneation be
stronger (if needed?) -- i.e., we'd really want that if the FL is set,
the middlebox/router doesn't really *need* to get the upper-layer ports,
etc.

> it might help somebody to tailor an attack.

I guess some suggested possible algorithms might help. -- otherwise I'd
expect yet another member for:
<https://tools.ietf.org/html/draft-gont-predictable-protocol-ids>

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Feb 2016 08:33:34 +1300

> the middlebox/router doesn't really *need* to get the upper-layer ports,

You won't find me disagreeing with that.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2016 16:42:43 -0300

> You won't find me disagreeing with that.

I mean, the requirement should not only be strong "to set", but also in
the quality of the FL. Such that if it is set, we can rely on it.

Otherwise, a poor FL is not much better than no FL at all...

Cheers,