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

JP Vasseur <jpv@cisco.com> Thu, 13 January 2011 17:31 UTC

Return-Path: <jpv@cisco.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 263C428C12E; Thu, 13 Jan 2011 09:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.4
X-Spam-Level:
X-Spam-Status: No, score=-110.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 KBz53mDUvPcN; Thu, 13 Jan 2011 09:31:19 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 39B2B28C0F7; Thu, 13 Jan 2011 09:31:19 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFzGLk2rR7Ht/2dsb2JhbACkSHOkQJhMgnSCWASLEIMo
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Jan 2011 17:33:42 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0DHXftX024707; Thu, 13 Jan 2011 17:33:41 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 18:33:39 +0100
Received: from dhcp-lyon-144-254-54-119.cisco.com ([144.254.54.119]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 18:33:39 +0100
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: JP Vasseur <jpv@cisco.com>
In-Reply-To: <A96D73E3-AFEA-47EA-A65B-62F030C04FEE@cisco.com>
Date: Thu, 13 Jan 2011 18:33:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1F90CCF-F155-4D52-B520-732A51FCEE49@cisco.com>
References: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com> <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com> <A96D73E3-AFEA-47EA-A65B-62F030C04FEE@cisco.com>
To: Joe Salowey <jsalowey@cisco.com>
X-Mailer: Apple Mail (2.1082)
X-OriginalArrivalTime: 13 Jan 2011 17:33:39.0826 (UTC) FILETIME=[041DA520:01CBB348]
X-Mailman-Approved-At: Mon, 17 Jan 2011 13:05:04 -0800
Cc: draft-ietf-roll-routing-metrics.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@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
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 17:31:20 -0000

Thanks Joe.

On Jan 13, 2011, at 6:31 PM, Joe Salowey wrote:

> This resolution looks good to me.
> 
> Thanks,
> 
> Joe
> 
> On Jan 13, 2011, at 6:39 AM, JP Vasseur wrote:
> 
>> 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
>>> 
>> 
>