Subject: [Fwd: I-D Action:draft-ietf-6man-flow-update-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Dec 2010 12:40:31 +1300

Hi,

This is intended to reflect the various comments made in Beijing,
notably strengthening the points about the flow label not being
changed en route. Please review - if the WG is generally OK
with this version, we'll start to think about RFC3697bis.

  Brian + Sheng + Shane

-------- Original Message --------
Subject: I-D Action:draft-ietf-6man-flow-update-00.txt
Date: Thu, 02 Dec 2010 15:00:02 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Update to the IPv6 flow label specification
	Author(s)       : S. Amante, et al.
	Filename        : draft-ietf-6man-flow-update-00.txt
	Pages           : 13
	Date            : 2010-12-02

Various published proposals for use of the IPv6 flow label are
incompatible with its existing specification in RFC 3697.
Furthermore, very little practical use is made of the flow label,
partly due to some uncertainties about the correct interpretation of
the specification.  This document proposes changes to the
specification in order to clarify it, making it clear what types of
usage are possible, and to introduce some additional flexibility.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-00.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Dec 2010 14:14:02 +1300

Hi,

The authors have received one off-list comment on this version,
requesting additional clarification of the text associated with
this recommendation:

>>        2.  A network domain MUST NOT forward packets outside the domain
>>            whose flow label values are other than zero or pseudo-random.
>> 

Does anyone else have comments, or are we getting somewhere near agreement?

Regards
   Brian Carpenter

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Dec 2010 17:26:20 -0800

So you're really really not interested in discussing the one use case that people have actually talked about wanting, which has to do with load sharing? What use case are you addressing?

On Dec 14, 2010, at 5:14 PM, Brian E Carpenter wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Dec 2010 15:00:39 +1300

We do have draft-ietf-6man-flow-ecmp, which is focussed on ECMP/LAG
load sharing in tunnels. The reason we're proposing to recommend
pseudo-random labels by default is so that load sharing becomes a
natural use case.

When we did RFC 3697, there was strong pressure to keep the spec
as "pure" as possible. I was sort of assuming the same approach
this time around. Of course, the WG can decide otherwise, but
embedding the use case(s) in the protocol spec does lengthen
the discussion considerably.

Regards
   Brian

---

From: Steven Blake <[email-masked]>
Date: Tue, 14 Dec 2010 21:58:49 -0500

> Does anyone else have comments, or are we getting somewhere near
agreement?

Brian,

The paragraph this excerpt is taken from is clear, but by itself, this
sentence (as well as the last one of the paragraph) suggests that a domain
has to make a decision based on information that may be unavailable (i.e.,
if no node in the domain rewrote the flow label value).  Please consider
rephrasing this.

Regards,

// Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Dec 2010 16:16:04 +1300

> if no node in the domain rewrote the flow label value).  Please consider

It's hard to make the sentence on its own avoid this problem, which is
exactly why the additional text was added after the discussion in Beijing.
I guess I should never quote it out of context.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Dec 2010 17:39:07 -0300

Hi, Brian et al.,

(I was meaning to send this one more than a week ago... but apparently
this one got stuck in my "Drafts" folder)

In general, the document looks good. However, there are IMO a few issues
that should probably be fixed.

In the Abstract, one gets the impression that this document actually
updates RFC 3697. I think this should be more clear in the abstract, and
also possibly in the Introduction.

In Section 1, this paragraph is duplicated:

>    RFC 2460 mandates only that "Hosts or routers that do not support the
>    functions of the Flow Label field are required to set the field to
>    zero when originating a packet, pass the field on unchanged when
>    forwarding a packet, and ignore the field when receiving a packet."

I'd remove the second instance of it.

Section 2 states:

>    Also, it could be used as a covert data channel, since apparently
>    pseudo-random flow label values could in fact consist of encrypted
>    data. 

Actually, an attacker willing to exploit this field for a covert channel
would *not* set it to a pseudo-random value, but simply to the data
bytes it is meaning to transfer over the covert channel.

Section 2:

> In this
>    sense, any use of the flow label must be viewed as an optimisation on
>    a best effort basis; a packet with a changed (or zero) flow label
>    value should never cause a hard failure.

If a packet with a changed flow label should not cause malfunction, and
as you correctly note the Flow Label is not even covered by a checksum,
the requirement of "A forwarding node MUST NOT change the flow label
value in an arriving packet if it is non-zero" (in Section 4, page 7) is
bogus. If anything, it should be a "SHOULD NOT".

>    o  The flow label is no longer unrealistically asserted to be
>       strictly immutable; it is recognised that it may, incorrectly, be
>       changed en route.  In some circumstances this will break end-to-
>       end usage, e.g. potential detection of third-party spoofing
>       attacks [I-D.gont-6man-flowlabel-security].

end-to-end usage is already broken by the fact that the Flow Label is
not protected in any way. e.g., you cannot reliably use the Flow Label
to protect against off-path spoofing attacks. (This is also exacerbated
by some implementations not even setting the Flow Label consistently).

Section 4 (page 7):

>    3.  A forwarding node MUST NOT change the flow label value in an
>        arriving packet if it is non-zero.

See above.

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Dec 2010 10:33:03 +1300

Fernando,

Thanks for the comments. About the non-editorial points:

On 2010-12-16 09:39, Fernando Gont wrote:
...
> bytes it is meaning to transfer over the covert channel.

Yes, that is what the text is supposed to mean. When you look at dbeef,
you can't tell whether it's a perfectly good random number, part of a
cleartext message about steak, or part of a cyphertext. Would it
be more general to say

    Also, it could be used as a covert data channel, since apparently
    pseudo-random flow label values could in fact consist of useful
    data.

> bogus. If anything, it should be a "SHOULD NOT".

I understood the WG preference to be for stating the *requirement* as
MUST NOT. Conformance is another matter.

> by some implementations not even setting the Flow Label consistently).

Well, if you make that argument, every nonce-based security solution is
broken, because there is always a finite chance that an attacker can guess
the nonce. Again, my reading of the WG discussion is to accept the
situation as described in the draft.

>>        arriving packet if it is non-zero.

See above ;-)

Regards

   Brian