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

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@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.

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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf