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

[joel jaeggli <[e-mail]>]

On 2/9/15 8:11 AM, C. M. Heard wrote:
> 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.

So the problem I have in application is if i'm applying an acl with an
L4 rule I have to find the upper layer header. If I can't parse the
header chain the packet is hitting a drop rule. if I can jumper over a
header due to 6564 and find the the L4 header then great, if I can't,
that packet is getting dropped.

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

in a device such a switch, I'm going to have to give up long before this
happens becasue the amount of the packet going towards the header
processing is only 64/128/256 bytes so I'm going to drop it if I don't
have that offset available to me.

I do think what you describe is a serious problem.

We do have a bunch of dos options to avail ourselves of on devices that
can be assumed to be capable of processing arbitrary header chains. If
such devices existed in my network I'd have to protect them with much
simpler devices.

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