    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]