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

[Michael Richardson <[e-mail]>]

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 <[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/

    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  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [