I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The analysis of threats and countermeasures in the Security Considerations section of this document is OK. Overall, I do not have any concerns about the approval of this document after the few issues listed here are corrected. Making these corrections should not be difficult. The Security Considerations section of the document has a few issues. First, the damage that a rogue DHCP relay could cause also includes changing DHCP options in DHCPACK messages and extending leases when they should not be extended. Second, the current text implies that either DHCP authentication or DHCP Relay Agent option authentication can be deployed to provide adequate protection against the threats described. Actually, this is not accurate. DHCP Relay Agent option authentication alone will not suffice unless protection is in place against the introduction of rogue DHCP relays. Without DHCP authentication, a rogue relay could simply change the Server Identifier in the DHCPOFFER without detection. Third, this draft does not add any new vulnerabilities that were not already present, except in the case where DHCP authentication is already in place and DHCP clients require its use. This should be noted. Fourth, this draft should recommend that either DHCP authentication SHOULD be deployed or protection be provided against the insertion of rogue DHCP relays and servers. Such protection continues to be essential in protecting clients from misconfiguration. A discussion of the security benefits provided by this option (if any) would also be useful. Apparently, this option extends the benefits of the DHCP Relay Agent Info option as described in section 4.0 of 3046 to cases where the DHCP client sends unicast packets (like the RENEWING state). I'm not sure that any of these benefits actually apply in that circumstance but it would be good to describe any security benefits provided. Here are a few non-security comments: On the last line of page 5, I think the phrase "all DHCP packets all servers" should be "all DHCP packets to all servers". The document should reference essential docs earlier, no later than section 3. For example, RFC 3046 is not actually referenced at all, although clearly section 5 intends to do so. This document should reference DHCPv6, since it is referred to. The references should be divided into normative and informative. The reference in section 5 should be to [6] not [3]. BTW, I am on vacation this week with limited Internet access so I may be late in responding to email. Sorry about that. Thanks, Steve Hanna _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf