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> Thu, 09 April 2015 08:42 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 EFCC61A8BB2; Thu, 9 Apr 2015 01:42:26 -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, 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 37S1bbquokGt; Thu, 9 Apr 2015 01:42:24 -0700 (PDT)
Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAF21AD359; Thu, 9 Apr 2015 01:42:22 -0700 (PDT)
Received: from roundcube.xs4all.nl ([194.109.20.204]) by smtp-cloud6.xs4all.net with ESMTP id DkiL1q0084QBLo201kiLx9; Thu, 09 Apr 2015 10:42:20 +0200
Received: from [2001:983:a264:1:f017:e82:631f:b88d] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 09 Apr 2015 10:42:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 09 Apr 2015 10:42: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: <c51807e7a0b4c3425c070f1f9cc35ac0@xs4all.nl>
X-Sender: stokcons@xs4all.nl (ZeSPPCO+q2E93otpI7pT97kYNQTuJ0o/)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/ha5PMeb5Mya6RBKIo-TbWVoBlo0>
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: Thu, 09 Apr 2015 08:42:27 -0000

Hi Stephen,

thanks for the comments.
There is one comment that I should like to react to before the others:

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

I have the same fear. BUT multicast will be used and having a secure 
protocol is an urgent wish.
I understand the reasons why the current draft will not make it. 
However, I know that other people are working on better sequels.
I think this multicast security is important.
Do you think I should add text to emphasize my opinion and encourage 
sequels to [I-D.keoh-dice-multicast-security] ?

Peter


Stephen Farrell schreef op 2015-04-09 01:34:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-roll-applicability-home-building-09: 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 
> http://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:
> http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> Please correct me if I'm getting this wrong, I honestly may
> have forgotten the plan. My understanding was that RPL and RFC
> 7416 etc. were approved on the basis that you needed to get to
> specific applications of RPL before you could sensibly specify
> interoperable security with automated key management (AKM) as
> is clearly required by BCP107 and as has been discussed
> between security ADs and the ROLL WG numerous times. This is
> going back to the 2010 discuss from Tim Polk that I inherited
> in 2011, hence me being uncertain if I remember the plan for
> sure;-) In any case it seems to me that this draft also
> doesn't get us to the point where we have a defined way to do
> AKM (Again, sigh.) I also have a set of comments on that below
> that I won't make into specific discuss points (at least until
> we figure out or re-discover the plan).
> 
> So, with that context, and with real regrets for sounding like
> an old and broken record, the discuss point: why is this not
> the ROLL WG draft where we finally get to specify AKM for RPL?
> If your answer is that this is just an applicablilty statement
> then I'll ask why it's going for proposed standard, and when
> to finally expect the AKM spec for RPL (for this application).
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> - 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.)
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll