Re: I-D Action: draft-gont-6man-ipv6-universal-extension-header-01.txt

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

On 04/05/2014 07:12, C. M. Heard wrote:
> On Fri, 2 May 2014, Brian E Carpenter wrote:
>> I've finally understood what's been bothering me about this draft.
>> Actually, two things:
>>
>> 1. If a node (regardless of whether it's the destination host,
>> or an intermediate node such as a firewall) has a policy
>> of discarding packets with an unknown extension header
>> or an unknown transport protocol, it *doesn't matter* that
>> it can't distinguish them. The packet is discarded anyway.
>>
>> Comment on that: In either case, this discard by a host is
>> consistent with RFC2460 (even as updated by RFC7045). In either
>> case, it's what we would expect a firewall to do if it has the
>> usual sort of paranoid policy, and that again is consistent
>> with RFC7045.
> 
> What motivated the draft was work on L2 middlebox functions that are 
> not required to have the usual paranoid "default deny" policy in 
> order to accomplish the intended purpose.  One was RA-Guard (see 
> http://tools.ietf.org/html/rfc7113); the other was DHCPv6-Shield 
> (http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield).  For 
> those functions extension headers do not matter so long as the 
> transport header can be found and inspected; the implementation 
> advice for the RA-Guard and DHCPv6-Shield filters is to pass 
> everything that can be positively identified as NOT being a 
> forbidden RA message or DHCPv6 message.
> 
> That being said, if Brian is correct in his assertion that we should 
> expect typical filtering middleboxes to agressively apply a "default 
> deny" policy to unknown extension headers, then I'd have to agree 
> with his conclusion that UEH (or a reserved range of next header 
> values) would fail to achieve its intended purpose, which is to get 
> them to skip over unknown extention headers.  On the other hand, I 
> have gotten the impression from much of the discussion here and on 
> v6ops that the usual aim of filtering middeboxes is to inspect 
> transport headers, not specifically extension headers, and apply a 
> "default deny" policy to transport protocols.  If the reason packets 
> with extension headers get dropped is because the middleboxes lack 
> the ability to find the transport header, then UEH (or a reserved 
> range of next header values) could help.

The scenario would be, for example, a load balancer or QoS classifier
that needs to find the transport header in order to extract port numbers.
And yes, I think you're right, if we have to cope with the risk of both
unknown extension headers (presumed to conform to RFC 6564) *and*
unknown transport protcols (about which we can presume nothing).

>> 2. Given that argument, I think this draft should consider a 4th 
>> possible solution: Do Nothing. I think it's a valid option.
> 
> If "do nothing" means make no changes to the normative 
> specifications in 7045 and 6564, then yes, that is a valid option.
> 
> That being said, there has in the past been an impression that RFC 
> 6564 guaranteed that it would be possible to skip over unknown 
> extension headers -- see, e.g., the changes in the above-referenced 
> DHCPv6-Shield draft in going from -01 to -02.
> 
> In order to clear up thus confusion, it would probably be useful to 
> at least publish advice to implementors of middleboxes that any 
> unrecognized Next Header value SHOULD be treated as if it indicates 
> the presence of an unknown upper-layer header, because it is unsafe 
> to treat it as if it were a new extension header with the TLV format 
> defined by RFC 6564.  

Right, because even if they use the complete IANA list of extension
headers, as specified in RFC 7045, it might be out of date.

> It would also be good to remind them that they 
> MUST provide a configuration option to allow packets containing such 
> values, as specified in RFC 7045, noting that a side-effect of 
> allowing all unrecognized extension headers is that unrecognized 
> transport protocols will be allowed also.

Yes. Whatever we decide about this draft and UEH, I think an
implementation guide is sorely needed.

    Brian