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

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

On Mon, 9 Feb 2015, Ted Lemon wrote:
> 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."

That, unfortunately, is not true, as I have been trying repeatedly 
to explain.

When the switch encounters an unknown next header value, it does not 
know if that refers to a new extension header, which is required to 
conform to the format of RFC 6564, or an upper layer protocol 
header, which is NOT required to conform to RFC 6564.  As I argue in 
http://www.ietf.org/mail-archive/web/opsec/current/msg01817.html, 
the switch opens itself up to DOS attacks if it assumes that any 
unknown header in the chain conforms to RFC 6564 and attempts to 
continue parsing the header chain.

RFC 6564 gives the misleading impression that it actually solves a 
problem.  It does not.  This is at least the third time I've seem 
this discussion has come up.  For that reason it's time to retire 
RFC 6564, but that of course is a job for 6man, not opsec.

There was some discussion of this problem in 6man -- one proposal 
was draft-gont-6man-rfc6564bis, discussed Feb-May 2014 (see, e.g., 
http://www.ietf.org/mail-archive/web/ipv6/current/msg20710.html).  
6man never came to consensus that the problem was sufficiently 
important to solve, but I think the current discussion has 
hughlighted the importance of putting it to rest.  Secifically:

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

THAT is a very a real problem in an Internet full of middleboxes.  
It would be fixed if the set of extension headers were closed off to 
further expansion.  Multiple technically viable ways to do this 
without sacrificing functionality have been proposed; this 
discussion sould, I hope, provide the motivation needed to get 6man 
to adopt one of those solutions (or something similar).

Sorry for the digression, but I think it was necessary to understand 
the problem.

//cmh