Security Threats for the Neighborhood Discovery Protocol (NHDP)
RFC 7186
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Jari Arkko; former steering group member) Yes
(Sean Turner; former steering group member) (was Discuss) Yes
(Stewart Bryant; former steering group member) Yes
It would be helpful to the RFCeditor to do an unexpanded abbreviation scrub before the draft is sent to them.
(Barry Leiba; former steering group member) No Objection
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.
(Benoît Claise; former steering group member) (was Discuss) No Objection
thanks for addressing my DISCUSS
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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; former steering group member) No Objection
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