Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)
peter van der Stok <stokcons@xs4all.nl> Mon, 13 April 2015 07:23 UTC
Return-Path: <stokcons@xs4all.nl>
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 C065B1A0113; Mon, 13 Apr 2015 00:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdgWF2o9ygxE; Mon, 13 Apr 2015 00:23:27 -0700 (PDT)
Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EBD1A00ED; Mon, 13 Apr 2015 00:23:26 -0700 (PDT)
Received: from roundcube.xs4all.nl ([194.109.20.206]) by smtp-cloud2.xs4all.net with ESMTP id FKPL1q0024SmhUa01KPLKd; Mon, 13 Apr 2015 09:23:20 +0200
Received: from [2001:983:a264:1:5815:b753:2294:f167] by roundcube.xs4all.nl 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 <stokcons@xs4all.nl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <20150408233408.4123.3118.idtracker@ietfa.amsl.com>
References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com>
Message-ID: <fb86c816367f2cef72685d1cbaf23e2a@xs4all.nl>
X-Sender: stokcons@xs4all.nl (X5MjZCvHNbqg+Gx94kgkESVc5gphfPrz)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/7Yj_8BBk4LC5P_mNYRDPJXMcsJY>
Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org
Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, 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, 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. Greetings, Peter > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 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. <peter> RPL MAY use unsecured messages to reduce message size. </peter> > > - 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. <peter> If there is a single node that uses unsecured RPL messages, link-layer security MUST be present. </peter> > > - 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. <peter> 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. </peter> > > - 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.) <peter> done </peter> > > - section 7, 3rd para, "can rely on" is sales language, please > strike that or s/rely on/depend upon/ <peter> back to an earlier version: Both MAY be done using: </peter> > > - 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 </peter> > > - 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? <peter> fixed in earlier GEN Art e_mail exchange </peter> > > - 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. <peter> 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. </peter> > > - 7.4, last sentence: more sales talk <peter> Remove it? It leaves the earlier phrase in the air </peter> > > - 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.) <peter> Specifies relation with 7416. </peter> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
- [Roll] Stephen Farrell's Discuss on draft-ietf-ro… Stephen Farrell
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Michael Richardson
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Michael Richardson
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Michael Richardson
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Robert Cragie
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… peter van der Stok