Mobile Ad hoc Networking (MANET)
Internet Engineering Task Force (IETF)                             J. Yi
Internet-Draft
Request for Comments: 7985                                    T. Clausen
Updates: 7186 (if approved)                                        Ecole Polytechnique
Intended status:
Category: Informational                                       U. Herberg
Expires: February 28, 2017                               August 27,
ISSN: 2070-1721                                             October 2016

       Security Threats for to Simplified Multicast Forwarding (SMF)
                  draft-ietf-manet-smf-sec-threats-06

Abstract

   This document analyzes security threats of the to Simplified Multicast
   Forwarding (SMF) mechanism, (SMF), including the vulnerabilities of duplicate packet
   detection and relay set selection mechanisms.  This document is not
   intended to propose solutions to the threats described.

   This

   In addition, this document also updates RFC7186 RFC 7186 regarding the threats to the
   relay set selection mechanisms using RFC6130. the Mobile Ad Hoc Network
   (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).

Status of this This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working  It has been approved for publication by the Internet
   Engineering Steering Group (IESG).  Not all documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts approved by the
   IESG are draft documents valid for a maximum candidate for any level of Internet Standard; see
   Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 28, 2017.
   http://www.rfc-editor.org/info/rfc7985.

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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  4   3
   3.  SMF Threats Threat Overview . . . . . . . . . . . . . . . . . . . . .   4
   4.  Threats to Duplicate Packet Detection . . . . . . . . . . . .   5
     4.1.  Attack to The on the Hop Limit Field . . . . . . . . . . . . . .  6   5
     4.2.  Threats to Identification-based Identification-Based Duplicate Packet
           Detection . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.1.  Pre-activation  Pre-Activation Attacks (Pre-Play) . . . . . . . . . .   7
       4.2.2.  De-activation Attacks (Sequence Number wrangling) Wrangling) . .   8
     4.3.  Threats to Hash-based Hash-Based Duplicate Packet Detection  . . . . .  9   8
       4.3.1.  Attack on the Hash-Assistant Value  . . . . . . . . . . . .   9
   5.  Threats to Relay Set Selection  . . . . . . . . . . . . . . . . 10   9
     5.1.  Common Threats to Relay Set Selection Common Threats . . . . . . . . . . . .  10
     5.2.  Threats to the E-CDS Algorithm  . . . . . . . . . . . . . . . .  10
       5.2.1.  Link Spoofing . . . . . . . . . . . . . . . . . . . . 11  10
       5.2.2.  Identity Spoofing . . . . . . . . . . . . . . . . . . 11  10
     5.3.  Threats to S-MPR Algorithm  . . . . . . . . . . . . . . . .  11
     5.4.  Threats to the MPR-CDS Algorithm  . . . . . . . . . . . . . . . 12  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . .  References  . . . 13
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  13
   9.
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 15  14

1.  Introduction

   This document analyzes security threats to the Simplified Multicast
   Forwarding (SMF) mechanism [RFC6621].  SMF aims at providing basic Internet
   Protocol (IP) multicast forwarding, forwarding in a way that is suitable for limited
   wireless mesh and Mobile Ad hoc NETworks Hoc Networks (MANET).  SMF is constituted consists of
   two major functional components:
   Duplicate Packet Detection duplicate packet detection (DPD) and Relay Set Selection.
   relay set selection (RSS).

   SMF is typically used in decentralized wireless environments, environments and is
   potentially exposed to various attacks and misconfigurations.  Some  In a
   wireless environment, some of these attacks and misconfigurtions, in a wireless enviroment, 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
   mechanism, such as IPsec IPsec, is used in the IP layer, as not all MANET
   deployments may be suitable able to deploy support deployment of such common IP
   protection mechanisms (e.g., because of limited resources of MANET routers to support may have limited
   resources for supporting the IPsec stack).  It also assumes that
   there is no lower-layer protection
   either. protection.  The document analyzes possible
   attacks on on, and mis-
   configurations of misconfigurations of, SMF and outlines the
   consequences of such attacks/
   mis-configurations attacks/misconfigurations to the state
   maintained by SMF in each router.

   In the Security Considerations section of [RFC6621], denial-of-
   service attack
   service-attack scenarios are briefly discussed.  This document
   further analyzes and describes the potential vulnerabilities of of, and
   attack vectors for 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 for when deploying SMF in a network and needing to understand
   for understanding the risks thereby incurred - incurred, as well as for providing a
   reference to and documented experience with SMF as input for
   possibly 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 - used, may offer some degree of protection
   against the threats described in this document related to identity
   spoofing. spoofing described in this
   document.

   This document also updates [RFC7186], specifically with respect to
   threats to relay set selection (RSS) mechanisms which that are using MANET
   NHDP [RFC6130].

2.  Terminology

   This document uses the terminology and notation defined in [RFC5444],
   [RFC6130], [RFC6621] [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 Threats 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 lower-layer interface information, by a concurrently
   operating MANET routing protocol that already maintains such
   information such as
   [RFC7181], (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 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 NHDP specific are
   indicated explicitly.

   Based on neighborhood discovery mechanisms, [RFC6621] specifies two
   principal functional components: Duplicate Packet Detection duplicate packet detection (DPD) and
   Relay Set Selection
   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 attacker has
   two ways in which to harm the DPD mechanisms, specifically mechanisms.  Specifically, it can:

   o  "deactivate" DPD, so as to make making it such that duplicate packets are not
      correctly detected, and that as detected.  As a consequence consequence, they are (redundantly)
      transmitted, increasing which increases the load on the network,
      draining drains the
      batteries of the routers involved, etc.

   o  "pre-activate" DPD, so as to make making DPD detect a later arriving (valid)
      packet as being a duplicate, which therefore won't duplicate and will, therefore, not be forwarded.

   Attacks on DPD can be achieved by replaying existing packets, by
   wrangling sequence numbers, by manipulating hash values, etc., and etc.; these are
   detailed in Section 4.

   RSS produces a reduced relay set for forwarding multicast data
   packets across the a MANET.  For use in SMF, [RFC6621] specifies several
   relay set
   algorithms, algorithms including E-CDS (Essential Connected Dominating
   Set) [RFC5614], S-MPR (Source-based Multi-point (Source-Based Multipoint Relay, as known from
   [RFC3626] and [RFC7181]), or and MPR-CDS [MPR-CDS], for use in SMF. (Multipoint Relay Connected
   Dominating Set) [MPR-CDS].  An
   Attacker attacker can disrupt the RSS
   algorithm, and thereby the SMF operation, by degrading it to
   classical flooding, 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 packet detection (DPD) is required for packet dissemination
   in MANETs because: (1) packets may be transmitted 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, same
   or on different interfaces) from different neighbors.  DPD is thus
   used to check if whether or not an incoming packet has been previously received or
   not.
   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 for each suggests two duplicate packet detection mechanisms: mechanisms for each:
   1) IP packet header content identification-based DPD (I-DPD), using packet
   headers, 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.

   In the Security Considerations section of [RFC6621], a selection of
   threats to DPD are briefly introduced.  This section expands on that
   discussion,
   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 first discussed.  Then 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, no matter
   if
   regardless of whether NHDP is used or not. used.

4.1.  Attack to The on the Hop Limit Field

   One immediate DoS Denial-of-Service (DoS) attack is based on manipulating
   the Time-to-Live (TTL, for IPv4) or hop limit Hop Limit (for IPv6) field.  As
   routers only forward packets with TTL > 1, an attacker can forward an
   otherwise valid packet, 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 --
   essentially, an attacker thus 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 MAC 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, H-DPD or the
   header content of the packets for I-DPD) but does not forward the
   packet (due to TTL == 1) not forward. 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

   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 with by setting
   TTL fields to some pre-determined predetermined value (e.g., 0) - such is -- for example 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 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 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 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 or not. received.

4.2.1.  Pre-activation  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 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
   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 currently 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 with (but, much less value). valuable).

4.2.2.  De-activation Attacks (Sequence Number wrangling) Wrangling)

   An attacker can also seek to de-activate DPD, 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
   probably
   will probably be treated as a duplicate packet, packet and will be dropped by
   router C.

4.3.  Threats to Hash-based 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 and the data payload can be generated, 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 recently 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 also
   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
   coming
   incoming packet has digest collision with previously generated
   packets, it actually can actually be regarded as a "flag" of potential digest
   collision.  An attacker can discover the HAV header, 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, packets and will be dropped
   because they have the same hash value with the precedent packet. as previously received packets.

   In the example of shown in Figure 3, Router routers A and B are legitimate SMF
   routers; X is an attacker.  Router A generates two packets packets, P1 and
   P2, with the same hash value h(P1)=h(P2)=x.  Based on the SMF
   specification, a
   hash-assistant value (HAV) HAV is added to the latter packet P2, so that
   h(P2+HAV)=x', to avoid
   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, 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

5.  Threats to Relay Set Selection

   A framework for an RSS mechanism, rather than a specific RSS algorithm
   algorithm, is provided by SMF.  It  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, the common threats to the RSS
   framework are first discussed.  Then specific threats to the three commonly used algorithms: Essential
   algorithms (Essential Connection Dominating Set (E-CDS) algorithm, Source-based (E-CDS), Source-Based
   Multipoint Relay (S-MPR) (S-MPR), and Multipoint Relay Connected Dominating
   Set (MPR-CDS) (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. NHDP specific.

5.1.  Common Threats to Relay Set Selection Common Threats

   Common (i.e., non algorithm specific)

   Non-algorithm-specific threats to RSS algorithms, including Denial of Service attack, DoS
   attacks, eavesdropping, message timing
   attack attacks, and broadcast storm have been 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 the an SMF operating region.  It  This algorithm
   requires 2-hop neighborhood information (the identify identity of the
   neighbors, the link to the neighbors neighbors, and the neighbors' priority information)
   information), as collected through NHDP or another process.

   An SMF Router router will select itself as a relay, if:

   o  The SMF Router router has a higher priority than all of its symmetric
      neighbors, or

   o  There does not exist a  A path from the neighbor with the largest priority to any other neighbor,
      neighbor via neighbors with greater
      priority. priority than the current
      router does not exist.

   An attacker can disrupt the E-CDS algorithm by link spoofing or
   identity spoofing.

5.2.1.  Link Spoofing

   Link spoofing implies that an attacker advertises non-existing links
   to another router (present (which may or may not be present in the network or not). network).

   An attacker can declare itself with to have high route priority, priority and spoofs spoof
   the links to as many legitimate SMF Routers routers as possible to declare
   high connectivity.  By doing so, it can prevent legitimate SMF
   Routers
   routers from self-selecting selecting themselves as relays.  As the "super" relay in
   the network, the attacker can manipulate the traffic relayed by it. 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
   overhearing
   eavesdropping the control messages or the source/destination address
   from datagrams.  The attacker can then generate control or datagram
   traffic,
   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, routers and
   declares
   declare a different router priority value.  If it declares a higher
   priority of that a
   spoofed router, router has a higher priority, it can prevent other routers
   from selecting themselves as relays.  On the other hand, if the
   attacker declares lower priority of that a spoofed router, router has a lower priority, it can
   force other routers to selecting select themselves as relays, relays to degrade the
   multicast forwarding to classical flooding.

5.3.  Threats to S-MPR Algorithm

   The source-based multipoint relay (S-MPR) 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 so by each router such that forwarding to the router's complete a
   message generated by it, and relayed only by its MPRs, will reach all
   of its 2-hop neighbor
   set is covered. 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, routers and the connectivity of the routers, it can be disrupted
   by both link spoofing and identity spoofing.  The  These threats and its their
   impacts have been illustrated in section Section 5.1 of [RFC7186].

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 weakness, weaknesses; the vulnerabilities
   of E-CDS and S-MPR that are discussed in Section Sections 5.2 and Section 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 for
   regarding packet dissemination in MANETs.  Possible attacks to the
   two main functional components of SMF, duplicate packet detection detection,
   and relay set selection, 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 driving 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 hash-assistant value. 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, 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 mitigating
   mitigate threats related to identity spoofing through the exchange of
   HELLO
   messages, messages and provides provide some general protection against identity
   spoofing by admitting only trusted routers to the network using ICVs
   in HELLO messages.

   Using ICVs does, does not, of course, not address the problem of attackers, attackers able
   to also generate valid ICVs.  Detection and exclusion of such
   attackers is, in general, a challenge, which 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  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, 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 attack attacks on hash-assistant
   value the HAV of the
   multicast datagrams are to be mitigated, a datagram-
   level datagram-level integrity
   protection mechanism is desired, by taking consideration of the
   identity field or hash-assistant value. HAV.  However, this would not be helpful for the
   attacks on the TTL (or hop
   limit Hop Limit for IPv6) field, because the mutable
   fields are generally not considered when ICV is calculated.

7.  IANA Considerations

   This document contains no actions for IANA.

   [RFC Editor: please remove this section prior to publication.]

9.  References

9.1.

7.1.  Normative References

   [RFC6130]  Clausen, T., Dean, J., and C. Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, DOI 10.17487/RFC6130, April 2011. 2011,
              <http://www.rfc-editor.org/info/rfc6130>.

   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
              RFC 6621, DOI 10.17487/RFC6621, May 2012. 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.

9.2. 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 broadcast
              storm problem in a Mobile Ad Hoc Network", 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.

   [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. T., Ed. and P. Jacquet, "The Optimized Ed., "Optimized Link
              State Routing Protocol", Protocol (OLSR)", RFC 3626,
              DOI 10.17487/RFC3626, October 2003. 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. 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. 2008,
              <http://www.rfc-editor.org/info/rfc5148>.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Mobile Ad Hoc Network (MANET) Packet/Message
              Format", RFC 5444, DOI 10.17487/RFC5444, February 2009. 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. 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 Version 2",
              RFC 7181, DOI 10.17487/RFC7181, April 2014. 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. 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. 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>.

8.

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, 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, 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/