[Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Mon, 13 July 2015 21:54 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C841A1EED; Mon, 13 Jul 2015 14:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 5b3N4Z5sDegM; Mon, 13 Jul 2015 14:54:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F81A1BDB; Mon, 13 Jul 2015 14:54:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150713215425.24718.94967.idtracker@ietfa.amsl.com>
Date: Mon, 13 Jul 2015 14:54:25 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/xD17-9ojKTekk4kFFgc1c33xJfM>
Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org
Subject: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Jul 2015 21:54:32 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-roll-applicability-home-building-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Thanks for the discussion so far and for the changes to
the document. I think (modulo comments) we're mostly
done with the blocking discuss stuff but I do two more
question at that level.

1) This could be my ignorance of zigbee, but how can we
use layer 2 security for only some network nodes?  (In
other words, I don't see how 4.1.8.2 works.)

2) Just checking - this depends on the zigbeeip
authentication mechanism, with which I'm also not
familiar, sorry. Does using that mean that this entire
applicability statement only covers use of RPL where
zigbee radios are in use? Or can that authentication
scheme be used independently of the radio technology
used? (I mean used in practice there, not in theory.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


First two comments are about text that's new in -11:

- 4.1.8: "MUST be present" is ambiguous - do you mean
it must be used? I think you do.

- 4.1.8: "MUST be distributed or established in a
secure fashion" isn't really a protocol requirement.
Do you really just mean "see 4.1.8.1" ?


OLD COMMENTS FOR -10 below, I didn't check if you'd made
any related changes.

- I don't get how there's an IPR disclosure for this, but
whatever.

- The non-security parts of this were quite a good read.

- 4.1.8: 1st sentence makes no sense. It says RPL does X or
not-X in order to Y. There is no choice but for RPL to do X or
not-X.

- 4.1.8 seems to me to imply that link layer security is
always needed since there can always be some node that will
send an unsecured RPL messsage. If you agree, then I think
that should be made more clear. If you disagree, I'd like to
understand how.

- 4.1.8, I am surprised not to see a recommendation that
separate group keys SHOULD be used for different applications
in the same bulding network. But that may be too fine grained
a recommendation for this document perhaps.

- 5.1.2.1, I think it'd be clearer to say Imin should be
between 10 and 50 ms. The "10 - 50 ms" notation can be
confusing. (Same elsewhere.)

- section 7, 3rd para, "can rely on" is sales language, please
strike that or s/rely on/depend upon/ 

- section 7, 3rd para, last sentence: this is sales language
and should be deleted. Or perhaps s/is/SHOULD be/ would turn
it back into a piece of specification language.

- 7.1 - this is odd text to see in a proposed standard, but I
think it's accurately describing the level of interop to
expect in RPL security, so is probably the right thing to say.
I'd argue that it'd be even better to bluntly admit/say that
there is currently no interoperable automated key management
for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
my discuss point.)

- 7.2, 1st sentence: this is meaningless as I read it - what
are you trying to say?

- 7.2, when a node is stolen, the chances are that any keys
contained in the node are at significant risk of being leaked.

- 7.3, I do not believe that [I-D.keoh-dice-multicast-security] 
is necessarily going to proceed via the DICE WG. Depending 
on it would be fairly high-risk in any case.

- 7.4, last sentence: more sales talk

- 7.5, what is this specifying? I don't get it. Does 7416 set
out what to implement to get interop? (I didn't think so, but
nor does this seem to.)