Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

On Feb 9, 2015, at 1:02 AM, C. M. Heard <[e-mail]> wrote:
> - A new extension header is defined that make sense to sandwich in 
>  front of a DHCPv6 packet (not all do; some extension headers are 
>  required to have a next header value of "no next header")
> 
> - This extension header is unknowm to a DHCPv6-Shield implementation
> 
> - This is extension header is known and considered valid by a host 
>  that DHCPv6-Shield implementation is trying to protect

In addition to being known by the host, the extension header would have to be a standard extension header that does not conform to RFC 6564.   Otherwise, the switch can just skip over it even though it's nominally "unknown."   Having skipped over it, it would correctly reach the UDP protocol header, and notice that the packet was a DHCP packet.

I think it's safe to assume that no future extension header that is standardized will fail to conform to RFC 6564.   Hence, we do not need to worry that the host will be able to parse a new extension header, but that the DHCPv6-shield device will not.   Hence, there is no need to drop packets with unknown extension headers.

This is particularly important, because in dropping packets with unknown extension headers, we are _also_ dropping packets with unknown protocol headers.   That is the real harm of the language of the document as it is currently written.