Re: [secdir] secdir re-review of draft-ietf-manet-olsrv2-16

Tom Yu <tlyu@MIT.EDU> Thu, 11 October 2012 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98E1921F871D; Thu, 11 Oct 2012 08:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fm7Y4WNkkvPV; Thu, 11 Oct 2012 08:14:07 -0700 (PDT)
Received: from (DMZ-MAILSEC-SCANNER-2.MIT.EDU []) by (Postfix) with ESMTP id AE82B21F8620; Thu, 11 Oct 2012 08:14:06 -0700 (PDT)
X-AuditID: 1209190d-b7f906d0000008de-ea-5076e23d0aa8
Received: from ( []) by (Symantec Messaging Gateway) with SMTP id A1.19.02270.D32E6705; Thu, 11 Oct 2012 11:14:06 -0400 (EDT)
Received: from (OUTGOING-AUTH.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id q9BFE4G7010999; Thu, 11 Oct 2012 11:14:04 -0400
Received: from (CATHODE-DARK-SPACE.MIT.EDU []) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by (8.13.6/8.12.4) with ESMTP id q9BFE0Sl003689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2012 11:14:01 -0400 (EDT)
Received: (from tlyu@localhost) by ( id q9BFE0XH019865; Thu, 11 Oct 2012 11:14:00 -0400 (EDT)
To: "Dearlove, Christopher (UK)" <>
References: <> <>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 11 Oct 2012 11:13:59 -0400
In-Reply-To: <> (Christopher Dearlove's message of "Thu, 11 Oct 2012 09:02:14 +0000")
Message-ID: <>
Lines: 56
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixCmqrWv3qCzAoLnMomv6bBaLZ91/2Cxm /JnIbPFh4UMWBxaPmYv3MnksWfKTyePL5c9sAcxRXDYpqTmZZalF+nYJXBknD0xlLrgtV3H7 cztLA+MKyS5GTg4JAROJdft6mCFsMYkL99azdTFycQgJ7GOUWNCwkx3C2cAosenjSiYI5wqT xKpVl1ggnC5GieuLv7GD9IsIOEj0LugDq2IWWMMocXHOIlaQhLCAtcTMLceAlnAAddRKNN2N BTHZBKQlji4uAzFZBFQltkxLAenkFJjKKPHn0n8mkE5eAQuJbWcngE3hEeCUuLT2MQtEXFDi 5MwnYDazgJbEjX8vmSYwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJ XmpK6SZGcBhL8u5gfHdQ6RCjAAejEg/vj52lAUKsiWXFlbmHGCU5mJREefselAUI8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuHtuQSU401JrKxKLcqHSUlzsCiJ815JuekvJJCeWJKanZpakFoE k5Xh4FCS4N39EKhRsCg1PbUiLTOnBCHNxMEJMpwHaLgWSA1vcUFibnFmOkT+FKOilDhvFkhC ACSRUZoH1wtLM68YxYFeEeZdC1LFA0xRcN2vgAYzAQ2WmVQCMrgkESEl1cBYFVbXGPmgb/a2 HrOfWqFGt955GCxX6jz4bskd+7Sq1XkzOKoEhE0d1T8tY/7+bGmBkNA53/nOCx/K6bTkrHEX +VdlyZzMq784fOFxH5OE50U9yQwZVS7xK06IPvES7b3Sy3alm3NyYm75tIilV9svPHHxMpyv tfik9IreL6f37i0skdkTH6nEUpyRaKjFXFScCADXN1ZbDgMAAA==
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir re-review of draft-ietf-manet-olsrv2-16
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: Thu, 11 Oct 2012 15:14:12 -0000

"Dearlove, Christopher (UK)" <> writes:

> With regard to the final correction, I think neither version is good. I think the original meant to say reject it as having the status valid, the replacement is saying reject it, it has the status invalid. I think a third wording (I'm not proposing a candidate here) would be better.

RFC 6130 Section 12.1 (which this document references) describes when
a message is invalid, so I think "invalid" is the correct word to use
in that sentence in Section 23.2 of this document.

> With regard to RFC 6622, I should note that I'm not an author of it. But from the perspective of OLSRv2, I can only comment that it was accepted by the IESG. Stressing the speaking personally, I would be happy to reference, or not reference, it.

RFC 6622 basically provides building blocks for authenticating MANET
messages.  I think it is not feasible to implement RFC 6622 in an
interoperable way, but even if it were, I think it remains the
responsibility of a document referencing RFC 6622 to describe how to
use those building blocks to construct an appropriate authentication

I find that this document doesn't provide enough specification detail
to build a plausible interoperable authentication scheme for the
OLSRv2 protocol out of RFC 6622 building blocks.  If anything, it
seems to defer such specification of such authentication schemes to
future work ("security extensions"), but it refers to no specific work
in progress.  Is any such work in progress or planned?  If there are
no such plans, perhaps it is best to explicitly state that (with
justifications), and let the IESG decide on those grounds.

> There are good reasons why security functionality is separated out, essentially because (as is commented on in the security considerations section) there are a wide range of circumstances that ad hoc networks are used in. To name but two, there are obviously different requirements (including key management approaches) in a community Wi-Fi network, and a military application such as a group of soldiers. It would be, for the people who will use the protocol, wrong to even consider putting a "one size fits all" mechanism for signatures, timestamps, or (probably especially) key management into the routing protocol.

I agree that there can be good reasons to separate out the security
capabilities of a protocol, but it should be possible to implement
something that provides a reasonable level of security.  For a routing
protocol, strong authentication seems desirable for most reasonable
deployment scenarios.  Confidentiality seems likely to be less
important for a routing protocol, except for specialized situations.
(I imagine that a combat deployment would be one situation where
revealing topology information about a wireless network could put
personnel at an elevated risk of physical attack by leaking
information about their physical locations.)

This document appears to recommend message authentication in Section
23.2, but it doesn't specify how to determine which cryptographic key
protects what message, or how protocol participants manage those keys.
It also doesn't specify which messages should be authenticated using
public key versus shared key cryptography.

Do you envision that an entire MANET shares a single symmetric key?
If so, how would operators provision this key to routers?  Is this a
reasonable risk in envisioned deployment scenarios?  What if one
router is compromised?  etc.

Although allowing alternative security mechanisms can be beneficial, I
think it's important to specify at least one, so that it is clear that
the architecture can support at least one mechanism that has the
desired security properties for the protocol.  The specification of
such a "proof of concept" security mechanism need not be in this
document, but it should be somewhere.