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

peter van der Stok <> Mon, 13 April 2015 07:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C065B1A0113; Mon, 13 Apr 2015 00:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FdgWF2o9ygxE; Mon, 13 Apr 2015 00:23:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59EBD1A00ED; Mon, 13 Apr 2015 00:23:26 -0700 (PDT)
Received: from ([]) by with ESMTP id FKPL1q0024SmhUa01KPLKd; Mon, 13 Apr 2015 09:23:20 +0200
Received: from [2001:983:a264:1:5815:b753:2294:f167] by with HTTP (HTTP/1.1 POST); Mon, 13 Apr 2015 09:23:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 13 Apr 2015 09:23:20 +0200
From: peter van der Stok <>
To: Routing Over Low power and Lossy networks <>
Organization: vanderstok consultancy
In-Reply-To: <>
References: <>
Message-ID: <>
X-Sender: (X5MjZCvHNbqg+Gx94kgkESVc5gphfPrz)
User-Agent: XS4ALL Webmail
Archived-At: <>
Cc:,, The IESG <>,,,
Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To:, Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Apr 2015 07:23:29 -0000

Hi Stephen,

I leave the AKM discussion out in the reactions below. Michael intends 
to start it.
My reactions below within <peter> </peter>
I am sure Robert will improve on my suggestions.



> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> - 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.

<peter> thanks </peter>
> - 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.
RPL MAY use unsecured messages to reduce message size.

> - 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.
If there is a single node that uses unsecured RPL messages, link-layer 
security MUST be present.
> - 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.
What is an application?
Different keys per group? But what about two overlapping groups of 5 
nodes within a single home?
I prefer to avoid these discussions.

> -, 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.)

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

back to an earlier version:
Both MAY be done using:
> - 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.
<peter> returned to original specification language, as suggested 
> - 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?
fixed in earlier GEN Art e_mail exchange
> - 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.
Concerning multicast security, the first light-weight attempt <xref 
target="I-D.keoh-dice-multicast-security"/> will probably be succeeded 
by more generally employable solutions.
> - 7.4, last sentence: more sales talk
Remove it? It leaves the earlier phrase in the air
> - 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.)
Specifies relation with 7416.
> _______________________________________________
> Roll mailing list