Early Review of draft-ietf-manet-nhdp-sec-threats-03

Request Review of draft-ietf-manet-nhdp-sec-threats
Requested rev. no specific revision (document currently at 06)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2013-06-11
Requested 2013-05-20
Authors Jiazi Yi, Ulrich Herberg, Thomas Clausen
Draft last updated 2013-06-13
Completed reviews Genart Last Call review of -03 by Wassim Haddad (diff)
Genart Telechat review of -04 by Wassim Haddad (diff)
Secdir Early review of -03 by Matt Lepinski (diff)
Assignment Reviewer Matt Lepinski
State Completed
Review review-ietf-manet-nhdp-sec-threats-03-secdir-early-lepinski-2013-06-13
Reviewed rev. 03 (document currently at 06)
Review result Has Nits
Review completed: 2013-06-13


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 provides a taxonomy of attacks against the Mobile Ad Hoc Network Neighborhood Discovery Protocol (NHDP) [RFC 6130]. The document also contains a discussion of the impact of these attacks on running on top of NHDP (in particular, 

OLSRv2 and SMF)

Having reviewed the document, I do not see substantial issues in the document. I believe it is reasonable to publish as an informational RFC.

One minor issue:

 The replay attack described in Section 4.5 did not seem substantially different than the attacks described in Section 4.4. It is not clear to me how replaying a message from another part of the network is any worse (or substantially different) than just fabricating a message claiming connectivity that does not exist (i.e., like what is described in 4.4.2). I would recommend either deleting 4.5 or else clarifying how these attacks are substantially different.

Trivial nit:

 In Section 5, "

a Compromised NHDP router will seek to manipulate" -- substitute "may seek" instead of "will seek". We don't know for certain what a compromised router will do (unless one assigns clear 


 to the adversary, which this document does not).