Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-home-building-12: (with COMMENT)

Hi Stephen,

thanks for your reaction.
Below a recap of the past discussions, copied from earlier e_mail 
exchanges.
Actual text changes in the draft after the comment answers below are not 
reproduced here, but can be checked in version 12.

Peter

Stephen Farrell schreef op 2015-07-25 16:08:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-roll-applicability-home-building-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> Thanks for the discussion about security. I didn't check
> if the comments below were handled in -12, happy to
> chat about that if you want.
> 
> First two comments are about text that's new in -11:
> 
> - 4.1.8: "MUST be present" is ambiguous - do you mean
> it must be used? I think you do.
<pvds> done</pvds>
> 
> - 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" ?
<pvds>
The symmetric key distributions has a scope (4.1.8.1) and MUST follow a 
mechanism (4.1.8.2).
</pvds>
> 
> 
> OLD COMMENTS FOR -10 below, I didn't check if you'd made
> any related changes.
> 
> - I don't get how there's an IPR disclosure for this, but
> whatever.
<pvds>
This refers to 5.1.1 and in particular the rt-layer that is proposed to 
reduce delays and losses under overload.
</pvds>
> 
> - 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>
<pvds> and see text in 4.1.8 following DISCUSS </pvds>
> 
> - 7.2, 1st sentence: this is meaningless as I read it - what
> are you trying to say?
<pvds>
Has been rephrased with two cases: (1) addition of nodes during 
operation (2) node is compromised
</pvds>
> 
> - 7.2, when a node is stolen, the chances are that any keys
> contained in the node are at significant risk of being leaked.
<pvds> see above </pvds>
> 
> - 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.
<pvds> 7.3 severely reduced to 1 phrase </pvds>
> 
> - 7.4, last sentence: more sales talk
<pvds>removed </pvds>
> 
> - 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.)
> 
<pvds> adapted to summary section, explaining relation to RFC7416 
</pvds>
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll