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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]