[secdir] SECDIR review of draft-ietf-roll-home-routing-reqs

Alan DeKok <aland@deployingradius.com> Mon, 09 February 2009 14:17 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E8E3A6C17; Mon, 9 Feb 2009 06:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.734
X-Spam-Level:
X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPhkq1T8BlwS; Mon, 9 Feb 2009 06:17:28 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id F08513A6BB9; Mon, 9 Feb 2009 06:17:26 -0800 (PST)
Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 9A4FA123444C; Mon, 9 Feb 2009 15:17:30 +0100 (CET)
Message-ID: <49903AFA.8020008@deployingradius.com>
Date: Mon, 09 Feb 2009 15:17:30 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: secdir@ietf.org, IESG IESG <iesg@ietf.org>, abr@zen-sys.com, jbu@zen-sys.com, giorgio.porcu@guest.telecomitalia.it
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [secdir] SECDIR review of draft-ietf-roll-home-routing-reqs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 09 Feb 2009 14:17:28 -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 discusses the routing requirements for low-power and
lossy (e.g. "in-home") wireless networks.

  The document discusses the use of such networks to drive devices such
as lights, window shades, ... and health care reporting and monitoring.
 The first sentence of the Security Considerations section says:

   Implementing security mechanisms in ROLL network devices may
   degrade energy efficiency and increase cost.

  This sentence is simply inadequate, and shows that the priorities are
in the wrong place.

  If the methods outlined here are to be used in health care reporting
and monitoring, then device security must be a higher priority than
energy efficiency.  The alternative is to design an "energy efficient"
device that is susceptible to attacks that cause illness or even death.

  The potential for abuse with cheap but insecure devices in healthcare
is so large as to be catastrophic for the people involved.  The ability
to forge inaccurate values for (e.g.) insulin levels can result in
incorrect diagnosis and/or dosages.

  Different jurisdictions may also have legal restrictions on the use
and dissemination of healthcare information.  Broadcasting data such as
insulin levels "in the clear" may be illegal.

  Even outside of the healthcare field, insecure protocols would allow
attackers to control window blinds, lights, and alarm systems.  The side
effects here are possible voyeurism, robbery and/or home invasion.
Attacks on lights and other devices could lead to artificially increased
power bills, with side-effects ranging from increased debt to
law-enforcement suspicion that the home is being used to grow illegal crops.

  The second sentence of the Security Considerations section says:

   The routing protocol chosen for ROLL MUST allow for low-power,
   low-cost network devices with limited security needs.

  Any device used for health care and/or home alarm systems CANNOT be
described as having "limited security needs".

  The third, and final, sentence of the Security Considerations section
says:

   Protection against unintentional inclusion in neighboring networks
   MUST be provided.

  These requirements are inadequate for the stated purpose of the document.

  At the minimum, the protocol must protect against:

 - forgery of data from known devices
 - alteration of data from known devices
 - unauthorized commands from unknown control devices
 - eavesdropping on private data

  These security requirements are difficult to meet.  I recognize that
they may conflict with the desire to have cheap, low-power devices.
However, the potential for abuse, loss of property, and death due to
insecure devices is large, and cannot be ignored.

  Alan DeKok.