--On Wednesday, November 26, 2008 02:58:25 AM -0500 Samuel Weiler
<weiler@xxxxxxxxxx> wrote:
The security considerations section cites rogue DHCP servers as attack
vectors, but doesn't do enough to encourage the use of DHCP Auth.
In many deployments, DHCP is used by devices which have no prior
configuration, or at least no prior association with the network operator.
In such scenarios, DHCP auth is frequently impractical. Instead, network
operators take other measures to insure that only replies from legitimate
DHCP servers ever reach clients. For example, they may configure switches
to monitor and filter DHCP traffic such that responses can only come from a
small set of trusted ports. I'm somewhat surprised that the document does
not mention this approach, as it is fairly common.
I believe there may also be some confusion as to the meaning of option 66.
This option has exactly the same semantics as the 'sname' field in the
bootp packet, and is used in the event that field is overloaded to carry
additional options. See RFC2132 sections 9.3, 9.4, 9.5, and the
description of the option overload option starting at the bottom of page 23
of RFC2131. So, putting a name in option 66 has exactly the same effect as
putting it in the 'sname' field, which is well-defined for BOOTP requests,
but not so well defined for DHCP replies (in fact, so far as I've been able
to tell, neither BOOTP nor DHCP has anything to say on the semantics of
this field other than that it's a "server host name", and calling option 66
"TFTP server name" is really misleading, because sname didn't actually mean
that(*).
In any case, the comment in the present document's security considerations
that use of a name rather than an address is "more secure" is flawed in
several ways. First, the DHCP server operator has no control over what
options an attacker sends; if an attacker prefers to send and address, he
can do so. Secondly, if a name is used, the attacker need only send a name
in a zone which he controls; there is no need to subvert any part of the
DNS.
I share Sam's confusion as to why a code point is needed here at all. What
purpose does this option serve that is not served by the siaddr field?
-- Jeff
(*) In fact, I've seen at least one widespread client implementation that
assumed that sname was the name of the server identified in the siaddr
field, and updated /etc/hosts so that sname would resolve to siaddr.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf