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

Joe Salowey <> Thu, 13 January 2011 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 269CC28C10E; Thu, 13 Jan 2011 09:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jOpklL9G5yu3; Thu, 13 Jan 2011 09:28:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 44C2228C0F7; Thu, 13 Jan 2011 09:28:33 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
Received: from ([]) by with ESMTP; 13 Jan 2011 17:30:56 +0000
Received: from [] ([]) by (8.13.8/8.14.3) with ESMTP id p0DHUtOt016119; Thu, 13 Jan 2011 17:30:56 GMT
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Joe Salowey <>
In-Reply-To: <>
Date: Thu, 13 Jan 2011 09:31:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: JP Vasseur <>
X-Mailer: Apple Mail (2.1082)
Cc:, The IESG <>,
Subject: Re: [secdir] secdir review of draft-ietf-roll-routing-metrics-14
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jan 2011 17:28:34 -0000

This resolution looks good to me.



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