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

[Robert Cragie <[e-mail]>]

Hi Stephen,

Thanks for your further review. Answers and comments inline, bracketed by
<RCC></RCC>

Robert

1) This could be my ignorance of zigbee, but how can we
> use layer 2 security for only some network nodes?  (In
> other words, I don't see how 4.1.8.2 works.)
>

<RCC>All network nodes use L2 security once they have joined the network.
Prior to that, they communicate using an authentication protocol which is
unsecured at L2. Enforcement points police unsecured traffic to ensure it
is only related to authentication, thus preventing data or other control
plane traffic unsecured at L2 from being allowed into the network. So, to
your point, the only traffic allowed unsecured at L2 is authentication
traffic and those nodes are not yet participating in the network.</RCC>

>
> 2) Just checking - this depends on the zigbeeip
> authentication mechanism, with which I'm also not
> familiar, sorry. Does using that mean that this entire
> applicability statement only covers use of RPL where
> zigbee radios are in use? Or can that authentication
> scheme be used independently of the radio technology
> used? (I mean used in practice there, not in theory.)
>

<RCC>The authentication scheme is independent of the radio technology as it
is based on UDP/IP and therefore could be use with a number of different
radio technologies or indeed other MAC/PHY technologies</RCC>

- 4.1.8: "MUST be present" is ambiguous - do you mean
> it must be used? I think you do.
>

<RCC>Yes</RCC>

- 4.1.8: "MUST be distributed or established in a
> secure fashion" isn't really a protocol requirement.
> Do you really just mean "see 4.1.8.1" ?
>

<RCC>Yes. It was meant more as an introductory statement but is redundant
really</RCC>

OLD COMMENTS FOR -10 below, I didn't check if you'd made
> any related changes.
>

<RCC>These seem to apply more to -09. Some of these were fixed in -10, some
in -11 </RCC>


> - I don't get how there's an IPR disclosure for this, but
> whatever.
>

<RCC>Not from me, so I can't comment on that</RCC>

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

<RCC>No longer applicable as 4.1.8 has been completely rewritten.</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>Used "to" instead of "-"</RCC>

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

<RCC>Paragraph has been rewritten</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>Section has been rewritten</RCC>

>
> - 7.2, 1st sentence: this is meaningless as I read it - what
> are you trying to say?
>

<RCC>Section has been rewritten</RCC>

>
> - 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>The text has been changed but probably doesn't meet your requirements
regarding this point. I would say nodes have to be re-keyed at L2 and MAY
need to have additional measures taken depending on the other credentials
they have and how the confidential information is stored. e.g. certificate
revocation..</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>Has been removed</RCC>

>
> - 7.4, last sentence: more sales talk
>

<RCC>I'm not sure we even need a section on MPL; MPL has nothing to do with
RPL. Assuming we do, this is still outstanding, so I suggest replacing "The
application of security measures for the specification of the multicast
addresses assures that the routing of MPL packets is secured." with
something like "For secure dissemination of MPL packets, layer 2 security
SHOULD be used and the configuration of multicast addresses MUST be secure."

>
> - 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>This is still outstanding. I think it is OK to briefly highlight the
steps being taken to mitigate against the threats outlined in RFC 7416. The
statement "Key management discussed in section 7.4, "Key Management" of
[RFC7416], is not standardized and discussions continue." is now not
relevant as there is now a proposal in this document. I will work with
Peter to produce some new text on this.</RCC>