DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
RFC 7610
Discuss
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Alvaro Retana No Objection
(Ted Lemon; former steering group member) 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.
(Joel Jaeggli; former steering group member) Yes
a dreft to be posted to address lc coments from ralph droms and Sheng Jiang
(Adrian Farrel; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) (was Discuss) No Objection
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.
(Barry Leiba; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
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; former steering group member) No Objection
- 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.
(Brian Haberman; former steering group member) No Objection
I agree with Stephen's point and believe that Ted's suggested change of the default behavior is one way to address that issue.
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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.
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
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/ ?
(Terry Manderson; former steering group member) No Objection
Thank you for the effort invested in this document. From my reading it appears that -06 addresses the discuss raised by Ted.