diff options
Diffstat (limited to 'doc/rfc/rfc7985.txt')
| -rw-r--r-- | doc/rfc/rfc7985.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7985.txt b/doc/rfc/rfc7985.txt new file mode 100644 index 0000000..a7894b2 --- /dev/null +++ b/doc/rfc/rfc7985.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Yi +Request for Comments: 7985 T. Clausen +Updates: 7186 Ecole Polytechnique +Category: Informational U. Herberg +ISSN: 2070-1721 November 2016 + + + Security Threats to Simplified Multicast Forwarding (SMF) + +Abstract + + This document analyzes security threats to Simplified Multicast + Forwarding (SMF), including vulnerabilities of duplicate packet + detection and relay set selection mechanisms. This document is not + intended to propose solutions to the threats described. + + In addition, this document updates RFC 7186 regarding threats to the + relay set selection mechanisms using the Mobile Ad Hoc Network + (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130). + +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 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 7841. + + 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/rfc7985. + + + + + + + + + + + + + + + + + +Yi, et al. Informational [Page 1] + +RFC 7985 Security Threats for SMF November 2016 + + +Copyright Notice + + Copyright (c) 2016 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. SMF Threat Overview . . . . . . . . . . . . . . . . . . . . . 4 + 4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5 + 4.1. Attack on the Hop Limit Field . . . . . . . . . . . . . . 6 + 4.2. Threats to Identification-Based Duplicate Packet + Detection . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2.1. Pre-Activation Attacks (Pre-Play) . . . . . . . . . . 7 + 4.2.2. De-activation Attacks (Sequence Number Wrangling) . . 8 + 4.3. Threats to Hash-Based Duplicate Packet Detection . . . . 9 + 4.3.1. Attack on the Hash-Assistant Value . . . . . . . . . 9 + 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . 10 + 5.1. Common Threats to Relay Set Selection . . . . . . . . . . 10 + 5.2. Threats to the E-CDS Algorithm . . . . . . . . . . . . . 10 + 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11 + 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 + 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . 11 + 5.4. Threats to the MPR-CDS Algorithm . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . 13 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + + + + + + + + + + +Yi, et al. Informational [Page 2] + +RFC 7985 Security Threats for SMF November 2016 + + +1. Introduction + + This document analyzes security threats to Simplified Multicast + Forwarding (SMF) [RFC6621]. SMF aims at providing basic Internet + Protocol (IP) multicast forwarding in a way that is suitable for + wireless mesh and Mobile Ad Hoc Networks (MANET). SMF consists of + two major functional components: duplicate packet detection (DPD) and + relay set selection (RSS). + + SMF is typically used in decentralized wireless environments and is + potentially exposed to various attacks and misconfigurations. In a + wireless environment, some of these attacks and misconfigurations + represent threats of particular significance as compared to what they + would do in wired networks. [RFC6621] briefly discusses several of + these, but does not define any explicit security measures for + protecting the integrity of the protocol. + + 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 support deployment of such common IP + protection mechanisms (e.g., because MANET routers may have limited + resources for supporting the IPsec stack). It also assumes that + there is no lower-layer protection. The document analyzes possible + attacks on, and misconfigurations of, SMF and outlines the + consequences of such attacks/misconfigurations to the state + maintained by SMF in each router. + + In the Security Considerations section of [RFC6621], denial-of- + service-attack scenarios are briefly discussed. This document + further analyzes and describes the potential vulnerabilities of, and + attack vectors for, SMF. While completeness in such analysis is + always a goal, no claims of being complete are made. The goal of + this document is to be helpful when deploying SMF in a network and + for understanding the risks incurred, as well as for providing a + reference to and documented experience with SMF as input for possible + future developments of SMF. + + This document is not intended to propose solutions to the threats + described. [RFC7182] provides a framework that can be used with SMF, + and depending on how it is used, may offer some degree of protection + against the threats related to identity spoofing described in this + document. + + This document also updates [RFC7186], specifically with respect to + threats to relay set selection (RSS) mechanisms that are using MANET + NHDP [RFC6130]. + + + + + +Yi, et al. Informational [Page 3] + +RFC 7985 Security Threats for SMF November 2016 + + +2. Terminology + + This document uses the terminology and notation defined in [RFC5444], + [RFC6130], [RFC6621], and [RFC4949]. + + Additionally, this document introduces the following terminology: + + SMF router: A MANET router, running SMF as specified in [RFC6621]. + + Attacker: A device that is present in the network and intentionally + seeks to compromise the information bases in SMF routers. It may + generate syntactically correct SMF control messages. + + Legitimate SMF router: An SMF router that is correctly configured + and not compromised by an attacker. + +3. SMF Threat Overview + + An SMF router requires an external dynamic neighborhood discovery + mechanism in order to maintain suitable topological information + describing its immediate neighborhood, and thereby allowing it to + select reduced relay sets for forwarding multicast data traffic. + Such an external dynamic neighborhood discovery mechanism may be + provided by lower-layer interface information, by a concurrently + operating MANET routing protocol that already maintains such + information (e.g., [RFC7181]) or by explicitly using the MANET + Neighborhood Discovery Protocol (NHDP) [RFC6130]. If NHDP is used + for both 1-hop and 2-hop neighborhood discovery by SMF, SMF + implicitly inherits the vulnerabilities of NHDP discussed in + [RFC7186]. As SMF relies on NHDP to assist in network-layer 2-hop + neighborhood discovery (no matter if other lower-layer mechanisms are + used for 1-hop neighborhood discovery), this document assumes that + NHDP is used in SMF. The threats that are NHDP specific are + indicated explicitly. + + Based on neighborhood discovery mechanisms, [RFC6621] specifies two + principal functional components: duplicate packet detection (DPD) and + relay set selection (RSS). + + DPD is required by SMF in order to be able to detect duplicate + packets and eliminate their redundant forwarding. An attacker has + two ways in which to harm the DPD mechanisms. Specifically, it can: + + o "deactivate" DPD, making it such that duplicate packets are not + correctly detected. As a consequence, they are (redundantly) + transmitted, which increases the load on the network, drains the + batteries of the routers involved, etc. + + + + +Yi, et al. Informational [Page 4] + +RFC 7985 Security Threats for SMF November 2016 + + + o "pre-activate" DPD, making DPD detect a later arriving (valid) + packet as being a duplicate and will, therefore, not be forwarded. + + Attacks on DPD can be achieved by replaying existing packets, + wrangling sequence numbers, manipulating hash values, etc.; these are + detailed in Section 4. + + RSS produces a reduced relay set for forwarding multicast data + packets across a MANET. For use in SMF, [RFC6621] specifies several + relay set algorithms including E-CDS (Essential Connected Dominating + Set) [RFC5614], S-MPR (Source-Based Multipoint Relay, as known from + [RFC3626] and [RFC7181]), and MPR-CDS (Multipoint Relay Connected + Dominating Set) [MPR-CDS]. An attacker can disrupt the RSS + algorithm, and thereby the SMF operation, by degrading it to + classical flooding or by "masking" certain parts of the network from + the multicasting domain. Attacks on RSS algorithms are detailed in + Section 5. + + Other than the attacks on DPD and RSS, a common vulnerability of + MANETs is "jamming", i.e., 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. The attacks on DPD and RSS can be further enhanced by + jamming. + +4. Threats to Duplicate Packet Detection + + Duplicate packet detection (DPD) is required for packet dissemination + in MANETs because: (1) packets may be retransmitted via the same + physical interface as the one over which they were received, and (2) + a router may receive multiple copies of the same packet (on the same + or on different interfaces) from different neighbors. DPD is thus + used to check whether or not an incoming packet has been previously + received. + + DPD is achieved by maintaining a record of recently processed + multicast packets, and comparing later received multicast packets + herewith. A duplicate packet detected is silently dropped and is not + inserted into the forwarding path of that router, nor is it delivered + to an application. DPD, as proposed by SMF, supports both IPv4 and + IPv6 and suggests two duplicate packet detection mechanisms for each: + 1) IP packet header content identification-based DPD (I-DPD), in + combination with flow state, to estimate temporal uniqueness of a + packet, and 2) hash-based DPD (H-DPD), employing hashing of selected + IP packet header fields and payload for the same effect. + + + + + + +Yi, et al. Informational [Page 5] + +RFC 7985 Security Threats for SMF November 2016 + + + In the Security Considerations section of [RFC6621], a selection of + threats to DPD are briefly introduced. This section expands on that + discussion and describes how to effectively launch the attacks on DPD + -- for example, by way of manipulating jitter and/or the Hash- + Assistant Value. In the remainder of this section, common threats to + packet detection mechanisms are discussed first; then, the threats to + I-DPD and H-DPD are introduced separately. The threats described in + this section are applicable to general SMF implementations, + regardless of whether NHDP is used. + +4.1. Attack on the Hop Limit Field + + One immediate Denial-of-Service (DoS) attack is based on manipulating + the Time-to-Live (TTL, for IPv4) or Hop Limit (for IPv6) field. As + routers only forward packets with TTL > 1, an attacker can forward an + otherwise valid packet while drastically reducing the TTL hereof. + This will inhibit recipient routers from later forwarding the same + multicast packet, even if received with a different TTL -- + essentially, an attacker can thus instruct its neighbors to block the + forwarding of valid multicast packets. + + For example, in Figure 1, router A forwards a multicast packet with a + TTL of 64 to the network. A, B, and C are legitimate SMF routers, + and X is an attacker. In a wireless environment, jitter is commonly + used to avoid systematic collisions in Media Access Control (MAC) + protocols [RFC5148]. An attacker can thus increase the probability + that its invalid packets arrive first by retransmitting them without + applying jitter. In this example, router X forwards the packet + without applying jitter and reduces the TTL to 1. Router C thus + records the duplicate detection value (hash value for H-DPD or the + header content of the packets for I-DPD) but does not forward the + packet (due to TTL == 1). When a second copy of the same packet, + with a non-maliciously manipulated TTL value (63 in this case), + arrives from router B, it will be discarded as a duplicate packet. + + .---. + | X | + --'---' __ + packet with TTL=64 / \ packet with TTL=1 + / \ + .---. .---. + | A | | C | + '---' '---' + packet with TTL=64 \ .---. / + \-- | B |__/ packet with TTL=63 + '---' + + Figure 1 + + + +Yi, et al. Informational [Page 6] + +RFC 7985 Security Threats for SMF November 2016 + + + As the TTL of a packet is intended to be manipulated by + intermediaries forwarding it, classic methods such as integrity check + values (e.g., digital signatures) are typically calculated by setting + TTL fields to some predetermined value (e.g., 0) -- for example, the + case for IPsec Authentication Headers -- rendering such an attack + more difficult to both detect and counter. + + If the attacker has access to a "wormhole" through the network (a + directional antenna, a tunnel to a collaborator, or a wired + connection, allowing it to bridge parts of a network otherwise + distant), it can make sure that the packets with such an artificially + reduced TTL arrive before their unmodified counterparts. + +4.2. Threats to Identification-Based Duplicate Packet Detection + + I-DPD uses a specific DPD identifier in the packet header to identify + a packet. By default, such packet identification is not provided by + the IP packet header (for both IPv4 and IPv6). Therefore, additional + identification headers, such as the fragment header, a hop-by-hop + header option, or IPsec sequencing, must be employed in order to + support I-DPD. The uniqueness of a packet can then be identified by + the source IP address of the packet originator and the sequence + number (from the fragment header, hop-by-hop header option, or + IPsec). By doing so, each intermediate router can keep a record of + recently received packets and determine whether or not the incoming + packet has been received. + +4.2.1. Pre-Activation Attacks (Pre-Play) + + In a wireless environment, or across any other shared channel, an + attacker can perceive the identification tuple (source IP address, + sequence number) of a packet. It is possible to generate a packet + with the same (source IP address, sequence number) pair with invalid + content. If the sequence number progression is predictable, then it + is trivial to generate and inject invalid packets with "future" + identification information into the network. If these invalid + packets arrive before the legitimate packets that they are spoofing, + the latter will be treated as a duplicate and will be discarded. + This can prevent multicast packets from reaching parts of the + network. + + Figure 2 gives an example of a pre-activation attack. A, B, and C + are legitimate SMF routers, and X is the attacker. The line between + the routers presents the packet forwarding. Router A is the source + and originates a multicast packet with sequence number n. When + router X receives the packet, it generates an invalid packet with the + source address of A and sequence number n. If the invalid packet + arrives at router C before the forwarding of router B, the valid + + + +Yi, et al. Informational [Page 7] + +RFC 7985 Security Threats for SMF November 2016 + + + packet will be dropped by C as a duplicate packet. An attacker can + manipulate jitter to make sure that the invalid packets arrive first. + Router X can even generate packets with future sequence numbers (if + they are predictable), so that the future legitimate packets with the + same sequence numbers will be dropped as duplicate ones. + + .---. + | X | + --'---' __ + packet with seq=n / \ invalid packet with seq=n + / \ + .---. .---. + | A | | C | + '---' '---' + packet with seq=n \ .---. / + \-- | B |__/ valid packet with seq=n + '---' + + Figure 2 + + As SMF does not currently have any timestamp mechanisms to protect + data packets, there is no viable way to detect such pre-play attacks + by way of timestamps. Especially, if the attack is based on + manipulation of jitter, the validation of the timestamp would not be + helpful because the timing is still valid (but, much less valuable). + +4.2.2. De-activation Attacks (Sequence Number Wrangling) + + An attacker can also seek to de-activate DPD by modifying the + sequence number in packets that it forwards. Thus, routers will not + be able to detect an actual duplicate packet as a duplicate -- + rather, they will treat them as new packets, i.e., process and + forward them. This is similar to DoS attacks, as each packet that is + considered unique will be multicasted: for a network with n routers, + there will be n-1 retransmissions. This can easily cause the + "broadcast storm" problem discussed in [MOBICOM99]. The consequence + of this attack is an increased channel load, the origin of which + appears to be a router other than the attacker. + + Given the topology shown in Figure 2, on receiving a packet with + seq=n, the attacker X can forward the packet with a modified sequence + number n+i. This has two consequences: firstly, router C will not be + able to detect that the packet forwarded by X is a duplicate packet; + secondly, the consequent packet with seq=n+i generated by router A + will probably be treated as a duplicate packet and will be dropped by + router C. + + + + + +Yi, et al. Informational [Page 8] + +RFC 7985 Security Threats for SMF November 2016 + + +4.3. Threats to Hash-Based Duplicate Packet Detection + + When explicit sequence numbers in packet headers is undesired, hash- + based DPD can be used. A hash of the non-mutable fields in the + header of the data payload can be generated and recorded at the + intermediate routers. A packet can thus be uniquely identified by + the source IP address of the packet and its hash-value. + + The hash algorithm used by SMF is being applied only to provide a + reduced probability of collision and is not being used for + cryptographic or authentication purposes. Consequently, a digest + collision is still possible. In case the source router or gateway + identifies that it has recently generated or injected a packet with + the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6 + header option into the packet, such that also calculating the hash + over this HAV will render the resulting value unique. + +4.3.1. Attack on the Hash-Assistant Value + + The HAV header is helpful when a digest collision happens. However, + it also introduces a potential vulnerability. As the HAV option is + only added when the source or the ingress SMF router detects that the + incoming packet has digest collision with previously generated + packets, it can actually be regarded as a "flag" of potential digest + collision. An attacker can discover the HAV header and be able to + conclude that a hash collision is possible if the HAV header is + removed. By doing so, the modified packet received by other SMF + routers will be treated as duplicate packets and will be dropped + because they have the same hash value as previously received packets. + + In the example shown in Figure 3, routers A and B are legitimate SMF + routers; X is an attacker. Router A generates two packets, P1 and + P2, with the same hash value h(P1)=h(P2)=x. Based on the SMF + specification, a HAV is added to the latter packet P2, so that + h(P2+HAV)=x' avoids digest collision. When the attacker X detects + the HAV of P2, it is able to conclude that a collision is possible by + removing the HAV header. By doing so, packet P2 will be treated as a + duplicate packet by router B and will be dropped. + + P2 P1 P2 P1 + .---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---. + | A |---------------------------> | X | ----------------------> | B | + `---' `---' `---' + + Figure 3 + + + + + + +Yi, et al. Informational [Page 9] + +RFC 7985 Security Threats for SMF November 2016 + + +5. Threats to Relay Set Selection + + A framework for an RSS mechanism, rather than a specific RSS + algorithm, is provided by SMF. Relay Set Selection is normally + achieved by distributed algorithms that can dynamically generate a + topological Connected Dominating Set based on 1-hop and 2-hop + neighborhood information. In this section, common threats to the RSS + framework are first discussed. Then specific threats to the three + algorithms (Essential Connection Dominating Set (E-CDS), Source-Based + Multipoint Relay (S-MPR), and Multipoint Relay Connected Dominating + Set (MPR-CDS)) explicitly enumerated by [RFC6621] are analyzed. As + the relay set selection is based on 1-hop and 2-hop neighborhood + information, which rely on NHDP, the threats described in this + section are NHDP specific. + +5.1. Common Threats to Relay Set Selection + + Non-algorithm-specific threats to RSS algorithms, including DoS + attacks, eavesdropping, message timing attacks, and broadcast storm, + are discussed in [RFC7186]. + +5.2. Threats to the E-CDS Algorithm + + The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] + forms a single CDS mesh for an SMF operating region. This algorithm + requires 2-hop neighborhood information (the identity of the + neighbors, the link to the neighbors, and the neighbors' priority + information), as collected through NHDP or another process. + + An SMF router will select itself as a relay, if: + + o The SMF router has a higher priority than all of its symmetric + neighbors, or + + o A path from the neighbor with the largest priority to any other + neighbor via neighbors with greater priority than the current + router does not exist. + + An attacker can disrupt the E-CDS algorithm by link spoofing or + identity spoofing. + + + + + + + + + + + +Yi, et al. Informational [Page 10] + +RFC 7985 Security Threats for SMF November 2016 + + +5.2.1. Link Spoofing + + Link spoofing implies that an attacker advertises non-existing links + to another router (which may or may not be present in the network). + + An attacker can declare itself to have high route priority and spoof + the links to as many legitimate SMF routers as possible to declare + high connectivity. By doing so, it can prevent legitimate SMF + routers from selecting themselves as relays. As the "super" relay in + the network, the attacker can manipulate the traffic it relays. + +5.2.2. Identity Spoofing + + Identity spoofing implies that an attacker determines and makes use + of the identity of other legitimate routers, without being authorized + to do so. The identity of other routers can be obtained by + eavesdropping the control messages or the source/destination address + from datagrams. The attacker can then generate control or datagram + traffic by pretending to be a legitimate router. + + Because E-CDS self-selection is based on the router priority value, + an attacker can spoof the identity of other legitimate routers and + declare a different router priority value. If it declares that a + spoofed router has a higher priority, it can prevent other routers + from selecting themselves as relays. On the other hand, if the + attacker declares that a spoofed router has a lower priority, it can + force other routers to select themselves as relays to degrade the + multicast forwarding to classical flooding. + +5.3. Threats to S-MPR Algorithm + + The S-MPR set selection algorithm enables individual routers, using + 2-hop topology information, to select relays from among their set of + neighboring routers. MPRs are selected by each router such that a + message generated by it, and relayed only by its MPRs, will reach all + of its 2-hop neighbors. + + An SMF router forwards a multicast packet if and only if: + + o the packet has not been received before, and + + o the neighbor from which the packet was received has selected the + router as MPR. + + Because MPR calculation is based on the willingness declared by the + SMF routers and the connectivity of the routers, it can be disrupted + by both link spoofing and identity spoofing. These threats and their + impacts have been illustrated in Section 5.1 of [RFC7186]. + + + +Yi, et al. Informational [Page 11] + +RFC 7985 Security Threats for SMF November 2016 + + +5.4. Threats to the MPR-CDS Algorithm + + MPR-CDS is a derivative from S-MPR. The main difference between + S-MPR and MPR-CDS is that while S-MPR forms a different broadcast + tree for each source in the network, MPR-CDS forms a unique broadcast + tree for all sources in the network. + + As MPR-CDS combines E-CDS and S-MPR and the simple combination of the + two algorithms does not address the weaknesses; the vulnerabilities + of E-CDS and S-MPR that are discussed in Sections 5.2 and 5.3 apply + to MPR-CDS also. + +6. Security Considerations + + This document does not specify a protocol or a procedure. The whole + document, however, reflects on security considerations for SMF + regarding packet dissemination in MANETs. Possible attacks to the + two main functional components of SMF, duplicate packet detection, + and relay set selection are analyzed and documented. + + Although neither [RFC6621] nor this document propose mechanisms to + secure the SMF protocol, there are several possibilities to secure + the protocol in the future and drive new work by suggesting which + threats discussed in the previous sections could be addressed. + + For the I-DPD mechanism, employing randomized packet sequence numbers + can avoid some pre-activation attacks based on sequence number + prediction. If predicable sequence numbers have to be used, applying + timestamps can mitigate pre-activation attacks. + + For the H-DPD mechanism, applying cryptographically strong hashes can + make the digest collisions effectively impossible, and it can avoid + the use of a HAV. + + [RFC7182] specifies a framework for representing cryptographic + Integrity Check Values (ICVs) and timestamps in MANETs. Based on + [RFC7182], [RFC7183] specifies integrity and replay protection for + NHDP using shared keys as a mandatory-to-implement security + mechanism. If SMF is using NHDP as the neighborhood discovery + protocol, implementing [RFC7183] remains advisable so as to enable + integrity protection for NHDP control messages. This can help + mitigate threats related to identity spoofing through the exchange of + HELLO messages and provide some general protection against identity + spoofing by admitting only trusted routers to the network using ICVs + in HELLO messages. + + + + + + +Yi, et al. Informational [Page 12] + +RFC 7985 Security Threats for SMF November 2016 + + + Using ICVs does not, of course, address the problem of attackers able + to also generate valid ICVs. Detection and exclusion of such + attackers is, in general, a challenge that is not unrelated to how + [RFC7182] is used. If, for example, it is used with a shared key (as + per [RFC7183]), excluding single attackers generally is not aided by + the use of ICVs. However, if routers have sufficient capabilities to + support the use of asymmetric keys (as per [RFC7859]), part of + addressing this challenge becomes one of providing key revocation in + a way that does not in itself introduce additional vulnerabilities. + + As [RFC7183] does not protect the integrity of the multicast user + datagram, and as no mechanism is specified by SMF for doing so, + duplicate packet detection remains vulnerable to the threats + introduced in Section 4. + + If pre-activation/de-activation attacks and attacks on the HAV of the + multicast datagrams are to be mitigated, a datagram-level integrity + protection mechanism is desired, by taking consideration of the + identity field or HAV. However, this would not be helpful for the + attacks on the TTL (or Hop Limit for IPv6) field, because the mutable + fields are generally not considered when ICV is calculated. + +7. References + +7.1. Normative References + + [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc + Network (MANET) Neighborhood Discovery Protocol (NHDP)", + RFC 6130, DOI 10.17487/RFC6130, April 2011, + <http://www.rfc-editor.org/info/rfc6130>. + + [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", + RFC 6621, DOI 10.17487/RFC6621, May 2012, + <http://www.rfc-editor.org/info/rfc6621>. + + [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for + the Neighborhood Discovery Protocol (NHDP)", RFC 7186, + DOI 10.17487/RFC7186, April 2014, + <http://www.rfc-editor.org/info/rfc7186>. + +7.2. Informative References + + [MOBICOM99] + Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The broadcast + storm problem in a mobile ad hoc network", MobiCom + '99 Proceedings of the 5th annual ACM/IEEE international + conference on Mobile computing and networking, + DOI 10.1145/313451.313525, 1999. + + + +Yi, et al. Informational [Page 13] + +RFC 7985 Security Threats for SMF November 2016 + + + [MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing + Connected Dominating Sets with Multipoint Relays", Journal + of Ad Hoc and Sensor Wireless Networks 2002, January 2002. + + [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link + State Routing Protocol (OLSR)", RFC 3626, + DOI 10.17487/RFC3626, October 2003, + <http://www.rfc-editor.org/info/rfc3626>. + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, + <http://www.rfc-editor.org/info/rfc4949>. + + [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter + Considerations in Mobile Ad Hoc Networks (MANETs)", + RFC 5148, DOI 10.17487/RFC5148, February 2008, + <http://www.rfc-editor.org/info/rfc5148>. + + [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, + "Generalized Mobile Ad Hoc Network (MANET) Packet/Message + Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, + <http://www.rfc-editor.org/info/rfc5444>. + + [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) + Extension of OSPF Using Connected Dominating Set (CDS) + Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, + <http://www.rfc-editor.org/info/rfc5614>. + + [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, + "The Optimized Link State Routing Protocol Version 2", + RFC 7181, DOI 10.17487/RFC7181, April 2014, + <http://www.rfc-editor.org/info/rfc7181>. + + [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity + Check Value and Timestamp TLV Definitions for Mobile Ad + Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, + April 2014, <http://www.rfc-editor.org/info/rfc7182>. + + [RFC7183] 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 7183, DOI 10.17487/RFC7183, April 2014, + <http://www.rfc-editor.org/info/rfc7183>. + + [RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc + Network (MANET) Routing Protocols", RFC 7859, + DOI 10.17487/RFC7859, May 2016, + <http://www.rfc-editor.org/info/rfc7859>. + + + +Yi, et al. Informational [Page 14] + +RFC 7985 Security Threats for SMF November 2016 + + +Acknowledgments + + The authors would like to thank Christopher Dearlove (BAE Systems + ATC) who provided detailed review and valuable comments. + +Authors' Addresses + + Jiazi Yi + Ecole Polytechnique + 91128 Palaiseau Cedex + France + + Phone: +33 1 77 57 80 85 + Email: jiazi@jiaziyi.com + URI: http://www.jiaziyi.com/ + + + Thomas Heide Clausen + Ecole Polytechnique + 91128 Palaiseau Cedex + France + + Phone: +33 6 6058 9349 + Email: T.Clausen@computer.org + URI: http://www.thomasclausen.org/ + + + Ulrich Herberg + + Email: ulrich@herberg.name + URI: http://www.herberg.name/ + + + + + + + + + + + + + + + + + + + + +Yi, et al. Informational [Page 15] + |