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

[Robert Cragie <[e-mail]>]

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 <[e-mail]> wrote:

>
> 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.
>>
> 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.
>
>> 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.
>>
> Good idea to do that first, yes.
>
> Cheers,
> S
>
>


-- 

Robert Cragie

Gridmerge Ltd.
8 Racecourse View,
Cottenham,
Cambridge, CB24 8AL, UK
[phone]
http://www.gridmerge.com