[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/>
- [Roll] [roll] #152: draft-ietf-roll-security-thre… roll issue tracker
- Re: [Roll] [roll] #152: draft-ietf-roll-security-… roll issue tracker
- Re: [Roll] [roll] #152 (security-threats): draft-… roll issue tracker