Re: [secdir] SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02

"Adrian Farrel" <> Wed, 06 March 2013 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 196EC21F86F5 for <>; Wed, 6 Mar 2013 10:31:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.629
X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aHKEhTVqfASP for <>; Wed, 6 Mar 2013 10:31:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B8D1921F85B1 for <>; Wed, 6 Mar 2013 10:31:00 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id r26ITpPl020497; Wed, 6 Mar 2013 18:29:52 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id r26ITmhG020467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Mar 2013 18:29:50 GMT
From: "Adrian Farrel" <>
To: "'Stephen Kent'" <>, "'secdir'" <>, <>, <>, <>, <>, <>, "'Stewart Bryant'" <>
References: <>
In-Reply-To: <>
Date: Wed, 6 Mar 2013 18:29:52 -0000
Message-ID: <022f01ce1a98$991192e0$cb34b8a0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0230_01CE1A98.991C8F60"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNG5uRV1AP4Bq9s3GOfb4X8RM35mZWnYFJw
Content-Language: en-gb
Subject: Re: [secdir] SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Mar 2013 18:31:07 -0000

Hi Stephen,
Thanks for this. I wanted to note that this is the rationale for adding metrics
to OLSRv2, not the whole deign rationale for OLSRv2, so there is a big gap
between "consideration of security did not play any part in the design of this
protocol" and "this document does not specify any design considerations".
However, I think your point is valid.
During my AD review I asked the authors:
> Were there any security considerations that cropped up while designing
> metric support in OSLRv2? If so, here would be the place to mention
> them.
The authors had no updates they wanted to make to this document and that led me
to conclude:
> Security issues arising from the inclusion of metrics in OLSRv2 did
> not get any specific discussion. Since OLSRv2 has its own security
> considerations to cover the whole protocol, there is nothing further
> to say in this document.
...a statement which I put to the WG and which they did not refute.
So that leads us to wonder: should the addition of a metric to a routing
protocol have been the subject of a discussion about the impact on security. And
if it wasn't, should this document record that it wasn't (and if so, why it
I think that would probably lead to a very short paragraph being inserted in
Section 8 saying "We knew that OSLRv2 already had adequate security so we did
not consider adding metrics in anyway changed the threats or mitigation
expressed in the base specification."
Would that have addressed the issue for you?
From: Stephen Kent [] 
Sent: 06 March 2013 15:40
To: secdir;;;;;; Stewart Bryant; Adrian Farrel
Subject: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02
SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02
I 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
This document is targeted as an Informational RFC. It describes itself as ". an
historic record of the rationale for, and design considerations behind, how link
metrics were included in OLSRv2."
The Security Considerations section says simply "This document does not specify
any security considerations." It's been a very long time (many years) since I've
encountered that phrase in a candidate RFC. A rationale document itself probably
does not entail security considerations, but the omission of any security
discussion suggests that security did not play a role in the deign of this
routing protocol. Is that true? If so, who thinks this is a good thing?
I looked at the I-D that defines OLSRv2. It contains a two-page Security
Considerations section. From my perspective, this document ought to provide
background info (rationale) for the security suggestions contained that