Subject: Adrian Farrel's No Objection on draft-ietf-6man-ext-transmit-04: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 07 Oct 2013 07:43:27 -0700

Adrian Farrel has entered the following ballot position for
draft-ietf-6man-ext-transmit-04: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit/

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

Thanks for the work on this document. I have no objection to its
publication and just two minor observations.

---

Section 1.1

A couple of points about the following paragraph:

   In this document "standard" IPv6 extension headers are those
   specified in detail by IETF standards actions.  "Experimental"
   extension headers are those defined by any Experimental RFC, and the
   experimental extension header values 253 and 254 defined by [RFC3692]
   and [RFC4727].  "Defined" extension headers are the "standard"
   extension headers plus the "experimental" ones.

My reading of the IANA registry (http://www.iana.org/assignments/
protocol-numbers/protocol-numbers.xhtml) is that allocations can be made
by IESG Approval or Standards Action. I think both of those are covered
by what you call "standard".

I am not convinced that an experiment that uses an experimental code 
point needs to be documented in an Experimental RFC. 

Are 253 and 254 intended solely for experimental extension headers? 
Couldn't the experiment be an experimental payload protocol?

---

I find myself in I-wouldn't-have-done-it-this-way land, so this is, of
course, just a Comment for you to chew on and accept or reject according
to how it strikes you...

It seems to me unwise to create a new registry that duplicates
information held in another registry. By adding a column to the
"Assigned Internet Protocol Numbers" registry you are making it 
completely clear which are the IPv6 Extension Headers. Rather than risk 
having this registry out of step with your new "IPv6 Extension Header
Types registry", I would have had the existing, empty "IPv6 Next Header
Types" registry redirect users to the "Assigned Internet Protocol
Numbers" registry and mention the existence of the specific column that
identifies extension headers.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 7 Oct 2013 09:53:40 -0700 (PDT)

>    extension headers plus the "experimental" ones.
...
> Couldn't the experiment be an experimental payload protocol?

This is a good point.  RFC 3692 calls these out as experimental 
values for the IP Protocol Field, so experiments could in principle 
use these values either for experimental upper layer protocols or 
for experimental IPv6 headers.  Nodes that are not involved in the 
experiment (including middleboxes) would have no way of knowing the 
difference.

This opens up a small can of worms, because Section 2.1 says that 
"[e]xperimental IPv6 extension headers SHOULD be treated in the same 
way as standard extension headers, including an individually 
configurable discard policy."  The problem is that if a node not 
participating in an experiment encounters a next header value of 253 
or 254 it won't know whether to treat what follows as an 
experimental extension header, conforming to the uniform TLV format 
specified in RFC 6564, or an experimental upper-layer protocol, 
where all bets are off with respect to format.  If packets 
containing these values are to be passed by a middlebox not 
participating in an experiment, it seems that the middlebox would 
have to stop parsing when encountering these values, and pass or 
drop the packet depending on what it's supposed to do with unknown 
upper layer protocol protocol types.

(As an aside, it occure to me that the same thing is true if a 
middlebox encounters a next header type that it does not recognize 
-- it won't know if it refers to an extension header or an upper 
layer protocol, and must treat it as the latter.  Hence the 
requirement that "[f]orwarding nodes MUST be configurable to allow 
packets containing unrecognised extension headers" means, in 
practice, that a middlebox needs to have a switch to allow unknown 
upper layer protocols to pass through.)

> identifies extension headers.

I think this idea has a lot of merit.  Putting that information in 
the Internet protocol numbers registry would also provide an 
opportunity to fix some things about extention header entryes that 
currently are not quite right, such as:

43	IPv6-Route	Routing Header for IPv6		[Steve_Deering]
44	IPv6-Frag	Fragment Header for IPv6	[Steve_Deering]

Thanks and regards,

Mike Heard

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Oct 2013 08:07:27 +1300

On 08/10/2013 03:43, Adrian Farrel wrote:
...
> by what you call "standard".

I don't see that "IESG Approval" implies "standard", but I guess that's
a matter of interpretation.

> point needs to be documented in an Experimental RFC. 

Yes, the definition could perhaps be slightly wider. s/are those/include those/
for example.

> Couldn't the experiment be an experimental payload protocol?

I'll comment on Mike Heard's message.

> identifies extension headers.

Logically, yes, but I (personally) think that the convenience factor
of a separate list is valuable. We have running code proof in current
firewall implementations that people are *not* identifying the extension
headers today, and we want to make it easy for them.

   Brian
> .

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Oct 2013 08:18:57 +1300

> upper layer protocols to pass through.)

Yes, and for a moment there you had me worried, but if the security
concern is that the unknown header may contain bad stuff and/or cause
a buffer overflow bug, then it really doesn't matter whether it is
an extension header or a payload header. In either case, if you let
the packet through, you are assuming that the destination host knows
what it's doing.

We might need a slight rewording to remove the implication that
253/254 can *only* be used as extension headers. Something like:

 "Experimental" extension headers include those defined by any
 Experimental RFC, and the values 253 and 254 defined by [RFC3692]
 and [RFC4727] when used as experimental extension headers.

> I think this idea has a lot of merit.  

Disagree, for reason given in my previous message.

> Putting that information in 

We can ask IANA to fix bugs anytime, surely?

    Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 7 Oct 2013 14:28:07 -0700 (PDT)

> the packet through, you are assuming that the destination host knows

That's correct.

>  and [RFC4727] when used as experimental extension headers.

That would be a good change to the last paragraph of Section 1.1 but 
I'm not sure that it's sufficient.

Section 2.1 recommends that forwarding nodes that inspect IPv6 
headers be able to parse all defined extension headers and deal with 
them appropriately, specifically by having an individually 
configurable discard policy.  I've assumed that this means that if a 
particular defined extension header type is not blackisted, the 
forwarding node should be able either to examine the innards of that 
header (a likely action with options headers) or skip over it and to 
proceed to the next header.  The problem with next header values 253 
and 254 when used as experimental next header types -- unlike 
assigned experimental extension header types that have a published 
spec -- is that it's not possible for the forwarding node to safely 
examine or skip over the headers they refer to without being part of 
the experiment.

Maybe I'm making too much of this.  Certainly a reasonable action 
for a middlebox that's told to pass packets with extension header 
types 253 and 254 is to stop parsing when it encounters those next 
header types and forward the packet in question.  Maybe that's 
obvious to everyone -- but it seems to me that the spec, as written, 
is actually asking for something different.

I'll gladly shut up if no one else sees a problem.

> We can ask IANA to fix bugs anytime, surely?

Yes, and we should do that irrespective of the disposition of 
Adrian's comment.  Since I brought this up, I'll volunteer to bring 
this to IANA's attention if the leadership wants me to do so (please 
let me know).

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Oct 2013 13:17:53 +1300

On 08/10/2013 10:28, C. M. Heard wrote:
...

> is actually asking for something different.

There's no header length field in an IPv6 header. That means that
since header types 253 and 254 might be used either for experimental
extension headers or for experimental payload types, there's no
generic way for a middlebox to tell the difference. I think that's
an issue that the current draft cannot resolve. I suspect we probably
need an extra sentence to state the problem, but the authors will
wait for direction on that.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Oct 2013 15:28:52 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Monday, October 07, 2013 5:18 PM
> To: C. M. Heard
> Cc: [email-masked]; Adrian Farrel; draft-ietf-6man-ext-
> [email-masked]; [email-masked]; The IESG
> Subject: Re: Adrian Farrel's No Objection on draft-ietf-6man-ext-
> transmit-04: (with COMMENT)
> 

When Wireshark encounters a header type 253 or 254, it assumes it is
an unknown extension header of length 8 bytes, then skips ahead and
attempts to parse anything that follows as additional headers.

Wireshark can be thought of as a middlebox of sorts (albeit one
that does not alter the traffic flow), and it wouldn't be hard to
imagine real middleboxes that do the same thing when they encounter
253/254.

Thanks - Fred
[email-masked]
 
>     Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Oct 2013 17:15:04 +1300

Fred,

On 09/10/2013 04:28, Templin, Fred L wrote:
...
> attempts to parse anything that follows as additional headers.

They must have just made that up; there's no justification for it.
It could be an unknown extension header of unknown length, or it
could be an unknown payload of unknown length. In real life
I'd expect firewalls to default-drop such packets.

We'll note this issue in the Security Considerations.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Oct 2013 15:55:01 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, October 10, 2013 9:15 PM
> To: Templin, Fred L
> Cc: C. M. Heard; [email-masked]; Adrian Farrel; draft-ietf-
> [email-masked]; [email-masked]

It could be that Wireshark has some kind of inference engine that
says: "let's look ahead and see if the next octet looks like another
NEXTHDR field, and if so keep on plowing through". It certainly
surprised me. It might also be worth noting that tcpdump does not
take this leap of faith and stops when it hits the first 253/254.

> We'll note this issue in the Security Considerations.

OK - thanks.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Oct 2013 16:33:23 +0000

> take this leap of faith and stops when it hits the first 253/254.

What is actually happening is that Wireshark assumes that the octet
that follows the NEXTHDR field that encodes 253/254 is a length field
and then seeks ahead by the number of octa-words indicated by the
"length".

In the case of my experimental protocol (SEAL, of course), the octet
that follows the NEXTHDR is *not* a length field, i.e., the same as
for the IPv6 fragment header. It just so happened that the octet
encoded the value 0 making the experimental header look like an
8-octet field. When I change the value to something other than 0,
Wireshark fails.

But, in the final analysis, there is no justification for assuming
that the field that follows the NEXTHDR field is a length field.
It's just that you might get lucky once in a while.

Thanks - Fred