Re: [secdir] secdir review of draft-ietf-roll-routing-metrics-14

Adrian Farrel <Adrian.Farrel@huawei.com> Thu, 13 January 2011 16:06 UTC

Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CF13A6BA0; Thu, 13 Jan 2011 08:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.567
X-Spam-Level:
X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBhCuuKnhJBD; Thu, 13 Jan 2011 08:06:49 -0800 (PST)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id CC4953A6BB4; Thu, 13 Jan 2011 08:06:49 -0800 (PST)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEY00LZNY7CO2@usaga01-in.huawei.com>; Thu, 13 Jan 2011 08:09:12 -0800 (PST)
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEY00F4YY7885@usaga01-in.huawei.com>; Thu, 13 Jan 2011 08:09:12 -0800 (PST)
Date: Thu, 13 Jan 2011 16:09:08 +0000
From: Adrian Farrel <Adrian.Farrel@huawei.com>
In-reply-to: <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com>
To: 'JP Vasseur' <jpv@cisco.com>, "'Joseph Salowey (jsalowey)'" <jsalowey@cisco.com>
Message-id: <040401cbb33c$37262ed0$a5728c70$@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-type: multipart/alternative; boundary="Boundary_(ID_vF0svZAZe4m8D2EcK+tEfA)"
Content-language: en-gb
Thread-index: AQLGyxyKgkV2GhAribjZa9D4bCr9wQFqc1ySkc2OR5A=
iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated.
References: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com> <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com>
Cc: secdir@ietf.org, 'The IESG' <iesg@ietf.org>, draft-ietf-roll-routing-metrics.all@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-roll-routing-metrics-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian.Farrel@huawei.com
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2011 16:06:51 -0000

I added an RFC note capturing this text (translated into English ;-) and put it
on the agenda for the IESG on 1/20 (ballot had already been issued).
 
Adrian
 
From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of JP
Vasseur
Sent: 13 January 2011 14:39
To: Joseph Salowey (jsalowey)
Cc: draft-ietf-roll-routing-metrics.all@tools.ietf.org; The IESG;
secdir@ietf.org
Subject: Re: secdir review of draft-ietf-roll-routing-metrics-14
 
Dear Joseph,
 
Thanks for your review.
 
On Jan 6, 2011, at 11:42 PM, Joseph Salowey (jsalowey) wrote:



I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

In general I think the document is clear.  I have one security related issue.
The security considerations mention attacks where the metric information is
manipulated to cause problems.  I think there may also be cases where disclosure
of some of the metric information may be an issue.  the main area of concern for
me is the node energy metric.  This information may be useful to an attacker to
determine which devices to attack with out-of-band or in-band attacks involving
energy draining.   I have not had a chance to see if the RPL protects the
confidentiality of these attributes.  If this is a concern in a deployment
environment then the usage of these attributes may be limited.   I think it is
probably worth mentioning this in the security considerations.
JP> This is a very good point. How about adding the following: 
 
"Some routing metrics may also be used to identify some areas of weaknesses in
the network (a highly unreliable links, a node running low in terms of energy,
...): such information may be used by a potential attacker. Thus it is
RECOMMENDED to carefully consider which metrics should be used by RPL and the
level of visibility that they provide about the network state or to use
appropriate the security measures as specified in draft-ietf-roll-rpl to protect
that information."
Also energy metric introduce a new vector into the system for an attacker to
modify routing behavior.  An attacker can purposely attempt to modify the stored
energy in a node to modify the metrics advertised.   
JP> Right but this is also true for other metrics, this is why we made a
recommendation to stop advertising metrics for unstable links, which should
address your point. It is a generally accepted feature of routing security that
it is not possible to protect against subverted routers. That is, a router that
can be made to lie is a significant security risk and the protection must be
physical or in the management system access, not in the routing protocol.
Modifying the stored energy in a router constitutes a physical attack on the
router (i.e. subversion) and would, of course, modify the router's ability to
forward data. Thus, the routing protocol would be correct to notify the rest of
the network of the revised state of power in the router and this would affect
how packets are routed.
Its not clear to me at this point if this is significant since the power drain
may have effect on metrics and routing beyond what is advertised and it seems
the recommendation to protect against unstable links would be effective in this
case as well.  
Exactly.
 
Thanks a lot.
 
Cheers.
 
JP.
Cheers,

Joe