Subject: [secdir] Security review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

From: "Hilarie Orman" <[email-masked]>
Date: Thu, 9 Feb 2017 13:50:09 -0700

Security review of DHCPv6 Prefix Length Hint Issues
	  draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

Do not be alarmed.  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 gives advice on how servers and clients can handle DHCP cases
in which the client requests a particular prefix length and the server
cannot exactly match it.  

This statement is very difficult to interpret:
"the server SHOULD provide the prefix with the shortest length
   possible which is closest to the prefix-length hint value."
This alternative in section 3.6 makes more sense:
"assign a prefix of at least the hint length (or shorter) if one is
   available."

I do not see any obvious security flaws, but my opinion is tempered by
the lack of prior discussion.  The security considerations refer to
RFC3633 "IPv6 Prefix Options for DHCPv6", and that refers to ongoing
development of IPsec for DHCPv6.  As nearly as I can tell, that work
was never done.  That makes it difficult to have confidence in the "no
new security considerations" claim.

Some nits:

Remove the comma in the first sentence of the introduction.

"prefix which length" should be "prefix with length" or possibly
"prefix whose length".

"The servers usually has a record" should be "The server usually has a record".

No comma in "When the client wants the same prefix back from the
server, and would prefer ...".

Hilarie

---

From: tianxiang li <[email-masked]>
Date: Fri, 10 Feb 2017 20:53:47 +0800

Hi Hilarie,

Thank you for the review, please see inline.

Cheers,
Tianxiang

2017-02-10 4:50 GMT+08:00 Hilarie Orman <[email-masked]>:

> [Tianxiang]Thanks for pointing that out, the sentence in section 3.2 is a
bit confusing, we could change it as follow:

OLD: ... the server SHOULD try to provide a prefix matching the
prefix-length value, or the prefix with the shortest length possible which
is closest to the prefix-length hint value."

NEW: ...the server SHOULD provide a prefix matching the prefix-length hint,
or a prefix which is length is shorter and as close as possible to the
prefix-length hint.

> [Tianxiang] Do you have some suggestions as to how we should address this
issue? I think one solution would be to change the Security Considerations
section as follow:

OLD: This document introduces no new security considerations over those
already discussed in section 15 of RFC3633, as this document provides
guidance on how the clients and servers interact with regard to the
prefix-length hint mechanism introduced in RFC3633.

NEW: This document provides guidance on how the clients and servers
interact with regard to the prefix-length hint mechanism introduced in
RFC3633, security considerations regarding DHCPv6 prefix delegation are
described in section 15 of RFC 3633.

> [Tianxiang] Thank you, we will change this accordingly.