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/

_____________________________________________

Stephen Farrell schreef op 2015-07-15 00:36:
> Hiya,
> 
> On 14/07/15 23:17, Robert Cragie wrote:
>> 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>
> 
> 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.
> 
>> 
>>> 
>>> 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>
>> 
>> 
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll