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

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Sun, 23 February 2014 20:10 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34D61A06FA for <roll@ietfa.amsl.com>; Sun, 23 Feb 2014 12:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level:
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46mGb_nV-Cw5 for <roll@ietfa.amsl.com>; Sun, 23 Feb 2014 12:10:29 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF451A06F7 for <roll@ietf.org>; Sun, 23 Feb 2014 12:10:29 -0800 (PST)
Received: from localhost ([127.0.0.1]:48737 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1WHfNP-0003Hi-Ln; Sun, 23 Feb 2014 21:10:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "roll issue tracker" <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-roll-security-threats@tools.ietf.org, mariainesrobles@gmail.com
X-Trac-Project: roll
Date: Sun, 23 Feb 2014 20:10:15 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/153
Message-ID: <067.cc7b7ee9b48456369af4633c53403c40@trac.tools.ietf.org>
X-Trac-Ticket-ID: 153
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-roll-security-threats@tools.ietf.org, mariainesrobles@gmail.com, robert.cragie@gridmerge.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: angel.lozano@upf.edu, mcr+ietf@sandelman.ca, mischa.dohler@cttc.es, roger.alexander@cooperindustries.com, tzeta.tsao@cooperindustries.com, vanesa.daza@upf.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/nDYi1y3dwtHEnoTyaMT91VoZtUc
Cc: roll@ietf.org
Subject: [Roll] [roll] #153: draft-ietf-roll-security-threats - Add further clarification/information - Section 6
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Feb 2014 20:10:32 -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-
  mariainesrobles@gmail.com          |  security-threats@tools.ietf.org
     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/>