diff options
Diffstat (limited to 'doc/rfc/rfc7186.txt')
| -rw-r--r-- | doc/rfc/rfc7186.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc7186.txt b/doc/rfc/rfc7186.txt new file mode 100644 index 0000000..619a33b --- /dev/null +++ b/doc/rfc/rfc7186.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Yi +Request for Comments: 7186 LIX, Ecole Polytechnique +Category: Informational U. Herberg +ISSN: 2070-1721 Fujitsu Laboratories of America + T. Clausen + LIX, Ecole Polytechnique + April 2014 + + + Security Threats for the Neighborhood Discovery Protocol (NHDP) + +Abstract + + This document analyzes common security threats of the Neighborhood + Discovery Protocol (NHDP) and describes their potential impacts on + Mobile Ad Hoc Network (MANET) routing protocols using NHDP. This + document is not intended to propose solutions to the threats + described. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7186. + + + + + + + + + + + + + + + + + +Yi, et al. Informational [Page 1] + +RFC 7186 Security Threats for NHDP April 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . 4 + 4. Detailed Threat Description . . . . . . . . . . . . . . . . . 5 + 4.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. Denial-of-Service Attack . . . . . . . . . . . . . . . . 5 + 4.3. Eavesdropping and Traffic Analysis . . . . . . . . . . . 6 + 4.4. Incorrect HELLO Message Generation . . . . . . . . . . . 7 + 4.4.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 7 + 4.4.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 8 + 4.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 + 4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . 9 + 4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . 10 + 4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . 10 + 4.7. Indirect Channel Overloading . . . . . . . . . . . . . . 10 + 4.8. Attack on Link Quality Update . . . . . . . . . . . . . . 11 + 5. Impact of Inconsistent Information Bases on Protocols using + NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 12 + 5.1.1. Flooding Disruption due to Identity Spoofing . . . . 12 + 5.1.2. Flooding Disruption due to Link Spoofing . . . . . . 13 + 5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 14 + 5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 15 + 5.3. Invalid or Nonexistent Paths to Destinations . . . . . . 16 + 5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 9.2. Informative References . . . . . . . . . . . . . . . . . 18 + + + +Yi, et al. Informational [Page 2] + +RFC 7186 Security Threats for NHDP April 2014 + + +1. Introduction + + The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers + to acquire topological information up to two hops away from + themselves, by way of periodic HELLO message exchanges. The + information acquired by NHDP is used by other protocols, such as the + Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] + and Simplified Multicast Forwarding (SMF) [RFC6621]. The topology + information, acquired by way of NHDP, serves these routing protocols + by detecting and maintaining local 1-hop and 2-hop neighborhood + information. + + As NHDP is typically used in wireless environments, it is potentially + exposed to different kinds of security threats, some of which are of + particular significance as compared to wired networks. As radio + signals can be received as well as transmitted by any compatible + wireless device within radio range, there is commonly no physical + protection as otherwise known for wired networks. NHDP does not + define any explicit security measures for protecting the integrity of + the information it acquires; however, it suggests that the integrity + protection be addressed in a fashion appropriate to the deployment of + the network. + + This document is based on the assumption that no additional security + mechanism such as IPsec is used in the IP layer, as not all MANET + deployments may be able to accommodate such common IP protection + mechanisms (e.g., because of limited resources of MANET routers). + The document analyzes possible attacks on and misconfigurations of + NHDP and outlines the consequences of such attacks/misconfigurations + to the state maintained by NHDP in each router (and, thus, made + available to protocols using this state). + + This document is not intended to propose solutions to the threats + described. [RFC7185] provides further information on how to enable + integrity protection to NHDP, which can help mitigating the threats + described related to identity spoofing. + + It should be noted that many NHDP implementations are configurable, + and so an attack on the configuration system (such as [RFC6779]) can + be used to adversely affect the operation of an NHDP implementation. + + The NHDP MIB module [RFC6779] might help monitoring some of the + security attacks mentioned in this document. [MGMT-SNAP] provides a + snapshot of OLSRv2-routed MANET management as currently deployed, + while [MANET-MGMT] is intended to provide specific guidelines on + MANET network management considering the various MIB modules that + have been written. + + + + +Yi, et al. Informational [Page 3] + +RFC 7186 Security Threats for NHDP April 2014 + + +2. Terminology + + This document uses the terminology and notation defined in + "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format" + [RFC5444], "Mobile Ad Hoc Network (MANET) Neighborhood Discovery + Protocol (NHDP)" [RFC6130], and "Internet Security Glossary, Version + 2" [RFC4949]. + + Additionally, this document introduces the following terminology: + + NHDP router: A MANET router, running NHDP as specified in [RFC6130]. + + Attacker: A device that is present in the network and intentionally + seeks to compromise the information bases in NHDP routers. + + Compromised NHDP router: An attacker that is present in the network + and generates syntactically correct NHDP control messages. + Control messages emitted by a compromised NHDP router may contain + additional information, or omit information, as compared to a + control message generated by a non-compromised NHDP router located + in the same topological position in the network. + + Legitimate NHDP router: An NHDP router that is not a compromised + NHDP router. + +3. NHDP Threat Overview + + NHDP defines a HELLO messages exchange, enabling each NHDP router to + acquire topological information describing its 1-hop and 2-hop + neighbors, and specifies information bases for recording this + information. + + An NHDP router periodically transmits HELLO messages using a link- + local multicast on each of its interfaces with a hop-limit of 1 + (i.e., HELLOs are never forwarded). In these HELLO messages, an NHDP + router announces the IP addresses as heard, symmetric, or lost + neighbor interface addresses. + + An Attacker has several ways of harming this neighbor discovery + process: it can announce "wrong" information about its identity, + postulate nonexistent links, and replay HELLO messages. These + attacks are presented in detail in Section 4. + + The different ways of attacking an NHDP deployment may eventually + lead to inconsistent information bases, not accurately reflecting the + correct topology of the MANET. The consequence is that protocols + using NHDP will base their operation on incorrect information, + causing routing protocols to not be able to calculate correct (or + + + +Yi, et al. Informational [Page 4] + +RFC 7186 Security Threats for NHDP April 2014 + + + any) paths, degrade the performance of flooding operations based on + reduced relay sets, etc. These consequences to protocols using NHDP + are described in detail in Section 5. + +4. Detailed Threat Description + + For each threat, a description of the mechanism of the corresponding + attack is given, followed by a description of how the attack affects + NHDP. The impacts from each attack on protocols using NHDP are given + in Section 5. + + For simplicity in the description, the examples given assume that + NHDP routers have a single interface with a single IP address + configured. All the attacks apply, however, for NHDP routers with + multiple interfaces and multiple addresses as well. + +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. Jamming is a form of interference and + overload with the threat consequence of disruption [RFC4593]. + + 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. As NHDP identifies whether a link to a + neighbor is unidirectional or bidirectional, 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 (a router + with jammed carrier) would appear simply as "disconnected" for the + unjammed part of the network, which is able to maintain accurate + topology maps. + + If a considerable amount of HELLO messages are lost or corrupted due + to collisions caused by a jamming attack, neighbor NHDP routers are + not able to establish links between themselves any more. Thus, NHDP + will present empty information bases to the protocols using it. + +4.2. Denial-of-Service Attack + + A denial-of-service (DoS) attack can be a result of misconfiguration + of legitimate NHDP routers (e.g., very short HELLO transmission + interval) or malicious behavior of compromised NHDP routers + [ACCT2012], so-called Byzantine routers [RFC4593]. DoS is a form of + interference and overload with the threat consequence of disruption + [RFC4593]. + + + +Yi, et al. Informational [Page 5] + +RFC 7186 Security Threats for NHDP April 2014 + + + By transmitting a huge amount of HELLO messages in a short period of + time, NHDP routers can increase channel occupation as described in + Section 4.1. Furthermore, a compromised NHDP router can spoof a + large amount of different IP addresses and send HELLOs to its + neighbors to fill their Link/Neighbor Sets. This may result in + memory overflow, and it makes the processing of legitimate HELLO + messages impossible. A compromised NHDP router can also use link + spoofing in its HELLO messages, generating huge 2-hop Sets in + adjacent NHDP routers and therefore potentially a memory overflow. + Moreover, protocols such as SMF and OLSRv2, using the 2-hop + information for multipoint relay (MPR) calculation, may exhaust the + available computational resources of the router if the Neighbor Set + and 2-hop Sets have too many entries. + + By exhausting the memory, CPU, and/or channel resources of a router + in a DoS attack or a misconfiguration, NHDP routers may not be able + to accomplish their specified tasks of exchanging 1-hop and 2-hop + neighborhood information, and thereby disturbing the operation of + routing protocols using NHDP. + + In some MANETs, the routers are powered by battery. Another + consequence of a DoS attack in such networks is that the power will + be drained quickly by unnecessary processing, transmitting, and + receiving of messages. + +4.3. Eavesdropping and Traffic Analysis + + Eavesdropping, sometimes referred to as sniffing, 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. Neither the source nor the + intended destination can detect this. A 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 or 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. + However, eavesdropping can provide network information required for + enabling other attacks, such as the identity of communicating NHDP + routers, detection of link characteristics, and NHDP router + configuration. The compromised NHDP routers may use the obtained + information to launch subsequent attacks, and they may also share + NHDP routing information with other NHDP or non-NHDP entities. + [RFC4593] would categorize the threat consequence as disclosure. + + + + +Yi, et al. Informational [Page 6] + +RFC 7186 Security Threats for NHDP April 2014 + + + Traffic analysis normally follows eavesdropping, which is the process + of intercepting messages in order to deduce information from + communication patterns. It can be performed even when HELLO messages + are encrypted (encryption is not a part of NHDP), for example: + + o Triggered HELLO messages: an attacker could figure out that + messages are triggered and determine that there was a change of + symmetric neighbors of an NHDP router sending the HELLO (as well + get the frequency). + + o Message size: the message grows exactly by x bytes per neighbor. + Depending on which cipher is used for the encryption, some + information about the size could be inferred, and thus the number + of neighbors could be guessed. + + [RFC4593] would categorize the threat consequence as disclosure. + +4.4. Incorrect HELLO Message Generation + + An NHDP router 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. + +4.4.1. Identity Spoofing + + Identity spoofing implies that a compromised NHDP router sends HELLO + messages, pretending to have the identity of another NHDP router, or + even a router that does not exist in the networks. A compromised + NHDP router can accomplish this by using an IP address, which is not + its own, in an address block of a HELLO message, and associating this + address with a LOCAL_IF Address Block TLV [IJNSIA2010]. + + An NHDP router receiving that 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 a symmetric + neighbor after another HELLO exchange). + + Identity spoofing is particularly 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. [RFC4593] would categorize the threat consequences + as disclosure and deception. + + + + + +Yi, et al. Informational [Page 7] + +RFC 7186 Security Threats for NHDP April 2014 + + + Figure 1 depicts a simple example. In that example, NHDP router A is + in radio range of NHDP router C, but not of the compromised NHDP + router X. If X spoofs the address of A, that can lead to conflicts + for a routing protocol that uses NHDP, and therefore for wrong path + calculations as well as incorrect data traffic forwarding. + + .---. .---. .---. + | A |----| C |----| X | + '---' '---' '---' + + Figure 1 + + Figure 2 depicts another example. In this example, NHDP router 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, NHDP router + D will take A as its 1-hop neighbor, and C may think that A is indeed + reachable through D. + + .---. .---. .---. .---. .---. + | A |----| B |----| C |----| D |----| X | + '---' '---' '---' '---' '---' + + Figure 2 + +4.4.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 is sometimes referred to as falsification + [RFC4593], and in NHDP it 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. + + The effect of link spoofing with respect to NHDP are twofold, + depending on the two cases mentioned above: + + o 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 + for these NHDP routers to or from other NHDP routers in the MANET. + + + + + + +Yi, et al. Informational [Page 8] + +RFC 7186 Security Threats for NHDP April 2014 + + + o On the other hand, if the compromised NHDP router advertises + nonexistent links, this will lead to inclusion of topological + information in the information base, describing nonexistent links + in the network (which, then, may be used by other protocols using + NHDP in place of other, existing, links). + + [RFC4593] would categorize the threat consequences as usurpation, + deception, and disruption. + +4.5. Replay Attack + + A replay attack implies that control traffic from one region of the + network is recorded and replayed in a different region at (almost) + the same time, or in the same region at a different time. 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). [RFC4593] would + categorize this as a falsification and interference threat with + threat consequences of usurpation, deception, and disruption. + + While this situation may result from an attack, it may also be + intentional: if data traffic is also 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. + + Compared to incorrect HELLO message attacks described in Section 4.4, + the messages used in replay attacks are legitimate messages sent out + by (non-malicious) NHDP routers and replayed at a later time or + different locality by malicious routers. This makes this kind of + attack harder to be detect and to counteract; integrity checks cannot + help in this case, as the original message's Integrity Check Value + (ICV) was correctly calculated. + +4.6. Message Timing Attacks + + In NHDP, each HELLO message contains a "validity time" (the amount of + time that information in that control message should be considered + valid before being discarded) and may contain an "interval time" + field (the amount of time until the next control message of the same + type should be expected) [RFC5497]. + + + + +Yi, et al. Informational [Page 9] + +RFC 7186 Security Threats for NHDP April 2014 + + +4.6.1. Interval Time Attack + + A use of the expected interval between two successive HELLO messages + is for determining the link quality in NHDP: 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) bidirectional + 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. If that expectation is not met, the link quality for the + link A-B will be decreased. Thus, X may cause NHDP router B's + estimate of the link quality for the link A-B to fall below the + minimum considered useful, so the link would not be used + [CPSCOM2011]. [RFC4593] would categorize the threat consequence as + usurpation. + +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. The sending of a low validity time can be caused + by intended malicious behaviors or simply misconfiguration in the + NHDP routers. [RFC4593] would categorize the threat consequence as + usurpation. + +4.7. Indirect Channel Overloading + + Indirect Channel Overloading 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 that + processes this control traffic. With this traffic originating from + legitimate NHDP routers, the malicious device may remain undetected + in the wider network. It is a form of interference and overload with + the threat consequence of disruption [RFC4593]. + + Figure 3 illustrates Indirect Channel Overloading with NHDP. A + compromised NHDP router X advertises a symmetric spoofed link to the + nonexistent NHDP router B (at time t0). Router A selects X as MPR + upon reception of the HELLO then triggers a HELLO at t1. Overhearing + this triggered HELLO, the attacker sends another HELLO at t2, + advertising the link to B as lost; this causes NHDP router A to + + + + + +Yi, et al. Informational [Page 10] + +RFC 7186 Security Threats for NHDP April 2014 + + + deselect the attacker as MPR, and to send another triggered message + at t3. The cycle may be repeated, where the link X-B is advertised + alternately 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 + +4.8. Attack on Link Quality Update + + According to NHDP [RFC6130]: + + Link quality is a mechanism whereby a router MAY take + considerations other than message exchange into account for + determining when a link is and is not a candidate for being + considered as HEARD or SYMMETRIC. As such, it is a "link + admission" mechanism. + + Section 14.4 of NHDP [RFC6130] then lists several examples of which + information can be used to update link quality. One of the listed + examples uses packet exchanges between neighbor routers (as described + in [RFC5444]), e.g., an NHDP router may update the link quality of a + neighbor based on receipt or loss of packets if they include a + sequential packet sequence number. + + NHDP does not specify how to acquire link quality updates + normatively; however, attack vectors may be introduced if an + implementation chooses to calculate link quality based on packet + sequence numbers. The consequences of such threats would depend on + specific implementations. For example, if the link quality update is + based on a sequential packet sequence number from neighbor routers, a + + + +Yi, et al. Informational [Page 11] + +RFC 7186 Security Threats for NHDP April 2014 + + + compromised NHDP router can spoof packets appearing to be from + another legitimate NHDP router that skips some packet sequence + numbers. The NHDP router receiving the spoofed packets may degrade + the link quality as it appears that several packets have been + dropped. Eventually, the router may remove the neighbor when the + link quality drops below HYST_REJECT. + +5. Impact of Inconsistent Information Bases on Protocols using NHDP + + This section describes the impact on protocols that use NHDP when + NHDP fails 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 + [RFC7181] and SMF [RFC6621]. + +5.1. MPR Calculation + + MPR selection (as used in [RFC7181] and [RFC6621], for example) uses + information about a router's 1-hop and 2-hop neighborhood, assuming + that (i) this information is accurate, and (ii) each 1-hop neighbor + is apt to act as MPR, depending on the willingness it reports. Thus, + a compromised NHDP router may seek to manipulate the 1-hop and 2-hop + neighborhood information in a router so as to cause the MPR selection + to fail, leading to a flooding disruption of traffic control + messages. This can result in incomplete topology advertisement or + can degrade the optimized flooding to classical flooding. + +5.1.1. Flooding Disruption due to Identity Spoofing + + A compromised NHDP router can spoof the identify of other routers in + order to disrupt the MPR selection, so as to prevent certain parts of + the network from receiving flooded traffic [IJNSIA2010]. + + In Figure 4, a compromised NHDP router X spoofs the identity of B. + The link between X and C is correctly detected and listed in X's + HELLOs. Router A will receive HELLOs indicating links from B:{B-E}, + X:{X-C, X-E}, and D:{D-E, D-C}, respectively. For router A, X and D + are equal candidates for MPR selection. To make sure the X can be + selected as MPR for router A, X can set its willingness to the + maximum value. + + + + + + + + + + + +Yi, et al. Informational [Page 12] + +RFC 7186 Security Threats for NHDP April 2014 + + + .---. .---. .---. + | E |----| D |----| C | + '---' '---' '---' + | | . + | | . + .---. .---. .---. + | B |----| A |----| X | + '---' '---' '---' + spoofs B + + Figure 4 + + If B and X (i) accept MPR selection and (ii) forward flooded traffic + as if they were both B, identity spoofing by X is harmless. However, + if X does not forward flooded traffic (i.e., does not accept MPR + selection), its presence entails flooding disruption: selecting B + over D renders C unreachable by flooded traffic. + + .---. + | D | + '---' + | + | + .---. .---. .---. .---. .---. + | X |----| A |----| B |----| C |----| E |... + '---' '---' '---' '---' '---' + spoofs E + + Figure 5 + + In Figure 5, the compromised NHDP router X spoofs the identity of E, + i.e., routers A and C both receive HELLOs from a router identifying + itself as E. For router B, routers A and C present the same neighbor + sets and are equal candidates for MPR selection. If router B selects + only router A as MPR, C will not relay flooded traffic from B or + transiting via B, and router X (and routers to the "right" of it) + will not receive flooded traffic. + +5.1.2. Flooding Disruption due to Link Spoofing + + A compromised NHDP router can also spoof links to other NHDP routers, + thereby making itself appear as the most appealing candidate to be + MPR for its neighbors, possibly to the exclusion of other NHDP + routers in the neighborhood. (In particular, this can occur if the + compromised NHDP router spoofs links to all other NHDP routers in the + neighborhood, plus to one NHDP router outside the neighborhood.) By + thus excluding other legitimate NHDP routers from being selected as + MPR, the compromised NHDP router will receive and be expected to + + + +Yi, et al. Informational [Page 13] + +RFC 7186 Security Threats for NHDP April 2014 + + + relay all flooded traffic (e.g., traffic control messages in OLSRv2 + or data traffic in SMF) that it can then drop or otherwise + manipulate. + + In the network in Figure 6, the compromised NHDP router X spoofs + links to the existing router C, as well as to a fictitious W. Router + A receives HELLOs from X and B, reporting X: {X-C, X-W}, B: {B-C}. + All else being equal, X appears a better choice for MPR than B, as X + appears to cover all neighbors of B, plus W. + + ,---. ..... + | S | . C . + '---' ..... + | . + | . + .---. .---. .---. .---. .---. + | D |----| C |----| B |----| A |----| X | + '---' '---' '---' '---' '---' + . + . + ..... + . W . + ..... + + Figure 6 + + As router A will not select B as MPR, B will not relay flooded + messages received from router A. The NHDP routers on the left of B + (starting with C) will, thus, not receive any flooded messages from + router A or transiting router A (e.g., a message originating from S). + +5.1.3. Broadcast Storm + + A compromised NHDP router may attack the network by attempting to + degrade the performance of optimized flooding algorithms so as to be + equivalent to classic flooding. This can be achieved by forcing an + NHDP router into choosing all its 1-hop neighbors as MPRs. In + MANETs, a broadcast storm caused by classic flooding is a serious + problem that can result in redundancy, contention, and collisions + [MOBICOM99]. + + As shown in Figure 7, the compromised NHDP router X spoofs the + identity of NHDP router B and, spoofs a link to router Y {B-Y} (Y + does not have to exist). By doing so, the legitimate NHDP router A + has to select the legitimate NHDP router B as its MPR in order for it + to reach all its 2-hop neighbors. The compromised NHDP router Y can + + + + + +Yi, et al. Informational [Page 14] + +RFC 7186 Security Threats for NHDP April 2014 + + + perform this identity-and-link spoofing for all of NHDP router A's + 1-hop neighbors, thereby forcing NHDP router A to select all its + neighbors as MPR and disabling the optimization sought by the MPR + mechanism. + + .---. + | B | + '---' + | + | + .---. .---. ..... + | A |----| X | . . . Y . + '---' '---' ..... + spoofs B + + Figure 7 + +5.2. Routing Loops + + Inconsistent information bases, provided by NHDP to other protocols, + can also cause routing loops. In Figure 8, the compromised NHDP + router X spoofs the identity of NHDP router E. NHDP router D has + data traffic to send to NHDP router A. The topology recorded in the + information base of router D indicates that the shortest path to + router A is {D->E->A}, because of the link {A-E} reported by X. + Therefore, the data traffic will be routed to NHDP router E. As the + link {A-E} does not exist in NHDP router E's information bases, it + will identify the next hop for data traffic to NHDP router A as being + NHDP router D. A loop between the NHDP routers D and E is thus + created. + + .---. .---. .---. .---. .---. + | A |----| B |----| C |----| D |----| E | + '---' '---' '---' '---' '---' + | + | + .---. + | X | + '---' + spoofs E + + Figure 8 + + + + + + + + + +Yi, et al. Informational [Page 15] + +RFC 7186 Security Threats for NHDP April 2014 + + +5.3. Invalid or Nonexistent Paths to Destinations + + By reporting inconsistent topology information in NHDP, the invalid + links and routers can be propagated as link state information with + traffic control messages and results in route failure. As + illustrated in Figure 8, if NHDP router B tries to send data packets + to NHDP router E, it will choose router A as its next hop, based on + the information about the nonexistent link {A-E} reported by the + compromised NHDP router X. + +5.4. Data Sinkhole + + With the ability to spoof multiple identities of legitimate NHDP + routers (by eavesdropping, for example), the compromised NHDP router + can represent a "data sinkhole" for its 1-hop and 2-hop neighbors. + Data packets that come across its neighbors may be forwarded to the + compromised NHDP router instead of to the real destination. The + packet can then be dropped, manipulated, duplicated, etc., by the + compromised NHDP router. As shown in Figure 8, if the compromised + NHDP router X spoofs the identity of NHDP router E, all the data + packets to E that cross NHDP routers A and B will be sent to NHDP + router X, instead of to E. + +6. Future Work + + This document does not propose solutions to mitigate the security + threats described in Section 4. However, this section aims at + driving new work by suggesting which threats discussed in Section 4 + could be addressed by deployments or applications. + + o Section 4.1: Jamming - If a single router or a small area of the + MANET is jammed, protocols could be specified that increase link + metrics in NHDP for the jammed links. When a routing protocol + such as OLSRv2 uses NHDP for neighborhood discovery, other paths + leading "around" the jammed area would be preferred, and therefore + would mitigate the threat to some extent. + + o Section 4.2: DoS - A DoS attack using a massive amount of HELLO + messages can be mitigated by admitting only trusted routers to the + network. [RFC7185] specifies a mechanism for adding Integrity + Check Values (ICVs) to HELLO messages and therefore providing an + admittance mechanism for NHDP routers to a MANET. (Note that + adding ICVs creates a new DoS attack vector, as ICV verification + requires CPU and memory resources.) However, using ICVs does not + address the problem of compromised routers. Detecting compromised + routers could be addressed in new work. [RFC7185] mandates + implementation of a security mechanism that is based on shared + keys and makes excluding single compromised routers difficult; + + + +Yi, et al. Informational [Page 16] + +RFC 7186 Security Threats for NHDP April 2014 + + + work could be done to facilitate revocation mechanisms in certain + MANET use cases where routers have sufficient capabilities to + support asymmetric keys. + + o Section 4.3: Eavesdropping - [RFC7185] adds ICVs to HELLO messages + but does not encrypt them. Therefore, eavesdropping of control + traffic is not mitigated. Future work could provide encryption of + control traffic for sensitive MANET topologies. Note that, other + than using a single shared secret key, providing encryption of + traffic among a set of neighbors (when that set is potentially + undetermined) is nontrivial, especially without multiplying + overheads. With traffic analysis, attackers could still deduce + the network information like HELLO message triggering and HELLO + message size, even though the HELLO messages are encrypted. + + o Section 4.4.2: Link spoofing - [RFC7185] provides certain + protection against link spoofing, but an NHDP router has to + "trust" the originator of a HELLO that the advertised links are + correct. For example, if a router A reports a link to B, routers + receiving HELLOs from A have to trust that B is actually a + (symmetric) neighbor of A. New protocol work could address + protection of links without overly increasing the space and time + overheads. An immediate suggestion for deployments is to protect + routers against being compromised and to distribute keys only to + trusted routers. + + o Section 4.5: Replay Attacks - [RFC7185] uses ICVs and timestamps + to provide some protection against replay attacks. It is still + feasible to replay control messages within a limited time. A + suggestion for deployments is to provide time synchronization + between routers. New work could provide time synchronization + mechanisms for certain MANET use cases or specify a mechanism + using nonces instead of timestamps in HELLO messages. + + o Section 4.4.1: Identity spoofing; Section 4.6: Message timing + attacks; Section 4.7: Indirect channel overloading; and + Section 4.8: Attack on link quality update - [RFC7185] provides + protection against these attacks, assuming the routers are not + compromised. + +7. Security Considerations + + This document does not specify a protocol or a procedure. The + document, however, reflects on security considerations for NHDP and + MANET routing protocols using NHDP for neighborhood discovery. + + + + + + +Yi, et al. Informational [Page 17] + +RFC 7186 Security Threats for NHDP April 2014 + + +8. Acknowledgments + + The authors would like to gratefully acknowledge the following people + for valuable comments and technical discussions: Teco Boot, Henning + Rogge, Christopher Dearlove, John Dowdell, Joseph Macker, and all the + other participants of the IETF MANET working group. + +9. References + +9.1. Normative References + + [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, + "Generalized Mobile Ad Hoc Network (MANET) Packet/Message + Format", RFC 5444, February 2009. + + [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value + Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March + 2009. + + [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc + Network (MANET) Neighborhood Discovery Protocol (NHDP)", + RFC 6130, April 2011. + +9.2. Informative References + + [ACCT2012] Jhaveri, R. and S. Patel, "DoS Attacks in Mobile Ad Hoc + Networks: A Survey", Second International Conference on + Advanced Computing & Communication Technologies (ACCT), + January 2012. + + [CPSCOM2011] + Yi, J., Clausen, T., and U. Herberg, "Vulnerability + Analysis of the Simple Multicast Forwarding (SMF) Protocol + for Mobile Ad Hoc Networks", Proceedings of the IEEE + International Conference on Cyber, Physical, and Social + Computing (CPSCom), October 2011. + + [IJNSIA2010] + Herberg, U. and T. Clausen, "Security Issues in the + Optimized Link State Routing Protocol version 2", + International Journal of Network Security & Its + Applications, April 2010. + + [MANET-MGMT] + Nguyen, J., Cole, R., Herberg, U., Yi, J., and J. Dean, + "Network Management of Mobile Ad hoc Networks (MANET): + Architecture, Use Cases, and Applicability", Work in + Progress, February 2013. + + + +Yi, et al. Informational [Page 18] + +RFC 7186 Security Threats for NHDP April 2014 + + + [MGMT-SNAP] + Clausen, T. and U. Herberg, "Snapshot of OLSRv2-Routed + MANET Management", Work in Progress, February 2014. + + [MOBICOM99] + Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast + Storm Problem in a Mobile Ad Hoc Network", Proceedings of + the 5th annual ACM/IEEE international conference on Mobile + computing and networking, 1999. + + [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to + Routing Protocols", RFC 4593, October 2006. + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC + 4949, August 2007. + + [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, + May 2012. + + [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of + Managed Objects for the Neighborhood Discovery Protocol", + RFC 6779, October 2012. + + [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, + "The Optimized Link State Routing Protocol Version 2", RFC + 7181, April 2014. + + [RFC7185] Herberg, U., Dearlove, C., and T. Clausen, "Integrity + Protection for the Neighborhood Discovery Protocol (NHDP) + and Optimized Link State Routing Protocol Version 2 + (OLSRv2)", RFC 7185, April 2014. + + + + + + + + + + + + + + + + + + + + +Yi, et al. Informational [Page 19] + +RFC 7186 Security Threats for NHDP April 2014 + + +Authors' Addresses + + Jiazi Yi + LIX, Ecole Polytechnique + 91128 Palaiseau Cedex + France + + Phone: +33 1 77 57 80 85 + EMail: jiazi@jiaziyi.com + URI: http://www.jiaziyi.com/ + + + Ulrich Herberg + Fujitsu Laboratories of America + 1240 E Arques Ave + Sunnyvale, CA 94085 + USA + + EMail: ulrich@herberg.name + URI: http://www.herberg.name/ + + + Thomas Heide Clausen + LIX, Ecole Polytechnique + 91128 Palaiseau Cedex + France + + Phone: +33 6 6058 9349 + EMail: T.Clausen@computer.org + URI: http://www.thomasclausen.org/ + + + + + + + + + + + + + + + + + + + + + +Yi, et al. Informational [Page 20] + |