Subject: draft-kampanakis-6man-ipv6-eh-parsing-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2014 14:26:31 +1200

Panos,

A few residual comments:

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

 [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 still reads as if you are quoting RFC 7112, but you are not.
I suggest:

 Guideline 2: As a consequence of Section 5 of [RFC7112], when parsing an EH chain,

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

> 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,
but that would need a formal standards track update.)

Regards
   Brian

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 6 Aug 2014 14:34:10 +0000

Thank you again for the comments Brian.
I will take care of all of them in the next iteration.
Panos

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2014 10:27 PM
To: Panos Kampanakis (pkampana)
Cc: [email-masked]
Subject: draft-kampanakis-6man-ipv6-eh-parsing-01.txt

Panos,

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

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

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

...

>    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, but that would need a formal standards track update.)

Regards
   Brian