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

From: peter van der Stok <[email-masked]>
Date: Wed, 13 May 2015 09:28:28 +0200

Hi Stephen,

About 2 weeks ago we submitted a new applicability home building draft 
010.

This new draft includes the return to the RFC2119 text.
It includes all comments answered during the security evaluation.
It includes suggestions by Michael to answer the DISCUSS raised by 
Stephen Farrell.
It maintains some of the text on the aspects of security in buildings 
that need additional work.

However I am not sure that it addresses your original concern:
" why is this not the ROLL WG draft where we finally get to specify AKM 
for RPL?"

Looking forward to your reaction,

Peter
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Routing Over Low power and Lossy
> networks Working Group of the IETF.
> 
>         Title           : Applicability Statement: The use of the RPL
> protocol suite in Home Automation and Building Control
>         Authors         : Anders Brandt
>                           Emmanuel Baccelli
>                           Robert Cragie
>                           Peter van der Stok
> Filename        : draft-ietf-roll-applicability-home-building-10.txt
> Pages           : 32
> Date            : 2015-04-26
> 2
> Abstract:
>    The purpose of this document is to provide guidance in the selection
>    and use of protocols from the RPL protocol suite to implement the
>    features required for control in building and home environments.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-10
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 May 2015 11:39:52 +0100

Hi all, and apologies for the slow response...

On 27/04/15 08:05, peter van der Stok wrote:
> Dear all,

I'm sorry to say I don't think we're there yet. I just read the
current draft and I think we still have significant issues for
this DISCUSS.

- If the way in which we are achieving interoperable security is
via layer2-only then I would argue that that has to be more clearly
stated up front (for truth-in-advertising reasons) as otherwise
people may implement/deploy assuming the opposite.

- I really seriously question the proposition that layer2-only
security is sufficient for more complex building requirements.
If that is true, then this document needs to say when it is safe
and when it is unsafe to use RPL in such networks. (I can accept
that layer2-only is ok for simple buildings and homes, at least
for the next few years.)

- The "MUST be present" at the start of 4.1.8 is not quite right.
If the plan here is layer2-only then you need to say something
more like that all RPL packets MUST be sent using the layer2
mechanisms and MUST be verified as having been received using
the layer2 mechanisms. That (I guess) could require some code
if a node can ever emit/receive an insecure message.

- 7.1 remains a collection of references that will not IMO give
us interop when multiple vendors are involved. Can you explain
to me why I'm wrong? (And I don't mean the multicast bit, but
the stuff about unicast.)

Again, apologies for being a barrier to progress here, but I
guess we're paying the price now for us collectively not having
addressed this issue back at the start of the ROLL WG's work. I
do think though that we need to ensure that we don't send out a
set of specifications that might put quite a number of networks
at risk because of our omissions, even if that means we need to
address some technically and politically tricky issues.

Cheers,
S.

PS: Sorry to say I'll be travelling for the next few days so
responses will continue to be slow. Maybe we should try setup a
concall on this in a week or so? If that helps, I'm very happy
to do that.

> Greetings,

---

From: peter van der Stok <[email-masked]>
Date: Tue, 19 May 2015 12:27:13 +0200

Hi Stephen,

thanks for continuing the discussion.
I respond between the lines below.
It is possible that my co-authors want to improve on my comments.

> that layer2-only is ok for simple buildings and homes, at least

<pvds>
The interpretation that layer-2 security is sufficient for building 
control is not meant.
Point to point security is certainly recommended and is a MUST when 
client and server are separated by a border router
(They reside on different network segments)

I suggest the following phrase at the end of 4.1.8:
The use of security measures at layer 3 or higher is RECOMMENDED. When 
two communicating nodes are separated by a border router, the nodes MUST 
use use security measures at layer 3 or higher.
For example, a client and server that use CoAP MUST use DTLS as 
specified in RFC7252.

Actually, I am not sure if this text addresses your point.
</pvds>

> if a node can ever emit/receive an insecure message.
<pvds>
I will rephrase as you suggest and refer to IEEE 802.15.4 security 
specification.
Your suggestion is clearer, but should not imply layer-2 security only 
as clarified above.
</pvds>

> the stuff about unicast.)
<pvds>
I think from interop point of view, the use of a layer-2 security 
initialization protocol is different from using DTLS or CoAP protocols.
The initialization happens on a given installation that is subject to 
installation specific constraints.
Manufacturers organize themselves in alliances which select the IETF 
protocols which best fit the boundary conditions of their installations.
In analogy section 7.1 refers to ZigBee/IP which recommends PANA with 
EAP/TLS and japanese ECHONET which recommends PANA with EAP/PSK.
Further, L2 key management is not defined in the basic
spec of L2 and other standards have created different key management
methodologies, including IEEE which is creating a framework(IEEE
802.15.9).
We see that other key management protocols are specified in the IETF 
currently, with progressing insight in the installation needs.

Therefore, I think that specifying a layer-2 initial deployment beyond 
what is done in 7.1 does not bring much more interop, given the ongoing 
progress in different organizations including IETF,
and given its limited scope to a given installation.
</pvds>
> address some technically and politically tricky issues.
<pvds>
I hope the issues become tractable with the ongoing discussion.
</pvds>
> concall on this in a week or so? If that helps, I'm very happy

<pvds>
If my responses above add to the confusion, I think that a telconf will 
help.
However, I should very much like that Robert Cragie and/or Michael 
Richardson assist as well.
Their experience will clearly contribute to arrive at a satisfying 
conclusion.
</pvds>

Greetings,

Peter
>>     Filename        : 
>> draft-ietf-roll-applicability-home-building-10.txt
>>     Pages           : 32
>>     Date            : 2015-04-26
>> 2
>> Abstract:

---

From: Robert Cragie <[email-masked]>
Date: Wed, 20 May 2015 17:01:21 +0100

Sorry for the very late reply on this. Firstly, here are my responses to
Stephen's original comments. I will look at the later e-mails and respond
accordingly.

Robert

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

<RCC>
The aim is to say:

"In order to support low-cost devices and devices running on a battery, RPL
MAY use either unsecured messages or secured messages"

The omitted subtext is probably "..., not just secured messages" as that is
what is being emphasised here, i.e. a greater choice and thus implied
security policy choice.

Would the following make more sense?:

"In order to support low-cost devices and devices running on a battery,
there are two security policies applicable to RPL; one where RPL uses
unsecured messages and another where RPL uses secured messages"
<RCC>

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

<RCC>If the security policy option where RPL uses unsecured messages
applies, then link layer security will always be needed. It is a policy
choice applicable to the deployed network</RCC>

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

<RCC>That is a separate issue from securing RPL messages, which is what
this section is about</RCC>

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

<RCC>Agree suggestion is clearer</RCC>

- section 7, 3rd para, "can rely on" is sales language, please
strike that or s/rely on/depend upon/

<RCC>
Rephrase as:

"The following mechanisms MAY be used: (i) pre-installation using an
out-of-band method, (ii) secure delivery when a device is introduced into
the network or (iii) secure delivery by a trusted neighbouring device."
</RCC>

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

<RCC>Agree with suggested change</RCC>

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

<RCC>There are many ways to achieve key distribution and in some respects
it would be nice to see one single way to do it. However, this is unlikely
to ever happen. The main reason is that a deployment standard is a complex
animal of which RPL is typically one small part. The key management is also
just a part and in itself typically is a conglomeration of various RFCs and
applicability statements, irrespective of what routing protocol is chosen
for said deployment. ZigBee IP is a good example of a full interoperable
deployment and there is an extensive list of 43 RFCs and IDs directly
referenced, not to mention the further indirect references from those. We
chose which protocols to use for key management and set security policy
</RCC>

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

<RCC>To be honest, I never quite understood the need for this section.
Peter wanted this in</RCC>

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

<RCC>I would remove the last sentence. It doesn't add anything</RCC>

- 7.4, last sentence: more sales talk

<RCC>I would remove the last sentence. It doesn't add anything</RCC>

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

<RCC>It seems to be just a summary section</RCC>

On 20 May 2015 at 04:49, Stephen Farrell <[email-masked]> wrote:

>
> Thanks Peter,
>
> On 19/05/15 11:27, peter van der Stok wrote:
>
>>
> Well I do confess to continuing confusion (not caused by you
> though) about how we get secure interop,in general here so
> maybe we ought think about it.
>
> Good idea to do that first, yes.
>
> Cheers,
> S
>
>

-- 

Robert Cragie

Gridmerge Ltd.
8 Racecourse View,
Cottenham,
Cambridge, CB24 8AL, UK
+44 7919 620526
http://www.gridmerge.com

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 May 2015 04:49:14 +0100

Thanks Peter,

On 19/05/15 11:27, peter van der Stok wrote:
>
> If my responses above add to the confusion, I think that a telconf 
> will help.

Cheers,
S