Last Call Review of draft-ietf-roll-security-threats-00

Request Review of draft-ietf-roll-security-threats
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-01-21
Requested 2013-01-10
Authors Tzeta Tsao, Roger Alexander, Mischa Dohler, Vanesa Daza, Angel Lozano, Michael Richardson
Draft last updated 2013-01-25
Completed reviews Genart Last Call review of -00 by Peter Yee (diff)
Genart Last Call review of -09 by Peter Yee (diff)
Genart Telechat review of -10 by Peter Yee (diff)
Secdir Last Call review of -00 by Stephen Kent (diff)
Secdir Telechat review of -01 by Stephen Kent (diff)
Rtgdir Last Call review of -09 by Manav Bhatia (diff)
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-roll-security-threats-00-secdir-lc-kent-2013-01-25
Reviewed rev. 00 (document currently at 11)
Review result Has Issues
Review completed: 2013-01-25


SECDIR review of 



I reviewed this document as part of the
        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
        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
        from integrity, and it also does not explicitly include
        authorization. This
        shortcoming shows up in the discussion on page 9. Use of the IS0
        security service terms might have yielded a better outcome, 

        that list also is not perfect. The introduction of the term
        “misuse” under the
        heading of integrity strikes me as inappropriate. I disagree


        might be relevant here. This
        security service (defined in ISO 6498-2) applies to people and
        not to devices.


3.3 – The
        phrase “sleepy node” is introduced, but was not defined in the


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


        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


5.1.2 -
        Passive wiretapping (“sniffing” to the authors) does not include
        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.


        here seems to diverge from the routing security focus of the
        document, when the authors discuss TA issues relevant to
        end-user traffic


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


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 “

        testing the limits
        of elliptic curve cryptography in sensor networks, 2008” is more
        up to date.


5.2.4 - 


this discussion seems to
        timestamps as a alternative to counters, without considering the
        vulnerabilities associated with transitively-relayed timestamp


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
        paradigm, the preceding section should be specific to that


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 


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

        and not
        elsewhere.” This is not always true, since a node might have an
        connection that provides faster or higher bandwidth service
        towards the


5.3.5 – “In
        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 


        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
        vulnerability against other more direct attacks …” -> “… and
        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


6.2 – Did you
        really mean
        to say “ … integrity of the encrypted message …”? Generally one
        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
        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
        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
        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
        operator. More to the point, we usually establish standards for
        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. “ … 

      supports several alternative private, public, or Diffie-Hellman …”
      Diffie-Hellman is a public-key scheme! 


6.5 – “ …
        diversified needs
        …” -> “… diverse needs…” 


8 – 

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


 specified …”