Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 09 April 2015 09:59 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 B15B81B2D7F; Thu, 9 Apr 2015 02:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 ME5SgddViYmE; Thu, 9 Apr 2015 02:59:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7821B2D6B; Thu, 9 Apr 2015 02:59:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 175C7BEED; Thu, 9 Apr 2015 10:59:19 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zE4RUVDtgNX; Thu, 9 Apr 2015 10:59:17 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ED075BEF6; Thu, 9 Apr 2015 10:59:12 +0100 (IST)
Message-ID: <55264D70.60106@cs.tcd.ie>
Date: Thu, 09 Apr 2015 10:59:12 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
References: <20150408233408.4123.3118.idtracker@ietfa.amsl.com> <c51807e7a0b4c3425c070f1f9cc35ac0@xs4all.nl>
In-Reply-To: <c51807e7a0b4c3425c070f1f9cc35ac0@xs4all.nl>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/sfZDtqbFScC9ULCeN4JXfCBKKag>
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: 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 09:59:22 -0000
Hiya, On 09/04/15 09:42, peter van der Stok wrote: > 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. That's clear. What's not clear is whether or not there is a way to meet that wish at the TLS layer. Seems that there may not be is my guess at the DICE WG current thinking. > 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] ? That could be fine, but if you do, please consider that the solution may need to use security primitives above the transport layer, e.g. perhaps in CoAP payload. Cheers, S. > > 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 >
- [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