Dear Fernando, all, I second this opinion; maybe some additional section could be added to state the extras issues related to a routed DHCPv6 server environment, and what can (or MUST) be done in such a setup?
As far as wording in this draft goes, I am not sure about the '- ' in "first-fragment" and in "state-less", but then again I am no English native speaker myself. Best regards Carsten From: OPSEC [mailto:[email protected]] On Behalf Of Sleigh, Robert Sent: Monday, May 12, 2014 6:28 PM To: Eric Vyncke (evyncke); KK Chittimaneni; [email protected] Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Hi All This seems like a good step in the right direction, so I think this document has some value and should progress but... Unless this functionality is to be deployed on every switch port across an entire environment (which I grant you, it may well be), I think this will only remove the risk entirely if the client and the DHCPv6 server are located on the same switch. It does not necessarily provide full protection for endusers in, for example, a routed DHCPv6 relay environment, and I think a similar issue arises in cascading L2 devices. In a routed DHCPv6 relay environment there will be an ingress port on the enduser's local switch which will need to be enabled for receiving DHCPv6-server messages, but the switch will be reliant on the upstream devices to have filtered out rogue DHCPv6-server messages, as the local switch has no way of determining which upstream DHCP-server messages are valid. Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile From: OPSEC [mailto:[email protected]] On Behalf Of Eric Vyncke (evyncke) Sent: 12 May 2014 14:10 To: KK Chittimaneni; [email protected]<mailto:[email protected]> Cc: Fernando Gont Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield 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) * 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 * Section 3: should define what a 'DHCP shield device' is * 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 * Section 5: "SHOULD be logged in an implementation-specific manner as security fault" => "security alert" or "security event" * 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. * 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 * Add a reference to SAVI-DHCP ? Else, good document, pretty much like the well-known rogue DHCPv4 -éric From: Kiran Kumar Chittimaneni <[email protected]<mailto:[email protected]>> Date: dimanche 11 mai 2014 05:12 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield Dear Opsec WG, The WGLC for this draft technically ended last month with just one response received. Not enough to move forward. The co-chairs chatted about this and noted that there was a lot more support for this doc during earlier stages. Given that, we'd like to give the WG a bit more time to review this and extend the LC to the 24th of May. Ideally, we'd like to get at least two volunteers who could do a thorough review of this doc and post their comments to the list. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ Please read it now and report to the list whether you support publication or not. Insufficient responses will be taken as an indication of lack of interest and we'll stop from proceeding further. Regards, KK (as Opsec WG co-chair) NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
