Subject: [Errata Rejected] RFC6564 (4423)

From: RFC Errata System <[email-masked]>
Date: Tue, 15 Sep 2015 06:02:35 -0700 (PDT)

The following errata report has been rejected for RFC6564,
"A Uniform Format for IPv6 Extension Headers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6564&eid=4423

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Fernando Gont <[email-masked]>
Date Reported: 2015-07-20
Rejected by: Brian Haberman (IESG)

Section: 5

Original Text
-------------
   Any IPv6 extension headers defined in the future, keeping in mind the
   restrictions specified in Section 3 and also the restrictions
   specified in [RFC2460], MUST use the consistent format defined in
   Figure 1.  This minimizes breakage in intermediate nodes that examine
   these extension headers.

Corrected Text
--------------
There's a bug in the logic of this document. Essentially:

   A key problem with the Uniform Format for IPv6 Extension Headers
   [RFC6564] lies in that both IPv6 Extension Headers and Transport
   Protocols share the same namespace ("Next Header" registry/
   namespace).  Thus, given an "unknown Next Header value", it is
   impossible to tell whether the aforementioned value refers to an IPv6
   Extension Header that employs the aforementioned uniform format, or
   an "unknown" upper-layer protocol (e.g. an "unknown" transport
   protocol).  That is, while [RFC6564] specifies the syntax for the
   Uniform Format for IPv6 Extension Headers, but it does not provide a
   mechanism for a node to identify whether the aforementioned format is
   being employed in the first place.

This problem is discussed in: draft-gont-6man-rfc6564bis.

Notes
-----
The problem is not specifically with Section 5, but rather with the logic in the document.
 --VERIFIER NOTES-- 
The changes proposed go beyond the level of an erratum. The issue should be discussed within the 6MAN working group and a revision of 6564 published if there is consensus to do so.

--------------------------------------
RFC6564 (draft-ietf-6man-exthdr-06)
--------------------------------------
Title               : A Uniform Format for IPv6 Extension Headers
Publication Date    : April 2012
Author(s)           : S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia
Category            : PROPOSED STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Sep 2015 08:17:15 +1200

(CCs trimmed)

I agree with the logic of the rejection.

I also believe that the problem raised is insoluble in IPv6;
we would need to version the protocol to fix it.

That's why RFC 7045 created the "IPv6 Extension Header Types" registry:
https://tools.ietf.org/html/rfc7045#section-4

Regards
   Brian

On 16/09/2015 01:02, RFC Errata System wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Sep 2015 20:03:31 -0300

Hi, Brian,

> I agree with the logic of the rejection.

I'd say I agree with the logic (i.e. "procedural", rather than "technical").

> https://tools.ietf.org/html/rfc7045#section-4

I disagree here. The problem is solvable as per
draft-gont-6man-ipv6-universal-extension-header.

(Well, you can argue that we "circumvent the problem": we defined the
last EH ever, which creates a subspace for EH types).

Since it is not unlikely that during IPv6's lifetime we want to specify
new EHs, we better fix this sooner than later...

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Sep 2015 14:17:31 +1200

> last EH ever, which creates a subspace for EH types).

Yes, nobody escapes having to write code for all the existing EH's.
But I haven't understood why your proposal is really different from
using the option headers as universal.

> new EHs, we better fix this sooner than later...

You would think so, but the history of IPv4 options says the opposite.
I think the problem is that whatever solution is used, firewalls will
block what they don't understand.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2015 01:05:07 -0300

Hi, Brian,

> using the option headers as universal.

Let me illustrate with an example:

Let's say I have a middle-box that wants to filter everything other than
TCP port 80. My middle-box will try to process the entire IPv6 header
chain, inspect the TCP port number, and allow the packets if they are
identified to be TCP port 80.

Let's say a new EH is introduced. Existing middle-boxes have no way to
tell whether the new "Next Header" value is an EH or a transport
protocols -- because the middle-box implementation predates the
specification of the new EH.

Therefore, it's impossible for the middlebox to skip past the
newly-defined EH.

Our I-D does this:
It defines a final EH syntax, which includes a "sub-type", and length.
Then, if you want to specify a new EH, you use our IANA-assigned "Next
Header" value, and request IANA a new "sub-type" for your EH.

As a result, once our new EH is implemented, middleboxes can parse past
newly-defined EHs, since all of them will share the same "Next Header"
value and the same syntax.

> block what they don't understand.

I don't necessarily disagree with you. But if we are going to keep them,
we better do whatever we can to improve the current state of affairs.

Thanks!

Best regards,

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Sep 2015 09:15:21 +0200

Fernando,

> value and the same syntax.

how would that be different from putting options in the DestOpt header?

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2015 04:28:47 -0300

> how would that be different from putting options in the DestOpt header?

Well, the Dst Opt EH is about options that must be processed at the
destination system.

This new EH can have any semantics you want, on a per-sub-type basis.
For example, you could implement a new HbH EH with this new EH, whereas
you couldn't implement such a thing with the Dst Opt EH (because such
options would only be processed by the final node).

Does this answer your question?

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Sep 2015 10:07:38 +0200

Fernando,

> Does this answer your question?

yes, thank you.

with the HBH container, DestOpt container and the RH container haven’t we covered pretty much all the bases already?

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2015 08:07:26 -0300

Hi, Ole,

On 09/16/2015 05:07 AM, Ole Troan wrote:
> Fernando,
> 
>>>> Our I-D does this: It defines a final EH syntax, which includes
>>>> a "sub-type", and length. Then, if you want to specify a new
>>>> EH, you use our IANA-assigned "Next Header" value, and request
>>>> IANA a new "sub-type" for your EH.
>>>> 
>>>> As a result, once our new EH is implemented, middleboxes can
>>>> parse past newly-defined EHs, since all of them will share the
>>>> same "Next Header" value and the same syntax.
>>> 
>> Well, the Dst Opt EH is about options that must be processed at
>> the destination system.
>> 
>> This new EH can have any semantics you want, on a per-sub-type
>> basis. For example, you could implement a new HbH EH with this new
>> EH, whereas you couldn't implement such a thing with the Dst Opt EH
>> (because such options would only be processed by the final node).
>> 
> with the HBH container, DestOpt container and the RH container
> haven’t we covered pretty much all the bases already?

Who knows...

In any case, right now RFC6564 not only does not really help (*), but is
misleading: I was tricked myself when I was working on RFC7610 that a
middle-box could parse past unknown EHs. So even if one didn't want to
address this problem (which I think would be a bad idea), at the very
least one shouldn't leave RFC6564 "as is".

(*) I must say that I was surprised when Erik reminded me some time ago
that they tried to push a similar idea at the time... i.e., not sure why
*that* didn't become RFC6564.

Thanks!

Best regards,

---

From: John Leslie <[email-masked]>
Date: Wed, 16 Sep 2015 10:47:35 -0400

Fernando Gont <[email-masked]> wrote:
>>...
>> haven?t we covered pretty much all the bases already?

   No. We haven't.

   Consider ConEx (congestion exposure):

   It wants to be accessed by the uplink ISP router in _both_ directions,
and by various monitoring points, mostly at AS boundaries. It _can_ be
ignored by every router along the way. We ended up calling it a destination
option; but that's a bad fit.

   There are certainly other cases of monitoring along the way which
absolutely _don't_ want to involve every router (and very likely don't
want to involve the destination).

> Who knows...

   Exactly! We can't know all the uses to which IPv6 may be put in the
future; and we really should cure ourselves of pretending we can.

> *that* didn't become RFC6564.

   Perhaps someone remembers?

--
John Leslie <[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Wed, 16 Sep 2015 11:51:54 -0700

>   Perhaps someone remembers?

I’m listed as an author on RFC 6564, and my recollection of the motivation for this RFC is that it was an attempt to make it possible to bring some order to the extension header chain so that upper-layer transport protocols could be identified by deep packet analyzers. In particular, I was anticipating the future existence of something like a Middlebox Alert extension header type which hosts and routers could ignore and only middleboxes would process.

  Sending Host: “Ahoy Middleboxes! I have an EH here especially to help you do your job forwarding my TCP packet!”
  Router: “IPv6 header looks fine. Next header = meh. Forward ho!”
  Packet Analyzer: “Oh hey, I see what you did there. There’s a TCP packet here, behind this thing I don’t recognize. I’m going to assume it's an EH that I don’t know about.”
  Middlebox: “I don’t understand Middlebox Alert extensions. No forwarding for you.” [drops packet]

The draft that became this RFC progressed through quite a few weird iterations as people danced around the basic problem here, which RFC 7045 eventually addressed better. Ultimately though, there is a fundamental problem, which still remains, that Next Header values not currently defined are ambiguous as to whether they will be Extension Headers or Upper-layer Protocols.

I would argue there is merit in saying that any new Extension Headers yet to be defined must conform to a regular format as described in RFC 6564, because it will help analyzers recognize things that appear to be existing Upper Layer Protocol headers when they appear behind what appear to be unrecognized Extension Headers. I think this Errata is in principle a denial of that proposition, and I am therefore in agreement that it should be rejected.

—james

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2015 16:09:34 -0300

Hi, Jim,

On 09/16/2015 12:51 PM, Jim Hoagland wrote:
> From a security perspective If there is any real chance of having
> additional extension headers during the IPv6 lifetime then if possible I
> would like for a middlebox to have a standards-based way of distinguishing
> extension headers and upper layer protocols.  -- Jim

Our I-D (<https://tools.ietf.org/html/draft-gont-6man-rfc6564bis-00>)
allows for that. Once IANA assigns our EH a "Next Header" value, all
remaining "Next Header" values can be considered upper-layer protocols
(e.g., transport protocols).

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2015 16:25:27 -0300

Hi, James,

On 09/16/2015 03:51 PM, james woodyatt wrote:
> On Sep 16, 2015, at 07:47, John Leslie <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> I’m listed as an author on RFC 6564, and my recollection of the
> motivation for this RFC is that it was an attempt to make it possible to
> bring some order to the extension header chain so that upper-layer
> transport protocols could be identified by deep packet analyzers. In
> particular, I was anticipating the future existence of something like a
> Middlebox Alert extension header type which hosts and routers could
> ignore and only middleboxes would process.
> 
[...]
> 
> The draft that became this RFC progressed through quite a few weird
> iterations as people danced around the basic problem here, which RFC
> 7045 eventually addressed better. Ultimately though, there is a
> fundamental problem, which still remains, that Next Header values not
> currently defined are ambiguous as to whether they will be Extension
> Headers or Upper-layer Protocols.

Exactly. That's the problem we try to tackle with
<https://tools.ietf.org/html/draft-gont-6man-rfc6564bis-00>.

> I would argue there is merit in saying that any new Extension Headers
> yet to be defined must conform to a regular format as described in RFC
> 6564, because it will help analyzers recognize things that appear to be
> existing Upper Layer Protocol headers when they appear behind what
> appear to be unrecognized Extension Headers. I think this Errata is in
> principle a denial of that proposition, and I am therefore in agreement
> that it should be rejected.

Huh?

How can a middlebox (or "analyzer", or whatever you want to call it)
infer that an unknown "Next Header" value follows the syntax in RFC6564,
if it doesn't know whether what follows is a transport protocol or an EH?

The reason for which the Ethernet header has an "EtherType" field, the
IPv4 header has a "Protocol" field, and IPv6 has a "Next Header" field
is so that you know what's the syntax of the protocol being encapsulated.

The only way in which you can expect a specific syntax for IPv6 EHs is:

1) That the upper-layer protocols and EHs had a separate namespace (so
you know that what follows is an EH, and that al EHs must follow the
syntax in RFC6564) -- too late, IPv6 doesn't follow that approach.

2) That you introduce an additional level of indirection as we do in our
I-D <https://tools.ietf.org/html/draft-gont-6man-rfc6564bis-00>: specify
one last EH that essentially creates a brand new registry for new EHs
(this is essentially a way of achieving "1)" above, starting from what
we have now).

I hope this clarifies what's the problem that we're trying to tackle.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: james woodyatt <[email-masked]>
Date: Wed, 16 Sep 2015 14:31:54 -0700

> if it doesn't know whether what follows is a transport protocol or an EH?

For example: when the Next Header in the presumed EH structure indicates SCTP and points to a valid SCTP header with the correct CRC-32 and either a previously seen association identifier or a correctly formed INIT packet. Admittedly, this might not be practical at wire speeds in a backbone middlebox, but is that really the only kind of deep packet inspection that matters?

—james

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Sep 2015 20:38:48 -0300

Hi, James,

On 09/16/2015 06:31 PM, james woodyatt wrote:
> On Sep 16, 2015, at 12:25, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> For example: when the Next Header in the presumed EH structure indicates
> SCTP and points to a valid SCTP header with the correct CRC-32 and
> either a previously seen association identifier or a correctly formed
> INIT packet. Admittedly, this might not be practical at wire speeds in a
> backbone middlebox, but is that really the only kind of deep packet
> inspection that matters?

I'd say that this is not practical, and not even desirable.

A few simple examples:

1) You have two back-to-back extension headers. So the Next Header of
the (presumed) first one just contains the NH value of the second EH.
What do you do? -- Just keep processing "assummed EHs" until you realize
you've hit garbage?

2) Case 1) above also implies that the upper-layer protocol is
well-known -- but that doesn't need to be the case.

Example #1 above (or even your own example) means that your middlebox
might ead to the intermmitent behavior we refer to in Section 3.2 of
draft-gont-opsawg-firewalls-analysis-00.

I would expect that the problem we're describing is clear. And, in such
case, I'm not sure how trying to find potential uses for something that
is fundamentally wrong can help.

I'd expect that you wouldn't deploy a box such as the one you're
describing... would you?

Thanks!

Cheers,

---

From: james woodyatt <[email-masked]>
Date: Fri, 18 Sep 2015 15:05:19 -0700

> I'd expect that you wouldn't deploy a box such as the one you're

Consider offline packet analyzers.

—james

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Sep 2015 19:37:35 -0300

Hi, James,

> Consider offline packet analyzers.

That's a whole different game. -- I still nred.to.understand why you agreed
witu the errata reject (other than thr procedural reasons given by brian,
with which i agree).

But another way: do you agree that RFC6564 does not allow middleboxes to
parse the entire ipv6 header chain, and that there ia a problem that we
should.fix?

Thanks!
Cheers,
Fernando

---

From: james woodyatt <[email-masked]>
Date: Fri, 18 Sep 2015 17:47:28 -0700

On Sep 18, 2015, at 15:37, Fernando Gont <[email-masked]> wrote:
> El 18/9/2015 19:05, "james woodyatt" <[email-masked] <mailto:[email-masked]>> escribió:
> >
> That's a whole different game.
> 
From my perspective, as an author of the document, the offline packet analyzers are the whole point, not a game on the side. Here is where I observe that the only mention of “middleboxes” in RFC 6564 comes in section 6, Future Work, which reads:

>> 6.  Future Work
>> 
>>    This document proposes one step in easing the inspection of extension
>>    headers by middleboxes.  There is further work required in this area.
>>    Some issues that are left unresolved beyond this document include:
>> 
>>    o  There can be an arbitrary number of extension headers.
>> 
>>    o  Extension headers must be processed in the order they appear.
>> 
>>    o  Extension headers may alter the processing of the payload itself,
>>       and hence the packet may not be processed properly without
>>       knowledge of said header.

If there is an error in the section quoted above, then I’m not seeing it.

> But another way: do you agree that RFC6564 does not allow middleboxes to parse the entire ipv6 header chain, and that there ia a problem that we should.fix?

Looks to me like the RFC itself admits that it doesn’t define enough to permit middleboxes to process the entire IPv6 header chain including the upper-layer protocol. I agree there was future work remaining to be done to facilitate middlebox processing when RFC 6564 was published. Some of which was done in RFC 7045. Some of which probably still remains unfinished, and perhaps the problem is intractable. I see no reason for an erratum to be recorded to drive the point home.

I don’t agree that I-D.gont-6man-rfc6564bis is an appropriate solution to the problem that seems to be under discussion. I actually think the problem is probably best resolved by simply instructing IANA to close the IPv6 Extension Header Types registry from RFC 7045 to new entires.

—james

---

From: Fernando Gont <[email-masked]>
Date: Wed, 23 Sep 2015 16:03:17 -0300

Hi, James,

On 09/18/2015 09:47 PM, james woodyatt wrote:
> On Sep 18, 2015, at 15:37, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> From my perspective, as an author of the document, the offline packet
> analyzers are the whole point, not a game on the side. Here is where I
> observe that the only mention of “middleboxes” in RFC 6564 comes in
> section 6, Future Work, which reads:

I never read it that way, and that's certainly not the message that I
got from other co-authors.

> If there is an error in the section quoted above, then I’m not seeing it.

I read the above section as "we'd still need improvements in these
areas", rather than anything else.

>> But another way: do you agree that RFC6564 does not allow middleboxes
>> to parse the entire ipv6 header chain, and that there ia a problem
>> that we should.fix?
> 
> Looks to me like the RFC itself admits that it doesn’t define enough to
> permit middleboxes to process the entire IPv6 header chain including the
> upper-layer protocol. I agree there was future work remaining to be done
> to facilitate middlebox processing when RFC 6564 was published. Some of
> which was done in RFC 7045. Some of which probably still remains
> unfinished, and perhaps the problem is intractable. I see no reason for
> an erratum to be recorded to drive the point home.
> 
> I don’t agree that I-D.gont-6man-rfc6564bis is an appropriate solution
> to the problem that seems to be under discussion. I actually think the
> problem is probably best resolved by simply instructing IANA to close
> the IPv6 Extension Header Types registry from RFC 7045 to new entires.

If you think the proper action is to close the EH registry, what's the
point of RFC6564? Specifying an EH format that will never be employed,
since new EHs will never be specified?

Thanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 24 Sep 2015 03:30:55 +0000

Hi James,
   Just providing some additional perspective.

On 09/18/2015 08:47 PM, james woodyatt wrote:
> to facilitate middlebox processing when RFC 6564 was published.

Exactly. And not for the lack of trying. Earlier versions of the draft 
that ended up becoming RFC6564 did actually try to allocate a protocol 
number to provide this differentiation. The WG was not open at that time 
to burning a protocol number "just in case" we needed a new header in 
the future. I think draft-gont-6man-rfc6564bis will test the WGs feeling 
on the same subject to see if it has changed or remains the same.

Thanks
Suresh