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

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.

Stephen Farrell schreef op 2015-05-17 12:39:
> Hi all, and apologies for the slow response...
> 
> On 27/04/15 08:05, peter van der Stok wrote:
>> Dear all,
>> 
>> 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.
> 
> 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.)

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

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

> 
> - 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.)
<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>
> 
> 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.
<pvds>
I hope the issues become tractable with the ongoing discussion.
</pvds>
> 
> 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.

<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
> 
>> It maintains some of the text on the aspects of security in buildings
>> that need additional work.
>> 
>> Greetings,
>> 
>> 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
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll