Hi, Eric,
Thanks so much for your feedback!
Please find my responses in-line...
On 05/12/2014 03:09 PM, Eric Vyncke (evyncke) wrote:
> KK, Gunter, Fernando & Will,
>
> I have reviewed the document and here are my comments (some cosmetic):
>
> * section 1: "on a specified port of the layer-2 device" => "on
> specific port(s) of the layer-2 device" (plural form)
> * Section 1: "Only those ports to which a DHCPv6 server" => "Only
> those ports to which a DHCPv6 server or relay" (relays should be
> allowed as well)
I have applied these two. Thanks!
> * Section 3: not sure whether it is relevant here, this is well-known
> and accepted terminology, I am always uneasy when information is
> duplicated as it is an open door for inconsistency
FWIW, the reason for which we added this is because we were requested to
define these terms for other documents (e.g., RFC 7112). Acording to
6man discussions, this was needed. But we could (alternatively just
reference the corresponding section of RFC7112.
> * Section 3: should define what a 'DHCP shield device' is
Done.
> * Section 5: I do not agree with point 1) if the specific platform
> cannot handle a long ext header chain, it should be allowed to drop
> the packet (the MUST NOT should be SHOULD NOT or even a MAY —
> reversing the proposed policy). Of course, such platforms cannot
> claim compatibility with DHCP-shield
I agree with you. :-) This comes from past discussions surrounding
RA-Guard. I've removed the "must not drop" claim. i.e., the text now looks:
RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a limit
on the number of bytes they can inspect (starting from the
beginning of the IPv6 packet), since this could introduce false-
positives: legitimate packets could be dropped simply because the
DHCPv6-Shield device does not parse the entire IPv6 header chain
present in the packet. An implementation that has such an
implementation-specific limit MUST NOT claim compliance with this
specification.
> * Section 5: "SHOULD be logged in an implementation-specific manner as
> security fault" => "security alert" or "security event"
Done.
> * Section 7: the whole I-D is only handling the physical/wired
> switched case while in the introduction it is stated to be
> 'broadcast network'. The security section and/or introduction should
> mention this.
I've s/broadcast/switched/
> * Section 7: should also mention other DHCP related threats? Such as
> DoS attack against DHCP servers? Amplification/reflection attacks?
> Of course, the mitigation techniques are out of scope, but, I think
> that the threats should be mentioned
Changed to:
---- cut here ----
The mechanism specified in this document can be used to mitigate
DHCPv6-based attacks against hosts. Attack vectors based on other
messages meant for network configuration (such as ICMPv6 Router
Advertisements) are out of the scope of this document. Additionally, the
mechanism specified in this document does not mitigate attacks against
DHCPv6 servers (e.g., DoS).
---- cut here ----
> * Add a reference to SAVI-DHCP ?
SAVI-DHCP seems rather orthogonal... but I might be wrong. i.e.,
savi-dhcp seems to be about building state on the layer-2 device based
on DHCPv6 exchanges, rather than about preventing malicious DHCPv6
exchanges. Am I right?
In any case, I guess one could add an informational reference as follows:
"The security of a site employing DHCPv6 Shield could be further
improved by deploying [SAVI-DHCP], to mitigate IPv6 address spoofing".
Thoughts?
> Else, good document, pretty much like the well-known rogue DHCPv4
That was the intent (porting dhcpv4 guard). :-)
Thanks so much!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
