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

I have a whole bunch of problems with this draft, but understand that this is part of way to get out of the current not so great situation.  Many of my comments lined up with the secdir review, but since Stewart called it out in his discuss I'll support him.  Here's some of my own:

0) This draft boils down to this paragraph if I'm not mistaken:

   A ROLL protocol MUST be made flexible by a design that offers the
   configuration facility so that the user (network administrator) can
   choose the security settings that match the application's needs.
   Furthermore, in the case of LLNs, that flexibility SHOULD extend to
   allowing the routing protocol security requirements to be met by
   measures applied at different protocol layers, provided the
   identified requirements are collectively met.

I'm absolutely fine with the first sentence.  I'm even okay with the second sentence it gets done at the application layer all the time, but at the application layer they can all point to something that's all specified up and has MTI etc (think TLS).  If we end up doing that here then something similar needs to end up happening.  If use cases are so broad that they can't possibly pick an underlying security mechanism then you need to try again but with a  smaller net.

1) s3.2: Adding "misuse" in the integrity strikes me as wrong.  It's about determining whether data has changed.  The examples used are about delayed or replayed messages which seem to be better characterized as availability.

2) s3.2: How on is non-repudiation going to apply to these tiny little assets?  I see how I, a person, can repudiate that I sent a message and I can see how you, as a person, can repudiate something else.  Are two nodes going to be claiming one sent something while the other will say no I didn't?  I hear all the time we can't do this and we can't do that because these are so constrained but you're going to log and capture on-going messages - color me confused?  I think you should say non-repudiation applies to people not to device-to-device/automated communications.

4) s3.4: Not this one is likely to be cleared after an email exchange or two because there's not much for the authors to do…

This made my head pop because I thought the only security defined in the RFC 6550 has confidentiality baked in.  So are we dumping the security solution in rpl?
 
 With regard to confidentiality, protecting
 the routing/topology information from eavesdropping or unauthorized
 exposure may be desirable in certain cases but is in itself less
 pertinent in general to the routing function.

I think this will be a hugely useful RFC but does have a
few things that could be improved.  My discuss points are
small, and perhaps easily fixed, but also I think
important since they relate to why we're still here after
a couple of years.

(1) 6.4 says that consistency with BCP107 is a SHOULD.
That's a MUST, (regardless of how you define MUST:-) Note
that BCP107 does say when you do not need automated key
managment, and when you do. So if you really don't need
AKM then you are still consistent with the BCP. It is not
however ok to be inconsistent with BCP107.

(2) 6.5.1 says: "This protocol-specific security
mechanism SHOULD be made optional within the protocol
allowing it to be invoked according to the given routing
protocol and application domain and as selected by the
system user. " If you mean optional-to-use, that's ok,
but please say so. If you mean optional-to-implement,
that's not clearly ok and I have more questions. Do you
mean optional-to-use? If not, then BCP61 comes into play
for me unless the quoted text only relates to some
mechanisms that counter Byzantine attacks, in which case
you need to be clear that you're not saying that all
integrity mechanisms are optional-to-implement.

From a routing point of view I thought that this was well written, but I am concerned that the security reviewer had considerable comments which appear to be currently unresolved.

Adrian points to:

http://www.ietf.org/mail-archive/web/secdir/current/msg03848.html

However this indirectly refers to a larger body of issues posted here:

http://www.ietf.org/mail-archive/web/secdir/current/msg03712.html

and the security reviewer only re-lists a subset  of these in note 03848 noting that only the typos were addressed in the -01 version of the text.