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

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

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.

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

Mike Heard