Telechat Review of draft-ietf-roll-applicability-home-building-09
review-ietf-roll-applicability-home-building-09-secdir-telechat-meadows-2015-04-09-00

I had the draft authors’ email address wrong on my last message, so I am
resending it.

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 document gives recommendations for the use of RPL in home automation and
building control,

that typically provide support such things as climate and lighting control.  I
reviewed a much earlier

version of this document, and I think this version is much improved in the way
it scopes out the problem

and handles the security implications.  The Security Considerations section in
particular is very

thorough.  There are a few improvements I would recommend, however:

Section 4.1.8   Security

You should  give justifications for these choices of parameters as you give
justifications for the

other parameters described in this draft.

Section 7.1 Security considerations during initial deployment

New approaches to initial security deployment are being developed in

   [I-D.kumar-dice-dtls-relay] and

   [I-D.richardson-6tisch--security-6top].  They assume a partial

   ordering of the nodes, such that unsecured nodes are added

   sequentially with the restriction that a path between two secured

   nodes exists which passes through secured nodes only.

I found this a little hard to understand.  When does a node pass from being
unsecured to secured?  Or does an unsecured node remain unsecured? If there is

a succinct way of saying this, it could go here.  Since this is only describing
new approaches that could potentially be applied, you would not

want to go into a lot of detail.

In the home, nodes can be visually inspected by the home owner

   and simple measures like pushing buttons simultaneously on joint and

   joining devices is probably sufficient.

I think this definitely needs to be clarified!  You need to say what is being
accomplished by pushing the buttons (device pairing)?

7.2

When nodes are lost, no additional security measures are needed, the

   network remains secure as before by not allowing the addition of new

   nodes.

I’m not sure what this means.  Does it mean that if a node is lost, then it is
treated as a “new node” if it reappears, and is not allowed

to rejoin the network?

New nodes can be added by using the same protocols used for

   initial deployment.

This came right after the sentence beginning “When nodes are lost” which said
that new nodes are not added.  That contradiction needs to

be reconciled.  I’m also not sure what “using the same protocol” means.  Does
it mean rerunning the protocol and rekeying all the nodes, or does

it mean using the features that protocol has for adding nodes?

Nits:

Section 1.1

This applicability statement

   recommends more light weight security solutions and specify the

   conditions under which these solutions are appropriate.

Should be “specifies” instead of “specify”.  I’m also not sure what is meant by
“conditions under which these solutions are appropriate.”  Do

you mean light-weight as opposed to no security, or light-weight as opposed to
heavy-weight.  Or are you talking about conditions

under which different light-weight solutions are appropriate? From reading the
rest of the draft, I would assume the last is what you mean.

I consider this document  ready with issues.

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