draft-ietf-manet-smf-sec-threats-05.txt   draft-ietf-manet-smf-sec-threats-06.txt 
Mobile Ad hoc Networking (MANET) J. Yi Mobile Ad hoc Networking (MANET) J. Yi
Internet-Draft T. Clausen Internet-Draft T. Clausen
Intended status: Informational LIX, Ecole Polytechnique Updates: 7186 (if approved) Ecole Polytechnique
Expires: September 9, 2016 U. Herberg Intended status: Informational U. Herberg
March 8, 2016 Expires: February 28, 2017 August 27, 2016
Security Threats for Simplified Multicast Forwarding (SMF) Security Threats for Simplified Multicast Forwarding (SMF)
draft-ietf-manet-smf-sec-threats-05 draft-ietf-manet-smf-sec-threats-06
Abstract Abstract
This document analyzes security threats of the Simplified Multicast This document analyzes security threats of the Simplified Multicast
Forwarding (SMF), including the vulnerabilities of duplicate packet Forwarding (SMF) mechanism, including the vulnerabilities of
detection and relay set selection mechanisms. This document is not duplicate packet detection and relay set selection mechanisms. This
intended to propose solutions to the threats described. document is not intended to propose solutions to the threats
described.
This document also updates RFC7186 regarding the threats to relay set
selection mechanisms using RFC6130.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2016. This Internet-Draft will expire on February 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SMF Threats Overview . . . . . . . . . . . . . . . . . . . . . 4 3. SMF Threats Overview . . . . . . . . . . . . . . . . . . . . . 4
4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5 4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5
4.1. Common Threats to Duplicate Packet Detection Mechanisms . 5 4.1. Attack to The Hop Limit Field . . . . . . . . . . . . . . 6
4.1.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 6
4.2. Threats to Identification-based Duplicate Packet 4.2. Threats to Identification-based Duplicate Packet
Detection . . . . . . . . . . . . . . . . . . . . . . . . 7 Detection . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 7 4.2.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 7
4.2.2. De-activation Attacks (Sequence Number wrangling) . . 8 4.2.2. De-activation Attacks (Sequence Number wrangling) . . 8
4.3. Threats to Hash-based Duplicate Packet Detection . . . . . 8 4.3. Threats to Hash-based Duplicate Packet Detection . . . . . 9
4.3.1. Attack on Hash-Assistant Value . . . . . . . . . . . . 9 4.3.1. Attack on Hash-Assistant Value . . . . . . . . . . . . 9
5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 9 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 10
5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 10 5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 10
5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 10 5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 10
5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11
5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11
5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 11 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 11
5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 11 5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 12
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document analyzes security threats to the Simplified Multicast This document analyzes security threats to the Simplified Multicast
Forwarding (SMF) mechanism [RFC6621]. SMF aims at providing basic Forwarding (SMF) mechanism [RFC6621]. SMF aims at providing basic
Internet Protocol (IP) multicast forwarding, in a way that is Internet Protocol (IP) multicast forwarding, in a way that is
suitable for limited wireless mesh and Mobile Ad hoc NETworks suitable for limited wireless mesh and Mobile Ad hoc NETworks
(MANET). SMF is constituted of two major functional components: (MANET). SMF is constituted of two major functional components:
Duplicate Packet Detection and Relay Set Selection. Duplicate Packet Detection and Relay Set Selection.
SMF is typically used in decentralized wireless environments, and is SMF is typically used in decentralized wireless environments, and is
potentially exposed to different kinds of attacks and potentially exposed to various attacks and misconfigurations. Some
misconfigurations. Some of the threats are of particular of these attacks and misconfigurtions, in a wireless enviroment,
significance as compared to wired networks. In [RFC6621], SMF does represent threats of particular significance as compared to what they
not define any explicit security measures for protecting the would do in wired networks. [RFC6621] briefly discusses several of
integrity of the protocol. 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 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 mechanism such as IPsec is used in the IP layer, as not all MANET
deployments may be suitable to deploy common IP protection mechanisms deployments may be suitable to deploy common IP protection mechanisms
(e.g., because of limited resources of MANET routers to support the (e.g., because of limited resources of MANET routers to support the
IPsec stack). It assumes that there is no lower-layer protection IPsec stack). It assumes that there is no lower-layer protection
either. The document analyzes possible attacks on and mis- either. The document analyzes possible attacks on and mis-
configurations of SMF and outlines the consequences of such attacks/ configurations of SMF and outlines the consequences of such attacks/
mis-configurations to the state maintained by SMF in each router. mis-configurations to the state maintained by SMF in each router.
This document aims at analyzing and describing the potential In the Security Considerations section of [RFC6621], denial-of-
vulnerabilities of and attack vectors for SMF. While completeness in service attack scenarios are briefly discussed. This document
such analysis is always a goal, no claims of being complete are made. further analyzes and describes the potential vulnerabilities of and
The goal of this document is to be helpful for when deploying SMF in attack vectors for SMF. While completeness in such analysis is
a network and needing to understand the risks thereby incurred - as always a goal, no claims of being complete are made. The goal of
well as for providing a reference and documented experience with SMF this document is to be helpful for when deploying SMF in a network
as input for possibly future developments of SMF. and needing to understand the risks thereby incurred - as well 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 This document is not intended to propose solutions to the threats
described. [RFC7182] provides a framework that can be used with SMF, described. [RFC7182] provides a framework that can be used with SMF,
and depending on how it is used - may offer some degree of protection and depending on how it is used - may offer some degree of protection
against the threats described in this document related to identity against the threats described in this document related to identity
spoofing. spoofing.
This document also updates [RFC7186], specifically with respect to
threats to relay set selection mechanisms which are using [RFC6130].
2. Terminology 2. Terminology
This document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
[RFC6130], [RFC6621] and [RFC4949]. [RFC6130], [RFC6621] and [RFC4949].
Additionally, this document introduces the following terminology: Additionally, this document introduces the following terminology:
SMF router: A MANET router, running SMF as specified in [RFC6621]. SMF router: A MANET router, running SMF as specified in [RFC6621].
Attacker: A device that is present in the network and intentionally Attacker: A device that is present in the network and intentionally
skipping to change at page 4, line 24 skipping to change at page 4, line 31
3. SMF Threats Overview 3. SMF Threats Overview
SMF requires an external dynamic neighborhood discovery mechanism in SMF requires an external dynamic neighborhood discovery mechanism in
order to maintain suitable topological information describing its order to maintain suitable topological information describing its
immediate neighborhood, and thereby allowing it to select reduced immediate neighborhood, and thereby allowing it to select reduced
relay sets for forwarding multicast data traffic. Such an external relay sets for forwarding multicast data traffic. Such an external
dynamic neighborhood discovery mechanism may be provided by lower- dynamic neighborhood discovery mechanism may be provided by lower-
layer interface information, by a concurrently operating MANET layer interface information, by a concurrently operating MANET
routing protocol that already maintains such information such as routing protocol that already maintains such information such as
[RFC7181], or by explicitly using MANET Neighborhood Discovery [RFC7181], or by explicitly using MANET Neighborhood Discovery
Protocol (NHDP) [RFC6130]. If NHDP is used for neighborhood Protocol (NHDP) [RFC6130]. If NHDP is used for both 1-hop and 2-hop
discovery by SMF, SMF implicitly inherits the vulnerabilities of neighborhood discovery by SMF, SMF implicitly inherits the
NHDP, as discussed in [RFC7186]. As SMF relies on NHDP to assist in vulnerabilities of NHDP discussed in [RFC7186]. As SMF relies on
network layer 2-hop neighborhood discovery (not matter if other NHDP to assist in network layer 2-hop neighborhood discovery (no
lower-layer mechanisms are used for 1-hop neighborhood discovery), matter if other lower-layer mechanisms are used for 1-hop
this document assumes that NHDP is used in SMF. The threats that are neighborhood discovery), this document assumes that NHDP is used in
NHDP-specific are indicated explicitly. SMF. The threats that are NHDP-specific are indicated explicitly.
Based on neighborhood discovery mechanisms, SMF specified two major Based on neighborhood discovery mechanisms, [RFC6621] specifies two
functional components: Duplicate Packet Detection (DPD) and Relay Set principal functional components: Duplicate Packet Detection (DPD) and
Selection (RSS). Relay Set Selection (RSS).
DPD is required by SMF in order to be able to detect duplicate DPD is required by SMF in order to be able to detect duplicate
packets and eliminate their redundant forwarding. An Attacker has packets and eliminate their redundant forwarding. An Attacker has
two ways in which to harm the DPD mechanisms: two ways in which to harm the DPD mechanisms, specifically it can:
o It can "deactivate" DPD, so as to make it such that duplicate o "deactivate" DPD, so as to make it such that duplicate packets are
packets are not correctly detected, and that as a consequence they not correctly detected, and that as a consequence they are
are (redundantly) transmitted, increasing the load on the network, (redundantly) transmitted, increasing the load on the network,
draining the batteries of the routers involved, etc. draining the batteries of the routers involved, etc.
o It can "pre-activate" DPD, so as to make DPD detect a later o "pre-activate" DPD, so as to make DPD detect a later arriving
arriving (valid) packet as being a duplicate, which therefore (valid) packet as being a duplicate, which therefore won't be
won't be forwarded. " forwarded.
The attacks on DPD can be achieved by replaying existed packets, Attacks on DPD can be achieved by replaying existing packets, by
wrangle sequence numbers, manipulate hash values, etc. They are wrangling sequence numbers, by manipulating hash values, etc., and
detailed in Section 4. are detailed in Section 4.
RSS produces a reduced relay set for forwarding multicast data RSS produces a reduced relay set for forwarding multicast data
packets across the MANET. SMF supports the use of several relay set packets across the MANET. [RFC6621] specifies several relay set
algorithms, including E-CDS (Essential Connected Dominating Set) algorithms, including E-CDS (Essential Connected Dominating Set)
[RFC5614], S-MPR (Source-based Multi-point Relay, as known from [RFC5614], S-MPR (Source-based Multi-point Relay, as known from
[RFC3626] and [RFC7181]), or MPR-CDS [MPR-CDS]. An Attacker can [RFC3626] and [RFC7181]), or MPR-CDS [MPR-CDS], for use in SMF. An
disrupt the RSS algorithm by degrading it to classical flooding, or Attacker can disrupt the RSS algorithm, and thereby SMF operation, by
by "masking" certain parts of the routers from the multicasting degrading it to classical flooding, or by "masking" certain parts of
domain. The attacks to RSS algorithms are detailed in Section 5. 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 Other than the attacks on DPD and RSS, a common vulnerability of
MANETs is "jamming", i.e., a device generates massive amounts of MANETs is "jamming", i.e., a device generates massive amounts of
interfering radio transmissions, which will prevent legitimate interfering radio transmissions, which will prevent legitimate
traffic (e.g., control traffic as well as data traffic) on part of a 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 network. The attacks on DPD and RSS can be further enhanced by
jamming. jamming.
4. Threats to Duplicate Packet Detection 4. Threats to Duplicate Packet Detection
Duplicate Packet Detection (DPD) is required for packet dissemination Duplicate Packet Detection (DPD) is required for packet dissemination
in MANETs because: (1) the packets may be transmitted via the same in MANETs because: (1) packets may be transmitted via the same
physical interface as the one over which they were received; (2) a physical interface as the one over which they were received, and (2)
router may also receive multiple copies of the same packet from a router may receive multiple copies of the same packet (on the same,
different neighbors. DPD is thus used to check if an incoming packet or on different interfaces) from different neighbors. DPD is thus
has been previously received or not. used to check if an incoming packet has been previously received or
not.
DPD is achieved by maintaining a record of recently processed DPD is achieved by maintaining a record of recently processed
multicast packets, and comparing later received multicast packets multicast packets, and comparing later received multicast packets
herewith. A duplicate packet detected is silently dropped and is not herewith. A duplicate packet detected is silently dropped and is not
inserted into the forwarding path of that router, nor is it delivered inserted into the forwarding path of that router, nor is it delivered
to an application. DPD, as proposed by SMF, supports both IPv4 and to an application. DPD, as proposed by SMF, supports both IPv4 and
IPv6 and for each suggests two duplicate packet detection mechanisms: IPv6 and for each suggests two duplicate packet detection mechanisms:
1) header content identification-based DPD (I-DPD), using packet 1) header content identification-based DPD (I-DPD), using packet
headers, in combination with flow state, to estimate temporal headers, in combination with flow state, to estimate temporal
uniqueness of a packet, and 2) hash-based DPD (H-DPD), employing uniqueness of a packet, and 2) hash-based DPD (H-DPD), employing
hashing of selected header fields and payload for the same effect. hashing of selected header fields and payload for the same effect.
In the following of this section, common threats to packet detection In the Security Considerations section of [RFC6621], a selection of
mechanisms are first discussed. Then the threats to I-DPD and H-DPD threats to DPD are briefly introduced. This section expands on that
are introduced separately. The threats described in this section are discussion, and describes how to effectively launch the attacks on
applicable to general SMF implementations, no matter if NHDP is used DPD - for example, by way of manipulating jitter and/or the Hash-
or not. Assistant Value. In the remainder of this section, common threats to
packet detection mechanisms are first discussed. Then the threats to
4.1. Common Threats to Duplicate Packet Detection Mechanisms I-DPD and H-DPD are introduced separately. The threats described in
4.1.1. Replay Attack this section are applicable to general SMF implementations, no matter
if NHDP is used or not.
A replay attack implies that control traffic from one region of the 4.1. Attack to The Hop Limit Field
network is recorded and replayed in a different region at (almost)
the same time, or in the same region at a different time.
One possible replay attack is based on the Time-to-Live (TTL, for One immediate DoS attack is based on manipulating the Time-to-Live
IPv4) or hop limit (for IPv6) field. As routers only forward packets (TTL, for IPv4) or hop limit (for IPv6) field. As routers only
with TTL > 1, an attacker can forward an otherwise valid packet, forward packets with TTL > 1, an attacker can forward an otherwise
while drastically reducing the TTL hereof. This will inhibit valid packet, while drastically reducing the TTL hereof. This will
recipient routers from later forwarding the same multicast packet, inhibit recipient routers from later forwarding the same multicast
even if received with a different TTL - essentially an attacker thus packet, even if received with a different TTL - essentially an
can instruct its neighbors to block forwarding of valid multicast attacker thus can instruct its neighbors to block forwarding of valid
packets. multicast packets.
For example, in Figure 1, router A forwards a multicast packet with a 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, TTL of 64 to the network. A, B, and C are legitimate SMF routers,
and X is the attacker. In a wireless environment, jitter is commonly and X is an attacker. In a wireless environment, jitter is commonly
used to avoid systematic collisions in MAC protocols [RFC5148]. An used to avoid systematic collisions in MAC protocols [RFC5148]. An
attacker can thus increase the probability that its invalid packets attacker can thus increase the probability that its invalid packets
arrive first by retransmitting them without jittering. In this arrive first by retransmitting them without applying jitter. In this
example, router X forwards the packet without jittering and reduces example, router X forwards the packet without applying jitter and
the TTL to 1. Router C thus records the duplicate detection value reduces the TTL to 1. Router C thus records the duplicate detection
(hash value for H-DPD, or the header content of the packets for 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 I-DPD) but does (due to TTL == 1) not forward. When a second copy
value. When the same packet with normal TTL value (63 in this case) the same packet, with a non-maliciously manipulated TTL value (63 in
arrives from router B, it will be discarded as duplicate packet. this case), arrives from router B, it will be discarded as duplicate
packet.
.---. .---.
| X | | X |
--'---' __ --'---' __
packet with TTL=64 / \ packet with TTL=1 packet with TTL=64 / \ packet with TTL=1
/ \ / \
.---. .---. .---. .---.
| A | | C | | A | | C |
'---' '---' '---' '---'
packet with TTL=64 \ .---. / packet with TTL=64 \ .---. /
skipping to change at page 10, line 16 skipping to change at page 10, line 32
this section, the common threats to the RSS framework are first this section, the common threats to the RSS framework are first
discussed. Then the three commonly used algorithms: Essential discussed. Then the three commonly used algorithms: Essential
Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint
Relay (S-MPR) and Multipoint Relay Connected Dominating Set (MPR-CDS) 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 are analyzed. As the relay set selection is based on 1-hop and 2-hop
neighborhood information, which rely on NHDP, the threats described neighborhood information, which rely on NHDP, the threats described
in this section are NHDP-specific. in this section are NHDP-specific.
5.1. Relay Set Selection Common Threats 5.1. Relay Set Selection Common Threats
The common threats to RSS algorithms, including Denial of Service Common (i.e., non algorithm specific) threats to RSS algorithms,
attack, eavesdropping, message timing attack and broadcast storm have including Denial of Service attack, eavesdropping, message timing
been discussed in [RFC7186]. attack and broadcast storm have been discussed in [RFC7186].
5.2. Threats to E-CDS Algorithm 5.2. Threats to E-CDS Algorithm
The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614]
forms a single CDS mesh for the SMF operating region. It requires forms a single CDS mesh for the SMF operating region. It requires
2-hop neighborhood information (the identify of the neighbors, the 2-hop neighborhood information (the identify of the neighbors, the
link to the neighbors and neighbors' priority information) collected link to the neighbors and neighbors' priority information) collected
through NHDP or another process. through NHDP or another process.
An SMF Router select itself as a relay, if: An SMF Router will select itself as a relay, if:
o The SMF Router has a higher priority than all of its symmetric o The SMF Router has a higher priority than all of its symmetric
neighbors, or neighbors, or
o There does not exist a path from the neighbor with largest o There does not exist a path from the neighbor with largest
priority to any other neighbor, via neighbors with greater priority to any other neighbor, via neighbors with greater
priority. priority.
An attacker can disrupt the E-CDS algorithm by link spoofing or An attacker can disrupt the E-CDS algorithm by link spoofing or
identity spoofing. identity spoofing.
skipping to change at page 11, line 19 skipping to change at page 11, line 37
to do so. The identity of other routers can be obtained by to do so. The identity of other routers can be obtained by
overhearing the control messages or the source/destination address overhearing the control messages or the source/destination address
from datagrams. The attacker can then generate control or datagram from datagrams. The attacker can then generate control or datagram
traffic, pretending to be a legitimate router. traffic, pretending to be a legitimate router.
Because E-CDS self-selection is based on the router priority value, Because E-CDS self-selection is based on the router priority value,
an attacker can spoof the identity of other legitimate routers, and an attacker can spoof the identity of other legitimate routers, and
declares a different router priority value. If it declares a higher declares a different router priority value. If it declares a higher
priority of a spoofed router, it can prevent other routers from priority of a spoofed router, it can prevent other routers from
selecting themselves as relays. On the other hand, if the attacker selecting themselves as relays. On the other hand, if the attacker
declares lower priority of a spoofed router, it can enforce other declares lower priority of a spoofed router, it can force other
routers to selecting themselves as relays, to degrade the multicast routers to selecting themselves as relays, to degrade the multicast
forwarding to classical flooding. forwarding to classical flooding.
5.3. Threats to S-MPR Algorithm 5.3. Threats to S-MPR Algorithm
The source-based multipoint relay (S-MPR) set selection algorithm The source-based multipoint relay (S-MPR) set selection algorithm
enables individual routers, using 2-hop topology information, to enables individual routers, using 2-hop topology information, to
select relays from their set of neighboring routers. MPRs are select relays from their set of neighboring routers. MPRs are
selected so that forwarding to the router's complete 2-hop neighbor selected so that forwarding to the router's complete 2-hop neighbor
set is covered. set is covered.
An SMF router forwards a multicast packet if and only if: An SMF router forwards a multicast packet if and only if:
o the packet has not been received received before, and o the packet has not been received before, and
o the neighbor from which the packet was received has selected the o the neighbor from which the packet was received has selected the
router as MPR. router as MPR.
Because MPR calculation is based on the willingness declared by the Because MPR calculation is based on the willingness declared by the
SMF routers, and the connectivity of the routers, it can be disrupted SMF routers, and the connectivity of the routers, it can be disrupted
by both link spoofing and identity spoofing. The threats and its by both link spoofing and identity spoofing. The threats and its
impacts have been illustrated in section 5.1 of [RFC7186]. impacts have been illustrated in section 5.1 of [RFC7186].
5.4. Threats to MPR-CDS Algorithm 5.4. Threats to MPR-CDS Algorithm
MPR-CDS is a derivative from S-MPR. The main difference between 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 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 each source in the network, MPR-CDS forms a unique broadcast
tree for all sources in the network. tree for all sources in the network.
As MPR-CDS combines E-CDS and S-MPR and the simple combination of the As MPR-CDS combines E-CDS and S-MPR and the simple combination of the
two algorithms does not address the weakness, the vulnerabilities of 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 E-CDS and S-MPR that discussed in Section 5.2 and Section 5.3 apply
to MPR-CDS also. to MPR-CDS also.
6. Future Work 6. Security Considerations
Neither [RFC6621] nor this document propose mechanisms to secure the This document does not specify a protocol or a procedure. The whole
SMF protocol. However, this section aims at discussing possibilities document, however, reflects on security considerations for SMF for
to secure the protocol in the future and driving new work by packet dissemination in MANETs. Possible attacks to the two main
suggesting which threats discussed in the previous sections could be functional components of SMF, duplicate packet detection and relay
addressed. set selection, are analyzed and documented.
Although [RFC6621] nor this document propose mechanisms to secure the
SMF protocol, there are several 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 the I-DPD mechanism, employing randomized packet sequence numbers For the I-DPD mechanism, employing randomized packet sequence numbers
can avoid some pre-activation attacks based on sequence number can avoid some pre-activation attacks based on sequence number
prediction. If predicable sequence numbers have to be used, applying prediction. If predicable sequence numbers have to be used, applying
timestamps can mitigate pre-activation attacks. timestamps can mitigate pre-activation attacks.
For the H-DPD mechanism, applying cryptographically strong hashes can For the H-DPD mechanism, applying cryptographically strong hashes can
make the digest collisions effectively impossible, and avoid the use make the digest collisions effectively impossible, and avoid the use
of hash-assistant value. of hash-assistant value.
[RFC7182] specifies a framework for representing cryptographic ICVs [RFC7182] specifies a framework for representing cryptographic
and timestamps in MANETs. Based on [RFC7182], [RFC7183] specifies Integrity Check Values (ICVs) and timestamps in MANETs. Based on
integrity and replay protection for NHDP using shared keys. If NHDP [RFC7182], [RFC7183] specifies integrity and replay protection for
is used as the neighborhood discovery protocol, [RFC7183] is NHDP using shared keys, as a mandatory-to-implement security
recommended to be implemented to enable integrity protection to NHDP, mechanism. If SMF is using NHDP as neighborhood discovery protocol,
which can help mitigating the threats related to identity spoofing implementing [RFC7183] remains advisable so as to enable integrity
through the exchange of HELLO messages. It provides certain protection for NHDP control messages. This can help mitigating
protection against identity spoofing by admitting only trusted threats related to identity spoofing through the exchange of HELLO
routers to the network using ICVs in HELLO messages. messages, and provides some general protection against identity
spoofing by admitting only trusted routers to the network using ICVs
in HELLO messages.
However, using ICVs does not address the problem of attackers that Using ICVs does, of course, not address the problem of attackers,
can generate valid ICVs. Detecting such attackers could be studied able to also generate valid ICVs. Detection and exclusion of such
in new work. If [RFC7183] is used, the shared key mechanism will attackers is, in general, a challenge, which is not unrelated to how
make excluding single attackers routers more difficult. Work could [RFC7182] is used. If, for example, it is used with a shared key (as
be done to facilitate revocation mechanisms in certain MANET use per [RFC7183]), excluding single attackers generally is not aided by
cases where routers have sufficient capabilities to support the use of ICVs. However if routers have sufficient capabilities to
asymmetric keys (such as [I-D.ietf-manet-ibs], which is an extension support the use of asymmetric keys (as per [RFC7859]), part of
of [RFC7182]). 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 As [RFC7183] does not protect the integrity of the multicast user
datagram, and no mechanism is specified to do that for SMF yet, the datagram, and as no mechanism is specified by SMF for doing so,
duplicate packet detection is still vulnerable to the threats duplicate packet detection remains vulnerable to the threats
introduced in Section 4. introduced in Section 4.
If pre-activation/de-activation attacks and attack on hash-assistant If pre-activation/de-activation attacks and attack on hash-assistant
value of the multicast datagrams are to be mitigated, a datagram- value of the multicast datagrams are to be mitigated, a datagram-
level integrity protection mechanism is desired, by taking level integrity protection mechanism is desired, by taking
consideration of the identity field or hash-assistant value. consideration of the identity field or hash-assistant value.
However, this would not be helpful for the attacks on the TTL (or hop 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 limit for IPv6) field, because the mutable fields are generally not
considered when ICV is calculated. considered when ICV is calculated.
7. Security Considerations 7. IANA 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. This document contains no actions for IANA.
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
9. Acknowledgments 8. Acknowledgments
The authors would like to thank Christopher Dearlove (BAE Systems The authors would like to thank Christopher Dearlove (BAE Systems
ATC) who provided detailed review and valuable comments. ATC) who provided detailed review and valuable comments.
10. References 9. References
9.1. Normative References
10.1. Normative References
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
May 2012. May 2012.
[RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for
the Neighborhood Discovery Protocol (NHDP)", RFC 7186, the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
April 2014. April 2014.
10.2. Informative References 9.2. Informative References
[I-D.ietf-manet-ibs]
Dearlove, C., "Identity-Based Signatures for MANET Routing
Protocols", draft-ietf-manet-ibs-04 (work in progress),
November 2015.
[MOBICOM99] [MOBICOM99]
Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
Storm Problem in a Mobile Ad Hoc Network", Proceedings of Storm Problem in a Mobile Ad Hoc Network", Proceedings of
the 5th annual ACM/IEEE international conference on Mobile the 5th annual ACM/IEEE international conference on Mobile
computing and networking, 1999. computing and networking, 1999.
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing [MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing
Connected Dominating Sets with Multipoint Relays", Journal Connected Dominating Sets with Multipoint Relays", Journal
of Ad Hoc and Sensor Wireless Networks 2002, January 2002. of Ad Hoc and Sensor Wireless Networks 2002, January 2002.
skipping to change at page 15, line 5 skipping to change at page 15, line 12
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, April 2014. Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP) Protection for the Neighborhood Discovery Protocol (NHDP)
and Optimized Link State Routing Protocol Version 2 and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7183, April 2014. (OLSRv2)", RFC 7183, April 2014.
[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>.
Authors' Addresses Authors' Addresses
Jiazi Yi Jiazi Yi
LIX, Ecole Polytechnique Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33 1 77 57 80 85 Phone: +33 1 77 57 80 85
Email: jiazi@jiaziyi.com Email: jiazi@jiaziyi.com
URI: http://www.jiaziyi.com/ URI: http://www.jiaziyi.com/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org/ URI: http://www.thomasclausen.org/
Ulrich Herberg Ulrich Herberg
Email: ulrich@herberg.name Email: ulrich@herberg.name
 End of changes. 44 change blocks. 
145 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/