Skip to main content

Last Call Review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03
review-ietf-dhc-dhcpv6-solmaxrt-update-03-secdir-lc-harrington-2013-09-05-00

Request Review of draft-ietf-dhc-dhcpv6-solmaxrt-update
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-03
Requested 2013-08-22
Authors Ralph Droms
I-D last updated 2013-09-05
Completed reviews Genart Last Call review of -03 by Dan Romascanu (diff)
Genart Telechat review of -05 by Dan Romascanu
Secdir Last Call review of -03 by David Harrington (diff)
Secdir Telechat review of -05 by David Harrington
Assignment Reviewer David Harrington
State Completed
Request Last Call review on draft-ietf-dhc-dhcpv6-solmaxrt-update by Security Area Directorate Assigned
Reviewed revision 03 (document currently at 05)
Result Has issues
Completed 2013-09-05
review-ietf-dhc-dhcpv6-solmaxrt-update-03-secdir-lc-harrington-2013-09-05-00
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.

The document describes a change to the values of DHCPv6 Options for Solicit
and Information timeout values (SOL_MAX_RT and INF_MAX_RT).

I am not very knowledgeable about DHCPv6 options, but I have a few
questions.
1) section 6 says " the client MUST process an included SOL_MAX_RT option
and/or an included INF_MAX_RT option"; this could be interpreted as OR even
if both are present. Hopefully no implementer would make that choice, but
they could claim compliance if they did. 
It would be tighter to say they MUST process SOL-MAX-RT and MUST process
INF_MAX_RT ...
2) section 7 says " A DHCPv6 client MUST include the SOL_MAX_RT option code
in an Option Request option [RFC3315] in any message it sends."  Is this
really required for every message?
3) if #2 is true, then section 8 seems to have some unnecessary
conditionals. "the server will send option SOL_MAX_RT and INF_MAX_RT only if
.... the client requested those options ...". Doesn't section 7 say the
client is REQUIRED to request these options?
4) similar to question #3, in section 8 paragraph 2, the server responds to
" a client that has included the SOL_MAX_RT option code in  an Option
Request option"; doesn't section 7 REQUIRE that the client include this?
Ditto for paragraph 3 and INF_MAX_RT?
5) In security considerations, the potential security **impact** of a
malicious server setting a high value isn't discussed.
6) On a related note to #5, are there operational considerations if a DHCPv6
server choose to set an arbitrarily high value? Could there be economic
benefit for a server to do this, leading some requesters to use a different
server either for load-balancing or servicing only priority customers? What
impact could such behavior create in a network that an operator should
consider?
7) In IANA considerations, you define OPTION_SOL_MAX_RT and
OPTION_INF_MAX_RT, but discussion of sending these options in sections 7 and
8 don't mention these codes; they refer only to SOL_MAX_RT and SOL_MAX_RT. I
don't know much about registering DHCP options; is this correct?

David Harrington
ietfdbh at comcast.net
+1-603-828-1401