A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)
draft-ietf-roll-security-threats-11

I think this is a nice improvement over the -01 version that we reviewed a year and a half ago.  Thanks for all the work on the document.

I do not have a blocking issue, but I'll note that issues from the earlier Gen-ART review didn't get resolved in the new version. While they are editorial, it would be much easier if raised issues were addressed, so that reviewers, ADs, or the RFC Editor do not have to track them. Approved::revised ID needed?

Thank you very much for factoring in all of the changes suggested in the SecDir review.
http://www.ietf.org/mail-archive/web/secdir/current/msg03712.html
http://www.ietf.org/mail-archive/web/secdir/current/msg03715.html
http://www.ietf.org/mail-archive/web/secdir/current/msg03719.html
http://www.ietf.org/mail-archive/web/secdir/current/msg03848.html

Although the last message says the changes were not made, they are reflected in the current revision of the draft.  The reviews above are from last year and the comments were mostly addressed.

I just have a few non-blocking comments/questions.

Section 4.3:

What's a sleepy node?  This came up in the SecDir review too.  I see it is now defined in RFC7102, could you put in a reference?  It look slike that was the plan, but this slipped through.

Section 6.4.2
Although explanations are provided in the referenced Karlof2003, short descriptions of each attack type would be helpful to include in this section as well.  I see they are described a little in later sections, but it would be better on first use.

It seems that Steve Kent's review was helpful in shaping this version of the draft, shouldn't he be acknowledged?

The following text could be more clearly stated:
"""
         Applied to routing, non-repudiation is not an
         issue because it does not apply to routing protocols, which are
         machine-to-machine protocols.
"""

It seems like it would be helpful to clarify that this is because the routing protocols themselves do not have a notion of repudiation, so the security mechanism for routing protocols doesn't need to put a control on repudiation.  Suggested text:
"""
Routing protocols typically do not have a notion of repudiation, so non-repudiation services are not required.
"""

Thanks for a vastly improved and, ISTM, very useful
document.

- 2nd last para of section 1: N-R is not a network
security service, I hope you properly ignored that.

- p11 2nd para: do you mean "cyclic graph" really?  I
thought RPL was all DAGs? Maybe a typo?

- p11 2nd para: I'm not sure that I agree fully with
the conclsion. Its correct that all nodes need to be
able to act securely, but it is also true that at a
given moment in time the impact of a risk to nodes
with lower rank is higher. Could be fixed via slight
wording tweaks I guess but saying "all nodes need to
be equally secure" is not a valid conclusion.

- 7.1.1: I'm not sure authentication is really a
prerequisite here. There have been various proposals
to over time accumulate reputation for
unauthenticated endpoints, and confidentiality could
be separated from that easily. 

- 7.3.4: Presumably a canary (a device that calls
home periodically) could also be used in this case.

- 8.4 is a little sad, isn't it? But for this
document, its fair. I don't actually agree that
asymmetric crypto is as expensive as indicated.  Such
arguments tend to be used in my experience long after
their sell-by dates should have passed and are
frequently found to no longer be true once tested.

- I tend to agree that the GEN-ART review's nits
should be fixed. There are still a number of typos
and other things to fix.