Subject: [Roll] [roll] #153: draft-ietf-roll-security-threats - Add further clarification/information - Section 6

From: "roll issue tracker" <[email-masked]>
Date: Sun, 23 Feb 2014 20:10:15 -0000

#153: draft-ietf-roll-security-threats - Add further clarification/information -
Section 6

 Section 6.1 Confidentiality Attack Countermeasures

 <rcc>Is a "compromised node" the same as a "tampered routing node" - if
 so, maybe use the same term?</rcc>

 Section 6.1.1 Countering Deliberate Exposure Attacks

  To mitigate the risk of deliberate exposure, the process that
 communicating nodes use to establish session keys must be peer-to-peer
 (i.e., between the routing initiating and responding nodes).This helps
 ensure that neither node is exchaning routing information with another
 peer without the knowledge of both communicating peers. For a deliberate
 exposure attack to succeed, the comprised node will need to be more overt
 and take independent actions in order to disclose the routing information
 to 3rd party.

 <rcc>It doesn't strike me as mandatory that "the process that
 communicating nodes use to establish session keys must be peer-to-peer".
 It seems possible for example to disseminate a group key in a secure
 manner which is subsequently used to authentically (based on shared key
 knowledge) exchange routing information. Even then, whilst generally
 understood, it is not entirely clear what "session key" means in this
 context</rcc>

 Section 6.1.2  Countering Passive Wiretapping Attacks

 A number of deployments, such as [ZigBeeIP] specify no layer-3/RPL
 encryption or authentication and rely upon similiar security at layer-2.
 These networks are immune to outside wiretapping attacks, but are
 particularly vulnerable to passive (and active) attacks through
 compromises of nodes.

 <rcc>
 Probably need to explain in a bit more detail why. It is really a property
 of how prolific a key used to secure routing information is within the
 network. If the same key is used in every node of the network, compromise
 of a single node provides the ability to wiretap any routing information
 in the network (or masquerade as another device and inject apparently
 valid routing information). Conversely, if security is based on pairwise
 keys between neighbors in all cases, then compromise of a node will only
 allow wiretapping of routing information with its neighbors. The tradeoff
 is usually storage space.

 Another problem with pairwise keys is that it is not possible to use
 broadcast traffic effectively.</rcc>

 Section 6.1.3  Countering Traffic Analysis

 The only means of fully countering a traffic analysis attack is through
 the use of tunneling (encapsulation) where encryption is applied across
 the entirety of the original packet source/destination  addresses.
 Deployments which use layer-2 security that includes encryption already do
 this for all traffic.

 <rcc>Really? I am not sure it would make much difference. Ultimately the
 L2 src/dest addresses have to be in the clear at some point at the very
 least to be used to look up relevant security information (unless of
 course it attempts to unsecure using every key it has until it finds the
 right one?)</rcc>

 Section 6.2.1 Countering Unauthorized Modification Attacks

   ...o  include sequence number under integrity protection.

 <rcc>...to mitigate against replay attacks</rcc>

 Section 6.2.2 Countering Overclaiming and Misclaiming Attacks

 <rcc>It would still be nice to have a better description of what
 "overclaim" and "misclaim" actually mean, or an example, or at least a
 reference</rcc>

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-roll-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  security-threats         |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

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

---

From: "roll issue tracker" <[email-masked]>
Date: Sun, 23 Feb 2014 20:24:16 -0000

Comment (by [email-masked]):

 The issues listed above were reported by Robert Cragie - 02/17/2014

 Severity:  In WG Last Call          |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/153#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 25 Feb 2014 13:51:22 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] =>
            [email-masked]
 * status:  new => assigned

-- 
---------------------------------------+-------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                     |      Status:  assigned
 Priority:  major                      |   Milestone:
Component:  security-threats           |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/153#comment:2>
roll <http://tools.ietf.org/wg/roll/>