Skip to main content

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

Request Review of draft-ietf-manet-nhdp-sec-threats
Requested revision 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 H. 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 revision 03 (document currently at 06)
Result Has Nits
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

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

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

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).