Re: [secdir] secdir review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03

["Ralph Droms (rdroms)" <[e-mail]>]

Thanks for your review.

Comments in line; all edits to appear in -04 rev.

On Aug 31, 2013, at 11:46 AM 8/31/13, ietfdbh <[e-mail]> 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.
> 
> 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 ...

Another artifact of adding INF_MAX_RT to the document.  Thanks for the suggested text, which I've used

> 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?

Hm.  This text is actually somewhat redundant as RFC 3315 is authoritative as to when the Option Request option is sent.  Changed to:

  A DHCPv6 client MUST include the SOL_MAX_RT option code in any Option
  Request option [RFC3315] it sends as required by RFC 3315.

> 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?

I think the text as it stands is appropriate for clarity regarding interoperation with non-compliant clients.  Otherwise, an implementor might interpret the text as requiring that the server send the options even if the client has not requested them.

> 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?

Previous answer applies here, as well.

> 5) In security considerations, the potential security **impact** of a
> malicious server setting a high value isn't discussed.

OK. Added:

   ...which may cause an undue delay in a client completing its DHCPv6
   protocol transaction in the case no other valid response is received.

> 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?

I can't think of any other impacts.  If you feel strongly about the issue, we can poll the dhc WG for their thoughts.

> 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?

Section 7 uses the phrases "SOL_MAX_RT option code" and "INF_MAX_RT option code, which would be considered equivalent to OPTION_SOL_MAX_RT and OPTON_INF_MAX_RT.  Section 8 uses the phrases "SOL_MAX_RT option" and "INF_MAX_RT option" to refer to the options themselves, not just the option codes.  I think the text is correct in all cases.

- Ralph

> 
> David Harrington
> [e-mail]
> [phone]
> 
>