Security Threats for the Neighborhood Discovery Protocol (NHDP)
RFC 7186

Note: This ballot was opened for revision 04 and is now closed.

(Jari Arkko) Yes

(Stewart Bryant) Yes

Comment (2013-06-10 for -04)
No email
send info
It would be helpful to the RFCeditor to do an unexpanded abbreviation scrub before the draft is sent to them.

(Adrian Farrel) Yes

(Sean Turner) (was Discuss) Yes

(Richard Barnes) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2013-06-13 for -05)
No email
send info
thanks for addressing my DISCUSS

(Spencer Dawkins) No Objection

Comment (2013-06-07 for -04)
No email
send info
I did have one comment, for your consideration.

I'm not an expert on MANET, of course, but most of the threat descriptions were clear enough that I could explain them to someone else if necessary. In 5.1.  MPR Calculation

   MPR selection (as used in e.g., [I-D.ietf-manet-olsrv2] and
   [RFC6621]) uses information about a router's 1-hop and 2-hop
   neighborhood, assuming that (i) this information is accurate, and
   (ii) all 1-hop neighbors are apt to act as as MPR, depending on the
   willingness they report.  Thus, a Compromised NHDP router will seek
   to manipulate the 1-hop and 2-hop neighborhood information in a
   router such as to cause the MPR selection to fail, leading to a
   flooding disruption of TC messages.

I didn't understand the threat except in the most general terms, and I think the problem is that "manipulate the information so that MPR selection fails" wasn't helpful for me. If it's possible to give an example ("if the Compromised NHDP router doesn't propagate the framitz field"), I suspect this section would be as clear as the rest of the very readable draft.

(Stephen Farrell) No Objection

Comment (2013-06-11 for -05)
No email
send info
I like that you've done this and have just a few comments
and some nits:

- "Attacker" definition - are you excluding nodes that are
on the Internet when the MANET is conncected to the
Internet? If so, I think you need to say so. And that might
be fine, but did you think about attacks from the Internet?
If you didn't think about those, why is that ok? (I assume
when you say "present in the network" you mean "in the
MANET" btw.)

- (A related question that demonstrates my ignorance of
multicast:-) is there any way to inject traffic from
outside into a MANET that will then appear to be NHDP
messages sent to a link local multicast address? E.g. if
some PIM service or something were also being run on the
MANET? (I've no clue myself, but if there were then that'd
be a new attack vector that some MANETs ought worry about I
think.)

- section 5: isn't causing lots of traffic to be directed
to a battery powered device so as to drain its battery an
attack here? I'd say that's worth a mention somewhere.
(Actually the word "power" doesn't occur at all, and that
seems wrong.)

Most of the rest are just nits, but here they are anyway:

- section 1, 2nd para: The last sentence seems to be
missing something - who or what is suggesting that "this"
(what this?) be addressed? I don't get it anyway.

- s1, last para: "attacks on and mis-configurations of
NHDP" would be better (if that's what you mean which I
think it is).  

- A compromised NHDP router could send malformed packets in
an attempt to get a buffer overrun or other similar attack.
I don't know if there are any NHDP packets such that
implementations are likely to have problems like this, but
if there were then maybe a warning would be good.

- References: I know there's a good bit of academic
literature on MANET security so I wondered if some more
pointers to good papers would be a worthwhile addition.
(I'm sure the authors know far better than I do what'd be
good to include.)

- The authors suggested a couple of changes [1] based on
the secdir review that look worthwhile.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04007.html

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-06-08 for -04)
No email
send info
This seems to be a fine document, thanks.

I have just one, small comment: there's an RFC 2119 reference, and 2119 boilerplate in Section 2.  But there are no 2119 key words in the document.  You should remove the boilerplate and reference.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection