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 rev. 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
Draft last updated 2015-07-02
Completed reviews Genart Last Call review of -04 by Peter Yee (diff)
Genart Telechat review of -06 by Peter 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
Review review-ietf-roll-mpl-parameter-configuration-04-secdir-lc-weis-2015-07-02
Reviewed rev. 04 (document currently at 08)
Review result Has Nits
Review completed: 2015-07-02

Review
review-ietf-roll-mpl-parameter-configuration-04-secdir-lc-weis-2015-07-02

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