Mobile Ad hoc Networking (MANET)                                   J. Yi
Internet-Draft                                                T. Clausen
Intended status: Informational                  LIX, Ecole Polytechnique
Expires: March 18, September 24, 2015                                   U. Herberg
                                         Fujitsu Laboratories of America
                                                      September 14, 2014
                                                          March 23, 2015

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

Abstract

   This document analyzes security threats of the Simplified Multicast
   Forwarding (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.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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 March 18, September 24, 2015.

Copyright Notice

   Copyright (c) 2014 2015 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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  SMF Threats Overview . . . . . . . . . . . . . . . . . . . . .  4
   4.  Threats to Duplicate Packet Detection  . . . . . . . . . . . .  5
     4.1.  Common Threats to Identification-based Duplicate Packet Detection Mechanisms  .  5
       4.1.1.  Replay Attack  . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Threats to Identification-based Duplicate Packet
           Detection  . . .  5
       4.1.1.  Pre-activation Attacks (Pre-Play) . . . . . . . . . .  6
       4.1.2.  De-activation Attacks (Sequence Number wrangling) . .  6
     4.2.  Threats to Hash-based Duplicate Packet Detection . . . . .  7
       4.2.1.  Replay Attack . . . .  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 . . . .  7
       4.2.2. .  8
       4.3.1.  Attack on Hash-Assistant Value . . . . . . . . . . . .  8  9
   5.  Threats to Relay Set Selection . . . . . . . . . . . . . . . .  9
     5.1.  Relay Set Selection Common Threats . . . . . . . . . . . .  9 10
     5.2.  Threats to E-CDS Algorithm . . . . . . . . . . . . . . . .  9 10
       5.2.1.  Link Spoofing  . . . . . . . . . . . . . . . . . . . . 10
       5.2.2.  Identity Spoofing  . . . . . . . . . . . . . . . . . . 10 11
     5.3.  Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 10 11
     5.4.  Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 11
   6.  Future Work  . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1. 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2. 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 14

1.  Introduction

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

   SMF is typically used in decentralized wireless environments, and is
   potentially exposed to different kinds of attacks and
   misconfigurations.  Some of the threats are of particular
   significance as compared to wired networks.  In [RFC6621], SMF 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 suitable to deploy common IP protection mechanisms
   (e.g., because of limited resources of MANET routers to support the
   IPsec stack).  The document analyzes possible attacks on and mis-
   configurations of SMF and outlines the consequences of such attacks/
   mis-configurations to the state maintained by SMF in each router.

   This document aims at analyzing and describing the potential
   vulnerabilities of and attack vecors vectors for SMF.  While completeness in
   such an analysis always is 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 the risks thereby incurred
   - as wll as for providing a reference and documented experience with
   SMF as input for possibly future developments of SMF.

   This document is not intended to propose solutions to the threats
   described.  [RFC7183]  [RFC7182] provides a framework, which can be used with
   SMF, and which - depending on how it is used - may offer some degree
   of protection against the threats described in this document related
   to identity spoofing.

2.  Terminology

   This document uses the terminology and notation defined in [RFC2119], [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.

   Compromised SMF router:  An attacker, present in the network and which generates syntactically
      correct SMF control messages.  Control messages emitted by a
      compromised SMF router may contain additional information, or omit
      information, as compared to a control message generated by a non-compromised non-
      compromised SMF router located in the same topological position in
      the network.

   Legitimate SMF router:  An SMF router, which is not a compromised SMF
      Router.

3.  SMF Threats Overview

   SMF requires an external dynamic neighborhood discovery mechanism in
   orde
   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 may be provided by lower-
   layer interface information, by a concurrently operating MANET
   routing protocol which that already maintains such information such as
   [RFC7181], or by explicitly using MANET Neighborhood Discovery
   Protocol (NHDP) [RFC6130].  If NHDP is used for neighborhood
   discovery by SMF, SMF implicitly inherits the vulnerabilities of
   NHDP, as discussed in [RFC7186].  This  As SMF relies on NHDP to assist in
   network layer 2-hop neighborhood discovery (not matter if other
   lower-layer mechanisms are used for 1-hop neighborhood discovery),
   this document assumes that NHDP is
   used. used in SMF.  The threats that are
   NHDP-specific are indicated explicitly.

   Based on neighborhood discovery mechanisms, SMF specified two major
   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
   several ways in which to harm the DPD mechanisms:

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

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

   The attacks on DPD are detailed in Section 4.

   RSS produces a reduced relay set forforwarding for forwarding multicast data
   packets across the MANET.  SMF supports the use of several relay set
   algorithms, including E-CDS (Essential Connected Dominating Set), Set)
   [RFC5614], S-MPR (Source-based Multi-point Relay, as known from
   [RFC3626] and [RFC7181]), or MPR-CDS. MPR-CDS [MPR-CDS].  An Attacker can
   disrupt the RSS algorithm, by degrading it to classical flooding, or
   by "masking" certain part parts of the routers from the multicasting
   domain.  The attacks to RSS algorithms are illustrated in Section 5.

4.  Threats to Duplicate Packet Detection

   Duplicate Packet Detection (DPD) is required for packet dissemination
   in MANET because the packets may be transmitted via the same physical
   interface as the one over which they were received.  A router may
   also receive multiple copies of the same packets from different
   neighbors.  DPD is thus used to check if an incoming packet has been
   received or not.

   DPD is achieved by a router maintaining a record of recently
   processed multicast packets, and comparing later received multicast
   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: 1) 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 header fields and payload for the same effect.

   As they

   In the following of this section, common threats to packet detection
   mechanisms are distinct mechanisms, first discussed.  Then the threats to I-DPD and H-DPD
   are
   discussed introduced separately.  The threats described in this section are
   applicable to general SMF implementations, no matter if NHDP is used
   or not.

4.1.  Common Threats to Identification-based Duplicate Packet Detection

   I-DPD uses Mechanisms

4.1.1.  Replay Attack

   A replay attack implies that control traffic from one region of the
   network is recorded and replayed in a specific DPD identifier different region at (almost)
   the same time, or in the packet header to identify same region at a packet.  By default, such packet identification different time.

   One possible replay attack is not provided by
   the IP packet header (for both IPv4 and IPv6).  Therefore, additional
   identification header, such as based on the fragment header, a hop-by-hop
   header option, Time-to-Live (TTL, for
   IPv4) or IPSec sequencing, must be employed in order to
   support I-DPD.  The uniqueness of hop limit (for IPv6) field.  As routers only forward packets
   with TTL > 1, 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 compromised SMF router can keep a record of
   recently received forward an otherwise valid
   packet, and determine while drastically reducing the coming packet has been TTL hereof.  This will inhibit
   recipient routers from later forwarding the same multicast packet,
   even if received or not.

4.1.1.  Pre-activation Attacks (Pre-Play)

   In with a wireless environment, or across any other shared channel, different TTL - essentially a compromised SMF
   router thus can perceive the identification tuple [source
   IP, sequence number] instruct its neighbors to block forwarding of valid
   multicast packets.

   For example, in Figure 1, router A forwards a packet.  If sequence number progression is
   predictable, then it is trivial to generate and inject invalid
   packets multicast packet with "future" identification information into the network.
   If these invalid packets arrive before the legitimate packets that
   they're spoofing, the latter will be treated as a duplicates and
   discarded.  This can prevent multicast packets from reaching parts
   TTL of 64 to the network.

   Figure 1 gives an example of pre-activation attack.  A, B, and C are legitimate SMF routers,
   and X is the compromised SMF router.  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 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 duplicate packet.  In  In a wireless environment,
   jitter is commonly used to avoid systematic collisions at in MAC layer [RFC5148], thus an
   protocols [RFC5148].  An attacker can thus increase the probability
   that its invalid packets arrive first by retransmitting them without
   jittering.  In this example, router X forwards the packet without
   jittering, 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 stops forwarding it to the next
   hops because of the TTL value.  When the same packet with normal TTL
   value (63 in this case) arrives from router B, it will be discarded
   as duplicate packet.

                                    .---.
                                    | X |
                                  --'---' __
           packet with seq=n TTL=64    /          \  invalid  packet with seq=n TTL=1
                                /            \
                            .---.              .---.
                            | A |              | C |
                            '---'              '---'
           packet with seq=n TTL=64   \    .---.   /
                                 \-- | B |__/  valid  packet with seq=n TTL=63
                                     '---'

                                 Figure 1

4.1.2.  De-activation Attacks (Sequence Number wrangling)

   A

   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
   setting TTL fields to some pre-determined value (e.g., 0) - such is
   for example the case for IPsec Authentication Headers - rendering
   such an attack more difficult to both detect and counter.

   If the compromised SMF router can also seek has access to de-activate DPD, by
   modifying a "wormhole" through the sequence number in packets that
   network (a directional antenna, a tunnel to a collaborator or a wired
   connection, allowing it forwards.  Thus,
   routers will not be able to detect an actual duplicate packet as bridge parts of a
   duplicate - rather, they will treat them as new packets, i.e.,
   process and forward them.  This is similar to DoS attack.  The
   consequence of this attack is an increased channel load, the origin
   of which appears to be a router other than the compromised SMF
   router.

   Given the topology shown in Figure 1, on receiving packet with seq=n,
   the attacker X network otherwise
   distant), it can forward the packet with modified sequence number
   n+i.  This has two consequences: firstly, router C will not be able
   to detect the packet forwarded by X is a duplicate packet; secondly, make sure that the consequent packet packets with seq=n+i generated by router A probably
   will be treated as duplicate packet, and dropped by router C. such an artificially
   reduced TTL arrive before their unmodified counterparts.

4.2.  Threats to Hash-based Identification-based Duplicate Packet Detection

   When it is not feasible to have explicit sequence numbers in packet
   headers, hash-based

   I-DPD uses a specific DPD can be used.  A hash of the non-mutable
   fields identifier in the packet header of and to identify
   a packet.  By default, such packet identification is not provided by
   the data payload can be generated, IP packet header (for both IPv4 and
   recorded at IPv6).  Therefore, additional
   identification header, such as the intermediate routers.  A 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 thus then be uniquely identified by
   the source [source IP address 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 packet originator, and is not being used for
   cryptographic or authentication purposes.  Consequently, a digest
   collision is still possible.  In case the source router [sequence
   number] (from the fragment header, hop-by-hop header option, or gateway
   identifies that it
   IPsec).  By doing so, each intermediate router can keep a record of
   recently received packets, and determine whether the incoming packet
   has generated been received or injected not.

4.2.1.  Pre-activation Attacks (Pre-Play)

   In a wireless environment, or across any other shared channel, a
   compromised SMF router can perceive the identification tuple [source
   IP address, sequence number] of a packet.  It is possible to generate
   packet with the same hash-value, [source IP address, sequence number] pair with
   invalid content.  If sequence number progression is predictable, then
   it inserts a "Hash-Assist Value (HAV)" IPv6
   header option is trivial to generate and inject invalid packets with "future"
   identification information into the packet, such network.  If these invalid
   packets arrive before the legitimate packets that calculating they're spoofing,
   the hash also
   over this HAV latter will render the resulting value unique.

4.2.1.  Replay Attack

   A replay attack implies that control traffic be treated as a duplicates and discarded.  This can
   prevent multicast packets from one region reaching parts of the
   network is recorded network.

   Figure 2 gives an example of pre-activation attack.  A, B, and replayed in a different region at (almost)
   the same time, or in the same region at a different time.

   One possible replay attack C are
   legitimate SMF routers, and X is based on the Time-to-Live (TTL, for
   IPv4) or hop limit (for IPv6) field.  As routers only forward packets
   with TTL > 1, a compromised SMF router can forward an otherwise valid
   packet, while drastically reducing router.  The
   line between the TTL hereof.  This will inhibit
   recipient routers from later forwarding presents the same packet forwarding.  Router A is
   the source and originates a multicast packet,
   even if received packet with a different TTL - essentially a compromised SMF sequence number n.
   When router thus can instruct its neighbors to block forwarding of valid
   multicast packets.

   For example, given X receives the example in Figure 2, router A forwards a
   multicast packet, it generates an invalid packet
   with a TTL of 64 to the network. the source address of A, B, and C are
   legitimate SMF routers, and X is the compromised SMF router.  Router
   X forwards sequence number n.  If the
   invalid packet without jittering, and reduces the TTL to 1.
   Router arrives at router C thus records before the hash value forwarding of router B,
   the packets, but stops
   forwarding it valid packet will be dropped by C as duplicate packet.  An
   attacker can manipulate jitter to make sure that the next hops because of invalid packets
   arrive first.  Router X can even generate packet with future sequence
   numbers (if they are predictable), so that the TTL value.  When future legitimate
   packets with the same packet with normal TTL value (63 in this case) arrives from
   router B, it sequence numbers will be discarded dropped as duplicate packet.
   ones.

                                .---.
                                | X |
                              --'---' __
       packet with TTL=64 seq=n     /          \  invalid packet with TTL=1 seq=n
                            /            \
                        .---.              .---.
                        | A |              | C |
                        '---'              '---'
       packet with TTL=64 seq=n    \    .---.   /
                             \-- | B |__/  valid packet with TTL=63 seq=n
                                 '---'

                                 Figure 2

   As the TTL of a packet is intended SMF currently does not have any timestamp mechanisms to be manipulated by
   intermediaries forwarding it, classic methods such as integrity check
   values (e.g., digital signatures) are typically calculated with
   setting TTL fields protect
   data packets, there is no viable way to some pre-determined value (e.g., 0) - detect such is
   for example pre-play attacks
   by timestamp.  Especially, if the case for IPsec Authentication Headers - rendering
   such an attack more difficult is based on manipulation of
   jitter, the timestamp would not be effective because the timing is
   still valid (but with much less value).

4.2.2.  De-activation Attacks (Sequence Number wrangling)

   A compromised SMF router can also seek to de-activate DPD, by
   modifying the sequence number in packets that it forwards.  Thus,
   routers will not be able to both detect an actual duplicate packet as a
   duplicate - rather, they will treat them as new packets, i.e.,
   process and counter.  If forward them.  This is similar to DoS attack.  The
   consequence of this attack is an increased channel load, the origin
   of which appears to be a router other than the compromised SMF
   router.

   Given the topology shown in Figure 2, on receiving packet with seq=n,
   the attacker X can forward the packet with modified sequence number
   n+i.  This has two consequences: firstly, router C will not be able
   to detect the packet forwarded by X is a duplicate packet; secondly,
   the consequent packet with seq=n+i generated by router A probably
   will be treated as duplicate packet, and dropped by router C.

4.3.  Threats to Hash-based Duplicate Packet Detection

   When it is not feasible to have explicit sequence numbers in packet
   headers, hash-based DPD can be used.  A hash of the non-mutable
   fields in the header of and 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 recently has access to a "wormhole" through the network
   (a directional antenna, a tunnel to a collaborator generated or injected a wired
   connection, allowing packet with
   the same hash-value, it to bridge parts of inserts a network otherwise
   distant) it can make sure that "Hash-Assist Value (HAV)" IPv6
   header option into the packets with packet, such an artificially
   reduced TTL arrive before their unmodified counterparts.

4.2.2. that calculating the hash also
   over this HAV will render the resulting value unique.

4.3.1.  Attack on 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 ingressing SMF router detects that
   the coming packet has digest collision with previously generated
   packets, it actually can be regarded as a "flag" of potential digest
   collision.  A compromised SMF router can discover the HAV header, and
   be able to conclude a hash collision is possible if the HAV header is
   removed.  By doing so, other SMF routers receiving the modified
   packet will be treated as duplicate packet, and be dropped because it
   has the same hash value with precedent packet.

   In the example of Figure Figure 3, Router A and B are legitimate SMF
   routers, X is a compromised SMF router.  A generate two packets P1
   and P2, with the same hash value h(P1)=h(P2)=x.  Based on SMF
   specification, a hash-assistant value (HAV) is added to the latter
   packet P2, so that h(P2+HAV)=x', to avoid 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 duplicate packet by router B, and 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 RSS mechanism, rather than a specific RSS algorithm
   is provided by SMF.  It 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 the three commonly used algorithms: Essential
   Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint
   Relay (S-MPR) and Multipoint Relay Connected Dominating Set (MPR-CDS)
   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.  Relay Set Selection Common Threats

   The common threats to RSS algorithms, including Denial of Service
   attack, eavesdropping, message timing attack and broadcast storm have
   been discussed in [RFC7186].

5.2.  Threats to E-CDS Algorithm

   The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614]
   forms a single CDS mesh for the SMF operating region.  It requires
   2-hop neighborhood information (the identify of the neighbors, the
   link to the neighbors and neighbors' priority information) collected
   through NHDP or another process.

   An SMF Router select itself as a relay, if:

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

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

   A Compromised SMF Router can disrupt the E-CDS algorithm by link
   spoofing or identity spoofing.

5.2.1.  Link Spoofing

   Link spoofing implies that a Compromised SMF Router advertises non-
   existing links to another router (present in the network or not).

   A Compromised SMF Router can declare itself with high route priority,
   and spoofs the links to as many Legitimate SMF Routers as possible to
   declare high connectivity.  By doing so, it can prevent Legitimate
   SMF Routers from self-selecting as relays.  As the "super" relay in
   the network, the Compromised SMF Router can manipulate the traffic
   relayed by it.

5.2.2.  Identity Spoofing

   Identity spoofing implies that a compromised SMF router determines
   and makes use of the identity of other legitimate routers, without
   being authorised to do so.  The identity of other routers can be
   obtained by overhearing the control messages or source/destination
   address from datagram.  The compromised SMF router can then generate
   control or datagram traffic, pretending to be a legitimate router.

   Because E-CDS self-selection is based on the router priority value, a
   compromised SMF router can spoof the identity of other legitimate
   routers, and declares a different router priority value.  If it
   declares a higher priority of a spoofed router, it can prevent other
   routers from selecting themselves as relays.  On the other hand, if
   the compromised router declares lower priority of a spoofed router,
   it can enforces other routers to selecting themselves as relays, to
   degrade the multicast forwarding to classical flooding.

5.3.  Threats to S-MPR Algorithm

   The source-based multipoint relay (S-MPR) set selection algorithm
   enables individual routers, using 2-hop topology information, to
   select relays from their set of neighboring routers.  MPRs are
   selected so that forwarding to the router's complete 2-hop neighbor
   set is covered.

   An SMF router forwards a multicast packet if and only if:

   o  the packet is not 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.  The threats and its
   impacts have been illustrated in section 5.1 of [RFC7186].

5.4.  Threats to 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, S-MPR and the simple combination of the
   two algorithms does not address the weakness, the vulnerabilities of
   E-CDS and S-MPR that discussed in Section 5.2 and Section 5.3 apply
   to MPR-CDS also.

6.  Future Work

   Neither [RFC6621] nor this document propose mechanisms to secure the
   SMF protocol.  However, this section aims at discussing possibilities
   to secure the protocol in the future and driving new work by
   suggesting which threats discussed in the previous sections could be
   addressed.

   For I-PDP mechanism, employing randomized packet sequence number can
   avoid some pre-activation attacks based on sequence number
   prediction.  If predicable sequence number has to be used, applying
   timestamps can mitigate pre-activation attacks.

   If NHDP is used as the neighborhood discovery protocol, [RFC7183] is
   recommended to be implemented to enable integrity protection to NHDP,
   which can help mitigating the threats related to identity spoofing
   through the exchange of HELLO messages.

   [RFC7183] provides certain protection against identity spoofing by
   admitting only trusted routers to the network using Integrity Check
   Values (ICVs) in HELLO messages.  However, using ICVs does not
   address the problem of compromised routers that can generate valid
   ICVs.  Detecting such compromised routers could be studied in new
   work.  [RFC7183] mandates implementation of a security mechanism that
   is based on shared keys and makes excluding single compromised
   routers difficult.  Work could be done to facilitate revocation
   mechanisms in certain MANET use cases where routers have sufficient
   capabilities to support asymmetric keys. keys (such as
   [I-D.ietf-manet-ibs]) .

   As [RFC7183] does not protect the integrity of the multicast
   datagram, and no mechanism is specified to do that for SMF yet, the
   duplicate packet detection is still vulnerable to the threats
   introduced in Section 4.

   If pre-activation/de-activation attacks and attack on hash-assistant
   value 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.
   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.  Security Considerations

   This document does not specify a protocol or a procedure.  The whole
   document, however, reflects on security considerations for SMF for
   packet dissemination in MANETs.

8.  IANA Considerations

   This document contains no actions for IANA.

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

9.  Acknowledgments

   The authors would like to thank Christopher Dearlove (BAE Systems
   ATC) who provided detailed review and valuable comments.

10.  References

9.1.

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5614]  Ogier, R.

   [RFC6130]  Clausen, T., Dean, J., and P. Spagnolo, C. Dearlove, "Mobile Ad Hoc
              Network (MANET)
              Extension of OSPF Using Connected Dominating Set (CDS)
              Flooding", Neighborhood Discovery Protocol (NHDP)",
              RFC 5614, August 2009. 6130, April 2011.

   [RFC6621]  Macker, J., "Simplified Multicast Forwarding", RFC 6621,
              May 2012.

   [RFC7186]  Yi, J., Herberg, U., and T. Clausen, "Security Threats for
              the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
              April 2014.

9.2.

10.2.  Informative References

   [I-D.ietf-manet-ibs]
              Dearlove, C., "Identity-Based Signatures for MANET Routing
              Protocols", draft-ietf-manet-ibs-03 (work in progress),
              September 2014.

   [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. and P. Jacquet, "The Optimized Link State
              Routing Protocol", RFC 3626, October 2003.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

   [RFC6130]  Clausen, T., Dean, J.,

   [RFC5614]  Ogier, R. and C. Dearlove, P. Spagnolo, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              Extension of OSPF Using Connected Dominating Set (CDS)
              Flooding", RFC 6130, April 2011. 5614, August 2009.

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol version 2",
              RFC 7181, April 2014.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, April 2014.

   [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, April 2014.

Authors' Addresses

   Jiazi Yi
   LIX, 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
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.thomasclausen.org/

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E Arques Ave
   Sunnyvale, CA 94085
   USA

   Email: ulrich@herberg.name
   URI:   http://www.herberg.name/