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

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

On Tue, 8 Oct 2013, Brian E Carpenter wrote:
> 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.

That's correct.

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

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.

> > 43	IPv6-Route	Routing Header for IPv6		[Steve_Deering]
> > 44	IPv6-Frag	Fragment Header for IPv6	[Steve_Deering]
> > 
> 
> 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