Security Threats for the Neighborhood Discovery Protocol (NHDP)
draft-ietf-manet-nhdp-sec-threats-06

[Ballot discuss]
Thanks for this well written draft.  Just want to discuss a couple of things:

0) In s3, it seems like the scope is set to just an attacker using NHDP messages to cause havoc.  Is there a concern about deliberate exposure?  That is an attacker gains control of a device and just starts blasting the routing information off to its friends?  If so/not I think maybe just a sentence in s3 could address this.

1) cleared

2) Any concerns about traffic analysis (i.e., who is talking to who)?  Or, is that lumped in with eavesdropping?  The two are slightly different in that for traffic analysis the attacker can deduce information even if encryption is applied.

[Ballot discuss]
An easy-to-fix DISCUSS.

Please insert two references to the NHDP MIB.
1. To the Security Considerations, https://tools.ietf.org/html/rfc6779#section-8, which contains extra security threats. Sometimes the threat could come from the NMS. No need to repeat the information. A since pointer is enough.

2. To the MIB module specified in [RFC 6779], which would help monitoring some of those security attacks with the 3 notifications and with OID polling.
An single sentence, similar to the following one, would be enough:

    [I-D.ietf-manet-nhdp-olsrv2-sec] provides further information on how to enable integrity protection to NHDP, which can help mitigating the threats described related to identity spoofing.

Note that, there are some more constraints in a MANET network (the NMS might not be available to receive those SNMP notifications), so you might have to also include a reference to https://datatracker.ietf.org/doc/draft-nguyen-manet-management/ that contains some more considerations.

[Ballot discuss]
Thanks for this well written draft.  Just want to discuss a couple of things:

0) In s3, it seems like the scope is set to just an attacker using NHDP messages to cause havoc.  Is there a concern about deliberate exposure?  That is an attacker gains control of a device and just starts blasting the routing information off to its friends?  If so/not I think maybe just a sentence in s3 could address this.

1) In s4.4, identity and link spoofing is discussed.  Is there any concern that the spoofers will somehow inject themselves in order to redirect traffic so that they can then eavesdrop?  I see there's something in s4.5 about recording the traffic and then having another replay it but it's not quite the same thing.

2) Any concerns about traffic analysis (i.e., who is talking to who)?  Or, is that lumped in with eavesdropping?  The two are slightly different in that for traffic analysis the attacker can deduce information even if encryption is applied.

[Ballot comment]
And now for some comments:

0) I always go back to RFC 4593.  Curious if the routing community does?  Not asking for wholesale changes just a nod or two to 4593:

a) s4.1, s4.2, s4.7: I hope I'm not splitting too fine a hair here (i.e., tell me if you think so) but aren't Jamming and DoS Attacks when not carried out to their fullest both forms of Interference?  When carried out of their fullest aren't Jamming and DoS Attacks as well as Indirect Channel Overloading forms of Overloading?

-s4.1:
  Jamming, depending on how jammed the link, is a form of Interference and Overload with threat consequences of Disruption [RFC4593].

-s4.2:
  DoS Attacks are a form of Interference and Overload with threat consequences of Disruption [RFC4593].

-s4.7:
  Indirect Channel Overloading is a form of Interference and Overload with threat consequences of Disruption [RFC4593].

b) s4.2: At the end of the first paragraph:

, so called byzantine routers [RFC4593].

c) s4.3: At the end of the section:

[RFC4593] would categorize the threat consequence as Disclosure.

d) s4.4.1: At the end of the section:

[RFC4593] would categorize the threat consequence as Disclosure and Deception.

e) s4.4.2: Often times spoofing is done for other reasons.  I think s4.4.1 does a good job explaining the impersonation issue, but s4.4.2 seems to be about falsification, i.e., overclaiming. misclaiming, and misstatements (see s4.5 of RFC 4593). Maybe adding the following to 1st sentence:

, sometimes referred to as Falsification [RFC4593].

And then at the end:

[RFC4593] would categorize the threat consequence as Usurpation, Deception, and Disruption.

f) s4.5: At the end of the section:

[RFC4593] would categorize this as a Falsification and Interference threat with a threat consequence of Usurpation, Deception, and Disruption.

g) 4.6.1/4.6.2: At the end of the section:

[RFC4593] would categorize the threat consequence as Usurpation.

1) s4.1: r/between them/between themselves

2) s4.2: I'd add battery to the last paragraph.

3) s4.3: sniffing is kind of synonymous so maybe:

Eavesdropping, sometimes referred to as sniffing, is a common ...

[Ballot comment]
And now for some comments:

1. I always go back to RFC 4593.  Curious if the routing community does?  Not asking for wholesale changes just a nod or two to 4593:

a) s4.1, s4.2, s4.7: I hope I'm not splitting too fine a hair here (i.e., tell me if you think so) but aren't Jamming and DoS Attacks when not carried out to their fullest both forms of Interference?  When carried out of their fullest aren't Jamming and DoS Attacks as well as Indirect Channel Overloading forms of Overloading?

-s4.1:
  Jamming, depending on how jammed the link, is a form of Interference and Overload with threat consequences of Disruption [RFC4593].

-s4.2:
  DoS Attacks are a form of Interference and Overload with threat consequences of Disruption [RFC4593].

-s4.7:
  Indirect Channel Overloading is a form of Interference and Overload with threat consequences of Disruption [RFC4593].

b) s4.2: At the end of the first paragraph:

, so called byzantine routers [RFC4593].

c) s4.3: At the end of the section:

[RFC4593] would categorize the threat consequence as Disclosure.

d) s4.4.1: At the end of the section:

[RFC4593] would categorize the threat consequence as Disclosure and Deception.

e) s4.4.2: Often times spoofing is done for other reasons.  I think s4.4.1 does a good job explaining the impersonation issue, but s4.4.2 seems to be about falsification, i.e., overclaiming. misclaiming, and misstatements (see s4.5 of RFC 4593). Maybe adding the following to 1st sentence:

, sometimes referred to as Falsification [RFC4593].

And then at the end:

[RFC4593] would categorize the threat consequence as Usurpation, Deception, and Disruption.

f) s4.5: At the end of the section:

[RFC4593] would categorize this as a Falsification and Interference threat with a threat consequence of Usurpation, Deception, and Disruption.

g) 4.6.1/4.6.2: At the end of the section:

[RFC4593] would categorize the threat consequence as Usurpation.

2) s4.1: r/between them/between themselves

3) s4.2: I'd add battery to the last paragraph.

4) s4.3: sniffing is kind of synonymous so maybe:

Eavesdropping, sometimes referred to as sniffing, is a common ...

[Ballot discuss]
Thanks for this well written draft.  Just want to discuss a couple of things:

0) In s3, it seems like the scope is set to just an attacker using NHDP messages to cause havoc.  Is there a concern about deliberate exposure?  That is an attacker gains control of a device and just starts blasting the routing information off to its friends?  If so/not I think maybe just a sentence in s3 could address this.

2) In s4.4, identity and link spoofing is discussed.  Is there any concern that the spoofers will somehow inject themselves in order to redirect traffic so that they can then eavesdrop?  I see there's something in s4.5 about recording the traffic and then having another replay it but it's not quite the same thing.

3) Any concerns about traffic analysis (i.e., who is talking to who)?  Or, is that lumped in with eavesdropping?  The two are slightly different in that for traffic analysis the attacker can deduce information even if encryption is applied.

[Ballot comment]
And now for some comments:

1. I always go back to RFC 4593.  Curious if the routing community does?  Not asking for wholesale changes just a nod or two to 4593:

a) s4.1, s4.2, s4.7: I hope I'm not splitting too fine a hair here (i.e., tell me if you think so) but aren't Jamming and DoS Attacks when not carried out to their fullest both forms of Interference?  When carried out of their fullest aren't Jamming and DoS Attacks as well as Indirect Channel Overloading forms of Overloading?

-s4.1:
  Jamming, depending on how jammed the link, is a form of Interference and Overload with threat consequences of Disruption [RFC4593].

-s4.2:
  DoS Attacks are a form of Interference and Overload with threat consequences of Disruption [RFC4593].

-s4.7:
  Indirect Channel Overloading is a form of Interference and Overload with threat consequences of Disruption [RFC4593].

b) s4.2: At the end of the first paragraph:

, so called byzantine routers [RFC4593].

c) s4.3: At the end of the section:

[RFC4593] would categorize the threat consequence as Disclosure.

d) s4.4.1: At the end of the section:

[RFC4593] would categorize the threat consequence as Disclosure and Deception.

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-nhdp-sec-threats-03, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Threats for NHDP) to Informational RFC


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Security Threats for NHDP'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document analyses common security threats of the Neighborhood
  Discovery Protocol (NHDP), and describes their potential impacts on
  MANET routing protocols using NHDP.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review
===
Hi,

Thanks for this document which I found readable and comprehensible.

I have done my usual AD review to find issues and concerns that I think
should be resolved before the document advances to IETF last call and
IESG review.

Since I am not a security weenie^H^H^H^H expert, my comments are sparse.
Therefore I am kicking off IETF last call at once. Please handle my
comments as part of the last call. (I have also sent a heads-up to the
Security ADs that this document definitely needs attention from the
Security Directorate.)

Thanks for the work,
Adrian

---

I know it is not the intent of this document to propose solutions or
mitigations to any of the threats described. However, I think two things
would be useful:

1. Please add a statement of exactly this point to the Abstract and to
  the end of the Introduction.

2. Please consider adding a short section that may drive new work by
  suggesting which threats need to be addressed in new protocol work,
  which in deployment, and which by applications.

---

The assumption stated in the Introduction...
  This document is based on the assumption that no additional security
  mechanism (such as IPsec) is used in the IP layer.
...is perfectly fine. You might add a note to explain why this is a
reasonable assumption (i.e., it is particularly hard to configure
security associations in this type of network) and you might also add a
note about whether none, some, or all of the threats would go away if
this problem could be resolved.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

The type of document is Informational. It provides discussion and
analyses useful for the internet and represents working group
consensus. The document indicates "Information"

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary: This document analyzes common security threats of
the Neighborhood Discovery Protocol (NHDP), and describes their
potential impacts on MANET routing protocols using NHDP.


Working Group Summary: The process for reaching working group
consensus on this was smooth; no controversy existed. Working group
consensus behind the document is solid.


Document Quality This document does not specify a protocol, therefore
no implementations are available. There are several NHDP
implementations existing, and the WG has a thorough understanding of
the protocol and its security considerations.

Personnel

Joseph Macker (joseph.macker@nrl.navy.mil) is the document shepherd
for this document. Adrian Farrel (adrian@olddog.co.uk) is the
responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has personally reviewed the document, and believes it is
ready for forwarding to the IESG for publication. The shepherd has
also run the id-nits tools.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document has had adequate review from both key working group
members and from key non-WG members. The shepherd does not have any
concerns about the depth or breadth of the reviews that have been
performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The shepherd does not have any concerns about the document needing
additional review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR disclosures were not necessary, therefore, none have been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Working group consensus behind this document is solid. The document
represents rough consensus of the working group as a whole, the
document passed WGLC with minimal comments and consensus to move
forward with publication.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Working group consensus behind this document is solid. There have a
few minor complaints that we do not believe represent consensus
opinion.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as
either normative or informative?

The document has split its references into normative and informative

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


The shepherd has verified that document IANA consideration section
exists, and is consistent with the body of the document. No actions
for IANA have been requested.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None required.

The WGLC was announced to the WG list on Feb 22, 2013.

The WG chairs announce a WG Last Call for the nhdp-sec-threats document.  Its intended status is INFORMATIONAL.

The WG Last Call will last two weeks from today until Friday, Mar 8, 2013