Last Call Review of draft-ietf-manet-olsrv2-sec-threats-03
review-ietf-manet-olsrv2-sec-threats-03-secdir-lc-salowey-2016-12-22-00

Request Review of draft-ietf-manet-olsrv2-sec-threats
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-12-20
Requested 2016-12-06
Draft last updated 2016-12-22
Completed reviews Secdir Last Call review of -03 by Joseph Salowey (diff)
Genart Last Call review of -03 by Elwyn Davies (diff)
Opsdir Last Call review of -03 by Victor Kuarsingh (diff)
Assignment Reviewer Joseph Salowey
State Completed
Review review-ietf-manet-olsrv2-sec-threats-03-secdir-lc-salowey-2016-12-22
Reviewed rev. 03 (document currently at 04)
Review result Has Issues
Review completed: 2016-12-22

Review
review-ietf-manet-olsrv2-sec-threats-03-secdir-lc-salowey-2016-12-22

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.

This document is ready with issues.

In general, I think the document does a reasonable job of describing some
of the threats associated with OLSRv2.  There are some places where the
document could be clearer and there are some additional variations threats
the authors may wish to consider.

One issue that I did not see discussed in the draft would be for the
attacker to effectively delay packets.  For example, the attacker captures
packets while jamming to prevent some stations from receiving packets.  The
attacker can collect a sequence of traffic and replay at a later time, with
different timing and in a different location.  Not all replay mechanisms
will defend against this attack int he same way.  Sequence number
validation (which appears to be allowed  in 7183) may not be as effective
as timestamps, depending upon the time skew allowed.  The document does
discuss timestamps , but I think it should probably make the following
clearer:

There are several places in sections 4 and 5 where the document says
something like "This kind of attack can be mitigated using integrity check
mechanisms".  I think in most of these instances replay protection is also
important.  One solution would be to remove these instances and just relay
on section 6.2 which has a better description of the available protections.
  Since it seems that the integrity check could be deployed with just
sequence number instead of timestamps it might be good to mention that it
is important to include and verify timestamps for replay protection.

Thanks,

Joe