Re: [secdir] secdir review of draft-raj-dhc-tftp-addr-option-04

--On Wednesday, November 26, 2008 02:58:25 AM -0500 Samuel Weiler 
<weiler@watson.org> 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.
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir