Eric Rescorla's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Fri, 21 April 2017 22:39 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7065129407; Fri, 21 Apr 2017 15:39:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan <otroan@employees.org>, 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org
Subject: Eric Rescorla's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149281434180.25836.10818713217769164593.idtracker@ietfa.amsl.com>
Date: Fri, 21 Apr 2017 15:39:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/oq6tbl5q9huH96VMIVQl9w5zPCk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 22:39:02 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-6man-rfc2460bis-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I get that this document is from a period before the style
became as uniformly to upper-casify RFC2119 keywords, but
but it seems like it might be a good idea to do that here.

It's a little hard to determine what is normative here, but S 4. says

   A full implementation of IPv6 includes implementation of the
   following extension headers:
      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication
      Encapsulating Security Payload

Given that 6434-bis seems to have backed away from IPsec, this
document needs to as well.

S 4.4.
Assuming I am reading this document correctly (and I've never
implemented v6 so I could be crazy), in order to implement
the routing header you need to decrement Segments Left,
but the document does not seem to say that.


S 4.5.
As I read this document the order of headers is only strongly
recommended, but the rules about fragmentation seem to absolutely
require a specific order:

      The Per-Fragment Headers consists of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

Is there a reason why the rules are not MUST?


S 4.5.
   The following conditions are not expected to occur, but are not
   considered errors if they do:
   
      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

If fragments follow different paths (not crazy) then the hop limit
will be different, right? So perhaps "not expected" is a bit strong.


S 8.4.
         Response packets that carry Routing headers that were derived
         by reversing the Routing header of the received packet IF AND
         ONLY IF the integrity and authenticity of the Source Address
         and Routing header from the received packet have been verified
         by the responder.

It's not clear to me how this works. If, as I suggest above, the
routing header gets changed in transit, how do you measure
the integrity and authenticity? Even if that is not the case,
and you use something like IPsec to provide integrity, why do you
trust whatever claims the sender makes about routing.