idnits 2.17.1 draft-yi-manet-smf-sec-threats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 4, 2014) is 3581 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) J. Yi 3 Internet-Draft T. Clausen 4 Intended status: Informational LIX, Ecole Polytechnique 5 Expires: January 5, 2015 U. Herberg 6 Fujitsu Laboratories of America 7 July 4, 2014 9 Security Threats for Simplified Multicast Forwarding (SMF) 10 draft-yi-manet-smf-sec-threats-00 12 Abstract 14 This document analyzes security threats of the Simplified Multicast 15 Forwarding (SMF), including the vulnerabilities of duplicate packet 16 detection and relay set selection mechanisms. This document is not 17 intended to propose solutions to the threats described. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 5, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SMF Threats Overview . . . . . . . . . . . . . . . . . . . . . 4 56 4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5 57 4.1. Threats to Identification-based Duplicate Packet 58 Detection . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 6 60 4.1.2. De-activation Attacks (Sequence Number wrangling) . . 6 61 4.2. Threats to Hash-based Duplicate Packet Detection . . . . . 7 62 4.2.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 7 63 4.2.2. Attack on Hash-Assistant Value . . . . . . . . . . . . 8 64 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 8 65 5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 9 66 5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 9 67 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 9 68 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 9 69 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 10 70 5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 This document analyzes security threats of the Simplified Multicast 81 Forwarding (SMF) mechanism [RFC6621]. SMF aims at providing basic 82 Internet Protocol (IP) multicast forwarding, in a way which is 83 suitable for limited wireless mesh and Mobile Ad hoc NETworks 84 (MANET). SMF is constituted of two major functional components: 85 Duplicate Packet Detection and Relay Set Selection. 87 SMF is typically used in decentralized wireless environments, and is 88 potentially exposed to different kinds of attacks and 89 misconfigurations. Some of the threats are of particular 90 significance as compared to wired networks. In [RFC6621], SMF does 91 not define any explicit security measures for protecting the 92 integrity of the protocol. 94 This document is based on the assumption that no additional security 95 mechanism such as IPsec is used in the IP layer, as not all MANET 96 deployments may be suitable to deploy common IP protection mechanisms 97 (e.g., because of limited resources of MANET routers to support the 98 IPsec stack). The document analyzes possible attacks on and mis- 99 configurations of SMF and outlines the consequences of such attacks/ 100 mis-configurations to the state maintained by SMF in each router 101 (and, thus, made available to protocols using this state). 103 This document aims at analyzing and describing the potential 104 vulnerabilities of and attack vecors for SMF. While completeness in 105 such an analysis always is a goal, no claims of being complete are 106 made. The goal of this document is to be helpful for when deploying 107 SMF in a network and needing to understand the risks thereby incurred 108 - as wll as for providing a reference and documented experience with 109 SMF as input for possibly future developments of SMF. 111 This document is not intended to propose solutions to the threats 112 described. [RFC7182] provides a framework, which can be used with 113 SMF, and which - depending on how it is used - may offer some degree 114 of protection against the threats described in this document related 115 to identity spoofing. 117 2. Terminology 119 This document uses the terminology and notation defined in [RFC2119], 120 [RFC5444], [RFC6621] and [RFC4949]. 122 Additionally, this document introduces the following terminology: 124 SMF router: A MANET router, running SMF as specified in [RFC6621]. 126 Attacker: A device that is present in the network and intentionally 127 seeks to compromise the information bases in SMF routers. 129 Compromised SMF router: An attacker, present in the network and 130 which generates syntactically correct SMF control messages. 131 Control messages emitted by a compromised SMF router may contain 132 additional information, or omit information, as compared to a 133 control message generated by a non-compromized SMF router located 134 in the same topological position in the network. 136 Legitimate SMF router: An SMF router, which is not a compromised SMF 137 Router. 139 3. SMF Threats Overview 141 SMF requires an external dynamic neighborhood discovery mechanism in 142 orde to maintain suitable topological information describing its 143 immediate neighborhood, and thereby allowing it to select reduced 144 relay sets for forwarding multicast data traffic. Such an external 145 dynamic neighborhood discovery mechanism MAY be provided by lower- 146 layer interface information, by a concurrently operating MANET 147 routing protocol which already maintains such information such as 148 [RFC7181], or by explicitly using MANET Neighborhood Discovery 149 Protocol (NHDP) [RFC6130]. If NHDP is used for neighborhood 150 discovery by SMF, SMF implicitly inherits the vulnerabilities of 151 NHDP, as discussed in [RFC7186]. This document assumes that NHDP is 152 used. 154 Based on neighborhood discovery mechanisms, SMF specified two major 155 functional components: Duplicate Packet Detection (DPD) and Relay Set 156 Selection (RSS). 158 DPD is required by SMF in order to be able to detect duplicate 159 packets and eliminate their redundant forwarding. An Attacker has 160 several ways in which to harm the DPD mechanisms: 162 o It can "deactivate" DPD, so as to make it such that duplicate 163 packets are not correctly detected, and that as a consequence they 164 are (redundantly) transmitted, increasing the load on the network, 165 draing the batteries of the routers involved, etc. 167 o It can "pre-activate" DPD, so as to make DPD detect a later 168 arriving (valid) packet as being a duplicate, which therefore 169 won't be forwarded" 171 The attacks on DPD are detailed in Section 4. 173 RSS produces a reduced relay set forforwarding multicast data packets 174 across the MANET. SMF supports the use of several relay set 175 algorithms, including E-CDS (Essential Connected Dominating Set), 176 S-MPR (Source-based Multi-point Relay, as known from [RFC3626] and 177 [RFC7181]), or MPR-CDS. An Attacker can disrupt the RSS algorithm, 178 by degrading it to classical flooding, or by "masking" certain part 179 of the routers from the multicasting domain. The attacks to RSS 180 algorithms are illustrated in Section 5. 182 4. Threats to Duplicate Packet Detection 184 Duplicate Packet Detection (DPD) is required for packet dissemination 185 in MANET because the packets may be transmitted via the same physical 186 interface as the one over which they were received. A router may 187 also receive multiple copies of the same packets from different 188 neighbors. DPD is thus used to check if an incoming packet has been 189 received or not. 191 DPD is achieved by a router maintaining a record of recently 192 processed multicast packets, and comparing later received multicast 193 herewith. A duplicate packet detected is silently dropped, and is 194 not inserted into the forwarding path of that router, nor is it 195 delivered to an application. DPD, as proposed by SMF, supports both 196 IPv4 and IPv6 and for each suggests two duplicate packet detection 197 mechanisms: 1) header content identification-based DPD (I-DPD), using 198 packet headers, in combination with flow state, to estimate temporal 199 uniqueness of a packet, and 2) hash-based DPD (H-DPD), employing 200 hashing of selected header fields and payload for the same effect. 202 As they are distinct mechanisms, the threats to I-DPD and H-DPD are 203 discussed separately. 205 4.1. Threats to Identification-based Duplicate Packet Detection 207 I-DPD uses a specific DPD identifier in the packet header to identify 208 a packet. By default, such packet identification is not provided by 209 the IP packet header (for both IPv4 and IPv6). Therefore, additional 210 identification header, such as the fragment header, a hop-by-hop 211 header option, or IPSec sequencing, must be employed in order to 212 support I-DPD. The uniqueness of a packet can then be identified by 213 the [source IP address] of the packet originator, and the [sequence 214 number] (from the fragment header, hop-by-hop header option, or 215 IPsec). By doing so, each intermediate router can keep a record of 216 recently received packet, and determine the coming packet has been 217 received or not. 219 4.1.1. Pre-activation Attacks (Pre-Play) 221 In a wireless environment, or across any other shared channel, a 222 compromised SMF router can perceive the identification tuple [source 223 IP, sequence number] of a packet. If sequence number progression is 224 predictable, then it is trivial to generate aand inject invalid 225 packets with "future" identification information into the network. 226 If these invalid packets arrive before the legitimate packets that 227 they're spoofing, the latter will be treated as a duplicates and 228 discarded. This can prevent multicast packets from reaching parts of 229 the network. 231 Figure 1 gives an example of pre-activation attack. A, B, and C are 232 legitimate SMF routers, and X is the compromised SMF router. The 233 line between the routers presents the packet forwarding. Router A is 234 the source and originates a multicast packet with sequence number n. 235 When router X receives the packet, it generates an invalid packet 236 with the the source address of A, and sequence number n. If the 237 invalid packet arrives at router C before the forwarding of router B, 238 the valid packet will be dropped by C as duplicate packet. In a 239 wireless environment, jitter is commonly used to avoid systematic 240 collisions at MAC layer [RFC5148], thus an attacker can increase the 241 probability that its invalid packets arrive first by retransmitting 242 them without jittering. 244 .---. 245 | X | 246 --'---' __ 247 packet with seq=n / \ invalid packet with seq=n 248 / \ 249 .---. .---. 250 | A | | C | 251 '---' '---' 252 packet with seq=n \ .---. / 253 \-- | B |__/ valid packet with seq=n 254 '---' 256 Figure 1 258 4.1.2. De-activation Attacks (Sequence Number wrangling) 260 A compromised SMF router can also seek to de-activate DPD, by 261 modifying the sequence number in packets that it forwards. Thus, 262 routers will not be able to detect an actual duplicate packet as a 263 duplicate - rather, they will treat them as new packets, i.e., 264 process and forward them. This is similar to DoS attack. The 265 consequence of this attack is an increased channel load, the origin 266 of which appears to be a router other than the compromised SMF 267 router. 269 Given the topology shown in Figure 1, on receiving packet with seq=n, 270 the attacker X can forward the packet with modified sequence number 271 n+i. This has two consequences: firstly, router C will not be able 272 to detect the packet forwarded by X is a duplicate packet; secondly, 273 the consequent packet with seq=n+i generated by router A probably 274 will be treated as duplicate packet, and dropped by router C. 276 4.2. Threats to Hash-based Duplicate Packet Detection 278 When it is not feasible to have explicit sequence numbers in packet 279 headers, hash-based DPD can be used. A hash of the non-mutable 280 fields in the header of and the data payload can be generated, and 281 recorded at the intermediate routers. A packet can thus be uniquely 282 identified by the source IP address of the packet, and its hash- 283 value. 285 The hash algorithm used by SMF is being applied only to provide a 286 reduced probability of collision and is not being used for 287 cryptographic or authentication purposes. Consequently, a digest 288 collision is still possible. In case the source router or gateway 289 identifies that it recently has generated or injected a packet with 290 the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6 291 header option into the packet, such that calculating the hash also 292 over this HAV will render the resulting value unique. 294 4.2.1. Replay Attack 296 A replay attack implies that control traffic from one region of the 297 network is recorded and replayed in a different region at (almost) 298 the same time, or in the same region at a different time. 300 One possible replay attack is based on the Time-to-Live (TTL, for 301 IPv4) or hop limit (for IPv6) field. As routers only forward packets 302 with TTL > 1, a compromised SMF router can forward an otherwise valid 303 packet, while drastically reducing the TTL hereof. This will inhibit 304 recipient routers from later forwarding the same multicast packet, 305 even if received with a different TTL - essentially a compromised SMF 306 router thus can instruct its neighbors to block forwarding of valid 307 multicast packets. As the TTL of a packet is intended to be 308 manipulated by intermediaries forwarding it, classic methods such as 309 integrity check values (e.g., digital signatures) are typically 310 calculated with setting TTL fields to some pre-determined value 311 (e.g., 0) - such is for example the case for IPsec Authentication 312 Headers - rendering such an attack more difficult to both detect and 313 counter. If the compromised SMF router has access to a "wormhole" 314 through the network (a directional antenna, a tunnel to a 315 collaborator or a wired connection, allowing it to bridge parts of a 316 network otherwise distant) it can make sure that the packets with 317 such an artificially reduced TTL arrive before their unmodified 318 counterparts. 320 4.2.2. Attack on Hash-Assistant Value 322 The HAV header is helpful when a digest collision happens. However, 323 it also introduces a potential vulnerability. As the HAV option is 324 only added when the source or the ingressing SMF router detects that 325 the coming packet has digest collision with previously generated 326 packets, it actually can be regarded as a "flag" of potential digest 327 collision. A compromised SMF router can discover the HAV header, and 328 be able to conclude a hash collision is possible if the HAV header is 329 removed. By doing so, other SMF routers receiving the modified 330 packet will be treated as duplicate packet, and be dropped because it 331 has the same hash value with precedent packet. 333 In the example of Figure Figure 2, Router A and B are legitimate SMF 334 routers, X is a compromised SMF router. A generate two packets P1 335 and P2, with the same hash value h(P1)=h(P2)=x. Based on SMF 336 specification, a hash-assistant value (HAV) is added to the latter 337 packet P2, so that h(P2+HAV)=x', to avoid digest collision. When the 338 attacker X detects the HAV of P2, it is able to conclude that a 339 collision is possible by removing the HAV header. By doing so, 340 packet P2 will be treated as duplicate packet by router B, and be 341 dropped. 343 P2 P1 P2 P1 344 .---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---. 345 | A |---------------------------> | X | ----------------------> | B | 346 `---' `---' `---' 348 Figure 2 350 5. Threats to Relay Set Selection 352 A framework for RSS mechanism, rather than a specific RSS algorithm 353 is provided by SMF. It is normally achieved by distributed 354 algorithms that can dynamically generate a topological Connected 355 Dominating Set based on 1-hop and 2-hop neighborhood information. In 356 this section, the common threats to the RSS framework are first 357 discussed. Then the three commonly used algorithms: Essential 358 Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint 359 Relay (S-MPR) and Multipoint Relay Connected Dominating Set (MPR-CDS) 360 are analyzed. 362 5.1. Relay Set Selection Common Threats 364 The common threats to RSS algorithms, including Denial of Service 365 attack, eavesdropping, message timing attack and broadcast storm have 366 been discussed in [RFC7186]. 368 5.2. Threats to E-CDS Algorithm 370 The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] 371 forms a single CDS mesh for the SMF operating region. It requires 372 2-hop neighborhood information (the identify of the neighbors, the 373 link to the neighbors and neighbors' priority information) collected 374 through NHDP or another process. 376 An SMF Router select itself as a relay, if: 378 o The SMF Router has a higher priority than all of its symmetric 379 neighbors, or 381 o There does not exist a path from the neighbor with largest 382 priority to any other neighbor, via neighbors with greater 383 priority. 385 A Compromised SMF Router can disrupt the E-CDS algorithm by link 386 spoofing or identity spoofing. 388 5.2.1. Link Spoofing 390 Link spoofing implies that a Compromised SMF Router advertises non- 391 existing links to another router (present in the network or not). 393 A Compromised SMF Router can declare itself with high route priority, 394 and spoofs the links to as many Legitimate SMF Routers as possible to 395 declare high connectivity. By doing so, it can prevent Legitimate 396 SMF Routers from self-selecting as relays. As the "super" relay in 397 the network, the Compromised SMF Router can manipulate the traffic 398 relayed by it. 400 5.2.2. Identity Spoofing 402 Identity spoofing implies that a compromised SMF router determines 403 and makes use of the identity of other legitimate routers, without 404 being authorised to do so. The identity of other routers can be 405 obtained by overhearing the control messages or source/destination 406 address from datagram. The compromised SMF router can then generate 407 control or datagram traffic, pretending to be a legitimate router. 409 Because E-CDS self-selection is based on the router priority value, a 410 compromised SMF router can spoof the identity of other legitimate 411 routers, and declares a different router priority value. If it 412 declares a higher priority of a spoofed router, it can prevent other 413 routers from selecting themselves as relays. On the other hand, if 414 the compromised router declares lower priority of a spoofed router, 415 it can enforces other routers to selecting themselves as relays, to 416 degrade the multicast forwarding to classical flooding. 418 5.3. Threats to S-MPR Algorithm 420 The source-based multipoint relay (S-MPR) set selection algorithm 421 enables individual routers, using 2-hop topology information, to 422 select relays from their set of neighboring routers. MPRs are 423 selected so that forwarding to the router's complete 2-hop neighbor 424 set is covered. 426 An SMF router forwards a multicast packet if and only if: 428 o the packet is not received before, and 430 o the neighbor from which the packet was received has selected the 431 router as MPR. 433 Because MPR calculation is based on the willingness declared by the 434 SMF routers, and the connectivity of the routers, it can be disrupted 435 by both link spoofing and identity spoofing. The threats and its 436 impacts have been illustrated in section 5.1 of [RFC7186]. 438 5.4. Threats to MPR-CDS Algorithm 440 MPR-CDS is a derivative from S-MPR. The main difference between 441 S-MPR and MPR-CDS is that while S-MPR forms a different broadcast 442 tree for each source in the network, MPR-CDS forms a unique broadcast 443 tree for all sources in the network. 445 As MPR-CDS combines E-CDS and S-MPR, the vulnerabilities of E-CDS and 446 S-MPR that discussed in Section 5.2 and Section 5.3 apply to MPR-CDS 447 also. 449 6. Security Considerations 451 This document does not specify a protocol or a procedure. The 452 document, however, reflects on security considerations for SMF for 453 packet dissemination in MANETs. 455 7. IANA Considerations 457 This document contains no actions for IANA. 459 8. References 461 8.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 467 Extension of OSPF Using Connected Dominating Set (CDS) 468 Flooding", RFC 5614, August 2009. 470 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 471 May 2012. 473 [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for 474 the Neighborhood Discovery Protocol (NHDP)", RFC 7186, 475 April 2014. 477 8.2. Informative References 479 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 480 Routing Protocol", RFC 3626, October 2003. 482 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 483 RFC 4949, August 2007. 485 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 486 Considerations in Mobile Ad Hoc Networks (MANETs)", 487 RFC 5148, February 2008. 489 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 490 "Generalized MANET Packet/Message Format", RFC 5444, 491 February 2009. 493 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 494 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 495 RFC 6130, April 2011. 497 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 498 "The Optimized Link State Routing Protocol version 2", 499 RFC 7181, April 2014. 501 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 502 Check Value and Timestamp TLV Definitions for Mobile Ad 503 Hoc Networks (MANETs)", RFC 7182, April 2014. 505 Authors' Addresses 507 Jiazi Yi 508 LIX, Ecole Polytechnique 509 91128 Palaiseau Cedex, 510 France 512 Phone: +33 1 77 57 80 85 513 Email: jiazi@jiaziyi.com 514 URI: http://www.jiaziyi.com/ 516 Thomas Heide Clausen 517 LIX, Ecole Polytechnique 518 91128 Palaiseau Cedex, 519 France 521 Phone: +33 6 6058 9349 522 Email: T.Clausen@computer.org 523 URI: http://www.thomasclausen.org/ 525 Ulrich Herberg 526 Fujitsu Laboratories of America 527 1240 E Arques Ave 528 Sunnyvale, CA 94085 529 USA 531 Email: ulrich@herberg.name 532 URI: http://www.herberg.name/