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

["Ted Lemon" <[e-mail]>]

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