Skip to main content

Last Call Review of draft-ietf-manet-nhdp-
review-ietf-manet-nhdp-secdir-lc-emery-2010-03-19-00

Request Review of draft-ietf-manet-nhdp
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-03-19
Requested 2010-03-06
Authors Thomas H. Clausen , Christopher Dearlove , Justin Dean
I-D last updated 2010-03-19
Completed reviews Secdir Early review of -?? by Shawn M Emery
Secdir Last Call review of -?? by Shawn M Emery
Assignment Reviewer Shawn M Emery
State Completed
Request Last Call review on draft-ietf-manet-nhdp by Security Area Directorate Assigned
Completed 2010-03-19
review-ietf-manet-nhdp-secdir-lc-emery-2010-03-19-00
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 draft describes a protocol for a one-hop and a symmetric two-hop
neighborhood discovery for mobile ad hoc networks (MANETs).

The security considerations section does exist and discusses the various
attack scenarios.  The first being HELLO messages that are correctly
formatted, but malicious.  Preventing this scenario can be handled in
different ways depending on the constraints in which the protocol is
deployed; physical or proximity access, link-layer authentication,
integrity checks, and confidentiality.

Then the section suggests how to protect HELLO messages for this
protocol by using the same mechanisms that RFC5444 outlines.  For
integrity; using signatures in Message TLV or Packet TLVs.  For privacy;
using link-layer protection, IPsec, or encrypting the Value field and
specifying the encrypted TLV type for the associated message.  It might
be helpful if they state something like this instead of just referring
to 5444 for confidentiality.  Other than this, I believe that the
section covers the possible issues and their respective solution.

General comments:

None.

Editorial comments:

5.5. Parameter Change Constraints

The first occurrence of L_time and NL_time should have their
corresponding definition.


9.2. Removing an Interface

s/router will longer participate/router will no longer participate/


9.3. Adding a Network Address to an Interface

s/network address is removed/network address, is removed/

--
Shawn.