[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

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 784381A6F39; Fri, 16 Oct 2015 09:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id t1sBxQfaxGpR; Fri, 16 Oct 2015 09:19:48 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F2B1A6F1E; Fri, 16 Oct 2015 09:19:47 -0700 (PDT)
Received: by wicgb1 with SMTP id gb1so15915799wic.1; Fri, 16 Oct 2015 09:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=KPAXd4uBRUyXwf0SPF0q9GHExZtjunN5zv94QdYH3Vk=; b=x/zudId9dDx/YanHhJa93vwRtgNN5awF+Mlc8ZVj06XFxyfOMkQpa14hjeIgaN9xv/ s2vWT8UI+5z+5e63/Th6Ost1IJKLcXV9x9A/KOdNYl7gB7QId1xn/JVUu2eB7LORYcEy PDEV57+TpiLv3ZmfOdMwyJ0tPoQ3BNyX+/tc9Poa8Zhe3A3/SCE1Cmwt6QxRqbNncqTg 3OEnsVfacF0fAYTzRYu566MTMadARP1FYCAipld/+9VuWPrz1KulNe9xfQ5JnMSluBPL 9CU3IzlQHNBn5XlrxTdS3ISAr7XsXwYoALs27gLnP/OW/V2IIipz/nngVJSSnvkPeioA A83A==
X-Received: by with SMTP id y1mr20358287wja.84.1445012386225; Fri, 16 Oct 2015 09:19:46 -0700 (PDT)
Received: from [] (bzq-109-66-107-104.red.bezeqint.net. []) by smtp.googlemail.com with ESMTPSA id ew2sm3776320wic.20.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2015 09:19:45 -0700 (PDT)
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
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 16:19:52 -0000

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.


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?