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

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Jan 2013 12:08:42 -0500

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 ..."

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jan 2013 13:17:04 -0500

I'd like this email thread on the mailing list.  Is that okay?
If so, I will forward your email, or you can repost, and I'll repost my reply.

Unless I say otherwise, I agree with pretty much everything you write,
and I am extremely thankful for your review.

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
    Stephen> 4949 the security glossary). These were good
    Stephen> omens. Unfortunately, there are 
    Stephen> a number of problems with the text, as noted below. Given
    Stephen> that this is a 00 
    Stephen> doc, I'm guessing that the ROLL WG has not been so
    Stephen> interested as to provide 
    Stephen> feedback. Pity.

This is a rename and truncation of 
    http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/

    Stephen> 3.3 -- The phrase "sleepy node" is introduced, but was not
    Stephen> defined in the 
    Stephen> terminology section.

I see that
http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/?include_text=1

also does not include sleepy node, and I think that it should, and be
referenced. 

    Stephen> 4.1- the authors should use technical terminology from
    Stephen> 4949, since they went 
    Stephen> to the trouble to cite in various places, e.g., replace
    Stephen> "sniffing" with 
    Stephen> "passive wiretapping," both here and throughput the
    Stephen> document. Also, the term 
    Stephen> "traffic analysis" is much broader than what the authors
    Stephen> suggest here. Even 

okay, than's a very good suggestion that will bring this document much
better in line with other IETF work.

    Stephen> 4.3- "Selective forwarding," "wormhole," and "sinkhole"
    Stephen> attacks are 
    Stephen> mentioned, without definition. Using a diagram to
    Stephen> illustrate these attacks is 
    Stephen> not a substitute for concise definitions. In 4.3.4
    Stephen> "overload" attacks are 
    Stephen> noted, but not defined. Also, selective forwarding isn't a
    Stephen> routing attack, so 
    Stephen> why is it included here?

I'd like these terms added to the terminology document too.

    Stephen> 5.1.4 -- Discussions of anti-tamper are rarely appropriate
    Stephen> for IETF 
    Stephen> documents. There is no reason to believe that these authors
    Stephen> are especially 
    Stephen> knowledgeable about such technology. I suggest this section
    Stephen> be deleted. 

We have some other work that proposes future protocol changes to deal
with the case where nodes are compromised, and relies a bit, on the amount
of time required for the adversary overcome anti-tampering.   So, I
would like some discussion to remain.

    Stephen> 5.3.1 -- Unlike previous sections, the focus here seems to be
    Stephen> protocol-specific. I'd feel more comfortable that this was
    Stephen> not simply an ad 
    Stephen> hocdiscussion if it were posed in a more general form. On
    Stephen> the other hand, if 
    Stephen> ROLL has already selected a specific routing paradigm, the
    Stephen> preceding section 
    Stephen> should be specific to that model.

Yes, ROLL already has a specific routing paradigm (RFC6550), I think
that this document simply did not evolve with enough with the discussion.

    Stephen> 5.3.2 -- "Overload attacks are a form of DoS attack in that
    Stephen> a malicious node overloads the network with irrelevant
    Stephen> traffic, thereby draining the nodes' energy store quicker"
    Stephen> -> "Overload attacks are a form of DoS attack in which 
    Stephen> a malicious node overloads the network with irrelevant
    Stephen> traffic, thereby draining the nodes' energy store _more
    Stephen> quickly_." This sort of attack is not 
    Stephen> one against routing, unless the overload is the result of
    Stephen> processing routing traffic?

The attack is against the routing system.  The result is not an invalid
route (the traffic gets through), but rather one that drains the energy
on a node which otherwise did not need to be involved.  

It's not clear, btw, that we have any defense against such an attack, as
it needs to be done by an insider, but the point of the document is to
detail this attack.

    Stephen> 5.3.5 -- "In wormhole attacks at least two malicious nodes
    Stephen> shortcut or divert the usual routing path by means of a
    Stephen> low-latency out-of-band channel." This seems to be a narrow
    Stephen> characterization of such attacks. One might also say 
    Stephen> that two nodes that _claim_ to have a short path between
    Stephen> themselves are effecting such an attack. If two nodes
    Stephen> really do have a short, low latency path between themselves
    Stephen> then, from a routing perspective, what's the problem? 

That's a legimate question.  It's not clear that there even *is* a problem.
The problem is who created such a thing, and what other things (such as
selective forwarding) might then occur as a result of this shorter path?

For instance, an appropriate pair of antenna connected together by coax
could "route around" a closed door or wall.   Whether this is a desired
part of the network is another question....

    Stephen> 6 -- I find the opening sentence to be very confusing: "The
    Stephen> assessments and 
    Stephen> analysis in Section 4 examined all areas of threats and
    Stephen> attacks that could 
    Stephen> impact routing, and the countermeasures presented in
    Stephen> Section 5 were reached 
    Stephen> without confining the consideration to means only available
    Stephen> to routing." 

I think that with section 7 gone, this should be removed.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Jan 2013 10:47:43 -0500

Michael,
> If so, I will forward your email, or you can repost, and I'll repost my reply.
yes.
>      http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/
OK. Glad the doc because shorter in the process.
> also does not include sleepy node, and I think that it should, and be
OK.
> better in line with other IETF work
Thanks.,
> I'd like these terms added to the terminology document too.
Good.
> would like some discussion to remain.
OK. But, this is where the approach adopted here (and in almost all other
IETF "threat" analysis docs falls short. This doc uses the term "threat"
in a way that has become common, and is consistent with the glossary. But,
historically, a threat has been defined as a "motivated, capable, 
adversary."
When I wrote the threat analysis doc for BGP security for SIDR
(draft-ietf-sidr-bgpsec-threats-04) I used the latter definition. That 
allows
one to examine different adversaries with different capabilities and 
motivations.
You'll need this if you elect to discuss who can and cannot extract a 
key from
a TPM, for example.
> that this document simply did not evolve with enough with the discussion.
I'd suggest referring to that doc in this doc.
> on a node which otherwise did not need to be involved.
I should have said that the attack is not against the routing protocol.
> it needs to be done by an insider, but the point of the document is to
OK.
> selective forwarding) might then occur as a result of this shorter path?
This may be a good example of my comment re "correct operation" as
a better basis for a routing security criterion. If the operation
mode for routing in these nets is that a tunnel between two nodes
is not be advertised as a path between, them, then this is an attack.
> I think that with section 7 gone, this should be removed.
OK.

Steve