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

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.

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

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

I agree with Stephen's point and believe that Ted's suggested change of the default behavior is one way to address that issue.

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

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.

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

Thank you for the effort invested in this document. From my reading it appears that -06 addresses the discuss raised by Ted.