SECDIR review of draft-ietf-roll-security-threats-00   I 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 is a long document moderate, 47 densely-written pages. It is characterized as a threat analysis for a routing technology for use in low power and lossy networks (ROLL). The abstract says that it builds on other routing security documents, and adapts them to this specific environment. Looking ahead, I see that he references section cites RFC 4593, probably the most relevant threat document for routing, at this time, RFC 4949 the security glossary). These were good omens. Unfortunately, there are a number of problems with the text, as noted below. Given that this is a 00 doc, I'm guessing that the ROLL WG has not been so interested as to provide feedback. Pity.   Section 3 gets off to a poor start. The definition of “security” introduced here is too generic, and quickly needs to be qualified to add notions of authorization, authentication, confidentiality, and timeliness. There are references to various academia papers, which may be appropriate. I note, however, that other such papers that characterize routing security in terms of “correct” operation of a routing protocol, e.g., in the BGP context, have not been cited, and do not appear to be part of the methodology here.   3.1 – Much of the model presented in this section seems to be unnecessarily abstract, but maybe it gets better, later.   3.2 – One shortcoming of the “CIA” model is that it fails to differentiate authentication from integrity, and it also does not explicitly include authorization. This shortcoming shows up in the discussion on page 9. Use of the IS0 7498-2 security service terms might have yielded a better outcome, although that list also is not perfect. The introduction of the term “misuse” under the heading of integrity strikes me as inappropriate. I disagree that   non-repudiation might be relevant here. This security service (defined in ISO 6498-2) applies to people and organizations, not to devices.   3.3 – The phrase “sleepy node” is introduced, but was not defined in the terminology section.   3.4 – The use of the term “misappropriated” is odd, at best. Are the authors referring to unauthorized use? The term “legitimacy,” applied to participants is not helpful. Do the authors mean ‘authorized” here? The term “truthfulness” appears here, and is equally unhelpful. How about “accurate?” I’m beginning to wonder how carefully the authors read 4593!   4.1- the authors should use technical terminology from 4949, since they went to the trouble to cite in various places, e.g., replace “sniffing” with “passive wiretapping,” both here and throughput the document. Also, the term “traffic analysis” is much broader than what the authors suggest here. Even without access to headers per se, one can examine the size of messages and the frequency of transmission, and both of these are examples of traffic analysis.   4.2 – here too, addressing integrity and authentication separately might result in a clearer discussion. For example, “identity misappropriation” is really a violation of an authentication guarantee. The terms “overclaiming” and “misclaiming” are introduced here (4.4.1), without being defined earlier. There is mention of “freshness” which might have been addressed by using the 7498-2 terminology “connection-orietned integrity.”   4.3- “Selective forwarding,” “wormhole,” and “sinkhole” attacks are mentioned, without definition. Using a diagram to illustrate these attacks is not a substitute for concise definitions. In 4.3.4 “overload” attacks are noted, but not defined.   Also, selective forwarding isn’t a routing attack, so why is it included here?   5. – Use of encryption does not counter deliberate exposure attacks. Use of encryption, and authentication, is a counter to exposure of routing data via passive wiretapping.   5.1.2 - Passive wiretapping (“sniffing” to the authors) does not include device compromise. The discussion of what constitutes a suitable key length is not a good topic for this document. First, the authors fail to note, at the beginning of the relevant paragraph, that the key length comments are applicable to symmetric cryptographic algorithms. Second, absent a mention of the granularity of key distribution, this discussion is premature, at best.   5.1.3 - TA is always a passive attack, so the description here “… may be passive…” is wrong. Also,   TA is broader in scope than the authors stated earlier, and thus the proposed countermeasures are a subset of what might be considered.   The discussion here seems to diverge from the routing security focus of the document, when the authors discuss TA issues relevant to end-user traffic flows.   5.1.4 – Discussions of anti-tamper are rarely appropriate for IETF documents. There is no reason to believe that these authors are especially knowledgeable about such technology. I suggest this section be deleted.   5.2 – Again, distinguishing among integrity, authentication, and authorization might make for a clearer discussion. Adherence to the “CAI” model is causing these problems.   5.2.1 – the discussion   here is very superficial, not as thorough as the subsections in 5.1.   5.2.2 – This discussion is very superficial as well.   5.2.3 – “liveliness” -> “liveness” The discussion of the   use of public key technology vs. symmetric cryptographic mechanisms for authentication is vastly oversimplified, and thus not very useful. Also, the work cited here [Wander2005] is not bad, but “ NanoECC: testing the limits of elliptic curve cryptography in sensor networks, 2008” is more up to date.   5.2.4 -   this discussion seems to overemphasize timestamps as a alternative to counters, without considering the vulnerabilities associated with transitively-relayed timestamp info.   5.3.1 – Unlike previous sections, the focus here seems to be protocol-specific. I’d feel more comfortable that this was not simply an ad hoc   discussion if it were posed in a more general form. On the other hand, if ROLL has already selected a specific routing paradigm, the preceding section should be specific to that model.   5.3.2 – “Overload attacks are a form of DoS attack in that a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy store quicker” -> “Overload attacks are a form of DoS attack in which a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy store more quickly .” This sort of attack is not one against routing, unless the overload is the result of processing routing traffic?   5.3.3 – “Selective forwarding” is not a routing attack.   5.3.4 – “…, if geographic positions of nodes are available, then the network can assure that data is actually routed towards the intended destination and not elsewhere.” This is not always true, since a node might have an onward connection that provides faster or higher bandwidth service towards the destination.   5.3.5 – “In wormhole attacks at least two malicious nodes shortcut or divert the usual routing path by means of a low-latency out-of-band channel.” This seems to be a narrow characterization of such attacks. One might also say that two nodes that claim to have a short path between themselves are effecting such an attack. If two nodes really do have a short, low latency path between themselves then, from a routing perspective, what’s the problem?   6 – I find the opening sentence to be very confusing: “The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing.”   6.1 - “… and improve vulnerability against other more direct attacks …” -> “… and reduce vulnerabilities relative to other attacks …” What does “privacy” mean here? This is the first use of the term in this document. Also, the cite to Geopriv is not helpful, as the context for most Geopriv work does not match the ROLL environment.   6.2 – Did you really mean to say “ … integrity of the encrypted message …”? Generally one applies integrity mechanisms to the plaintext message, prior to encryption. The requirement to verify “message sequence” is grammatically incorrect and ambiguous. Routing protocols may not require delivery of every routing message. If the requirement here is anti-replay, say so. Also, the phrase “unintentional Byzantine” seems odd to me. It does not appear earlier, in the discussion of Byzantine threats. The common notion of a Byzantine attack is that the actors are doing so with intent. There is a very worrisome sentence in this section: In the most basic form, verification of routing peer authenticity and liveliness can be used to build a "chain of trust" along the path the routing information flows, such that network-wide information is validated through the concatenation of trust established at each individual routing peer exchange.” This sentence seems to endorse the notion of transitive trust for routing security, a bad idea.   6.4 – A more appropriate title would be “Cryptographic Key Management.” The endorsement of TPMs here seems inappropriately-specific. “ … a LLN is also encouraged to have automatic …” I don’t think you want to try to encourage a network, vs. a network operator. More to the point, we usually establish standards for security features for protocols, which seems to be the focus of this document. This is a directive directed to a network operator, and thus is out of place here. The reference to RFC 3029 is old, and refers to an experimental protocol. I'd suggest RFC 5055, which is much more recent, and is a proposed standard. “ … which supports several alternative private, public, or Diffie-Hellman …” Diffie-Hellman is a public-key scheme!   6.5 – “ … diversified needs …” -> “… diverse needs…”   8 – Although the text says that “ … design guidelines with a scope limited to ROLL.” there are a few instances where the discussion is not limited to routing. I wish the document used standard terms for security services, and employed these for the requirements, e.g., from ISO 7498-2. The security service terminology used in this document is often ad hoc.   “… mechanisms to be used to deal with each threat is specified …” -> “…mechanisms to be used to deal with each threat are specified …”