inline...
On Dec 2, 2008, at 9:30 AM, Jeffrey Hutzelman wrote:
--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.
Yes, in some cases this could be done. Since this applies to ALL DHCP
options, it seems a little strange to point it out for this one as
though it's a special case. I guess as long as the text makes it
clear that this doesn't apply only to this one option, then it would
make sense to add it. Do you have suggested text?
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(*).
Option 66 is called "TFTP server name" in the document because that's
the name of the option. Quoting RFC2132:
9.4 TFTP server name
This option is used to identify a TFTP server when the 'sname' field
in the DHCP header has been used for DHCP options.
The code for this option is 66, and its minimum length is 1.
Code Len TFTP server
+-----+-----+-----+-----+-----+---
| 66 | n | c1 | c2 | c3 | ...
+-----+-----+-----+-----+-----+---
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.
Yep, valid point. Do you have suggested replacement text?
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?
The document is following the instructions outlined in RFC3942:
2. Vendors that currently use one or more of the reclassified
options
have 6 months following this RFC's publication date to notify the
DHC WG and IANA that they are using particular options numbers
and
agree to document that usage in an RFC. IANA will move these
options from the "Unavailable" to "Tentatively Assigned" state.
...
4. For those options in the "Tentatively Assigned" state, vendors
have 18 months following this RFC's publication date to submit an
Internet-Draft documenting the option. The documented usage MUST
be consistent with the existing usage. When the option usage is
published as an RFC, IANA will move the option to the "Assigned"
state.
Finally, since RFC3942 specifically says the documentation of the
usage "MUST be consistent with the existing usage", it would actually
be violating RFC3942 if we were to add a mandate that the "DHCP Auth"
option be used.
/raj
-- 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