Re: A problem with RFC 6465's Uniform Format for Extension Headers

[Fernando Gont <[e-mail]>]

On 02/09/2014 04:35 PM, C. M. Heard wrote:
> 
> In the absence of a strong argument to the contrary, it seems to me 
> that the existing Destination Options header can be used to do 
> exactly the same thing as the proposed UEH.  In other words, I agree 
> with Jen's comments.

There are two issues here:

1) Your proposed outcome still means that we should still do something
about this issue. i.e., state "New Next Headers will never be specified.
And hereby we deprecate RFC6465's section on the unified format".

2) I wonder whether we really want to close the door to new extension
headers. After all, new ext header will not be more harmful than the
existing ones (in terms of the issues that have been discussed a number
of times on this and other lists).


[....]
>> Let's say that, tomorrow, the IETF standardizes the GTP (Google
>> Transport Protocol :-)), and it is assigned the Next Header value 0xFF
>> (I'm assuming this one is not currently assigned, bbut I'm not checking
>> the IANA registry right now).
>>
>> Say a middle-box receives a packet that simply encapsulates GTP in IPv6,
>> and that middlebox does not yet support GTP. If the middle-box tries to
>> interpret the GTP header as in RFC6465, it will certainly fail.
>>
>> The reason? -- RFC 6465 implicitly assumes that every new Next Header
>> will employ the RFC6465 format. This may be sensible for new *extension
>> headers*, but certainly not for new transport protocols.
>>
>> And since transport protocols and extension headers share the same
>> namespace (see RFC7045), this is a problem.
> 
> All this is true.  The implication is that the middlebox must stop 
> parsing the header chain when it encounters an unknown Next Header.

Agreed. But what we want to achieve is that they don't need to --
particularly when the unknown Next Header is an extension.



> In more detail, I see the three cases:
> 
> 1.) The middlebox encounters an ESP Next Header, signalling that an 
>     encrypted payload follows.  In that case it stops parsing the 
>     header chain and applies its policy for encrypted payloads.

Agreed. IN this case, ESP would be the "upper layer protocol" as per our
definition in RFC 7112.



> 2.) The middlebox encounters a Next Header corresponding to a known 
>     transport protocol.  In that case it may perform filtering 
>     actions specific to that transport protocol (and of course may 
>     continue parsing into the transport header in order to do so).

The problem is that, right now, a middle-box cannot tell whether it's in
the presence of a new transport protocol, or an extension header. This
is the ambiguity we should get rid off. RFC 7045 tackles part of the
problem (ie., for known ext headers)... but there's still the ambiguity
for new ones.


> 
> 3.) The middlebox encounters an unknown Next Header value.  In that 
>     case it stops parsing the header chain and applies its policy 
>     for packets with unknown Next Header values.  In order to comply 
>     with RFC 7045, it MUST be possible to configure the policy to 
>     allow such packets, but the default MAY be to drop them.  A 
>     high-quality implementation would allow the policy to be 
>     configured individually for each unknown Next Header value.
> 
> I agree that there are use cases where it is important for a middlebox 
> to clearly distinguish between an unknown extension header and an 
> unknown transport protocol.  

Agreed. This is th key point.


[...]
>> What's clear is that the only way in which RFC6465 can possibly work is
>> if the middle-box has some a-priori knowledge that what is being
>> encapsulated follows RFC6465 -- whether as a result of a reserved range
>> (as originally proposed by Hagen) or by specifying a single UEH, and
>> then encoding all possible future "extension headers" as subtypes of UEH.
> 
> A third possibility would be to go a step further than RFC 6564 and 
> ban new extension headers outright, insisting that a Destination 
> Option be used instead.

Yes. That is among the options. I'm not sure that I'd side with this
one. But certainly, any of the three options that have been discussing
(the one currently documented in our I-D, Hagen's, or this one) are
better than the current state of affairs.

Thanks!

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