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

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Sun, 23 February 2014 20:06 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 92A101A06F4 for <roll@ietfa.amsl.com>; Sun, 23 Feb 2014 12:06:19 -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 ixNDpL4-SnD6 for <roll@ietfa.amsl.com>; Sun, 23 Feb 2014 12:06:17 -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 6E9851A06F3 for <roll@ietf.org>; Sun, 23 Feb 2014 12:06:17 -0800 (PST)
Received: from localhost ([127.0.0.1]:48666 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 1WHfJO-0000CH-Ff; Sun, 23 Feb 2014 21:06:06 +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:06:06 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/152
Message-ID: <067.ea0f5fb7c02a51fe7d13f9cc66287cad@trac.tools.ietf.org>
X-Trac-Ticket-ID: 152
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/h4JJl6HD3WpvW6JIL3Mm9F_kInc
Cc: roll@ietf.org
Subject: [Roll] [roll] #152: draft-ietf-roll-security-threats - Add further clarification/information - Section 5
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:06:19 -0000

#152: draft-ietf-roll-security-threats - Add further clarification/information -
Section 5

 Reported by Robert Cragie - 02/17/2014

 * Section 5 Threats and Attacks

 The source of the attacks is assumed to be from either inside or outside
 attackers.  The capability these attackes may be limited to node-
 equivalent, but also to more sophisticated computing platforms.



 <rcc>The above sentence is difficult to read and understand ("node-
 equivalent"?)</rcc>

 * Section 5.1.  Threats due to failures to Authenticate

 <rcc>I would say these are more consequences for the routing process than
 threats</rcc>

 * Section 5.1.1.  Node Impersonation

 If an attacker can join a network with any identify,



 <rcc>What does "join a network with any identify" mean?</rcc>



  In other systems where there is separate application layer security, the
 ability to impersonate a node would permit an attacker to direct traffic
 to itself, which facilitates on-path attacks including replaying,
 delaying, or duplicating control messages.



 <rcc>I don't understand the distinction for separate application layer
 security wrt. directing traffic to itself. Moreover, the intra-asset
 security domains outside of the control plane have not been clearly
 identified at this point</rcc>



 * Section 5.1.2.  Dummy Node

    If an attacker can join a network with any identify,



 <rcc>What does "join a network with any identify" mean?</rcc>

 then it can  pretend to be a legitimate node, receiving any service
 legitimate
 nodes receive.  It may also be able to report false readings (in metering
 applications), or provide inappropriate authorizations (in control systems
 involving actuators), or perform any other attacks  that are facilitated
 by being able to direct traffic towards itself.



 <rcc>How is this different from 5.1.1?</rcc>



 * Section 5.1.3.  Node Resource Spam

    If an attacker can join a network with any identify,



 <rcc>What does "join a network with any identify" mean?</rcc>



    then it can continously do so, draining down the resources of the
 network to  store identity and routing information, potentionally forcing
 legitimate nodes of the network.



 <rcc>End of sentence seems to be missing</rcc>



 * Section 5.2.1. Routing Exchange Exposure



    Routing exchanges include both routing information as well as
 information associated with the establishment and maintenance of neighbor
 state information.  As indicated in Section 3.1, the
    associated routing information assets may also include device  specific
 resource information, such as memory, remaining power, etc.,  that may be
 metrics of the routing protocol.



 <rcc>Not sure how "memory" can be a metric of a routing protocol? Does
 this mean "available memory"?</rcc>




 * Section 5.2.2.  Routing Information



 The exposure of this information will allow attachers to gain direct
 access to the configuration and connectivity of the network thereby
 exposing routing to targeted attacks on key nodes or links.  Since routes
 and neighbor topology information is stored within the node device,threats
 or attacks on the confidentiality of the information will apply to the
 physical device including specified and unspecified internal and external
 interfaces.



 <rcc>Can't really have a "threat on" something - an attack is a physical
 realization of a threat. Can have a "threat to" something, which means
 that a threat is nascent and is not realized until processed into an
 attack</rcc>



 Both of these attack vectors are considered a device specific issue, and
 are out of scope for RPL to defend against.  In some applications,
 physical device compromise may be a real threat and it may be necessary to
 provide for other devices to react quickly to exclude a compromised
 device.




 <rcc>Exclusion can only be done when a compromised device can be
 authentically detected otherwise this could form another attack vector,
 i.e. an attacker could try to convince Node A that Node B is compromised
 when Node B is actually functioning correctly. Also, this is general
 compromise, not just that associated with breach of confidentiality</rcc>



 * Section 5.3.1. Routing Information Manipulation

      o  Falsification, including overclaiming and misclaiming;



 <rcc>Probably worth explaining what "overclaiming" and "misclaiming"
 mean</rcc>



 ...

    o  Byzantine (internal) attacks that permit corruption of routing
       information in the node even where the node continues to be a
       validated entity within the network (see, for example, [RFC4593]
       for further discussions on Byzantine attacks);



 <rcc>Isn't that also falsification? Degrees of subtlety to falsification
 may be worth highlighting; subtle changes would be done to avoid
 detection</rcc>




 * Section 5.3.2. Node Identity Misappropriation

    o  Identity attacks, including Sybil attacks in which a malicious node
 illegitimately assumes multiple identities;

 <rcc>Assumption is that a Sybil attack is an intelligent attack where a
 device can purport to be many devices and appear legitimate and inject
 seemingly valid data into the network. Is there a reference?</rcc>



 * Section 5.4.1.   Routing Exchange Interference or Disruption

    The forms of attack that allow interference or disruption of routing
 exchange include:

    o  Routing information replay;


 <rcc>This has already been mentioned in the context of node impersonation
 (which IMHO is where it should live) - maybe state this could be sustained
 routing information replay? Or is this simply an overload attack?</rcc>


 * Section 5.4.2 Network Traffic Forwarding Disruption

 <rcc>What's the difference between a "sinkhole" attack and a "blackhole"
 attack (mentioned earlier)? Also, isn't "sinkhole" better known as
 "honeypot"?</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/152>
roll <http://tools.ietf.org/wg/roll/>