ietf
[Top] [All Lists]

secdir review of draft-ietf-dhc-server-override-04.txt

2007-07-02 05:24:24
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • secdir review of draft-ietf-dhc-server-override-04.txt, Stephen Hanna <=