Re: [Roll] RtgDir review: draft-ietf-roll-security-threats-09.txt

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 01 September 2014 20:38 UTC

Return-Path: <mcr@sandelman.ca>
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 596BD1A06F6 for <roll@ietfa.amsl.com>; Mon, 1 Sep 2014 13:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.131
X-Spam-Level:
X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 xqomXEjU2jhB for <roll@ietfa.amsl.com>; Mon, 1 Sep 2014 13:38:27 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B991A06F0 for <roll@ietf.org>; Mon, 1 Sep 2014 13:38:26 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F57120028; Mon, 1 Sep 2014 16:42:21 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id BCB3963AE8; Mon, 1 Sep 2014 16:38:22 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AD4FA638D6; Mon, 1 Sep 2014 16:38:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: manav bhatia <manav@ionosnetworks.com>, roll@ietf.org
In-Reply-To: <CAGS6MpDXeJpmc=fiA8MLiRSgRNtnbTwfsZxtqC63HDJtvttFAA@mail.gmail.com>
References: <087f01cfc036$26032120$72096360$@ionosnetworks.com> <CAGS6MpDXeJpmc=fiA8MLiRSgRNtnbTwfsZxtqC63HDJtvttFAA@mail.gmail.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 01 Sep 2014 16:38:22 -0400
Message-ID: <9079.1409603902@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/NOw4ym-r2wf-elsOYrqauCIdvQg
Cc: draft-ietf-roll-security-threats.all@tools.ietf.org, roll-chairs@tools.ietf.org, draft-ietf-roll-security-threats@tools.ietf.org, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [Roll] RtgDir review: draft-ietf-roll-security-threats-09.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <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: Mon, 01 Sep 2014 20:38:30 -0000

Thank you Manav for your extensive and detailed review.

I'm CC'ing the WG for further comment, perhaps they would like to disagree
with me.  If there is some significant discussion that we need to have on
any of your points, I'll open tickets to track it.  I just want to pull some
text up to the top.

***
This document is as much about naming the threat, and much less about
providing a definitive solution to the threat...
***


On Mon, Aug 25, 2014 at 12:58 PM, Manav Bhatia <manav@ionosnetworks.com> wrote:
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate,
> please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document:
>
> draft-ietf-roll-security-threats-09
>
> Reviewer: Manav Bhatia
> Review Date: 25-08-14
> IETF LC End Date: 28-08-14
> Intended Status: Informational
>
> Summary:
>
> I have some concerns about this document and recommend that the Routing
> ADs discuss these issues further with the authors.
>
> Comments:
>
> This document presents a threat analysis for securing the routing
> protocols used in LLNs which are more prone to packet losses and other
> vulnerabilities. It then discusses how those attacks/threats can be
> mitigated.
>
> Major Issues:
>
> (1)  Sec 7.2.2.  "Countering Overclaiming and Misclaiming Attacks" says
> that " counter to overclaiming and misclaiming may employ: comparison with
> historical routing/topology data;"
>
> I don't understand how this will work. Assume node A was always a leaf
> node and was never attached to any routing device. Later, a new router
> gets attached to this node. The node A now starts advertising this new
> router. How will the peers know whether it's a legitimate advertisement or
> an "overclaim" from node A? I don't agree with notion that somebody could
> look at the historical data to figure out if a router is over/under
> claiming.
>
> I also don't think it's a good idea to suggest that we "restrict
> realizable network topologies" to counter overclaim/misclaim attacks.

I guess I will say two things about this.
1) we have no specific mechanisms in RPL to either recognize this situation
   or deal with it.  It's an attack that (any) node with the L2-keys
   can do, and therefore falls in the category of threats by insiders.

   ***
   This document is as much about naming the threat, and much less about
   providing a definitive solution to the threat...
   ***

2) while RPL does have the *A* bit, which can restrict which nodes can
   operate as intermediate routers and which ones are restricted to leaf
   nodes.  This requires layer-3 security (rather than just layer-2)
   and further in many situations seems to require that the layer-3
   security be provided by asymmetric cryptographic mechanisms.
   Many are not (yet) convinced that this can be done cheaply enough...
   The *A* bit can not keep one router from claiming something that belongs
   to another router, though. It can only keep leafs from becoming routers.


> (2) Sec 7.3.2 "Countering Overload Attacks" suggests that "overload
> attacks" can be countered by "isolate nodes which send traffic above a
> certain threshold based on system operation characteristics;". Has this
> been adequately discussed in the WG? It's certainly possible that in an

No; I would say that it is a subject of much research.

On the topic of nodes getting overloaded,  one might want to depreference the
overloaded node, one would need better energy aware objective functions.
RPL has pluggable objective functions, and we know that coming up with better
ones is a hot reserach topic.
http://datatracker.ietf.org/doc/draft-ajunior-roll-energy-awareness/
is an example of such an effort, but I suspect that over time there will be
better ones.
On the topic of sending too much non-malicious traffic, the 6tisch WG
exists specifically to deal with providing tracks (an MPLS-like form of
routes) with both upper and lower bounds on traffic.
If the node is malicious, isolation seems to be the right answer.
Turning it into a leaf node doesn't help, the node can still send traffic.

> Minor Issues:
>
> (1) A common threat in routing protocols is that there is some
> unauthorized entity that somehow manages to gain access to keying
> material. Using this material, the attacker can send packets that pass the
> authenticity checks based on Message Authentication Codes (MACs). The most
> obvious way to mitigate such threat is by periodically changing the keys
> currently in use by the legitimate routing peers. Hence routing protocols
> designed for LLN must provide provision to easily change their keying
> material. Additionally security mechanisms designed for RPL must be such
> that the operators can quickly change keys without disrupting the routing
> system (data loss) and with minimal operational overhead/expense. If there
> is a significant overhead than this can lead to the keys not being changed
> often enough.  I don't think this aspect is covered in the document.

Changing keys is certainly and important way, and if you look at the security
parts of the applicability statements allude to in section 2, and of which
draft-ietf-roll-applicability-template* is the template, you'll see that it
specifically asks what kind of security mechanisms will be in place.
Being able to change keys easily is important, but it is not always possible.

> (2) Nodes in this environment can be installed but not switched on for
> quite some time. How would such devices get the updated keying material if
> it has changed by the time these get turned on? On a related note, what
> happens if these nodes support an authentication/encryption algorithm that
> gets deprecated by the time these nodes get switched on -- can happen if
> this particular node lies dormant for a few years before its turned on
> (refer to sec 4.3)

I think that those nodes which do not get updated (and can not securely
firmware updated), are, sadly, industrial waste.   Dan Greer has some
opinions about that.  I don't know what the security threats documents
should say about that.

> (3) An automated key management protocol is a very important component of
> the security framework.  Do all nodes in the LLN need to be manually
> configured? This may not be possible if there are large number of nodes in
> the routing domain. Wouldn't it make sense to actually discuss this

It's not a security framework; it's a set of security threats.

> (4) Sec 4.4. "RPL Security Objectives". Are we interested in message
> contents validation? Lest there is any doubt let me clarify that I am not
> talking about message integrity. I am talking about ensuring that a claim
> made in the route advertisement is indeed correct before accepting it
> (like SIDR).  If we're not doing this, then it might help to explicitly
> state that message content validation is out of scope. If you're adding
> this, then a note or two on why would be extremely helpful.

There are no mechanisms at present to carry SIDR like statements; perhaps a
future protocol will figure out how to add that.  The WG has discussed this
some very long time ago.

> (5) Sec 4.4 says " Hence, routing in LLNs needs to bootstrap the
> authentication process and allow for flexible expiration scheme of
> authentication credentials."
>
> Can you explain this a bit more? Will this not lead to a circular
> dependency where routing bootstraps security, but you need security
> already in place for routing to work (to ensure we're speaking to an
> authorized node)?

It's not circular, but rather, concentric.  The security has to bootstraped
From the root node outwards.

> (6) Sec 7.3.3 "Countering Selective Forwarding Attacks". Are you really
> suggesting that RPL should redundantly flood protocol messages over
> multiple paths in the hope that at least one will make it to the
> destination. Given the delicate energy and network utilization constraints
> this just doesn't look right. Shouldn't we focus more on ensuring that we
> don't get an insider malicious node than on what we can do once we have
> one inside our routing domain?

Flooding is an option if you want to deal with selective forwarding attacks.
Yes, that's right, it's a really bad answer, energy-wise.  Some deployments
might be willing to make that tradeoff.  In fact, MPL does *exactly* this,
using trickle to control the flood.

Or, there is option two: "dynamically selecting the next hop from a set of
    candidates", as you note.  They are mostly mutually exclusive choices.

Or, option three: applicability statement says that they aren't going to
solve it.

> (7) Sec 7.3.3 suggests "dynamically selecting the next hop from a set of
> candidates." to counter selective forwarding attacks. I am not sure i
> completely understand the point. Are you suggesting that we should
> consider multiple paths when constructing the shortest path tree? This
> will only work when you have ECMP because its only then that you have a
> set of nexthops that you can use without affecting the total cost to reach
> the destination. Without ECMP, how can you have a set of nexthops to
> choose from? I don't think you're alluding to pinning the path here?

You used the term "shortest path" --- RPL doesn't always make a shortest path
tree.  It can make a lowest-energy-cost tree, or a lowest-latency-tree, or
a number of other things if you come up with new objective functions.  Most
nodes will be in radio range of quite a number of other nodes, so even ECMP
is not unreasonable.

> (8)7.3.4 "Countering Sinkhole Attacks" suggests "isolate nodes which
> receive traffic above a certain threshold;". I disagree doing this without
> further qualifying on what's meant by a "certain threshold" for the same
> reason as i cited above in (4).
>
> Nits:
>
> (1) There are several instances where RFC 2119 keywords are used. While I
> personally don't have an issue with using those keywords in an
> Informational draft, I was grilled in the IESG review on this and went
> through the pain of removing those at the last minute.

The WG discussed this recently, and decided to keep 2119 keywords.

> (2) Sec 6 describes the threats and the possible attacks on RPL. In this
> context the title of Sec 6.1 is very clear and the reader understands the
> threat/attack being discussed in the following subsection. However the
> title of Sec 6.2 is very vague. I had to read the entire subsection to
> understand what the subsection was about.  I think what you want to cover
> are the threats you get exposed to if your system *lacks* confidentiality.

So you are suggesting that the title:
6.2.  Threats and Attacks on Confidentiality

should say something more like:
6.2.  Threats due to failures to keep routing information confidential

???






--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-