[Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Wed, 08 April 2015 23:34 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 F154E1ACD75; Wed, 8 Apr 2015 16:34:09 -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 5raHxR9BMDrk; Wed, 8 Apr 2015 16:34:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1761ACD41; Wed, 8 Apr 2015 16:34:08 -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: 5.13.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408233408.4123.3118.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 16:34:08 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/rihTE46Cc0hbP7_ZCg9XJJRb-FI>
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-09: (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: <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: Wed, 08 Apr 2015 23:34:10 -0000
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] 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