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

From: "Stephen Farrell" <[email-masked]>
Date: Sat, 25 Jul 2015 07:08:40 -0700

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.

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

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.

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

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

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

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

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

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

- 7.4, last sentence: more sales talk

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

---

From: peter van der Stok <[email-masked]>
Date: Tue, 28 Jul 2015 09:48:54 +0200

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:
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
<pvds> done</pvds>
> 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>
> - I don't get how there's an IPR disclosure for this, but
<pvds>
This refers to 5.1.1 and in particular the rt-layer that is proposed to 
reduce delays and losses under overload.
</pvds>
> not-X in order to Y. There is no choice but for RPL to do X or

<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>
> that should be made more clear. If you disagree, I'd like to

<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>
> a recommendation for this document perhaps.

<RCC>That is a separate issue from securing RPL messages, which is what 
this section is about</RCC>
> confusing. (Same elsewhere.)
<RCC>Agree suggestion is clearer</RCC>
> 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>

> it back into a piece of specification language.

<RCC>Agree with suggested change</RCC>
> for RPL. (Same for 7.3) Or, and better, to fix that lack. (See

<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
<pvds>
Has been rephrased with two cases: (1) addition of nodes during 
operation (2) node is compromised
</pvds>
> contained in the node are at significant risk of being leaked.
<pvds> see above </pvds>
> 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>
> out what to implement to get interop? (I didn't think so, but
<pvds> adapted to summary section, explaining relation to RFC7416 
</pvds>
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Jul 2015 09:18:56 +0100

Hi Stephen,

Please see inline for specific responses.

Regarding the old comments: We have tried to respond to these issues in
previous follow up e-mails and modify the document in accordance with the
responses. Repeating these old comments suggests that neither those
responses nor the updated text have been read yet. Please can you read the
responses and updated text before simply repeating these comments?
Otherwise I can't see how we can make any progress on this.

Robert

> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/

<RCC>This has been changed to "MUST be used on all nodes" in -12</RCC>

> Do you really just mean "see 4.1.8.1" ?

<RCC>As mentioned before, this is just introductory. I suggest removing the
sentence to close the comment.</RCC>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 28 Jul 2015 10:23:34 +0200

Hi Robert,

was this a response to my answer; or did our answers cross?
My intentions was to pass over the old comments quickly;

Peter

Robert Cragie schreef op 2015-07-28 10:18:
> Regarding the old comments: We have tried to respond to these issues
> in previous follow up e-mails and modify the document in accordance
> with the responses. Repeating these old comments suggests that neither
> those responses nor the updated text have been read yet. Please can
> you read the responses and updated text before simply repeating these
> comments? Otherwise I can't see how we can make any progress on this.
> 
> Robert
> 
> <RCC>As mentioned before, this is just introductory. I suggest
> removing the sentence to close the comment.</RCC>
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jul 2015 10:50:34 +0100

Hiya,

> Otherwise I can't see how we can make any progress on this.

Sorry, we're talking past one another. The old comments are present in
the tracker and get attached to the email unless I go through them and
delete them manually. And since they are not blocking I don't spend
much time tracking if they have/haven't been addressed. And mostly I
forget once sufficient time has elapsed;-) In other words, it's up to
you and your AD if you want to consider them or not, I don't mind.

So you can make progress on this in various ways. One is to just ignore
the comments. Another is to say "yeah, we know it's not blocking but
we'd actually like to chat about <this> comment." Your chairs/AD may
have more ideas.

But the main thing is that a "No Objection" ballot is just that, I
don't object to this moving ahead.

So I'd say if there are any of the comments where you think it is
interesting to continue to chat, please just mail me about that but
there is no need to address each one in blow-by-blow fashion. If
you and your AD think there's no need for more chat, then we're done
already.

Hope that helps,
S.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Jul 2015 10:58:30 +0100

Hi Stephen,

Understood - thanks for the clarification. As mentioned, we did go through
the comments and respond and make changes so will be happy to show these to
the chairs/AD if required.

Robert

---

From: Ines Robles <[email-masked]>
Date: Tue, 28 Jul 2015 15:00:03 +0300

Hi,

First two comments from ballotage [4] from v11:

Addressed: changed to " security MUST be used on all nodes"

In [1] states "Yes. It was meant more as an introductory statement but is
redundant really".

For this sentence more clarification was added in 12:

"A symmetric key is used to secure a RPL message using either RPL
message security or link-layer security.  The symmetric key MUST be
distributed or established in a secure fashion.  There may be more
than one symmetric key in use by any node at any one time.  The same
symmetric key MUST NOT be used for both RPL message security and
link-layer security between two peer nodes."

In [2] is suggested to remove the sentence, so it could be done by the RFC
Editor. Do you agree with that?

The other comments  (v10) from ballotage are addressed as states in [3]

[1] http://www.ietf.org/mail-archive/web/roll/current/msg09368.html
[2] http://www.ietf.org/mail-archive/web/roll/current/msg09388.html
[3] http://www.ietf.org/mail-archive/web/roll/current/msg09376.html
[4]
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ballot/

I believe that the document is ready to go forward.

Thank you very much for your hard work on this,

Ines

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jul 2015 13:04:25 +0100

(Just in case it helps...)

> I believe that the document is ready to go forward.

The comment resolutions you suggest seem fine to me.

Thanks,
S.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Jul 2015 14:50:24 +0100

Ines - sounds good to me.

Robert

On 28 July 2015 at 13:00, Ines Robles <[email-masked]>
wrote:

>> Understood - thanks for the clarification. As mentioned, we did go
>> through the comments and respond and make changes so will be happy to show
>> these to the chairs/AD if required.
>>
>> Robert
>>