Skip to main content

Last Call Review of draft-ietf-roll-mpl-parameter-configuration-04
review-ietf-roll-mpl-parameter-configuration-04-secdir-lc-weis-2015-07-02-00

Request Review of draft-ietf-roll-mpl-parameter-configuration
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-06-30
Requested 2015-06-18
Authors Yusuke Doi , Matthew Gillmore
I-D last updated 2015-07-02
Completed reviews Genart Last Call review of -04 by Peter E. Yee (diff)
Genart Telechat review of -06 by Peter E. Yee (diff)
Secdir Last Call review of -04 by Brian Weis (diff)
Opsdir Last Call review of -04 by Menachem Dodge (diff)
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-roll-mpl-parameter-configuration by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 08)
Result Has nits
Completed 2015-07-02
review-ietf-roll-mpl-parameter-configuration-04-secdir-lc-weis-2015-07-02-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.

This draft defines a new DHCPv6 option, whereby a DHCP server can configure a
client with  Multicast Protocol for Low power and Lossy Networks (MPL) policy.
The option definition seems straightforward. Security Considerations outlines
three items which seem useful:

1. Describing a resource consumption threat ("excessive layer-2 broadcasting“)
resulting from a man-in-the-middle modifying policy sent within an option. If
there is a suggested mitigation (e.g., a means of integrity protecting the
DHCPv6 traffic between the client and server) this would be worth noting. But
I’m not sure if there any available mitigation in a ROLL environment.

2. Making a requirement that a server implementation choose reasonable policy
values. This might be more useful if it were phrased as a threat, something
like “Server implementations need to take care in setting reasonable bounds for
each parameter in order to avoid overloading the network."

3. Making a requirement that the "DHCP server or the network itself shall be
trusted by some means including network access control or DHCP authentication”.
 Is this this “shall” intended to be an RFC 2119  “MUST”?

I consider this draft to be Ready with nits.

Brian