DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
draft-ietf-opsec-dhcpv6-shield-08
Discuss
Yes
No Objection
(Adrian Farrel)
(Alia Atlas)
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
Note: This ballot was opened for revision 04 and is now closed.
Ted Lemon Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2015-02-07 for -05)
Unknown
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 IESG member
Yes
Yes
(2014-12-31 for -04)
Unknown
a dreft to be posted to address lc coments from ralph droms and Sheng Jiang
Adrian Farrel Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2015-04-20 for -06)
Unknown
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.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2015-05-13 for -06)
Unknown
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 IESG member
No Objection
No Objection
(2015-01-20 for -05)
Unknown
- 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 IESG member
No Objection
No Objection
(2015-01-22 for -05)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-01-21 for -05)
Unknown
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 IESG member
No Objection
No Objection
(for -05)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2015-01-20 for -05)
Unknown
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 IESG member
No Objection
No Objection
(for -05)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-01-22 for -05)
Unknown
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 IESG member
No Objection
No Objection
(2015-05-13 for -06)
Unknown
Thank you for the effort invested in this document. From my reading it appears that -06 addresses the discuss raised by Ted.