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

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

On Sun, 8 Feb 2015, Ted Lemon wrote:
> On Feb 7, 2015, at 10:37 PM, C. M. Heard <[e-mail]> wrote:
> > That is incorrect because extension headers and upper layer headers 
> > share a numbering space.  Upper layer headers do NOT follow the 
> > format in RFC 6564.  That makes it in UNSAFE to attempt to skip over 
> > an unknown next header value.
> 
> I addressed that in my DISCUSS position.

Wherein you wrote:

| If an unknown protocol header is seen, this will look to the 
| switch like a malformed IP extension header, but this is harmless 
| in the context of DHCPv6 shield because any such packet is by 
| definition _not_ a DHCPv6 packet.

It is not necessarily true that an unknown upper layer protocol 
header will look like a malformed extension header to a device that 
assumes it is an extension header following the format in RFC 6564.  
If the value of the 2nd octet of the unknown header is v, then it 
won't appear malformed if at least 8*(v+1) bytes remain in the 
packet, starting from the beginning of the unknown header.  At that 
point the device would be interpreting the payload of the unknown 
upper layer PDU as an extension header chain.  In the benign case 
where the packet is a legitimate one with an upper layer protocol 
unknown to the device, it is likely (but not assured) that the chain 
would quickly terminate in something that looks like a malformed 
extension header.  However, it would not be difficult to craft a 
packet that makes a very long apparent header chain.  Depending on 
how the device processes header chains, that could easily be a 
vector for DOS attacks -- e.g., by consuming processing resources or 
by exercising a rarely used processing path.  That is why I think it 
is UNSAFE to continue processing a header chain after encountering 
an unknown next header value.

That being said, I think I agree with your main point: if the 
default for a DHCPv6-Shield device is to drop packets with unknown 
next header values, then a DHCPv6-Shield device will by default 
block unknown upper layer protocols, and that is not a desirable 
effect if the ONLY purpose of the device is to shield against rogue 
DHCPv6 packets.

Perhaps a way forward would be to specify that a DHCPv6-Shield 
device SHOULD pass packets with unknown next header values if 
protection against rogue DHCPv6 packets is the ONLY purpose of the 
device, but it MAY default to blocking such packets (in accordance 
with RFC 7045) if other functionality is included.  In any case, the 
behaviour MUST be user configurable (per RFC 7045).

In my opinion, it's truly unfortunate that new IPv6 extension 
headers have not been banned outright in favor of using new 
destination options or upper layer protocol headers.  That would 
make the correct action in this case unambiguous: pass the packet, 
as it's some protocol other than DHCPv6.  RFC 6564 leaves the 
possibility of new extension headers open but raises they very high 
bar of proving that a new destination option or upper layer protocol 
header won't work.  As far as I can see, that is an impossible bar 
to get over.

> The fact that RA guard gives bad advice is no reason for the bad 
> advice to be repeated in this document.

I agree that the advice should be the same.

Mike Heard