This is  a resend of my review.  I had incorrectly entered the alias for the authors and it got bounced.

My apologies to everyone who receives this twice.

I have reviewed this document as part of the security directorate's 

ongoing effort to review all IETF documents being processed by the 

IESG.  These comments were written primarily for the benefit of the 

security area directors.  Document editors and WG chairs should treat 

these comments just like any other last call comments.

This ID gives recommendations on the use of the RPL protocol in building and home environments, which are characterized as relatively small networks

that integrate a number of different devices, many including computers, alarm systems, light switches, remote controls ,etc.  Many of the network

components are resource and power-constrained.   The ID  characterizes the different types

of networks that can arise in these environments, and gives recommendations such  as which versions of the protocol to use and how

to set the parameters, depending on the type of home network.

For the security considerations the authors mainly refer the reader to RFC6997,  RFC6550, and I-D.ietf-roll-trickle-mcast.  However, there is one issue that these

documents do not cover.  RPL makes the assumption that all the members of the network share a key, but intentionally does not give any information as to how

the key gets there.  Thus this document includes a section on Security Considerations for distribution of certificates required by RPL.  It explains that for RPL the

credential is a shared key, and then goes on to say:

Therefore, there MUST be a mechanism in place which

allows secure distribution of a shared key and configuration of

network identity. Both MAY be done using (i) pre-installation using

an out-of-band method, (ii) delivered securely when a device is

introduced into the network or (iii) delivered securely by a trusted

neighboring device. The shared key MUST be stored in a secure

fashion which makes it difficult to be read by an unauthorized party.

An example of a method whereby this can be achieved is detailed in

[SmartObj]

I found the wording of this confusing.  I took the “this” in the last sentence to refer to the storage of a key in

a secure fashion, and wondered why it there were no references to means of achieving secure key distribution.  It wasn’t until I looked at the SmartOb reference that I found that it

actually was such a reference.  This should be made more clear,

e.g. "An example of a method whereby this secure key distribution can be achieved in detailed in [SmatObj]."

I notice also that the SmartObj  paper does not seem to be finished (there are several sections labeled TODO), and that it also

appears to be intended as an Internet Draft.  What is the status of it?  Is it intended to be developed in tandem with this I-D?

Also, it would be good to be more specific about what is meant by “securely” here.  For example, the key must be authenticated and kept secret between its intended users, and must not

be repeated (replay protection). 

It might also be helpful to include of a discussion as to when it is more advantageous to use link encryption or group keys.

In the case that a network consists of both highly security-relevant and well-protected devices (such as alarm systems), and

non-security relevant and not so well-protected devices (such as TV remotes), group keying means that either the remote must

be as well-protected as the alarm system, or the entire network must be rekeyed if the remote is lost.  I don’t whether or not

it would be necessary to give any MUST or SHOULD recommendations, but it would be helpful to give the reader an understanding

of the issues involved when making decisions about link encryption versus group keys.  As far as I can see this subject is not addressed

in any of the documents cited at the beginning of the security considerations.

Cathy Meadows

Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email: 

catherine.meadows at nrl.navy.mil