idnits 2.17.1 draft-herberg-manet-nhdp-sec-threats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2009) is 5276 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-11 == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-10 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-09 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) U. Herberg 3 Internet-Draft T. Clausen 4 Intended status: Informational LIX, Ecole Polytechnique 5 Expires: May 16, 2010 November 12, 2009 7 Security Threats for NHDP 8 draft-herberg-manet-nhdp-sec-threats-00 10 Abstract 12 This document analyses common security threats of the Neighborhood 13 Discovery Protocol (NHDP) and describes impacts for MANET routing 14 protocols using NHDP. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 16, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . . 3 71 4. Detailed Description of Security Threats to NHDP . . . . . . . 4 72 4.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4.2. Incorrect HELLO Message Generation . . . . . . . . . . . . 5 74 4.2.1. Identity Spoofing . . . . . . . . . . . . . . . . . . . 5 75 4.2.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . . 6 76 4.3. Replay attack . . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Impact of inconsisent Information Bases for Routing 78 Protocols using NHDP . . . . . . . . . . . . . . . . . . . . . 6 79 5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . . 7 80 5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . . 7 81 5.3. Invalid or non-existing Paths to Destinations . . . . . . . 7 82 5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . . 7 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 85 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 88 1. Introduction 90 The Neighborhood Discovery Protocol (NHDP) [NHDP] allows routers to 91 exchange information about their one-hop and two-hop neighbors by 92 means of HELLO messages. It is a common base protocol for several 93 protocols in the MANET working group, such as OLSRv2 [OLSRv2] and SMF 94 [SMF]. The neighborhood information, exchanged between routers using 95 NHDP, serves these routing protocols as a baseline for calculating 96 paths to all destinations in the MANET, relay set selection for 97 network-wide transmissions etc. 99 Due to the fact that NHDP is typically used in wireless environments, 100 it is potentially exposed to different kinds of security threats, 101 some of which are of particular significance as compared to wired 102 networks. As wireless radio waves can be captured as well as 103 transmitted by any wireless device within radio range, there is 104 commonly no physical protection as for wired networks. The NHDP 105 specification does not define any security means for protecting the 106 integrity of the information it acquires, however suggests that this 107 be addressed in a fashion appropriate to the deployment of the 108 network. 110 This document will describe these security attacks which NHDP is 111 vulnerable to. In addition, the document outlines the consequences 112 of such security attacks to NHDP for routing protocols using NHDP for 113 neighborhood discovery. It is out of scope of this document to 114 provide solutions to counteract security attacks to NHDP. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in RFC 121 2119 [RFC2119]. 123 Additionally, this document uses the terminology of [RFC5444] and 124 [NHDP]. 126 3. NHDP Threat Overview 128 NHDP [NHDP] defines a message exchange protocol based on HELLO 129 messages in order for each router to acquire topological information 130 about 1-hop and 2-hop neighbors. It specifies information bases that 131 store the information and the necessary message exchange. These 132 information bases can be accesses by routing protocols such as OLSRv2 133 [OLSRv2] to construct routes to destinations in the MANET. 135 Every router periodically transmits HELLO messages on each of its 136 interfaces with a hop-limit of 1 (i.e. HELLOs are never forwarded by 137 a router). In these HELLO messages, a router announces the IP 138 addresses of heard, symmetric and lost neighbor interface addresses. 140 An adversary has several ways of harming the neighbor discovery 141 process: It can announce "wrong" information about its identity, 142 postulate non-existent links, and replay HELLO messages. These 143 attacks are presented in detail in Section 4. 145 The different ways of attacking an NHDP deployment will eventually 146 lead to inconsistent information bases, not reflecting the correct 147 topology of the MANET any more. This means that routers may be 148 unable to detect links to their neighbors correctly (for NHDP), and 149 thus corrupt the routing process of a routing protocol using the 150 neighbor information of NHDP. These implications to protocols using 151 the state of NHDP are in detail described in Section 5. 153 4. Detailed Description of Security Threats to NHDP 155 In this section, the different kind of threats to NHDP are detailed. 156 For every attack, a description of the mechanism of the attack is 157 followed by the implications for the NHDP instance. Implications on 158 routing protocols using NHDP are presented in Section 5. 160 For simplicity, in all examples contained in the following sections, 161 it is assumed that routers only have a single interface with a single 162 IP address configured. All the attacks apply as well for routers 163 with multiple interfaces and multiple addresses. 165 4.1. Jamming 167 One vulnerability, common for all protocols operating a wireless ad 168 hoc network, is that of "jamming" - i.e. that a router generates 169 massive amounts of interfering radio transmissions, which will 170 prevent legitimate traffic (e.g. control traffic as well as data 171 traffic) on part of a network. This vulnerability cannot be dealt 172 with at L3 (if at all), leaving the network without the ability to 173 maintain connectivity. Jamming is somewhat similar to that of 174 network overload and subsequent denial of service: a sufficiently 175 significant amount of control traffic is lost, preventing HELLO 176 messages to be correctly received. 178 If a considerable amount of HELLO messages are lost or corrupted due 179 to collisions, neighbor routers are able not any more to establish 180 links between them. This effectively renders NHDP unusable for upper 181 layer protocols, since no stable links can be used for sending out 182 control packets, or for calculating routing information. 184 4.2. Incorrect HELLO Message Generation 186 Every router running NHDP performs mainly two tasks: Periodically 187 generating HELLO messages and processing incoming HELLO messages from 188 neighbor routers. This section describes two security attacks 189 involving the HELLO generation. 191 4.2.1. Identity Spoofing 193 The so-called identity spoofing implies that a router sends HELLO 194 messages pretending to have the identity of another router. An 195 attacker can accomplish this by using another router's IP address in 196 an address block of a HELLO, and associating this address with a 197 LOCAL_IF Address Block TLV. In addition, it may need to set the 198 source address of the IP header that contains the control message. 200 If a router receives such a forged HELLO message from a neighbor, it 201 will assume that this HELLO comes from a router with the claimed 202 interface address. As a consequence, it will add a Link Tuple to 203 that neighbor with the spoofed address, and include it in its next 204 HELLO messages as a heard neighbor (and possibly as symmetric 205 neighbor after another HELLO exchange). 207 Identity spoofing is particular harmful if a router spoofs the 208 identity of another router that exists in the same routing domain. 209 With respect to NHDP, such a duplicated, spoofed address can lead to 210 an inconsistent state up to two hops from a router. Figure 1) 211 depicts a simple example. In that example, router A is in radio 212 range of C, but not of X. If X spoofs the address of A, that can lead 213 to conflicts for upper-layer routing protocols, and therefore for 214 wrong path calculations as well as incorrect data traffic forwarding. 216 ,---. ,---. ,---. 217 | A |----| C |----| X | 218 '---` '---` '---` 220 Figure 1 222 Figure 2) depicts another example. In this example, A is two hops 223 away from router C, reachable through router B. If the attacker X 224 spoofs the address of A, C may think that A is indeed reachable 225 through router D. 227 ,---. ,---. ,---. ,---. ,---. 228 | A |----| B |----| C |----| D |----| X | 229 '---` '---` '---` '---` '---` 231 Figure 2 233 4.2.2. Link Spoofing 235 Similarly, link spoofing implies that a router sends HELLO messages, 236 signaling an incorrect set of neighbors. This may take either of two 237 forms: An attacker can postulate addresses of non-present neighbor 238 routers in an address block of a HELLO, associated with LINK_STATUS 239 TLVs. Alternatively, a compromised router can "ignore" existing 240 neighbors by not advertizing them in its HELLO messages. 242 The effect of link spoofing with respect to NHDP are twofold, 243 depending on the two cases mentioned above: If the compromised router 244 ignores existing neighbors, there may not be any connectivity to or 245 from these routers to others routers in the MANET. If, on the other 246 hand, the router advertizing non-existing links, this can lead wrong 247 topological information in the information base, which may be used by 248 routing protocols. 250 4.3. Replay attack 252 A replay attack is, simply, where control traffic from one region of 253 the network is recorded and replayed in a different region (this type 254 of attack is also known as the Wormhole attack). This may, for 255 example, happen when two routers collaborate on an attack, one 256 recording traffic in its proximity and tunneling it to the other 257 router, which replays the traffic. In a protocol where links are 258 discovered by testing reception, this will result in extraneous link 259 creation (basically, a link between the two ``attacking'' routers). 260 While this may result from an attack, we note that it may also be 261 intentional: if data-traffic too is relayed over the virtual link 262 over the ``tunnel'', the link being detected is, indeed valid. This 263 is, for instance, used in wireless repeaters. If data traffic is not 264 carried over the virtual link, an imaginary, compromised, link has 265 been created. Replay attacks can be especially damaging if coupled 266 with spoofing and playing with sequence numbers in the replayed 267 messages, potentially destroying some important topology information 268 in routers all over the network. 270 5. Impact of inconsisent Information Bases for Routing Protocols using 271 NHDP 273 The different security attacks on NHDP have been presented in 274 Section 4 which lead to an inconsistent state of the topology on the 275 routers. This section describes the impact for routing protocols 276 that use NHDP as underlying neighbor discovery protocol, in 277 particular OLSRv2 [OLSRv2], and SMF. 279 5.1. MPR Calculation 281 TBD 283 5.2. Routing Loops 285 TBD 287 5.3. Invalid or non-existing Paths to Destinations 289 TBD 291 5.4. Data Sinkhole 293 TBD 295 6. IANA Considerations 297 This document contains no actions for IANA. 299 7. Security Considerations 301 This document does not specify a protocol or a procedure. The 302 document, however, reflects on security considerations for NHDP and 303 MANET routing protocols using NHDP for neighborhood discovery. 305 8. Normative References 307 [NHDP] Clausen, T., Dean, J., and C. Dearlove, "MANET 308 Neighborhood Discovery Protocol (NHDP)", work in 309 progress draft-ietf-manet-nhdp-11.txt, October 2009. 311 [OLSRv2] Clausen, T., Dearlove, C., and P. Philippe, "The Optimized 312 Link State Routing Protocol version 2", work in 313 progress draft-ietf-manet-olsrv2-10.txt, September 2009. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 319 "Generalized MANET Packet/Message Format", RFC 5444, 320 February 2009. 322 [SMF] Macker, J., "Simplified Multicast Forwarding", work in 323 progress draft-ietf-manet-smf-09.txt, July 2009. 325 Authors' Addresses 327 Ulrich Herberg 328 LIX, Ecole Polytechnique 329 91128 Palaiseau Cedex, 330 France 332 Phone: +33-1-6933-4126 333 Email: ulrich@herberg.name 334 URI: http://www.herberg.name/ 336 Thomas Heide Clausen 337 LIX, Ecole Polytechnique 338 91128 Palaiseau Cedex, 339 France 341 Phone: +33 6 6058 9349 342 Email: T.Clausen@computer.org 343 URI: http://www.thomasclausen.org/