Last Call Review of draft-ietf-v6ops-reducing-ra-energy-consumption-02

Request Review of draft-ietf-v6ops-reducing-ra-energy-consumption
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-10-27
Requested 2015-10-15
Authors Andrew Yourtchenko, Lorenzo Colitti
Draft last updated 2015-10-22
Completed reviews Genart Last Call review of -02 by Christer Holmberg (diff)
Genart Telechat review of -03 by Christer Holmberg
Secdir Last Call review of -02 by Yaron Sheffer (diff)
Opsdir Last Call review of -02 by Qin Wu (diff)
Assignment Reviewer Yaron Sheffer 
State Completed
Review review-ietf-v6ops-reducing-ra-energy-consumption-02-secdir-lc-sheffer-2015-10-22
Reviewed rev. 02 (document currently at 03)
Review result Has Issues
Review completed: 2015-10-22


    I have reviewed this document as part of the security directorate's
    ongoing effort to review all IETF documents being processed by the
    These comments were written primarily for the benefit of the
    area directors.  Document editors and WG chairs should treat these
    comments just like any other last call comments.

    This document contains device-side and network-side recommendations
    aimed at reducing the number of IPv6 Router Advertisements, so that
    battery-powered devices are not badly affected by them. The document
    is short and well-written.


    The document is ready to be published, with a few minor issues.


    - My main issue with the document is that it describes a situation
    that's broken on both the network and the device side. It then
    proposes to change both sides, but it seems to me that we are now at
    a "local minimum". Given the existing network, there is no
    motivation for devices to change. And given the existing devices,
    there is no motivation for networks to change. I would suggest to
    propose a transition strategy that will get us there without
    assuming that all networks and all devices will magically start
    doing "the right thing" all at the same time. For example, during
    the transition period devices SHOULD allow to configure certain
    networks for the old behavior, and other networks for the new one.
    Or maybe devices can detect the network's behavior automatically.

    - Sec. 5.1 suggests to prefer certain Router Solicitations on the
    network side, so I would expect Sec. 5.2. to recommend that devices
    should use exactly those Solicitations.

    - The term "appropriate countermeasures" is not very useful when
    recommending security solutions. Do you have any examples? Router
    configurations? IPS devices? Legal actions? :-)

    - Can you add something about whether your proposal increases or
    decreases the risk of malicious hosts bricking a device (or a
    router?) by sending a RA with incorrect information?