DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
draft-ietf-opsec-dhcpv6-shield-08

Note: This ballot was opened for revision 04 and is now closed.

(Ted Lemon) Discuss

Discuss (2015-02-07 for -05)
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 (2015-02-07 for -05)
No email
send info
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. :)

(Joel Jaeggli) Yes

Comment (2014-12-31 for -04)
No email
send info
a dreft to be posted to address lc coments from ralph droms and Sheng Jiang

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-05-13 for -06)
No email
send info
I'm not going to block on this, but it seems weird to me that this would be a BCP. (And I see I am not the first to ask about that.)

(Benoît Claise) No Objection

Comment (2015-01-20 for -05)
No email
send info
- We note that DHCPv6-Shield only mitigates only DHCPv6-based attacks
   against hosts.
Remove one "only"

- 
OLD:
      DHCPv6-Shield MUST parse the entire IPv6 header chain present in
       the packet, to identify whether it is a DHCPv6 packet meant for a
       DHCPv6 client (i.e., a DHCPv6-server message).
NEW:
       DHCPv6-Shield implementations MUST parse the entire IPv6 header chain present in
       the packet, to identify whether it is a DHCPv6 packet meant for a
       DHCPv6 client (i.e., a DHCPv6-server message).

- As mentioned by Jürgen in his OPS-DIR review:
  Section 5 is titled "DHCPv6-Shield Implementation Advice". It uses
  RFC2129 MUST language and talks about criteria for compliance. Is
  "Advice" really the right word for this? Sounds a bit soft for what
  are actually implementation requirements.

Fernando propoped: The title was borrowed from a similar I-D for RA-Guard implementation. I
guess we could simply say "DHCPv6-Shield Implementation"?

I thought it was a good idea.

Alissa Cooper (was Discuss) No Objection

Comment (2015-04-20 for -06)
No email
send info
I see that the normative recommendations about logging have been removed, so I am clearing my DISCUSS. However, I still think the document would be better if it explained the difference between a security fault and a security alert. I don't understand what the difference is supposed to be.

Also, it seems the changes I had suggested in my COMMENT originally were not adopted -- not sure if that was on purpose or an oversight.

= Section 1 =
s/meant to DHCPv6 clients/intended for DHCPv6 clients/

s/a specific ports/specific ports/

s/DCHPv6-Shield/DHCPv6-Shield/

s/only mitigates only/only mitigates/

= Section 5 =
I support all of the changes to Section 5 suggested by Pete. 

I don't think the spec should recommend logging packet drop events unless it explains what is meant to be done with the logs.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2015-01-22 for -05)
No email
send info
There is one thing here I can't figure out, maybe you can
enlighten me though...

section 5, bullet 3: this seems like another "don't make it
easier to use IPv6 rule" and as a default, which I can't
figure.  Why do you even need to block "an unrecognized Next
Header value" to protect against a spoofed DHCPv6 response
message?

- intro: s/meant to/sent to/ ?

(Brian Haberman) No Objection

Comment (2015-01-22 for -05)
No email
send info
I agree with Stephen's point and believe that Ted's suggested change of the default behavior is one way to address that issue.

Barry Leiba No Objection

(Terry Manderson) No Objection

Comment (2015-05-13 for -06)
No email
send info
Thank you for the effort invested in this document. From my reading it appears that -06 addresses the discuss raised by Ted.

(Kathleen Moriarty) No Objection

Comment (2015-01-21 for -05)
No email
send info
I'd like to understand why this is a BC and if that's the right designation.  Hannes brought this up in his SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05273.html

(Pete Resnick) No Objection

Comment (2015-01-20 for -05)
No email
send info
Abstract:

   This document specifies
   a Best Current Practice for the implementation of DHCPv6 Shield.

No, this does not specify a Best Current Practice *for* implementing DHCPv6-Shield; it's a Best Current Practice *for* the Internet (or some portion thereof). A "Best Current Practice" is not something that you specify. This document *does* specify "a set of operational practices or guidelines for implementation of DHCPv6 Shield." Say that instead.

Section 4: s/MUST be/is

Section 5:

OLD
   The following filtering rules MUST be enforced as part of a
NEW
   The following are the filtering rules that are enforced as part of

Sub bullet 2:

   s/SHOULD log the packet/ought to log the packet

(That's not an implementation requirement, just something good to do.)

Sub bullet 2:

   s/MUST contain the/must contain the

(That's just  re-describing something in another document, not a new requirement.)

Sub bullet 3, first paragraph: The first sentence contradicts the second sentence as it's written with regard to unrecognized Next Header values. I suggest splitting this up:

   3.  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". When parsing the
       IPv6 header chain, if the packet contains an unrecognized Next
       Header value and the configuration knob is configured to "drop",
       DHCPv6-Shield MUST drop the packet, and ought to log the packet
       drop event in an implementation-specific manner as a security
       alert.
       
          RATIONALE: [...]

   4.  When parsing the IPv6 header chain, if the packet is identified
       to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield
       MUST drop the packet, and ought to the packet drop event in an
       implementation-specific manner as a security alert.

   5.  In all other cases...

OLD
   The above rules require that if a packet is dropped due to this
   filtering policy, the packet drop event be logged in an
   implementation-specific manner as a security fault.  The logging
   mechanism SHOULD include a per -port drop counter dedicated to
   DHCPv6-Shield packet drops.
NEW
   The above indicates that if a packet is dropped due to this filtering
   policy, the packet drop event be logged in an implementation-specific
   manner as a security fault.  It is useful for the logging mechanism
   to include a per -port drop counter dedicated to DHCPv6-Shield packet
   drops.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection