Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Ole Troan <otroan@employees.org> Mon, 04 August 2014 09:51 UTC

Return-Path: <otroan@employees.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91D21B298A; Mon, 4 Aug 2014 02:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level:
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkfDDUwHcbEt; Mon, 4 Aug 2014 02:51:02 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B501B298C; Mon, 4 Aug 2014 02:51:00 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmEGAKJW31OtJssW/2dsb2JhbABbhDaCeNB2BAIBgS53hAMBAQQBI1YFCwsYAgImAgIhNgYTiC4DCQitZI9sDYcAF4Esi3OBViQzB4J5NoEcAQSZf5A+hiiDTzsvAYEE
X-IronPort-AV: E=Sophos;i="5.01,797,1400025600"; d="scan'208";a="132591672"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Aug 2014 09:50:59 +0000
Received: from dhcp-10-61-106-70.cisco.com (dhcp-10-61-106-70.cisco.com [10.61.106.70]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s749ovhq019970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2014 09:50:58 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <53DBF16F.2090202@gmail.com>
Date: Mon, 4 Aug 2014 11:50:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.org>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1971.5)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/CoviHxmzzLhbva3_Cp4EIkc6_d8
X-Mailman-Approved-At: Mon, 04 Aug 2014 02:52:09 -0700
Cc: 6man WG <ipv6@ietf.org>, roll <roll@ietf.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 09:51:04 -0000

> On 01 Aug 2014, at 21:58 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 01/08/2014 23:23, Carsten Bormann wrote:
> ...
>> The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”.  Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it.  So the evolution just eats it.  Teachable moment.
> 
> RFC 6437 co-author hat on (but only speaking for myself, of course):
> 
> My opinion is that the draft doesn't retract RFC 6437. As I already said,
> 6437 attempts to recognise the reality that middleboxes can mess with the
> flow label, and to set conditions for that messing such that remote systems
> can still use it for load balancing. Since it's unprotected by checksum or
> crypto, there is a strict limit to how much it can be trusted anyway. As
> the RFC says:
> 
>   There is no way to verify whether a flow label has been modified en
>   route or whether it belongs to a uniform distribution.  Therefore, no
>   Internet-wide mechanism can depend mathematically on unmodified and
>   uniformly distributed flow labels; they have a "best effort" quality.
>   Implementers should be aware that the flow label is an unprotected
>   field that could have been accidentally or intentionally changed en
>   route (see Section 6).
> 
> It is true that the RFC also says
> 
>   A forwarding node
>   MUST either leave a non-zero flow label value unchanged or change it
>   only for compelling operational security reasons...
> 
> There is a case for arguing that flow-label-for-rpl should carry the
> legend "Updates: 6437 (if approved)" because it adds another exception
> to this sentence. There is also a case for arguing that flow-label-for-rpl
> is a stateful mechanism, out of scope for RFC 6437 according to
> Section 4 of that RFC.
> 
> Either way, I don't see a problem.

I see the principles in these two documents as mutually exclusive:
RFC6437: middleboxes can mess with the flow label
-flow-label-for-rpl: networks uses flow label field as an immutable protocol field

you can't both use the flow label as an immutable protocol field and have middleboxes rewriting it.

cheers,
Ole