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

[Stephen Kent <[e-mail]>]

Michael,
> 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.
yes.
> Unless I say otherwise, I agree with pretty much everything you write,
> and I am extremely thankful for your review.
>
>>>>>> "Stephen" == Stephen Kent <[e-mail]> 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/
OK. Glad the doc because shorter in the process.
>      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.
OK.
>      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
Thanks.,
>      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.
Good.
>      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.
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.
>      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.
I'd suggest referring to that doc in this doc.
>      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.
I should have said that the attack is not against the routing protocol.
> 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.
OK.
>      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?
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.
> 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.
OK.

Steve