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

[Brian E Carpenter <[e-mail]>]

On 08/10/2013 05:53, C. M. Heard wrote:
> On Mon, 7 Oct 2013, Adrian Farrel wrote:
>> 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.
> ...
>> Are 253 and 254 intended solely for experimental extension headers? 
>> 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.)

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 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.
> 
> I think this idea has a lot of merit.  

Disagree, for reason given in my previous message.

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

We can ask IANA to fix bugs anytime, surely?

    Brian

> 
> Thanks and regards,
> 
> Mike Heard
>