Subject: Re: [manet] NHDP-sec-threats feedback

From: Teco Boot <[email-masked]>
Date: Fri, 10 Aug 2012 16:35:52 +0200

Op 31 jul. 2012, om 03:17 heeft Jiazi YI het volgende geschreven:

> No problem, Joe. 
> Actually, there is no update since the last IETF in Paris, so just a few words to be added:
> 
> The main comment from the last IETF meeting is regarding the scope of this document. We have explained our approach/consideration  in a previous mail (http://www.ietf.org/mail-archive/web/manet/current/msg12897.html ), and there is no objection of that. 
> 
> Therefore, we would like ask for WGLC, and comments from the working group. 

Here some feedback.

Overall:
I miss a description on what mode we are running in, e.g. closed network (some security in sub-IP), or attackers within the network, with or without access to any key material.

Also, I have often concerns on how well (or bad) security procedures are forfilled . With a little experience, I came to the conclusion that only the most easy to implement procedures provides somewhat protection. In other words: complex security mechanisms is a threat on its own.

Personal opinion: Why not change all plain text NHDP to crypto text [RFC6130]? 
(better use plain text :-)

> 4.1.  Jamming
> 
>   One vulnerability, common for all protocols operating a wireless ad
>   hoc network, is that of "jamming", i.e., that a device generates
>   massive amounts of interfering radio transmissions, which will
>   prevent legitimate traffic (e.g.,control traffic as well as data
>   traffic) on part of a network.
> 
>   Depending on lower layers, this may not affect transmissions: HELLO
>   messages from an NHDP router with "jammed" interfaces may be received
>   by other NHDP routers.  
Is it "this may or may not affect transmissions"?
With CSMA, Tx is blocked.

It is not the interfaces that are jammed. The carrier is jammed.

> As [RFC6130] identifies and uses only bi-
>   directional links,
???
It uses the transmission channel (either uni or bi-directional to detect if links are bi-directional.

> a link from a jammed NHDP router to a non-jammed
>   NHDP router
Again, the carrier is jammed, not the routers.
Although hammers can be used to trash routers. This is a real world threat too.

> would not be considered, and the jammed NHDP router
>   appear simply as "disconnected" for the un-jammed part of the network
>   - which is able to maintain accurate topology maps.
In general, jamming results in an increase of the noise level. This leads to a large effect on link quality. The effect is very similar to other blocking factors, like too long range or obstacles. So for NHDP, it is nothing special.

> 
>   If, due to a jamming attack, a considerable amount of HELLO messages
>   are lost or corrupted due to collisions, neighbor NHDP routers are
>   not able to establish links between them any more.  Thus, NHDP will
>   present empty information bases to the protocols using it.
So jamming does not introduce a specific threat on NHDP.

I suggest removing the RF jamming threat out of this document. It has little to do with NHDP.
Or why not mention EMP bombs? Or more natural threats, like what water can do with electronics?

What can be included: injecting massive amount of hello messages, which fills the carrier, affects CPU/memory, gets batteries low etc.

> 
> 4.2.  Eavesdropping
> 
>   Eavesdropping is a common and easy passive attack in a wireless
>   environment.  Once a packet is transmitted, any adjacent NHDP router
>   can potentially obtain a copy, for immediate or later processing.
Eavesdropping by itself is not a threat on the NHDP protocol. 

One may have problems with leakage of topology information

>   Neither the source nor the intended destination can detect this.  A
>   malicious NHDP router
(attacker, not malicious NHDP router)

> can eavesdrop on the NHDP message exchange and
>   thus learn the local topology.  It may also eavesdrop on data traffic
>   to learn source and destination addresses of data packets, or other
>   header information, as well as the packet payload.

> 
>   Eavesdropping does not pose a direct threat to the network nor to
>   NHDP, in as much as that it does not alter the information recorded
>   by NHDP in its information bases and presented to other protocols
>   using it, but it can provide network information required for
>   enabling other attacks, such as the identity of communicating NHDP
>   routers, link characteristic, NHDP router configuration, etc.
So eavesdropping has little to do with threats to NHDP.

I suggest removing this topic. Or add "Concerns on confidentiality and privacy".

> 4.3.  Incorrect HELLO Message Generation
> 
>   An NHDP router running [RFC6130] performs two distinct tasks: it
>   periodically generates HELLO messages, and it processes incoming
>   HELLO messages from neighbor NHDP routers.  This section describes
>   security attacks involving the HELLO generation.
I don't think there is a threat on message generation, other than bugs.
I think the focus should be on threats on non-compromised nodes, processing incoming malicious NHDP messages, sent by attacker.

> 4.3.1.  Identity Spoofing
> 
>   Identity spoofing implies that a Compromised NHDP router sends HELLO
>   messages, pretending to have the identity of another NHDP router.  A
>   Compromised NHDP router can accomplish this by using another NHDP
>   router's IP address in an address block of a HELLO message, and
>   associating this address with a LOCAL_IF Address Block TLV.
Spoofing can be done with any IP address, which does not "belong" to the sender. 

> 
>   An NHDP router receiving the HELLO message from a neighbor, will
>   assume that it originated from the NHDP router with the spoofed
>   interface address.  As a consequence, it will add a Link Tuple to
>   that neighbor with the spoofed address, and include it in its next
>   HELLO messages as a heard neighbor (and possibly as symmetric
>   neighbor after another HELLO exchange).
> 
>   Identity spoofing is particular harmful if a Compromised NHDP router
>   spoofs the identity of another NHDP router that exists in the same
>   routing domain.  With respect to NHDP, such a duplicated, spoofed
>   address can lead to an inconsistent state up to two hops from an NHDP
>   router.  Figure 1 depicts a simple example.  In that example, NHDP
>   router A is in radio range of C, but not of the Compromised NHDP
>   router X. If X spoofs the address of A, that can lead to conflicts
>   for upper-layer routing protocols,
What are upper-layer routing protocols? We are in the IP layer, I think.

> and therefore for wrong path
>   calculations as well as incorrect data traffic forwarding.
Could be, but this get not clear in this example.
Isn't this link spoofing?

> 
>                          .---.    .---.    .---.
>                          | A |----| C |----| X |
>                          '---'    '---'    '---'
> 
>                                 Figure 1
> 
>   Figure 2 depicts another example.  In this example, A is two hops
>   away from NHDP router C, reachable through NHDP router B.  If the
>   Compromised NHDP router X spoofs the address of A, C may think that A
>   is indeed reachable through NHDP router D.
Router D is affected first. After link is verified as bi-directional, C is affected.

>                 .---.    .---.    .---.    .---.    .---.
>                 | A |----| B |----| C |----| D |----| X |
>                 '---'    '---'    '---'    '---'    '---'
> 
>                                 Figure 2
> 
> 4.3.2.  Link Spoofing
> 
>   Similar to identity spoofing, link spoofing implies that a
>   Compromised NHDP router sends HELLO messages, signaling an incorrect
>   set of neighbors.  This may take either of two forms:
> 
>   o  A Compromised NHDP Router can postulate addresses of non-present
>      neighbor NHDP routers in an address block of a HELLO, associated
>      with LINK_STATUS TLVs.
> 
>   o  A Compromised NHDP router can "ignore" otherwise existing
>      neighbors by not advertising them in its HELLO messages.
I can't see why this is forbidden. I don't say "it is nice behavior".

> 
>   The effect of link spoofing with respect to NHDP are twofold,
>   depending on the two cases mentioned above: If the Compromised NHDP
>   router ignores existing neighbors in its advertisements, links will
>   be missing in the information bases maintained by other routers, and
>   there may not be any connectivity to or from these NHDP routers to
>   others NHDP routers in the MANET.
Yes. But why forward packets via a compromised router anyway?

> If, on the other hand, the
>   Compromised NHDP router advertises non-existing links, this will lead
>   to inclusion of topological information in the information base,
>   describing non-existing links in the network (which, then, may be
>   used by other protocols using NHDP in place of other, existing,
>   links).
Exactly. The effect would be black holes.

> 
> 4.4.  Replay Attack
> 
>   A replay attack implies that control traffic from one region of the
>   network is recorded and replayed in a different region (this type of
>   attack is also known as the Wormhole attack).
Replay Attack could also be: same place, replayed later in time. Or even directly in time.
Isn't wormhole: (almost) same time, different place?

> This may, for example,
>   happen when two Compromised NHDP routers collaborate on an attack,
>   one recording traffic in its proximity and tunneling it to the other
>   Compromised NHDP router, which replays the traffic.  In a protocol
>   where links are discovered by testing reception, this will result in
>   extraneous link creation (basically, a "virtual link between the two
>   Compromised NHDP routers will appear in the information bases of
>   neighboring NHDP routers).
The packet capture, transfer and inject must be two-way before it has a practical affect.

> 
>   While this situation may result from an attack, it may also be
>   intentional: if data-traffic also is relayed over the "virtual" link,
>   the link being detected is indeed valid for use.  This is, for
>   instance, used in wireless repeaters.  If data traffic is not carried
>   over the virtual link, an imaginary, useless, link between the two
>   Compromised NHDP routers, has been advertised, and is being recorded
>   in the information bases of their neighboring NHDP routers.
Exactly. It is not the repeater characteristic what matters, but the filters in forwarding.

> 
>   Replay attacks can be especially damaging if coupled with spoofing
>   and tampering with sequence numbers in the replayed messages,
>   potentially destroying some important topology information in NHDP
>   routers all over the network, as described in Section 4.5.
I don't see why replay is more damaging than false packet injection.

The difference is that replay attacks need additional protection mechanisms (more than just signing).

> 
> 4.6.  Message Timing Attacks
> 
>   In [RFC6130], each HELLO message contains a "validity time" and may
>   contain an "interval time" field, identifying the time for which
>   information in that control message should be considered valid until
>   discarded, and the time until the next control message of the same
>   type should be expected [RFC5497].
> 
> 4.6.1.  Interval Time Attack
> 
>   A use of the expected interval between two successive HELLO messages
>   is for determining the link quality in [RFC6130]: if messages are not
>   received within the expected intervals (e.g., a certain fraction of
>   messages are missing), then this may be used to exclude a link from
>   being considered as useful, even if (some) bi-directional
>   communication has been verified.  If a Compromised NHDP router X
>   spoofs the identity of an existing NHDP router A, and sends HELLOs
>   indicating a low interval time, an NHDP router B receiving this HELLO
>   will expect the following HELLO to arrive within the interval time
>   indicated - or otherwise, decrease the link quality for the link A-B.
>   Thus, X may cause NHDP router B's estimate of the link quality for
>   the link A-B to fall below the limit, where it is no longer
>   considered as useful and, thus, not used.
This needs spoofing, I think. Why would an attacker take such a difficult approach? It can declare the links as unusable directly.

> 
> 4.6.2.  Validity Time Attack
> 
>   A Compromised NHDP router X can spoof the identity of an NHDP router
>   A and send a HELLO using a low validity time (e.g.,1 ms).  A
>   receiving NHDP router B will discard the information upon expiration
>   of that interval, i.e., a link between NHDP router A and B will be
>   "torn down" by X.

(more general comment) I think the attacker can create messages, or capture & replay. On the created messages, it can inject whatever. I'm not sure the listed options are complete. Why such an in detail description? At least, I would include a "any other false message" section.

> 
> 4.7.  Indirect Jamming
> 
>   Indirect jamming is when a Compromised NHDP router X by its actions
>   causes other legitimate NHDP routers to generate inordinate amounts
>   of control traffic.  This increases channel occupation, and the
>   overhead in each receiving NHDP router processing this control
>   traffic.  With this traffic originating from Legitimate NHDP routers,
>   the malicious device may remain undetected to the wider network.
Yes, it may or may not be detected. I miss the message here :-)

> 
>   Figure 3 illustrates indirect jamming of [RFC6130].  A Compromised
>   NHDP router X advertises a symmetric spoofed link to the non-existing
>   NHDP router B (at time t0).  Router A selects X as MPR upon reception
>   of the HELLO, and will trigger a HELLO at t1.  Overhearing this
>   triggered HELLO, the attacker sends another HELLO at t2, advertising
>   the link to B as lost, which leads to NHDP router A deselecting the
>   attacker as MPR, and another triggered message at t3.  The cycle may
>   be repeated, alternating advertising the link X-B as LOST and SYM.
> 
>                             MPRs(X)                   MPRs()
>                .---.        .---.        .---.        .---.
>                | A |        | A |        | A |        | A |
>                '---'        '---'        '---'        '---'
>                  |            |            |            |
>                  | SYM(B)     |            | LOST(B)    |
>                  |            |            |            |
>                .---.        .---.        .---.        .---.
>                | X |        | X |        | X |        | X |
>                '---'        '---'        '---'        '---'
>                  .            .
>                  .            .
>                  .            .
>                .....        .....
>                . B .        . B .
>                .....        .....
> 
>                 t0           t1           t2           t3
> 
>                                 Figure 3

I don't get why the channel would be occupied.

When the attacker spoofs many identities and set up links with extreme long validity time, the hello messages from affected routers would increase to huge sizes. In a somewhat dense network, this can easily overload the network.
Similar approach for TC messages and flooding.

> 
> 5.  Impact of inconsistent Information Bases on Protocols using NHDP
> 
>   This section describes the impact on protocols, using NHDP, of NHDP
>   failing to obtain and represent accurate information, possibly as a
>   consequence of the attacks described in Section 4.  This description
>   emphasizes the impacts on the MANET protocols OLSRv2 [OLSRv2], and
>   SMF [SMF].
> 
> 5.1.  MPR Calculation
MPR calculation and flooding is not a task of NHDP.

> 5.1.3.  Broadcast Storm
I use broadcast storm for a very different problem (STP problems).

> 5.2.  Routing Loops
Set up routes is not a task of NHDP.

> 
> 5.3.  Invalid or Non-Existing Paths to Destinations
Set up routes is not a task of NHDP.

> 5.4.  Data Sinkhole
Set up routes is not a task of NHDP.

Teco

> 
> best
> 
> Jiazi Yi
> 
> http://www.jiaziyi.com
> LIX, Ecole Polytechnique
> Route de Saclay 91128 Palaiseau Cedex France
> 
> On Jul 30, 2012, at 5:09 PM, Joseph Macker <[email-masked]> wrote:
> 
>> I apologize to Jiazi and co-authors as we accidentally skipped one of the slide sets at this afternoon's meeting.
>> 
>> Please review the slides for NHDP-sec-threats located at http://tools.ietf.org/wg/manet/agenda
>> and see draft-ietf-manet-nhdp-sec-threats-00
>> 
>> The authors are asking for consideration of WG LAST CALL on this document so please comment.
>> 
>> -Joe
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 13 Aug 2012 09:12:26 +0000

> Personal opinion: Why not change all plain text NHDP to crypto text [RFC6130]? 

Pre-shared single secret key for all? Or what?

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Teco Boot <[email-masked]>
Date: Tue, 14 Aug 2012 07:01:51 +0200

> Pre-shared single secret key for all? Or what?
Be reader friendly, use "NHDP", not "[RFC6130]". 

Teco

---

From: Jiazi YI <[email-masked]>
Date: Tue, 28 Aug 2012 12:30:39 +0200

Dear Teco,

Thanks for your detailed comments. Please check the reply inline:

> Also, I have often concerns on how well (or bad) security procedures are forfilled . With a little experience, I came to the conclusion that only the most easy to implement procedures provides some…

This nhdp-sec-threat document is based on the assumption that no extra security mechanism is applied in the IP layer. 

> (better use plain text :-)

Yes, we need to be consistent through the document. We can use 

The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers
   to acquire topological information ...

at the beginning, and then NHDP afterwards, for reader-friendly. 

> With CSMA, Tx is blocked.

The original sentence in the draft is correct. Depending on the L2, only reception may be affected, not necessarily transmission. 
We are going to make the text more clear in the next revision.

> It is not the interfaces that are jammed. The carrier is jammed.

Yes

> It uses the transmission channel (either uni or bi-directional to detect if links are bi-directional.

We agree that it's not very clear here. Maybe change it to:

As [RFC6130] identifies whether a link to a neighbor is uni-directional or bi-directional, a routing protocol that uses NHDP for neighborhood discovery may ignore a link from a jammed NHDP router to a non-jammed NHDP router.
The jammed router would appear simply as "disconnected" for the un-jammed part of the network - which is able to maintain accurate topology maps. 

> Again, the carrier is jammed, not the routers.

Yes

> What can be included: injecting massive amount of hello messages, which fills the carrier, affects CPU/memory, gets batteries low etc.

We agree that jamming is not a particular threat to NHDP. It can be handled by the detection of unidirectional links. 
The authors are going to have further discussion on this section. 

> I suggest removing this topic. Or add "Concerns on confidentiality and privacy".

Maybe I didn't get your point very well here. 
Although it doesn't have *direct* threat to the network, eavesdropping is an important vector of topology information leakage. In most of the literatures, it's kind of attack/threat. 
In fact, in RFC 3532 Guidelines for Writing RFC Text on Security Considerations, it says: 
 At least the following forms of attack MUST be considered:
   *eavesdropping*, replay, message insertion, deletion, modification, and
   man-in-the-middle. 

> I think the focus should be on threats on non-compromised nodes, processing incoming malicious NHDP messages, sent by attacker.

What we are trying to say is generation of *incorrect* HELLO message, rather than incorrect generation. Maybe change it to Generation of Malicious HELLO message can be more consistent with other parts of the draft, and more clear. 
Furthermore, we actually think incorrect generation of HELLO by non-compromised routers (for example, because of mis-configuration), can be a potential threat to the network. This has been addressed in our previous reply to John Dowdell, which can be discussed in a different section. 

> Spoofing can be done with any IP address, which does not "belong" to the sender. 

Agree. 

> What are upper-layer routing protocols? We are in the IP layer, I think.

The routing protocol that uses NHDP. We will be more precise here. 

> Isn't this link spoofing?

X is spoofing the identify of A, so it's identity spoofing. 

> Router D is affected first. After link is verified as bi-directional, C is affected.

Yes.

> Yes. But why forward packets via a compromised router anyway?

Agree. 

> Isn't wormhole: (almost) same time, different place?

We mentioned in the parenthesis that it is also known as Wormhole attack. 
And we agree with you that just using the word wormhole attack is more clear here.  

> The packet capture, transfer and inject must be two-way before it has a practical affect.

That depends on the kind of traffic (e.g. UDP without application layer ACK or response).

> The difference is that replay attacks need additional protection mechanisms (more than just signing).

I think you already give a good reason why it's more damaging :-P

> This needs spoofing, I think. Why would an attacker take such a difficult approach? It can declare the links as unusable directly.

Yes, but sometimes more sophisticated attacks are more difficult to detect. We don't make a judgement which is the best way to attack, just try to be exhaustive on different attacks.

> (more general comment) I think the attacker can create messages, or capture & replay. On the created messages, it can inject whatever. I'm not sure the listed options are complete. Why such an in d…

We agree that the routers can declare the links as unusable directly. 
One of the considerations here is the misconfiguration of certain routers. We will make it more clear here. 

> Similar approach for TC messages and flooding.

This example is not related to message size. 
The Compromised router keep advertising different topology information can have two possible results: increase the HELLO message generation frequency, and additional resources for route calculation. 

> MPR calculation and flooding is not a task of NHDP.

yes, that's why this section has the title "Impact of inconsistent Information Bases on Protocols using NHDP". While MPR calculation and flooding is not a task of NHDP, attacks on NHDP may have a severe impact on protocols using it. 

> Set up routes is not a task of NHDP.

This section is related to the scope of this document, which we have been mentioned in a previous mail: http://www.ietf.org/mail-archive/web/manet/current/msg12897.html

**
The current revision of the document also includes a section for the impacts on protocols using NHDP. The rationale is that, as a neighbor discovery protocol, NHDP is used in combination with other protocols most of the time. Therefore, the document describes how the those protocols might be disrupted by the misbehavior of NHDP (in common sense, such as MPR calculation, data sinkhole, etc. ). If we are going to produce more threats documents in the future, there is no need to worry about those common ones in NHDP (for example, we probably don't want to discuss the threats in MPR selection in both SMF-threats and OLSRv2-threats). 
**

best

Jiazi and Ulrich