Last Call Review of draft-ietf-manet-nhdp-olsrv2-sec-03
review-ietf-manet-nhdp-olsrv2-sec-03-secdir-lc-nir-2013-08-02-00

Do not be alarmed.  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.

Summary: Has issues. This document needs some more work, both on the security
considerations section and general terminology.

This draft adds integrity protection and replay protection to the NHDP protocol
and the OLSRv2 protocol. These protocols use the TLV format defined in RFC
5444. This draft specifies the use of the ICV and TIMESTAMP TLVs (both defined
in draft-ietf-manet-rfc6622-bis), the former for integrity protection, and the
latter for replay protection.

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.

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.

On to the security considerations section:
This section is generally well-written, although it might have been clearer to
write the limitations along with the list of alleviated attacks. The section
does cover the dependency on clock synchronization, the limited time in which
replay is possible, the vulnerability to other routers who possess the same
shared key, and the reliance on another key distribution and key revocation
mechanism.

About the general writing:
This document contains some examples of sloppy language:
- Figure 1 shows messages being processed by "this specification".
Specifications don't process messages. Hardware or software components do. -
Section 3 says that "[RFC6130] and [OLSRv2] enable extensions to recognize…".
Extensions don't recognize, they're just a string of bytes. Implementations
recognize things. - Section 4 says something about "messages owned by [RFC6130]
and [OLSRv2]". Again, RFCs define messages, they don't own them. - TC is used
multiple times, but never expanded.

Yoav