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

Michael Richardson <> Tue, 14 April 2015 20:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60BFC1B2A4D; Tue, 14 Apr 2015 13:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 34uNzg26H3qE; Tue, 14 Apr 2015 13:31:07 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9D451AD35D; Tue, 14 Apr 2015 13:31:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E80A3E00B; Tue, 14 Apr 2015 16:42:10 -0400 (EDT)
Received: by (Postfix, from userid 179) id 95F4E63B76; Tue, 14 Apr 2015 16:31:05 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 81864636A2; Tue, 14 Apr 2015 16:31:05 -0400 (EDT)
From: Michael Richardson <>
To: Routing Over Low power and Lossy networks <>, The IESG <>,,,,,
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 14 Apr 2015 16:31:05 -0400
Message-ID: <>
Archived-At: <>
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: Tue, 14 Apr 2015 20:31:09 -0000

Stephen Farrell asked:
> 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).

BCP107 certainly does ask for automatic key management when keys are going to
be used.  The part of the plan that is perhaps not so clear is that we have
yet to have anyone say that they intend to use layer-3 keying in for RPL.

The intention of having the security being precisely specified in the
applicability statements was so that we would know if layer-2 security was
being used, or if there was a layer-3 security being used.
If there is layer-3 security, then BCP107 would demand that we have an AKM for it.

In reading section 7 again just now, I see how things went wrong... Some text
seems to have snuck into section 7(.0) that tries to sit on the fence, so I
propose to remove paragraphs 3 and 4 of that section and say instead:
    "This document mandates that a layer-2 mechanism be used during initial
     and incremental deployment. Please see the following sections."

Section 7.1, is quite clear that PANA is being specified to carry EAP
messages for a 1x bootstrap into layer-2 security.    That this is the
default position of this document.  I have tried to persuade the authors to
be clearer and less speculative. While I'm thrilled that they like the
methods 6tisch is considering, I'd prefer to remove the paragraph "New

I would like prefer that this document was even more precisely about what
kind of 15.4 security is being used, either directly profiling the relevant
parts of the 802.15.4 specification, or by indirect reference to something
that does.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-