Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Jen Linkova <furry13@gmail.com> Thu, 30 March 2017 22:14 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2F1295E7; Thu, 30 Mar 2017 15:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 x_IsCxudx0mC; Thu, 30 Mar 2017 15:14:05 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B7A12426E; Thu, 30 Mar 2017 15:14:05 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id y18so2823125itc.0; Thu, 30 Mar 2017 15:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xfRV0uNVwkm5pRQtWVuMEUfHqVsUdlRyijKL5Hc1Tpc=; b=mxy3f9V4DCMOycfXjjH2A2qd7e2Bhi4tbFdCBO/oq0tuFiNs4quSweD7TLupsN9ZOR VPVqIO5lYozHvm01lA5L8izBNTbN9yEjDwEaveGAJdZnZhnlXFFnAIUL42UTMmmgW754 DCSW4ryK2o2p910qhLxz6GAusOu2qijTRmd/xWdleBM47m6ex0XwApIXs54EQ4w2l4Vb gny/F/YyBr17e5SXRLAsEAmgsn+5qxQIfIodwAuYZozjyfpujMgqUypeB0/eaOtT99Pq e56f60TPkt1VP2GDCYOHEtDabLE1H2FDff2KqIFBcUZ4j6rtjskb/p0/qPXwBBTptXVS pfEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xfRV0uNVwkm5pRQtWVuMEUfHqVsUdlRyijKL5Hc1Tpc=; b=pSyyj9HXIIznRu6reg2h5u0nHaPYZtrM6AELzQBMWXeJYmxr9RpFthqO1v7UKQGnoQ v49Zmkwg3sz5lEm49q6nJdWmW6I1aelQlr80/GSk/99gHbmhLK410PSl2Kb9QGkxECsi pml+eCl2zaX9vmf6aaM3mwCcQUgIrdWydU7hc+SU1gpQik0lkszTDHuB1aY4xzoYSl/s 71NgUeEa7kYXHohUoLDMpKYSm4r0kcQ4MFWpVisleHQBMAyzSVUgrIPVZnYXrXeDjSux iSqxpkYM7rB93IX7Ybff0bh7UHKHV2TjHXogv2iBZy/PvUU4wy3Qp+Lx2eTOkU6KwBtG emug==
X-Gm-Message-State: AFeK/H17CtTMWQRTjQXatUqgwWD0rksqzHU80HS9VLtg8kmXi0LTqnTtIUk/NH5vOtAONRQafN5iBGd0pQq1eg==
X-Received: by 10.36.48.66 with SMTP id q63mr624614itq.18.1490912044818; Thu, 30 Mar 2017 15:14:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.184.197 with HTTP; Thu, 30 Mar 2017 15:13:44 -0700 (PDT)
In-Reply-To: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com>
From: Jen Linkova <furry13@gmail.com>
Date: Fri, 31 Mar 2017 00:13:44 +0200
Message-ID: <CAFU7BAS4zZ44ZRgmNSHBYvV9iWwRvn1X2Z-_-ncD-=E4mzhp9g@mail.gmail.com>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>, 6man WG <ipv6@ietf.org>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/M7yaIJSTzXaLlc77OnsDCLbpEMU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 22:14:07 -0000

On Wed, Mar 15, 2017 at 3:47 AM, Suresh Krishnan
<suresh.krishnan@ericsson.com> wrote:
> Thanks to everyone who commented during the IETF Last Call of draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft was mainly focused around the text in Section 4 that discusses the handling of extension headers. The biggest concern raised was that the current text is ambiguous on whether header insertion is allowed on intermediate nodes or not. There were some people arguing that an explicit prohibition is not necessary as the text is already clear, while others believed that explicitly listing the prohibitions will minimize any misunderstandings in the future. There was also a small number of people who wanted to explicitly allow header insertion and describe how to do it, but this was clearly out of scope for this draft (but may be in scope for future work in 6man). Overall, no one argued against the fact that the intent of the text in RFC2460 was to forbid insertion of extension headers on any other node but the source of the packet.  The only argument made against adding clarifying text was that the text was already clear. Given this, I believe there is consensus to add explicit text about header insertion into the draft before it progresses further. I have discussed this with the editor and the document shepherd and would like to propose the following text change.
>
> OLD (from -08):
>
>  The insertion of Extension Headers by any node other than the source
>  of the packet causes serious problems.  Two examples include breaking
>  the integrity checks provided by the Authentication Header Integrity
>  [RFC4302], and breaking Path MTU Discovery which can result in ICMP
>  error messages being sent to the source of the packet that did not
>  insert the header, rather than the node that inserted the header.
>
>  One approach to avoid these problems is to encapsulate the packet
>  using another IPv6 header and including the additional extension
>  header after the first IPv6 header, for example, as defined in
>  [RFC2473]
>
>  With one exception, extension headers are not processed by any node
>  along a packet's delivery path, until the packet reaches the node (or
>  each of the set of nodes, in the case of multicast) identified in the
>  Destination Address field of the IPv6 header...
>
> NEW:
>
>  With one exception, extension headers are not examined, processed,
>  inserted, or deleted by any node along a packet's delivery path,
>  until the packet reaches the node (or each of the set of nodes, in
>  the case of multicast) identified in the Destination Address field of
>  the IPv6 header...

I have some concerns with how that sentence AND the following note
comes together:

"  With one exception, extension headers are not examined, processed,
   inserted, or deleted by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  Note: If an intermediate forwarding node examines
   an extension header for any reason, it must do so in accordance with
   the provisions of [RFC7045].  "

I'm afraid that the lack of the normative language strikes back..
If 'are not examined" is to be interpreted as RFC2119 'MUST NOT',
then the following note conflicts with that statement. 'A node MUST
NOT examine EHs
but if it does it must do it as per RFC7045' - it is extremely controversial.

If ''are not examined" is to be read as RFC2119 'SHOULD NOT' then I
have a very good news for
those who would still like to insert/delete EHs: they can do it  as
long as  they have
"valid reasons in particular circumstances when the particular
behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.".
But from today's presentation I've got an impression that the
intention of this text was actually to prohibit EH insertion
(the sildes say 'no one argued against the fact that the intent of the
text in RFC2460
was to forbid insertion of extension headers on any other node but the source
of the packet.).

So to summarize: the proposed text either explicitly prohibits the
examination (and then it contradicts the next sentence and we need to
do smth with the note and RFC7045) OR it allows EH insertion - it
depends how the text is interpreted.

-- 
SY, Jen Linkova aka Furry