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

[Joel Jaeggli <[e-mail]>]

Right one would expect future extension headers to match the TLV  expectations of 6564. I can live with the removal of filtering advice but I'd like to see that run past the working group at the very least.

Sent from my iPhone

> On Feb 7, 2015, at 11:46, Ted Lemon <[e-mail]> wrote:
> 
> Ted Lemon has entered the following ballot position for
> draft-ietf-opsec-dhcpv6-shield-05: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> When I began with this DISCUSS, my understanding was that in order to
> implement DHCPv6 Shield and be sure of stopping all DHCP packets, it
> would, as the document says, be necessary to filter packets with unknown
> IPv6 headers.   This would likely mean that the layer 2 switching fabric
> of a network supporting DHCPv6 shield would be unable to carry any IP
> packets containing not only unknown IP extension headers, but also
> packets containing unknown (to the switching fabric) protocol headers.  
> Consequently I suggested a fairly elaborate way to mitigate the risk
> without requiring that all such packets be filtered.
> 
> However, after discussing this at length with Fernando, I realized that
> it was actually not at all necessary to filter unknown IPv6 headers.  
> The reason for this is that we can safely assume that any IP extension
> header that appears in a packet conforms to RFC 6564.   This means that
> switches implementing DHCPv6 shield can at least in principle skip over
> unknown IP extension headers.   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.   I believe that a switching
> fabric should not default to dropping packets it doesn't recognize,
> because this pretty much guarantees that new protocols can't be deployed
> even in site-specific situations.
> 
> Therefore, I believe that this document should not only not require
> filtering unknown IP extension headers, but should not even mention
> filtering them.   It may be that some implementations may need to filter
> them for other reasons, but this is already allowed by RFC 7045, and
> therefore needn't be mentioned here.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This is the original text of this DISCUSS:
> 
> This text makes sense, but I think it needs to be changed somewhat:
> 
>   3.  When parsing the IPv6 header chain, if the packet is identified
>       to be a DHCPv6 packet meant for a DHCPv6 client or the packet
>       contains an unrecognized Next Header value, DHCPv6-Shield MUST
>       drop the packet, and SHOULD log the packet drop event in an
>       implementation-specific manner as a security alert.
>       DHCPv6-Shield MUST provide a configuration knob that controls
>       whether packets with unrecognized Next Header values are dropped;
>       this configuration knob MUST default to "drop".
> 
>          RATIONALE: An unrecognized Next Header value could possibly
>          identify an IPv6 Extension Header, and thus be leveraged to
>          conceal a DHCPv6-server packet (since there is no way for
>          DHCPv6-Shield to parse past unrecognized Next Header values
>          [I-D.gont-6man-rfc6564bis]).  [RFC7045] requires that nodes be
>          configurable with respect to whether packets with unrecognized
>          headers are forwarded, and allows the default behavior to be
>          that such packets be dropped.
> 
> I think it's worth considering whether the default setting for this
> configuration knob should be "drop" or "pass."   The problem with
> defaulting to "drop" is that it means that extension headers the DHCPv6
> Shield device does not understand fail to pass, which could cause
> operational problems.   The problem with not defaulting to "drop" you
> have already explained.   I do not think that the threat of DHCPv6
> spoofing is sufficient to justify defaulting to drop.   Yes, DHCPv6
> spoofing can cause operational issues.   So can filtering "unknown"
> headers.
> 
> The frustrating thing about this document is that it actually solves the
> problem the wrong way.   What this document should recommend is filtering
> of DHCPv6 packets from _clients_.   If a rogue DHCP server can't see
> client multicasts because DHCPv6 shield is blocking them, then it can't
> know to attack DHCPv6 clients.   This substantially limits the rogue's
> ability to attack DHCPv6 clients on the local subnet.   If you combine
> that with server packet filtering but do not block unknown headers, I
> think you have achieved a good tradeoff between the problems caused by
> whatever spoofing might get to a client using an unknown header and the
> problems caused by blocking non-DHCP packets that use that unknown header
> for some legitimate purpose.
> 
> So, realizing that this would be a major change, the way I would LIKE you
> to address this discuss is to add DHCPv6 client packet filtering.   You
> could also address it by changing the default for the unknown header
> filter, but I would understand if you felt that this was inadequate.   Or
> you could argue persuasively that I'm wrong, which has been known to
> happen. :)
> 
> 
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>