Re: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03

Yoav Nir <> Fri, 02 August 2013 10:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A103B11E828F; Fri, 2 Aug 2013 03:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.478
X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C9KEDqEXjvT0; Fri, 2 Aug 2013 03:57:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3183911E8251; Fri, 2 Aug 2013 03:57:12 -0700 (PDT)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r72Av8Q6023835; Fri, 2 Aug 2013 13:57:08 +0300
X-CheckPoint: {51FB9084-3-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Fri, 2 Aug 2013 13:57:07 +0300
From: Yoav Nir <>
To: "<>" <>
Thread-Topic: SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
Thread-Index: AQHOjkRzWPcMempN206ICOIpPpticZl/4aaAgAGrfgCAAAIWAA==
Date: Fri, 2 Aug 2013 10:57:06 +0000
Message-ID: <>
References: <> <> <005201ce8f6d$fcc8ac20$f65a0460$>
In-Reply-To: <005201ce8f6d$fcc8ac20$f65a0460$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 114f3aae9f1ac07032ddcf217b6e2e1a042259464f
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>, IESG <>, Ulrich Herberg <>, "<>" <>
Subject: Re: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
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: Fri, 02 Aug 2013 10:57:24 -0000

With the proposed changes, including a statement that someone is working on key distribution, I'm fine.

On Aug 2, 2013, at 12:49 PM, Adrian Farrel <>

> Hello all,
>>> I am not convinced by the suitability of a POSIX timestamp (32-bits with 1-
>>> second resolution) to protect in general against replay. Within the same
> second, a
>>> packet can be replayed. I don't know enough about the NHDP and OLSRv2
>>> protocols to say whether this is a problem. Its usefulness depends on
>>> synchronized clocks, but this is well explained in the document, both in the
>>> security considerations, and in the regular sections where timestamp is
>>> mentioned.
>> UH> In the majority of MANET use cases that we are aware of, time
>> synchronization much below one second is not possible. Also, keep in
>> mind that the MANET routers are not the typical huge backbone router,
>> but rather very constrained devices with CPUs of only a few Megahertz
>> and memory of megabytes or even just kilobytes. The precision of the
>> clocks on such devices will consequently not be of the same
>> granularity as on the big Internet routers. Note that, as we explained
>> in the previous comment, only the *implementation* of this framework
>> is mandatory, not the *usage*. In use cases with higher requirements
>> (and with routers of appropriate capability), higher granularity
>> timestamps may be used (e.g., for military use cases).
>> UH> In addition, when looking at the default message intervals and
>> validity times (minimum 2 seconds) anyone repeating the message within
>> a second is (bandwidth occupation aside) doing you a favor, not a
>> harm. If going into details, the use of RFC5148 jitter can cause a
>> message to take that long or more to traverse the network. In fact
>> even in a perfectly synchronized network, with fine granularity times,
>> the TC maximum delay would probably be greater than 1 second. (Shorter
>> for HELLO messages.)
> Yes, this seems right.
> This is good text and helps explain a lot about the operation of the protocols
> in environments that need to be secured. It also can be used to highlight the
> small vulnerability of replay within the timestamp granularity.
> Could you polish it and add it to the draft?
>>> The biggest hole in this specification is that it is silent about key
> distribution
>>> ("This framework does not...Specify how to distribute cryptographic material
>>> (shared secret key(s))." This is the real hard problem, and the draft doesn't
> even
>>> reference some other specification that does have a suitable key distribution
>>> protocol. You can't do HMAC without key distribution being in place.
>> UH> We have intensely discussed this with Stephen Farrel, who agreed
>> with this approach (and which actually triggered this particular
>> draft). The relevant text why we do not specify a key management
>> mechanism, can be found in the "Security Considerations" section in
>> OLSRv2. We can add a pointer to that text in the nhdp-olsrv2-sec
>> draft.
> That pointer would be a great idea.
> I suspect that we must take small steps towards the complete security picture.
> That the key distribution is still an open issue  is at last exposed here.
> Is there enough text describing how deployed systems handle this issue? I
> suspect that, since many MANETs are military, there is an operational solution
> to this problem (probably involving men with guns and RSA tokens :-)
>>> On to the security considerations section:
> [snip]
>> UH> Very good catches. We will fix them.
> Ulrich and authors...
> Last call expires on 8/14 and the document is currently set for IESG review on
> 8/15
> If the resolution of these comments can be agreed with Yoav, no more substantive
> comments come in, and a new version is ready to post on 8/14 we can go ahead on
> the current schedule.
> If you think you need more time, I will move the document out to a later IESG
> telechat.
> Adrian
> Email secured by Check Point