[secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07

Derek Atkins <derek@ihtfp.com> Sat, 19 September 2009 23:27 UTC

Return-Path: <derek@ihtfp.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 3844E3A68C8; Sat, 19 Sep 2009 16:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.875
X-Spam-Level:
X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 hUZQAb5GG0U3; Sat, 19 Sep 2009 16:27:18 -0700 (PDT)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 1A8423A67EE; Sat, 19 Sep 2009 16:27:18 -0700 (PDT)
Received: from pgpdev.ihtfp.org (unknown [69.7.239.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 8375D8B4005; Sat, 19 Sep 2009 19:28:15 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n8JNSCF7030014; Sat, 19 Sep 2009 19:28:12 -0400
To: iesg@ietf.org, secdir@ietf.org
From: Derek Atkins <derek@ihtfp.com>
Date: Sat, 19 Sep 2009 19:28:12 -0400
Message-ID: <sjmtyyyldkj.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: pieter.demil@intec.ugent.be, nicolas.riou@fr.schneider-electric.com, jerald.p.martocci@jci.com, wouter@vooruit.be, roll-chairs@tools.ietf.org
Subject: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
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: Sat, 19 Sep 2009 23:27:19 -0000

Hi,

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.

   The Routing Over Low power and Lossy network (ROLL) Working Group has
   been chartered to work on routing solutions for Low Power and Lossy
   networks (LLN) in various markets: Industrial, Commercial (Building),
   Home and Urban networks. Pursuant to this effort, this document
   defines the IPv6 routing requirements for building automation.

First, this document has no section named "Security Considerations".
There is a "Security Requirements" sub-section (5.8) which looks like
it might be the "Security Considerations" section misnamed and poorly
placed in the document structure.

Second, the new "Security Requirements" sub-section matches the
contents of the "Security Considerations" section of version 05 of
this document, almost word-for-word.  Therefore my review from version
05 still applies.  Here is what I said:

> The Security Considerations appear to take into account various
> requirements for different systems.  What seems to be lacking is
> direction about how or when to apply various requirements and what
> it means to the deployment.
> 
> For example, what would it mean to a deployment if it has
> authentication versus not having authentication?  Also, it's unclear
> how these requirements would apply to an implementor.
> 
> Variable security policies is a good idea, but it requires more
> guidance because the end user will never understand the ramifications
> of choosing one policy over another.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant