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

["Adrian Farrel" <[e-mail]>]

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