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@nrl.navy.mil