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

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 2 Jun 2014 17:36:50 +0000

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: [email-masked] [mailto:[email-masked]] 
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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jun 2014 17:04:06 +1200

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 9 Jun 2014 16:53:16 +0000

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:[email-masked]] 
Sent: Sunday, June 08, 2014 1:04 AM
To: Panos Kampanakis (pkampana)
Cc: [email-masked]
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.

...
>    occurrences of headers, but it does not provide other guidance on how

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?:

> 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.

...

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.

...

>    contains 59, those octets must be ignored, and passed on unchanged if

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:
> Subject: New Version Notification for 
> draft-kampanakis-6man-ipv6-eh-parsing-00.txt
> 
>

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 12 Jun 2014 14:33:16 -0700 (PDT)

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:
> 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
> 
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 13 Jun 2014 20:29:01 +0000

Thank you Mike for the detailed response. Very valuable feedback. 
I will make sure to address it in the next iteration if the document becomes an WG item.
Panos

-----Original Message-----
From: C. M. Heard [mailto:[email-masked]] 
Sent: Thursday, June 12, 2014 5:33 PM
To: Panos Kampanakis (pkampana)
Cc: Brian E Carpenter; 6man
Subject: RE: New Version Notification for draft-kampanakis-6man-ipv6-eh-parsing-00.txt

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.

<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>

<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:

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

<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

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

<PROPOSED TEXT>
5.  Other guidelines

<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:
> 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
> 
> 
> Subject: Re: New Version Notification for 
> look at the IETF's latest thinking on this. There is a lot of code out 
> there based on careless reading of RFC 2460.)
> 
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6