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 | |
| Draft 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 | |
| Review |
review-ietf-roll-mpl-parameter-configuration-04-secdir-lc-weis-2015-07-02
|
|
| 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