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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 13 Jul 2015 14:54:25 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-roll-applicability-home-building-11: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the discussion so far and for the changes to
the document. I think (modulo comments) we're mostly
done with the blocking discuss stuff but I do two more
question at that level.

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

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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: Robert Cragie <[email-masked]>
Date: Tue, 14 Jul 2015 23:17:36 +0100

Hi Stephen,

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

Robert

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

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

> it must be used? I think you do.

<RCC>Yes</RCC>

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

> 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

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

> a recommendation for this document perhaps.

<RCC>No longer applicable as 4.1.8 has been completely rewritten.</RCC>

> confusing. (Same elsewhere.)

<RCC>Used "to" instead of "-"</RCC>

> it back into a piece of specification language.

<RCC>Paragraph has been rewritten</RCC>

> for RPL. (Same for 7.3) Or, and better, to fix that lack. (See

<RCC>Section has been rewritten</RCC>

> - 7.2, 1st sentence: this is meaningless as I read it - what

<RCC>Section has been rewritten</RCC>

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

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

> out what to implement to get interop? (I didn't think so, but

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jul 2015 23:36:36 +0100

Hiya,

> traffic and those nodes are not yet participating in the network.</RCC>

Right, that's what I thought. So I can't see how the text that
implies that only a subset of nodes on the network are using l2
security works which seems to be implied by the bullet just
before the start of 4.1.8.2.

All the stuff below is fine, so we're just down to the above in
terms of clearing the discuss.

Cheers,
S.

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 15 Jul 2015 10:23:39 +0100

On 14 Jul 2015 23:36, "Stephen Farrell" <[email-masked]> wrote:

Hi Stephen,

The text before 4.1.8.2 doesn't imply that some nodes are not using
security, it only implies that symmetric key scope used by nodes may be
less than the whole network. I will add clarification regarding this point.

Robert

> [snip]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jul 2015 10:51:55 +0100

Hiya,

On 15/07/15 10:23, Robert Cragie wrote:
> less than the whole network. 

Well, I'm still not getting it sorry;-) Unless you mean that
the n/w might accept/use >1 group symmetric key? If that's it
then just saying it that way would be good.

> I will add clarification regarding this point.

Grand - I'm sure clarification is all that's needed.

Cheers,
S.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 21 Jul 2015 12:09:40 +0200

Hi Stephen,

We have submitted a new version 12 of the applicability draft with text 
as discussed below.
Many thanks for your comments and thoughts.

Looking forward to your comments,

Greetings,

Robert and 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-12.txt
     Pages           : 37
     Date            : 2015-07-21

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:
https://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-12

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/

_____________________________________________