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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf