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 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
