idnits 2.17.1 draft-ietf-manet-smf-sec-threats-06.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 date (August 27, 2016) is 2799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Updates: 7186 (if approved) Ecole Polytechnique 5 Intended status: Informational U. Herberg 6 Expires: February 28, 2017 August 27, 2016 8 Security Threats for Simplified Multicast Forwarding (SMF) 9 draft-ietf-manet-smf-sec-threats-06 11 Abstract 13 This document analyzes security threats of the Simplified Multicast 14 Forwarding (SMF) mechanism, including the vulnerabilities of 15 duplicate packet detection and relay set selection mechanisms. This 16 document is not intended to propose solutions to the threats 17 described. 19 This document also updates RFC7186 regarding the threats to relay set 20 selection mechanisms using RFC6130. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 28, 2017. 39 Copyright Notice 41 Copyright (c) 2016 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 Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. SMF Threats Overview . . . . . . . . . . . . . . . . . . . . . 4 59 4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5 60 4.1. Attack to The Hop Limit Field . . . . . . . . . . . . . . 6 61 4.2. Threats to Identification-based Duplicate Packet 62 Detection . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 7 64 4.2.2. De-activation Attacks (Sequence Number wrangling) . . 8 65 4.3. Threats to Hash-based Duplicate Packet Detection . . . . . 9 66 4.3.1. Attack on Hash-Assistant Value . . . . . . . . . . . . 9 67 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 10 68 5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 10 69 5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 10 70 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11 71 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 72 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 11 73 5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 12 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 This document analyzes security threats to the Simplified Multicast 85 Forwarding (SMF) mechanism [RFC6621]. SMF aims at providing basic 86 Internet Protocol (IP) multicast forwarding, in a way that is 87 suitable for limited wireless mesh and Mobile Ad hoc NETworks 88 (MANET). SMF is constituted of two major functional components: 89 Duplicate Packet Detection and Relay Set Selection. 91 SMF is typically used in decentralized wireless environments, and is 92 potentially exposed to various attacks and misconfigurations. Some 93 of these attacks and misconfigurtions, in a wireless enviroment, 94 represent threats of particular significance as compared to what they 95 would do in wired networks. [RFC6621] briefly discusses several of 96 these, but does not define any explicit security measures for 97 protecting the integrity of the protocol. 99 This document is based on the assumption that no additional security 100 mechanism such as IPsec is used in the IP layer, as not all MANET 101 deployments may be suitable to deploy common IP protection mechanisms 102 (e.g., because of limited resources of MANET routers to support the 103 IPsec stack). It assumes that there is no lower-layer protection 104 either. The document analyzes possible attacks on and mis- 105 configurations of SMF and outlines the consequences of such attacks/ 106 mis-configurations to the state maintained by SMF in each router. 108 In the Security Considerations section of [RFC6621], denial-of- 109 service attack scenarios are briefly discussed. This document 110 further analyzes and describes the potential vulnerabilities of and 111 attack vectors for SMF. While completeness in such analysis is 112 always a goal, no claims of being complete are made. The goal of 113 this document is to be helpful for when deploying SMF in a network 114 and needing to understand the risks thereby incurred - as well as for 115 providing a reference and documented experience with SMF as input for 116 possibly future developments of SMF. 118 This document is not intended to propose solutions to the threats 119 described. [RFC7182] provides a framework that can be used with SMF, 120 and depending on how it is used - may offer some degree of protection 121 against the threats described in this document related to identity 122 spoofing. 124 This document also updates [RFC7186], specifically with respect to 125 threats to relay set selection mechanisms which are using [RFC6130]. 127 2. Terminology 129 This document uses the terminology and notation defined in [RFC5444], 130 [RFC6130], [RFC6621] and [RFC4949]. 132 Additionally, this document introduces the following terminology: 134 SMF router: A MANET router, running SMF as specified in [RFC6621]. 136 Attacker: A device that is present in the network and intentionally 137 seeks to compromise the information bases in SMF routers. It may 138 generate syntactically correct SMF control messages. 140 Legitimate SMF router: An SMF router that is correctly configured 141 and not compromised by an attacker. 143 3. SMF Threats Overview 145 SMF requires an external dynamic neighborhood discovery mechanism in 146 order to maintain suitable topological information describing its 147 immediate neighborhood, and thereby allowing it to select reduced 148 relay sets for forwarding multicast data traffic. Such an external 149 dynamic neighborhood discovery mechanism may be provided by lower- 150 layer interface information, by a concurrently operating MANET 151 routing protocol that already maintains such information such as 152 [RFC7181], or by explicitly using MANET Neighborhood Discovery 153 Protocol (NHDP) [RFC6130]. If NHDP is used for both 1-hop and 2-hop 154 neighborhood discovery by SMF, SMF implicitly inherits the 155 vulnerabilities of NHDP discussed in [RFC7186]. As SMF relies on 156 NHDP to assist in network layer 2-hop neighborhood discovery (no 157 matter if other lower-layer mechanisms are used for 1-hop 158 neighborhood discovery), this document assumes that NHDP is used in 159 SMF. The threats that are NHDP-specific are indicated explicitly. 161 Based on neighborhood discovery mechanisms, [RFC6621] specifies two 162 principal functional components: Duplicate Packet Detection (DPD) and 163 Relay Set Selection (RSS). 165 DPD is required by SMF in order to be able to detect duplicate 166 packets and eliminate their redundant forwarding. An Attacker has 167 two ways in which to harm the DPD mechanisms, specifically it can: 169 o "deactivate" DPD, so as to make it such that duplicate packets are 170 not correctly detected, and that as a consequence they are 171 (redundantly) transmitted, increasing the load on the network, 172 draining the batteries of the routers involved, etc. 174 o "pre-activate" DPD, so as to make DPD detect a later arriving 175 (valid) packet as being a duplicate, which therefore won't be 176 forwarded. 178 Attacks on DPD can be achieved by replaying existing packets, by 179 wrangling sequence numbers, by manipulating hash values, etc., and 180 are detailed in Section 4. 182 RSS produces a reduced relay set for forwarding multicast data 183 packets across the MANET. [RFC6621] specifies several relay set 184 algorithms, including E-CDS (Essential Connected Dominating Set) 185 [RFC5614], S-MPR (Source-based Multi-point Relay, as known from 186 [RFC3626] and [RFC7181]), or MPR-CDS [MPR-CDS], for use in SMF. An 187 Attacker can disrupt the RSS algorithm, and thereby SMF operation, by 188 degrading it to classical flooding, or by "masking" certain parts of 189 the network from the multicasting domain. Attacks on RSS algorithms 190 are detailed in Section 5. 192 Other than the attacks on DPD and RSS, a common vulnerability of 193 MANETs is "jamming", i.e., a device generates massive amounts of 194 interfering radio transmissions, which will prevent legitimate 195 traffic (e.g., control traffic as well as data traffic) on part of a 196 network. The attacks on DPD and RSS can be further enhanced by 197 jamming. 199 4. Threats to Duplicate Packet Detection 201 Duplicate Packet Detection (DPD) is required for packet dissemination 202 in MANETs because: (1) packets may be transmitted via the same 203 physical interface as the one over which they were received, and (2) 204 a router may receive multiple copies of the same packet (on the same, 205 or on different interfaces) from different neighbors. DPD is thus 206 used to check if an incoming packet has been previously received or 207 not. 209 DPD is achieved by maintaining a record of recently processed 210 multicast packets, and comparing later received multicast packets 211 herewith. A duplicate packet detected is silently dropped and is not 212 inserted into the forwarding path of that router, nor is it delivered 213 to an application. DPD, as proposed by SMF, supports both IPv4 and 214 IPv6 and for each suggests two duplicate packet detection mechanisms: 215 1) header content identification-based DPD (I-DPD), using packet 216 headers, in combination with flow state, to estimate temporal 217 uniqueness of a packet, and 2) hash-based DPD (H-DPD), employing 218 hashing of selected header fields and payload for the same effect. 220 In the Security Considerations section of [RFC6621], a selection of 221 threats to DPD are briefly introduced. This section expands on that 222 discussion, and describes how to effectively launch the attacks on 223 DPD - for example, by way of manipulating jitter and/or the Hash- 224 Assistant Value. In the remainder of this section, common threats to 225 packet detection mechanisms are first discussed. Then the threats to 226 I-DPD and H-DPD are introduced separately. The threats described in 227 this section are applicable to general SMF implementations, no matter 228 if NHDP is used or not. 230 4.1. Attack to The Hop Limit Field 232 One immediate DoS attack is based on manipulating the Time-to-Live 233 (TTL, for IPv4) or hop limit (for IPv6) field. As routers only 234 forward packets with TTL > 1, an attacker can forward an otherwise 235 valid packet, while drastically reducing the TTL hereof. This will 236 inhibit recipient routers from later forwarding the same multicast 237 packet, even if received with a different TTL - essentially an 238 attacker thus can instruct its neighbors to block forwarding of valid 239 multicast packets. 241 For example, in Figure 1, router A forwards a multicast packet with a 242 TTL of 64 to the network. A, B, and C are legitimate SMF routers, 243 and X is an attacker. In a wireless environment, jitter is commonly 244 used to avoid systematic collisions in MAC protocols [RFC5148]. An 245 attacker can thus increase the probability that its invalid packets 246 arrive first by retransmitting them without applying jitter. In this 247 example, router X forwards the packet without applying jitter and 248 reduces the TTL to 1. Router C thus records the duplicate detection 249 value (hash value for H-DPD, or the header content of the packets for 250 I-DPD) but does (due to TTL == 1) not forward. When a second copy 251 the same packet, with a non-maliciously manipulated TTL value (63 in 252 this case), arrives from router B, it will be discarded as duplicate 253 packet. 255 .---. 256 | X | 257 --'---' __ 258 packet with TTL=64 / \ packet with TTL=1 259 / \ 260 .---. .---. 261 | A | | C | 262 '---' '---' 263 packet with TTL=64 \ .---. / 264 \-- | B |__/ packet with TTL=63 265 '---' 267 Figure 1 269 As the TTL of a packet is intended to be manipulated by 270 intermediaries forwarding it, classic methods such as integrity check 271 values (e.g., digital signatures) are typically calculated with 272 setting TTL fields to some pre-determined value (e.g., 0) - such is 273 for example the case for IPsec Authentication Headers - rendering 274 such an attack more difficult to both detect and counter. 276 If the attacker has access to a "wormhole" through the network (a 277 directional antenna, a tunnel to a collaborator or a wired 278 connection, allowing it to bridge parts of a network otherwise 279 distant), it can make sure that the packets with such an artificially 280 reduced TTL arrive before their unmodified counterparts. 282 4.2. Threats to Identification-based Duplicate Packet Detection 284 I-DPD uses a specific DPD identifier in the packet header to identify 285 a packet. By default, such packet identification is not provided by 286 the IP packet header (for both IPv4 and IPv6). Therefore, additional 287 identification headers, such as the fragment header, a hop-by-hop 288 header option, or IPSec sequencing, must be employed in order to 289 support I-DPD. The uniqueness of a packet can then be identified by 290 the source IP address of the packet originator and the sequence 291 number (from the fragment header, hop-by-hop header option, or 292 IPsec). By doing so, each intermediate router can keep a record of 293 recently received packets and determine whether the incoming packet 294 has been received or not. 296 4.2.1. Pre-activation Attacks (Pre-Play) 298 In a wireless environment, or across any other shared channel, an 299 attacker can perceive the identification tuple (source IP address, 300 sequence number) of a packet. It is possible to generate a packet 301 with the same (source IP address, sequence number) pair with invalid 302 content. If sequence number progression is predictable, then it is 303 trivial to generate and inject invalid packets with "future" 304 identification information into the network. If these invalid 305 packets arrive before the legitimate packets that they are spoofing, 306 the latter will be treated as a duplicate and discarded. This can 307 prevent multicast packets from reaching parts of the network. 309 Figure 2 gives an example of pre-activation attack. A, B and C are 310 legitimate SMF routers, and X is the attacker. The line between the 311 routers presents the packet forwarding. Router A is the source and 312 originates a multicast packet with sequence number n. When router X 313 receives the packet, it generates an invalid packet with the source 314 address of A and sequence number n. If the invalid packet arrives at 315 router C before the forwarding of router B, the valid packet will be 316 dropped by C as a duplicate packet. An attacker can manipulate 317 jitter to make sure that the invalid packets arrive first. Router X 318 can even generate packets with future sequence numbers (if they are 319 predictable), so that the future legitimate packets with the same 320 sequence numbers will be dropped as duplicate ones. 322 .---. 323 | X | 324 --'---' __ 325 packet with seq=n / \ invalid packet with seq=n 326 / \ 327 .---. .---. 328 | A | | C | 329 '---' '---' 330 packet with seq=n \ .---. / 331 \-- | B |__/ valid packet with seq=n 332 '---' 334 Figure 2 336 As SMF currently does not have any timestamp mechanisms to protect 337 data packets, there is no viable way to detect such pre-play attacks 338 by way of timestamps. Especially, if the attack is based on 339 manipulation of jitter, the validation of timestamp would not be 340 helpful because the timing is still valid (but with much less value). 342 4.2.2. De-activation Attacks (Sequence Number wrangling) 344 An attacker can also seek to de-activate DPD, by modifying the 345 sequence number in packets that it forwards. Thus, routers will not 346 be able to detect an actual duplicate packet as a duplicate - rather, 347 they will treat them as new packets, i.e., process and forward them. 348 This is similar to DoS attacks, as each packet that is considered 349 unique will be multicasted: for a network with n routers, there will 350 be n-1 retransmissions. This can easily cause the "broadcast storm" 351 problem discussed in [MOBICOM99]. The consequence of this attack is 352 an increased channel load, the origin of which appears to be a router 353 other than the attacker. 355 Given the topology shown in Figure 2, on receiving a packet with 356 seq=n, the attacker X can forward the packet with modified sequence 357 number n+i. This has two consequences: firstly, router C will not be 358 able to detect the packet forwarded by X is a duplicate packet; 359 secondly, the consequent packet with seq=n+i generated by router A 360 probably will be treated as duplicate packet, and dropped by router 361 C. 363 4.3. Threats to Hash-based Duplicate Packet Detection 365 When explicit sequence numbers in packet headers is undesired, hash- 366 based DPD can be used. A hash of the non-mutable fields in the 367 header of and the data payload can be generated, and recorded at the 368 intermediate routers. A packet can thus be uniquely identified by 369 the source IP address of the packet and its hash-value. 371 The hash algorithm used by SMF is being applied only to provide a 372 reduced probability of collision and is not being used for 373 cryptographic or authentication purposes. Consequently, a digest 374 collision is still possible. In case the source router or gateway 375 identifies that it recently has generated or injected a packet with 376 the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6 377 header option into the packet, such that calculating the hash also 378 over this HAV will render the resulting value unique. 380 4.3.1. Attack on Hash-Assistant Value 382 The HAV header is helpful when a digest collision happens. However, 383 it also introduces a potential vulnerability. As the HAV option is 384 only added when the source or the ingress SMF router detects that the 385 coming packet has digest collision with previously generated packets, 386 it actually can be regarded as a "flag" of potential digest 387 collision. An attacker can discover the HAV header, and be able to 388 conclude that a hash collision is possible if the HAV header is 389 removed. By doing so, the modified packet received by other SMF 390 routers will be treated as duplicate packets, and be dropped because 391 they have the same hash value with the precedent packet. 393 In the example of Figure 3, Router A and B are legitimate SMF 394 routers; X is an attacker. A generates two packets P1 and P2, with 395 the same hash value h(P1)=h(P2)=x. Based on the SMF specification, a 396 hash-assistant value (HAV) is added to the latter packet P2, so that 397 h(P2+HAV)=x', to avoid digest collision. When the attacker X detects 398 the HAV of P2, it is able to conclude that a collision is possible by 399 removing the HAV header. By doing so, packet P2 will be treated as 400 duplicate packet by router B, and be dropped. 402 P2 P1 P2 P1 403 .---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---. 404 | A |---------------------------> | X | ----------------------> | B | 405 `---' `---' `---' 407 Figure 3 409 5. Threats to Relay Set Selection 411 A framework for RSS mechanism, rather than a specific RSS algorithm 412 is provided by SMF. It is normally achieved by distributed 413 algorithms that can dynamically generate a topological Connected 414 Dominating Set based on 1-hop and 2-hop neighborhood information. In 415 this section, the common threats to the RSS framework are first 416 discussed. Then the three commonly used algorithms: Essential 417 Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint 418 Relay (S-MPR) and Multipoint Relay Connected Dominating Set (MPR-CDS) 419 are analyzed. As the relay set selection is based on 1-hop and 2-hop 420 neighborhood information, which rely on NHDP, the threats described 421 in this section are NHDP-specific. 423 5.1. Relay Set Selection Common Threats 425 Common (i.e., non algorithm specific) threats to RSS algorithms, 426 including Denial of Service attack, eavesdropping, message timing 427 attack and broadcast storm have been discussed in [RFC7186]. 429 5.2. Threats to E-CDS Algorithm 431 The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] 432 forms a single CDS mesh for the SMF operating region. It requires 433 2-hop neighborhood information (the identify of the neighbors, the 434 link to the neighbors and neighbors' priority information) collected 435 through NHDP or another process. 437 An SMF Router will select itself as a relay, if: 439 o The SMF Router has a higher priority than all of its symmetric 440 neighbors, or 442 o There does not exist a path from the neighbor with largest 443 priority to any other neighbor, via neighbors with greater 444 priority. 446 An attacker can disrupt the E-CDS algorithm by link spoofing or 447 identity spoofing. 449 5.2.1. Link Spoofing 451 Link spoofing implies that an attacker advertises non-existing links 452 to another router (present in the network or not). 454 An attacker can declare itself with high route priority, and spoofs 455 the links to as many legitimate SMF Routers as possible to declare 456 high connectivity. By doing so, it can prevent legitimate SMF 457 Routers from self-selecting as relays. As the "super" relay in the 458 network, the attacker can manipulate the traffic relayed by it. 460 5.2.2. Identity Spoofing 462 Identity spoofing implies that an attacker determines and makes use 463 of the identity of other legitimate routers, without being authorized 464 to do so. The identity of other routers can be obtained by 465 overhearing the control messages or the source/destination address 466 from datagrams. The attacker can then generate control or datagram 467 traffic, pretending to be a legitimate router. 469 Because E-CDS self-selection is based on the router priority value, 470 an attacker can spoof the identity of other legitimate routers, and 471 declares a different router priority value. If it declares a higher 472 priority of a spoofed router, it can prevent other routers from 473 selecting themselves as relays. On the other hand, if the attacker 474 declares lower priority of a spoofed router, it can force other 475 routers to selecting themselves as relays, to degrade the multicast 476 forwarding to classical flooding. 478 5.3. Threats to S-MPR Algorithm 480 The source-based multipoint relay (S-MPR) set selection algorithm 481 enables individual routers, using 2-hop topology information, to 482 select relays from their set of neighboring routers. MPRs are 483 selected so that forwarding to the router's complete 2-hop neighbor 484 set is covered. 486 An SMF router forwards a multicast packet if and only if: 488 o the packet has not been received before, and 489 o the neighbor from which the packet was received has selected the 490 router as MPR. 492 Because MPR calculation is based on the willingness declared by the 493 SMF routers, and the connectivity of the routers, it can be disrupted 494 by both link spoofing and identity spoofing. The threats and its 495 impacts have been illustrated in section 5.1 of [RFC7186]. 497 5.4. Threats to MPR-CDS Algorithm 499 MPR-CDS is a derivative from S-MPR. The main difference between 500 S-MPR and MPR-CDS is that while S-MPR forms a different broadcast 501 tree for each source in the network, MPR-CDS forms a unique broadcast 502 tree for all sources in the network. 504 As MPR-CDS combines E-CDS and S-MPR and the simple combination of the 505 two algorithms does not address the weakness, the vulnerabilities of 506 E-CDS and S-MPR that discussed in Section 5.2 and Section 5.3 apply 507 to MPR-CDS also. 509 6. Security Considerations 511 This document does not specify a protocol or a procedure. The whole 512 document, however, reflects on security considerations for SMF for 513 packet dissemination in MANETs. Possible attacks to the two main 514 functional components of SMF, duplicate packet detection and relay 515 set selection, are analyzed and documented. 517 Although [RFC6621] nor this document propose mechanisms to secure the 518 SMF protocol, there are several possibilities to secure the protocol 519 in the future and driving new work by suggesting which threats 520 discussed in the previous sections could be addressed. 522 For the I-DPD mechanism, employing randomized packet sequence numbers 523 can avoid some pre-activation attacks based on sequence number 524 prediction. If predicable sequence numbers have to be used, applying 525 timestamps can mitigate pre-activation attacks. 527 For the H-DPD mechanism, applying cryptographically strong hashes can 528 make the digest collisions effectively impossible, and avoid the use 529 of hash-assistant value. 531 [RFC7182] specifies a framework for representing cryptographic 532 Integrity Check Values (ICVs) and timestamps in MANETs. Based on 533 [RFC7182], [RFC7183] specifies integrity and replay protection for 534 NHDP using shared keys, as a mandatory-to-implement security 535 mechanism. If SMF is using NHDP as neighborhood discovery protocol, 536 implementing [RFC7183] remains advisable so as to enable integrity 537 protection for NHDP control messages. This can help mitigating 538 threats related to identity spoofing through the exchange of HELLO 539 messages, and provides some general protection against identity 540 spoofing by admitting only trusted routers to the network using ICVs 541 in HELLO messages. 543 Using ICVs does, of course, not address the problem of attackers, 544 able to also generate valid ICVs. Detection and exclusion of such 545 attackers is, in general, a challenge, which is not unrelated to how 546 [RFC7182] is used. If, for example, it is used with a shared key (as 547 per [RFC7183]), excluding single attackers generally is not aided by 548 the use of ICVs. However if routers have sufficient capabilities to 549 support the use of asymmetric keys (as per [RFC7859]), part of 550 addressing this challenge becomes one of providing key revocation, in 551 a way that does not in itself introduce additional vulnerabilities. 553 As [RFC7183] does not protect the integrity of the multicast user 554 datagram, and as no mechanism is specified by SMF for doing so, 555 duplicate packet detection remains vulnerable to the threats 556 introduced in Section 4. 558 If pre-activation/de-activation attacks and attack on hash-assistant 559 value of the multicast datagrams are to be mitigated, a datagram- 560 level integrity protection mechanism is desired, by taking 561 consideration of the identity field or hash-assistant value. 562 However, this would not be helpful for the attacks on the TTL (or hop 563 limit for IPv6) field, because the mutable fields are generally not 564 considered when ICV is calculated. 566 7. IANA Considerations 568 This document contains no actions for IANA. 570 [RFC Editor: please remove this section prior to publication.] 572 8. Acknowledgments 574 The authors would like to thank Christopher Dearlove (BAE Systems 575 ATC) who provided detailed review and valuable comments. 577 9. References 578 9.1. Normative References 580 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 581 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 582 RFC 6130, April 2011. 584 [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, 585 May 2012. 587 [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for 588 the Neighborhood Discovery Protocol (NHDP)", RFC 7186, 589 April 2014. 591 9.2. Informative References 593 [MOBICOM99] 594 Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast 595 Storm Problem in a Mobile Ad Hoc Network", Proceedings of 596 the 5th annual ACM/IEEE international conference on Mobile 597 computing and networking, 1999. 599 [MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing 600 Connected Dominating Sets with Multipoint Relays", Journal 601 of Ad Hoc and Sensor Wireless Networks 2002, January 2002. 603 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 604 Routing Protocol", RFC 3626, October 2003. 606 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 607 RFC 4949, August 2007. 609 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 610 Considerations in Mobile Ad Hoc Networks (MANETs)", 611 RFC 5148, February 2008. 613 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 614 "Generalized MANET Packet/Message Format", RFC 5444, 615 February 2009. 617 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 618 Extension of OSPF Using Connected Dominating Set (CDS) 619 Flooding", RFC 5614, August 2009. 621 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 622 "The Optimized Link State Routing Protocol version 2", 623 RFC 7181, April 2014. 625 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 626 Check Value and Timestamp TLV Definitions for Mobile Ad 627 Hoc Networks (MANETs)", RFC 7182, April 2014. 629 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 630 Protection for the Neighborhood Discovery Protocol (NHDP) 631 and Optimized Link State Routing Protocol Version 2 632 (OLSRv2)", RFC 7183, April 2014. 634 [RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc 635 Network (MANET) Routing Protocols", RFC 7859, 636 DOI 10.17487/RFC7859, May 2016, 637 . 639 Authors' Addresses 641 Jiazi Yi 642 Ecole Polytechnique 643 91128 Palaiseau Cedex, 644 France 646 Phone: +33 1 77 57 80 85 647 Email: jiazi@jiaziyi.com 648 URI: http://www.jiaziyi.com/ 650 Thomas Heide Clausen 651 Ecole Polytechnique 652 91128 Palaiseau Cedex, 653 France 655 Phone: +33 6 6058 9349 656 Email: T.Clausen@computer.org 657 URI: http://www.thomasclausen.org/ 659 Ulrich Herberg 661 Email: ulrich@herberg.name 662 URI: http://www.herberg.name/