Last Call Review of draft-ietf-roll-security-threats-00
review-ietf-roll-security-threats-00-secdir-lc-kent-2013-01-25-00

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 …”