[Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)

Catherine Meadows <catherine.meadows@nrl.navy.mil> Mon, 06 April 2015 21:38 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org
Delivered-To: roll@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6664E1ACC8B; Mon, 6 Apr 2015 14:38:00 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4925F1ACC82 for <xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com>; Mon, 6 Apr 2015 14:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mgKPaf7Gaw2 for <xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com>; Mon, 6 Apr 2015 14:37:57 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A129D1ACCD8 for <draft-ietf-roll-applicability-home-building.all@ietf.org>; Mon, 6 Apr 2015 14:37:56 -0700 (PDT)
Received: from mx0.ccs.nrl.navy.mil ([2001:480:20:118:118::211]:57723 helo=ccs.nrl.navy.mil) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from <catherine.meadows@nrl.navy.mil>) id 1YfEiP-0008WV-Og for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Mon, 06 Apr 2015 14:37:56 -0700
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t36LbgEw014314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Apr 2015 17:37:42 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_990CEB30-E296-4D3E-B5E9-CB3F898FC618"
Date: Mon, 6 Apr 2015 17:37:42 -0400
Message-Id: <F189CF1A-B989-4326-9B1C-0856164687D7@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
X-Helo-Check-Failed: Verification failed for HELO ccs.nrl.navy.mil
X-SA-Exim-Connect-IP: 2001:480:20:118:118::211
X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org
X-SA-Exim-Mail-From: catherine.meadows@nrl.navy.mil
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-roll-applicability-home-building.all@ietf.org
Resent-Message-Id: <20150406213756.A129D1ACCD8@ietfa.amsl.com>
Resent-Date: Mon, 6 Apr 2015 14:37:56 -0700 (PDT)
Resent-From: catherine.meadows@nrl.navy.mil
Archived-At: <http://mailarchive.ietf.org/arch/msg/draft-ietf-roll-applicability-home-building.all@tools/Ng9pjIRmUw3-2O2oFrP5ZqTKBGc>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/dZihNYYBmyuRRYhT8iIDoDmi4bk>
X-Mailman-Approved-At: Mon, 06 Apr 2015 14:55:19 -0700
Cc: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Subject: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Apr 2015 21:38:00 -0000

I had the draft authors’ email address wrong on my last message, so I am resending it.

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 gives recommendations for the use of RPL in home automation and building control,
that typically provide support such things as climate and lighting control.  I reviewed a much earlier
version of this document, and I think this version is much improved in the way it scopes out the problem
and handles the security implications.  The Security Considerations section in particular is very
thorough.  There are a few improvements I would recommend, however:

Section 4.1.8   Security

You should  give justifications for these choices of parameters as you give justifications for the
other parameters described in this draft.

Section 7.1 Security considerations during initial deployment

New approaches to initial security deployment are being developed in
   [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top].  They assume a partial
   ordering of the nodes, such that unsecured nodes are added
   sequentially with the restriction that a path between two secured
   nodes exists which passes through secured nodes only.

I found this a little hard to understand.  When does a node pass from being unsecured to secured?  Or does an unsecured node remain unsecured? If there is
a succinct way of saying this, it could go here.  Since this is only describing new approaches that could potentially be applied, you would not
want to go into a lot of detail. 

In the home, nodes can be visually inspected by the home owner
   and simple measures like pushing buttons simultaneously on joint and
   joining devices is probably sufficient.

I think this definitely needs to be clarified!  You need to say what is being accomplished by pushing the buttons (device pairing)?

7.2

When nodes are lost, no additional security measures are needed, the
   network remains secure as before by not allowing the addition of new
   nodes.

I’m not sure what this means.  Does it mean that if a node is lost, then it is treated as a “new node” if it reappears, and is not allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
   initial deployment.

This came right after the sentence beginning “When nodes are lost” which said that new nodes are not added.  That contradiction needs to
be reconciled.  I’m also not sure what “using the same protocol” means.  Does it mean rerunning the protocol and rekeying all the nodes, or does
it mean using the features that protocol has for adding nodes?


Nits:

Section 1.1 

This applicability statement
   recommends more light weight security solutions and specify the
   conditions under which these solutions are appropriate.

Should be “specifies” instead of “specify”.  I’m also not sure what is meant by “conditions under which these solutions are appropriate.”  Do
you mean light-weight as opposed to no security, or light-weight as opposed to heavy-weight.  Or are you talking about conditions
under which different light-weight solutions are appropriate? From reading the rest of the draft, I would assume the last is what you mean.


I consider this document  ready with issues.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil