[Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation

["roll issue tracker" <[e-mail]>]

#124: draft-ietf-roll-security-threats-01.txt --- Include further explanation

 Comments done by Stephen Kent (SK),source:[http://www.ietf.org/mail-
 archive/web/secdir/current/msg03712.html] and [http://www.ietf.org/mail-
 archive/web/secdir/current/msg03848.html][[BR]]
 Comments done by Sean Turner (ST),source:
 [https://datatracker.ietf.org/doc/draft-ietf-roll-security-
 threats/ballot/]

 === Section 3.2[[BR]]
 * s3.2: I thought this was about the control plane?  Why does the
 availability paragraph talk about forwarding "services"?-- by ST[[BR]]
 * s3.2: The last paragraph has to be more tightly coupled to ROLL.  I'm
 afraid of a food fight between the various routing security groups that
 are doing work in this space because they're not all implementing
 enforcement mechanisms for the services described in s3.2. -- by ST

 === Section 3.3[[BR]]
 * s3.3: What does this mean and why: In addition, the choices of security
 mechanisms are more stringent. -- BY ST[[BR]]
 * s3.3: Highly directional traffic: Are you trying to say that the LBRs
 are higher valued targets and warrant something different than the regular
 nodes?-- BY ST

 === Section 3.4[[BR]]
 * s3.4: Not this one is likely to be cleared after an email exchange or
 two
 because there's not much for the authors to do…

 This made my head pop because I thought the only security defined in the
 RFC
 6550 has confidentiality baked in.  So are we dumping the security
 solution in
 rpl?

  With regard to confidentiality, protecting
  the routing/topology information from eavesdropping or unauthorized
  exposure may be desirable in certain cases but is in itself less
  pertinent in general to the routing function.-- by ST

 === Section 5.2.4[[BR]]
 * 5.2.4 -  this discussion seems to overemphasize timestamps as a
 alternative to counters, without considering the vulnerabilities
 associated with transitively-relayed timestamp info.-- by SK

 === Section 5.3.1[[BR]]
 * 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. -- by SK

 === Section 5.3.4[[BR]]
 * 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. -- by SK

 === Section 5.3.5[[BR]]
 * 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? -- by SK

 === Section 6.1[[BR]]
 * 6.1 - Also, the cite to Geopriv is not helpful, as the context for most
 Geopriv work does not match the ROLL environment.-- by SK

 === Section 6.2[[BR]]
 * 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.-- by SK[[BR]]
 * s6.2: Can't do security but can keep logs ;)-- by ST

 === Section 6.4[[BR]]
 * 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. -- BY SK

 === Section 6.5.1[[BR]]
 *This draft boils down to this paragraph if I'm not mistaken:

    A ROLL protocol MUST be made flexible by a design that offers the
    configuration facility so that the user (network administrator) can
    choose the security settings that match the application's needs.
    Furthermore, in the case of LLNs, that flexibility SHOULD extend to
    allowing the routing protocol security requirements to be met by
    measures applied at different protocol layers, provided the
    identified requirements are collectively met.

 I'm absolutely fine with the first sentence.  I'm even okay with the
 second
 sentence it gets done at the application layer all the time, but at the
 application layer they can all point to something that's all specified up
 and
 has MTI etc (think TLS).  If we end up doing that here then something
 similar
 needs to end up happening.  If use cases are so broad that they can't
 possibly
 pick an underlying security mechanism then you need to try again but with
 a
 smaller net. -- by ST

 === Section 8[[BR]]
 * 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. --
 by SK

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  [e-mail]          |  [e-mail]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  security-threats         |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/124>
roll <http://tools.ietf.org/wg/roll/>