[secdir] SECDIR review of draft-ietf-roll-security-threats-00

[Stephen Kent <[e-mail]>]

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 thatnon-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 discussionhere 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 theuse 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 hocdiscussion 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 ..."