[secdir] Secdir review of draft-ietf-v6ops-reducing-ra-energy-consumption-02

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 16 October 2015 16:19 UTC

From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: IETF Security Directorate <secdir@ietf.org>, iesg@ietf.org, draft-ietf-v6ops-reducing-ra-energy-consumption.all@tools.ietf.org
Message-ID: <5621239F.60006@gmail.com>
Date: Fri, 16 Oct 2015 19:19:43 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/IgyDawasNTYjml6sZoKrj_uxqas>
Subject: [secdir] Secdir review of draft-ietf-v6ops-reducing-ra-energy-consumption-02
Precedence: list

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

Summary

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

Details

- 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?

Thanks,
Yaron

[secdir] Secdir review of draft-ietf-v6ops-reduci… Yaron Sheffer