RE: New Version Notification for draft-kampanakis-6man-ipv6-eh-parsing-00.txt

["C. M. Heard" <[e-mail]>]

Greetings,

Here are some things that I perceive as issues with this draft, 
along with suggestions for how to fix them.

First: not all devices that process IPv6 header header chains to 
enforce policies match (or even care about) the content of IPv6 
extension headers; all they want to to is to traverse the header 
chain to find the upper-layer header.  Examples are RA-Guard 
(http://tools.ietf.org/html/rfc7113)  and DHCPv6-Shield 
(http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield).  For 
those functions extension headers do not matter so long as the 
transport header can be found and inspected; the implementation 
advice for the RA-Guard and DHCPv6-Shield filters is to pass 
everything that can be positively identified as NOT being a 
forbidden RA message or DHCPv6 message.

For that reason, I would recommend the following global changes:

<CURRENT TEXT>
intermediate devices that enforce policies by matching on IPv6 EHs (ACLs, stateful inspection and firewalling)
</CURRENT TEXT>

<PROPOSED TEXT>
intermediate devices that process IPv6 header chains in order to enforce policies
</PROPOSED TEXT>

<CURRENT TEXT>
an intermediate device that enforces policies by matching on IPv6 EHs (ACLs, stateful inspection and firewalling)
</CURRENT TEXT>

<PROPOSED TEXT>
an intermediate device that processed IPv6 header chains in order to enforce policies
</PROPOSED TEXT>


Now for some specific issues.

<CURRENT TEXT>
   Guideline 4: According to Section 4.1 of [RFC2460], when a end-host
   processes a IPv6 packet with multiple DestOpt EHs,

   o  if there is no RH EH in the packet, then only the final
      destination host SHOULD process only the last DestOpt EH.

   o  if there is a RH in the packet

      *  if the node is the final destination, then it SHOULD process
         all the DestOpt EHs in the packet.

      *  if the node is one of the destinations in the RH, it SHOULD
         only process the DestOpt EHs in the chain that are before the
         RH EH.
</CURRENT TEXT>

It would seem that these rules should apply to end systems or to 
intermediate systems that do not enforce policies, but that's not quite 
what is said.  Also, I think that the first bullet is simply wrong.  
The relevant note in RFC 2460 says:

           note 1: for options to be processed by the first destination
                   that appears in the IPv6 Destination Address field
                   plus subsequent destinations listed in the Routing
                   header.

so the final destination end system should process ALL of the DestOPt 
EHs in the packet.  Here is proposed replacement text:

<PROPOSED TEXT>
   Guideline 4: As specified in Section 4.1 of [RFC2460], when a end-host
   or an intermediate system that does not inspect IPv6 header chains in
   order to enforce policies processes an IPv6 packet with multiple DestOpt
   EHs,

   o  if there is no RH EH in the packet, then the final
      destination host alone SHOULD process all the DestOpt EHs
      in the packet.

   o  if there is a RH in the packet

      *  if the node is the final destination, then it SHOULD process
         all the DestOpt EHs in the packet.

      *  if the node is one of the destinations in the RH, it SHOULD
         only process the DestOpt EHs in the chain that are before the
         RH EH.
</PROPOSED TEXT>


Given the impossibility of distinguishing between an unknown 
extension header and an unknown upper-layer protocol, I believe that 
the following text is problematic:

<CURRENT TEXT>
5.  Other guidelines

   Guideline 7: Unknown Eh

   o  As defined in Section 4 of [RFC2460], end-hosts should discard
      packets with unknown EH types and send an ICMP Parameter Problem
      message to the source of the packet.

   o  Intermediate devices that enforce policies (ACLs, stateful
      inspection and firewalling) by matching on IPv6 EHs MUST only drop
      unknown EH as part of configuration policy (Section 2.1 of
      [RFC7045]).
</CURRENT TEXT>

Here is the proposed replacement, which would require adding a 
reference to RFC 6564:

<PROPOSED TEXT>
5.  Other guidelines

   Since IPv6 Extension Headers and upper-layer protocols share the same
   namespace (the "Assigned Internet Protocol Numbers" registry/namespace),
   it is impossible to  tell whether an unrecognized Next Header value refers
   to an IPv6 Extension Header to to an unrecognized upper-layer protocol,
   [RFC6564] notwithstanding.  Thus, when parsing an IPv6 header chain:

   Guideline 7: Unecognized Next Header values

   o  As specified in Section 4 of [RFC2460], end-hosts should discard packets
      with unrecognized Next Header values and send an ICMP Parameter Problem
      message to the source of the packet, with an ICMP Code value of 1
      ("unrecognized Next Header type encountered") and the ICMP Pointer field
      containing the offset of the unrecognized value within the original packet.

   o  Intermediate devices that process IPv6 header chains in order to enforce
      policies MUST NOT attempt to continue parsing an IPv6 header chain after
      encountering an unrecognized Next Header value.  Per Section 2.1 of [RFC7045],
      such systems MUST be configurable to allow such packets, but the default
      configuration MAY drop such packets.
</PROPOSED TEXT>


And finally I recommend changing

<CURRENT TEXT>
   Guideline 8: Intermediate or end-hosts MUST process a RH in an IPv6
   packet only when the host's address is the same as the packet's IPv6
   Destination Address.  (Section 4.4 of [RFC2460])
</CURRENT TEXT>

to

<PROPOSED TEXT>
   Guideline 8: End-hosts or intermediate systems that do not process
   IPv6 header chains in order to enforce policies MUST process an RH
   in an IPv6 packet only when the node's address is the same as the
   packet's IPv6 Destination Address.  (Section 4.4 of [RFC2460])
</PROPOSED TEXT>


I agree with Brian Carpenter that the implementation advice in this 
draft is needed.  I would like to believe that with the changes 
proposed above (or something similar to them) it could subsume 
implementation guide aspects of Fernando Gont's recent draft 
http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header, 
and I freely confess to stealing some of Fernando's excellent text.

Thanks and regards,

Mike Heard


On Mon, 9 Jun 2014, Panos Kampanakis (pkampana) wrote:
> Thank you Brian.
> 
> I will certainly address all these along with your previous MUST 
> NOT comment in the next iteration.
> 
> As for BCP, I think it could be either Informational or BCP. I 
> don't feel strongly about it. I will defer to the chairs and the 
> rest of the group, if this doc ends up being adopted and a WG 
> item. We can certainly change it.
> 
> Panos
> 
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Sunday, June 08, 2014 1:04 AM
> To: Panos Kampanakis (pkampana)
> Cc: [e-mail]
> Subject: Re: New Version Notification for draft-kampanakis-6man-ipv6-eh-parsing-00.txt
> 
> Panos,
> 
> I think this draft fills a gap. In fact I wonder whether it shouldn't
> be a BCP, so that it gets anough attention.
> 
> I do have a few comments, and I hope that some real implementors
> can have a look too.
> 
> > 1.  Introduction
> ...
> >    [RFC2460]
> >    describes some IPv6 EH recommendations of the order and allowed
> >    occurrences of headers, but it does not provide other guidance on how
> >    EHs should be parsed. 
> 
> I apologise for plugging my own RFC, but I think it's important to insert
> something like this:
> 
>  [RFC7045] updates RFC 2460 by specifying the required behavior of
>  middleboxes when handing an EH chain, but it does not go into detail
>  about the parsing process.
> 
> (The reason is that we really need all those middlebox implementors to
> look at the IETF's latest thinking on this. There is a lot of code
> out there based on careless reading of RFC 2460.)
> 
> >  Guideline 2: From Section 5 of [RFC7112], when parsing an EH chain,
> 
> That reads as if you are quoting RFC 7112, but you are not. Is this
> what you mean?:
> 
>  Guideline 2: As a consequence of Section 5 of [RFC7112], when parsing an EH chain,
> 
> Then you have this phrase twice:
> 
> > field is not an Upper Layer (UL) protocol (i.e.  TCP) 
> 
> I hope you mean "(e.g. TCP)" because this would apply to any
> protocol, not just TCP.
> 
> Also, you could add a note that the current list of defined EH values
> is maintained by IANA in the "IPv6 Extension Header Types" registry
> created by RFC 7045. This registry is intended precisely as a
> convenient reference for implementors.
> 
> > Guideline 3: Thus, when parsing an EH chain,
> ...
> > o  an intermediate device that enforces policies (ACLs, stateful
> >    inspection and firewalling) by matching on IPv6 EHs MUST discard
> >    packets that have an HbH EH that is not first in the chain
> >    (Section 2.2 of [RFC7045]).  If the device is not parsing the EH
> >    chain, it MAY NOT discard the packets.
> 
> I've already mentioned in private mail that this needs to be MUST NOT.
> However, a picky implementor will want to know how a device that is
> not parsing the header chain will even know that there is a HbH EH
> that is not first.
> 
> > 4.  Parsing malformed EHs
> ...
> >    If the data of the last EH or the UL
> >    Header plus its data does not align with the original IPv6 Header
> >    Payload Length the packet MUST be dropped unless another policy step
> >    already discarded it.
> 
> I think this is inconsistent with a statement in RFC 2460:
> 
> > 4.7 No Next Header
> > 
> >    The value 59 in the Next Header field of an IPv6 header or any
> >    extension header indicates that there is nothing following that
> >    header.  If the Payload Length field of the IPv6 header indicates the
> >    presence of octets past the end of a header whose Next Header field
> >    contains 59, those octets must be ignored, and passed on unchanged if
> >    the packet is forwarded.
> 
> Unless I have misunderstood something, your guideline 5 needs
> an exception for the No Next Header case.
> 
> (Or we could decide that the case described in RFC 2460 is an
> invitation to buffer overflow attacks, and change the rule.)
> 
> Regards
>    Brian
> 
> On 03/06/2014 05:36, Panos Kampanakis (pkampana) wrote:
> > Hello,
> > 
> > I just submitted an Informational draft that provides guidelines for IPv6 implementers on how to parse IPv6 extension headers.
> > 
> > There are multiple RFCs like RFC2460, RFC7112, RFC7045, RFC5722 and RFC6946 already that provide some rules on IPv6 packet processing. These address separate issues and is tough for an implementer to track all rules in each RFC. Additionally, there are some gaps in parsing malformed EHs and how EH chains should be parsed. To my knowledge, there is no document that and implementer could use as a single source of truth that would tell him how IPv6 EH should be parsed. That has led to different implementations that are inconsistent. For example malformed packets are in some cases processed and others dropped based on vendor implementation.
> > 
> > As more and more smart devices are starting to participate in the network, there is a need for a document that will ensure there is consistency on how IPv6 EHs are processed to prevent inconsistencies and potential security implications from incorrectly parsing headers. This document is trying to address that need.
> > 
> > Name:		draft-kampanakis-6man-ipv6-eh-parsing
> > Revision:	00
> > Title:		Implementation Guidelines for parsing IPv6 Extension Headers
> > Document date:	2014-06-02
> > Group:		Individual Submission
> > Pages:		8
> > URL:            http://www.ietf.org/internet-drafts/draft-kampanakis-6man-ipv6-eh-parsing-00.txt 
> > Status:         https://datatracker.ietf.org/doc/draft-kampanakis-6man-ipv6-eh-parsing 
> > Htmlized:       http://tools.ietf.org/html/draft-kampanakis-6man-ipv6-eh-parsing-00 
> > 
> > 
> > Thoughts on the doc being adopted as WG item and other feedback is welcome.
> > 
> > Panos
> > Cisco Systems
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> > Sent: Monday, June 02, 2014 1:08 PM
> > To: Panos Kampanakis (pkampana); Panos Kampanakis (pkampana)
> > Subject: New Version Notification for draft-kampanakis-6man-ipv6-eh-parsing-00.txt
> > 
> > 
> > A new version of I-D, draft-kampanakis-6man-ipv6-eh-parsing-00.txt
> > has been successfully submitted by Panos Kampanakis and posted to the IETF repository.
> > 
> > Name:		draft-kampanakis-6man-ipv6-eh-parsing
> > Revision:	00
> > Title:		Implementation Guidelines for parsing IPv6 Extension Headers
> > Document date:	2014-06-02
> > Group:		Individual Submission
> > Pages:		8
> > URL:            http://www.ietf.org/internet-drafts/draft-kampanakis-6man-ipv6-eh-parsing-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-kampanakis-6man-ipv6-eh-parsing/
> > Htmlized:       http://tools.ietf.org/html/draft-kampanakis-6man-ipv6-eh-parsing-00
> > 
> > 
> > Abstract:
> >    IPv6 is widely used on the internet today and is expected to be
> >    deployed more as more devices (i.e. home automation) get inter-
> >    connected.  The IPv6 header format allows for the use of Extension
> >    Headers (EH).  EHs could be chained together with very few existing
> >    guidelines by the IPv6 protocol on how devices should parse them,
> >    which open room for security concerns and inconsistencies.  This
> >    document presents guidelines for parsing IPv6 EHs with a goal of
> >    providing a common and consistent parsing methodology for IPv6
> >    implementers among the industry.
> > 
> >                                                                                   
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> > 
> > The IETF Secretariat
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
>