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

[tianxiang li <[e-mail]>]

Hi Hilarie,

Thank you for the review, please see inline.

Cheers,
Tianxiang

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

>          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."
>
> [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.


> 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.
>
> [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.


> 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 ...".
>
> [Tianxiang] Thank you, we will change this accordingly.


> Hilarie
>