Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-76-942261511
From: JP Vasseur <jpv@cisco.com>
In-Reply-To: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com>
Date: Thu, 13 Jan 2011 15:39:17 +0100
Message-Id: <6C8230FE-0DC4-461A-8549-A7127DDDEB01@cisco.com>
References: <123DE172-C230-4A8E-81A8-2B60D9E6AD92@cisco.com>
To: Joseph Salowey (jsalowey) <jsalowey@cisco.com>
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
Precedence: list

--Apple-Mail-76-942261511
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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.
>=20
> 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.
>=20
>=20
JP> This is a very good point. How about adding the following:=20

"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. =20=

>=20
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. =20
>=20
>=20
Exactly.

Thanks a lot.

Cheers.

JP.
> Cheers,
>=20
> Joe
>=20


--Apple-Mail-76-942261511
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear =
Joseph,<div><br></div><div>Thanks for your =
review.<br><div><br><div><div>On Jan 6, 2011, at 11:42 PM, Joseph =
Salowey (jsalowey) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">
<div>
<!-- Converted from text/plain format --><p><font size=3D"2">I have =
reviewed this document as part of the security directorate's<br>
ongoing effort to review all IETF documents being processed by the<br>
IESG.&nbsp; These comments were written primarily for the benefit of =
the<br>
security area directors.&nbsp; Document editors and WG chairs should =
treat<br>
these comments just like any other last call comments.<br>
<br>
In general I think the document is clear.&nbsp; I have one security =
related issue.&nbsp; The security considerations mention attacks where =
the metric information is manipulated to cause problems.&nbsp; I think =
there may also be cases where disclosure of some of the metric =
information may be an issue.&nbsp; the main area of concern for me is =
the node energy metric.&nbsp; 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.&nbsp;&nbsp; I have not had a =
chance to see if the RPL protects the confidentiality of these =
attributes.&nbsp; If this is a concern in a deployment environment then =
the usage of these attributes may be limited.&nbsp;&nbsp; I think it is =
probably worth mentioning this in the security considerations.<br>
<br></font></p></div></blockquote><div>JP&gt; This is a very good point. =
How about adding the following:&nbsp;</div><div><br></div><div><i>"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."</i></div><blockquote =
type=3D"cite"><div><p><font size=3D"2">
Also energy metric introduce a new vector into the system for an =
attacker to modify routing behavior.&nbsp; An attacker can purposely =
attempt to modify the stored energy in a node to modify the metrics =
advertised.&nbsp;&nbsp; </font></p></div></blockquote><div>JP&gt; 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.&nbsp;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.</div><blockquote =
type=3D"cite"><div><p><font size=3D"2">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.&nbsp;&nbsp;<br>
=
<br></font></p></div></blockquote><div>Exactly.</div><div><br></div><div>T=
hanks a =
lot.</div><div><br></div><div>Cheers.</div><div><br></div><div>JP.</div><b=
lockquote type=3D"cite"><div><p><font size=3D"2">
Cheers,<br>
<br>
Joe<br>
</font>
</p>

</div>
</blockquote></div><br></div>
</div>


</body></html>=

--Apple-Mail-76-942261511--