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

[Samuel Weiler <weiler at watson.org>]

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