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

Sam - I think most of the issues in your review of draft-raj-dhc-tftp- 
addr-option-04 can be resolved by reviewing the purposes of RFC 3942  
and publishing Informational RFCs describing DHCP option codes.   
Fundamentally, the reason to publish RFCs under the process described  
in RFC 3942 is to document existing uses of option codes in the range  
of option codes reclaimed for assignment to new DHCP options.  The  
concern is to avoid conflicts between new options and those  
grandfathered ("hijacked") option codes.  As such, these RFCs (usually  
Informational) simply document the already established use of those  
option codes, so there are only very minimal requirements for  
demonstrating a need to record the use of the option code, and  
mandating changes to the established use of the option code is out-of- 
scope.  In the opinion of the dhc WG, this I-D meets the requirements  
of RFC 3942, which addresses your statement "It's not clear why a  
distinct code point is needed here" and the suggestions to require  
DHCP authentication, as well as the pointers to other, similar options  
are out-of-scope.

Responding to some of your specific points:

>> At the very least, I suggest mandating the use of DHCP Auth and  
>> removing the suggestion to use option 66 to enhance security.  And,  
>> in the absence of a more data about how widely used this option is,  
>> I suggest not publishing this document at all.

The consensus of the dhc WG, to which I concur, is to publish the  
document as Informational. The text in the Security Considerations  
section about option 66 might be removed.

>> It's not clear why a distinct code point is needed here.  The  
>> document
>> claims that the "TFTP server name" option (#66) must contain a domain
>> name, but I'm pretty sure that real-world devices (e.g. the Cisco
>> 7960) happily accept and use v4 address literals in option 66.
>> Furthermore, there appear to be other DHCP options that could do the
>> trick (e.g. #128, documented in the IANA registry as "TFTP Server IP
>> address (for IP Phone software load)").

To reiterate, it's not so much a question of whether a new code point  
is needed; rather, according to the procedures described in RFC 3942,  
this document gives a description of an existing use of option code  
150.  That option code is in use today and, to eliminate any chance of  
conflict with a new option code in the future, it is entirely  
appropriate to record the use of the option code in the IANA registry  
and document its use.

>> The document's write-up says is "it is believed that to some extent  
>> this
>> option is in use in some deployments of VoIP devices".  That's not a
>> very convincing argument that enough devices use this to justify
>> invoking the RFC3942 procedure, given that other devices are making  
>> do
>> just fine with existing fields.

Richard checked internally at Cisco and got the following response  
from one of our colleagues:

   I would say that over 99% of Cisco Unified Communications Manager
   deployments use Option 150 with a small minority using Option 66.
   We do support Option 66, but it requires a DNS lookup if specified
   by name and does not allow for an array of addreses for the purposes
   of config server redundancy. Any third party phones that support
   registering with CUCM (e.g. Tandberg, Polycom, Sony, and others)
   also support using Option 150.

   Here's more information about uses of option 150 by Cisco customers  
(current as of 8/19/08):

	• 95,000+ Cisco Unified Communications customers (all using option 150)
	• 400+ customers deploying more than 5,000 IP phones
	• 18M+ IP Phones shipped

Also, there are two key differences between the "VoIP Configuration  
server address" option described in this document and other options:

* This option can carry a list of addresses, rather than just a single  
address.
* Cisco's use of the option will ultimately move toward using other
   protocols such as HTTP instead of TFTP, which is why the name was
   changed from "TFTP server address" to "VoIP Configuration server  
address".

>> And if we do want to proceed with defining this option: shouldn't it
>> also allow for v6 addresses?  (The current doc only allows for v4.)

As this document describes existing practice and does not define a new  
option, there is no need to describe a version of the option for  
DHCPv6 to carry IPv6 addresses.  Cisco expects to use a vendor- 
identifying vendor-specific option for the DHCPv6 version of this  
option.

- Ralph

On Nov 26, 2008, at Nov 26, 2008,2:58 AM, Samuel Weiler wrote:

> 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.
>
> Summary:
>
> At the very least, I suggest mandating the use of DHCP Auth and  
> removing the suggestion to use option 66 to enhance security.  And,  
> in the absence of a more data about how widely used this option is,  
> I suggest not publishing this document at all.
>
> Details:
>
> In 2004 RFC3942 defined a procedure for vendors to lay claim to DHCP  
> option code points that, while previously set aside for "site- 
> specific" options, had been used by vendors.  This document attempts  
> to claim such a code point.
>
> It's not clear why a distinct code point is needed here.  The document
> claims that the "TFTP server name" option (#66) must contain a domain
> name, but I'm pretty sure that real-world devices (e.g. the Cisco
> 7960) happily accept and use v4 address literals in option 66.
> Furthermore, there appear to be other DHCP options that could do the
> trick (e.g. #128, documented in the IANA registry as "TFTP Server IP
> address (for IP Phone software load)").
>
> The document's write-up says "it is believed that to some extent this
> option is in use in some deployments of VoIP devices".  That's not a
> very convincing argument that enough devices use this to justify
> invoking the RFC3942 procedure, given that other devices are making do
> just fine with existing fields.  Do these devices ALSO check option
> #66, such that continued use of #150 is really unnecessary?  In the
> four years since publication of RFC3942, have enough of these devices
> been obsoleted (or updated to also use other DHCP option fields) that
> this code point is no longer needed?
>
> And if we do want to proceed with defining this option: shouldn't it
> also allow for v6 addresses?  (The current doc only allows for v4.)
>
> The security considerations section cites rogue DHCP servers as attack
> vectors, but doesn't do enough to encourage the use of DHCP Auth.
> Furthermore, it suggests using the "TFTP server name" option, on the
> basis that a client must do a DNS lookup to use the contents, thereby
> giving an tiny extra layer of assurance.  I'm pretty sure that
> real-world devices happily accept v4 literals in option 66, making the
> suggestion a poor one.
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf