draft-ietf-manet-smf-sec-threats-01.txt   draft-ietf-manet-smf-sec-threats-02.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 Intended status: Informational LIX, Ecole Polytechnique
Expires: March 18, 2015 U. Herberg Expires: September 24, 2015 U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
September 14, 2014 March 23, 2015
Security Threats for Simplified Multicast Forwarding (SMF) Security Threats for Simplified Multicast Forwarding (SMF)
draft-ietf-manet-smf-sec-threats-01 draft-ietf-manet-smf-sec-threats-02
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), including the vulnerabilities of duplicate packet
detection and relay set selection mechanisms. This document is not detection and relay set selection mechanisms. This document is not
intended to propose solutions to the threats described. intended to propose solutions to the threats described.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 18, 2015. This Internet-Draft will expire on September 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
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. Threats to Identification-based Duplicate Packet 4.1. Common Threats to Duplicate Packet Detection Mechanisms . 5
Detection . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 6 4.2. Threats to Identification-based Duplicate Packet
4.1.2. De-activation Attacks (Sequence Number wrangling) . . 6 Detection . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Threats to Hash-based Duplicate Packet Detection . . . . . 7 4.2.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 7
4.2.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 7 4.2.2. De-activation Attacks (Sequence Number wrangling) . . 8
4.2.2. Attack on Hash-Assistant Value . . . . . . . . . . . . 8 4.3. Threats to Hash-based Duplicate Packet Detection . . . . . 8
4.3.1. Attack on Hash-Assistant Value . . . . . . . . . . . . 9
5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 9 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 9
5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 9 5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 10
5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 9 5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 10
5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 10 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11
5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 10 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 11
5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 11 5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 11
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document analyzes security threats of 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 which 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 different kinds of attacks and
misconfigurations. Some of the threats are of particular misconfigurations. Some of the threats are of particular
significance as compared to wired networks. In [RFC6621], SMF does significance as compared to wired networks. In [RFC6621], SMF does
not define any explicit security measures for protecting the not define any explicit security measures for protecting the
integrity of the protocol. 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). The document analyzes possible attacks on and mis- IPsec stack). 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 This document aims at analyzing and describing the potential
vulnerabilities of and attack vecors for SMF. While completeness in vulnerabilities of and attack vectors for SMF. While completeness in
such an analysis always is a goal, no claims of being complete are 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 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 SMF in a network and needing to understand the risks thereby incurred
- as wll as for providing a reference and documented experience with - as wll as for providing a reference and documented experience with
SMF as input for possibly future developments of SMF. 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. [RFC7183] provides a framework, which can be used with described. [RFC7182] provides a framework, which can be used with
SMF, and which - depending on how it is used - may offer some degree SMF, and which - depending on how it is used - may offer some degree
of protection against the threats described in this document related of protection against the threats described in this document related
to identity spoofing. to identity spoofing.
2. Terminology 2. Terminology
This document uses the terminology and notation defined in [RFC2119], This document uses the terminology and notation defined in [RFC5444],
[RFC5444], [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
seeks to compromise the information bases in SMF routers. seeks to compromise the information bases in SMF routers.
Compromised SMF router: An attacker, present in the network and Compromised SMF router: An attacker, which generates syntactically
which generates syntactically correct SMF control messages. correct SMF control messages. Control messages emitted by a
Control messages emitted by a compromised SMF router may contain compromised SMF router may contain additional information, or omit
additional information, or omit information, as compared to a information, as compared to a control message generated by a non-
control message generated by a non-compromised SMF router located compromised SMF router located in the same topological position in
in the same topological position in the network. the network.
Legitimate SMF router: An SMF router, which is not a compromised SMF Legitimate SMF router: An SMF router, which is not a compromised SMF
Router. Router.
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
orde 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 which 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 neighborhood
discovery by SMF, SMF implicitly inherits the vulnerabilities of discovery by SMF, SMF implicitly inherits the vulnerabilities of
NHDP, as discussed in [RFC7186]. This document assumes that NHDP is NHDP, as discussed in [RFC7186]. As SMF relies on NHDP to assist in
used. 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 in SMF. The threats that are
NHDP-specific are indicated explicitly.
Based on neighborhood discovery mechanisms, SMF specified two major Based on neighborhood discovery mechanisms, SMF specified two major
functional components: Duplicate Packet Detection (DPD) and Relay Set functional components: Duplicate Packet Detection (DPD) and Relay Set
Selection (RSS). 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
several ways in which to harm the DPD mechanisms: several ways in which to harm the DPD mechanisms:
o It can "deactivate" DPD, so as to make it such that duplicate o It can "deactivate" DPD, so as to make it such that duplicate
packets are not correctly detected, and that as a consequence they packets are not correctly detected, and that as a consequence they
are (redundantly) transmitted, increasing the load on the network, are (redundantly) transmitted, increasing the load on the network,
draing 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 It can "pre-activate" DPD, so as to make DPD detect a later
arriving (valid) packet as being a duplicate, which therefore arriving (valid) packet as being a duplicate, which therefore
won't be forwarded" won't be forwarded"
The attacks on DPD are detailed in Section 4. The attacks on DPD are detailed in Section 4.
RSS produces a reduced relay set forforwarding multicast data packets RSS produces a reduced relay set for forwarding multicast data
across the MANET. SMF supports the use of several relay set packets across the MANET. SMF supports the use of several relay set
algorithms, including E-CDS (Essential Connected Dominating Set), algorithms, including E-CDS (Essential Connected Dominating Set)
S-MPR (Source-based Multi-point Relay, as known from [RFC3626] and [RFC5614], S-MPR (Source-based Multi-point Relay, as known from
[RFC7181]), or MPR-CDS. An Attacker can disrupt the RSS algorithm, [RFC3626] and [RFC7181]), or MPR-CDS [MPR-CDS]. An Attacker can
by degrading it to classical flooding, or by "masking" certain part disrupt the RSS algorithm, by degrading it to classical flooding, or
of the routers from the multicasting domain. The attacks to RSS by "masking" certain parts of the routers from the multicasting
algorithms are illustrated in Section 5. domain. The attacks to RSS algorithms are illustrated in Section 5.
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 MANET because the packets may be transmitted via the same physical in MANET because the packets may be transmitted via the same physical
interface as the one over which they were received. A router may interface as the one over which they were received. A router may
also receive multiple copies of the same packets from different also receive multiple copies of the same packets from different
neighbors. DPD is thus used to check if an incoming packet has been neighbors. DPD is thus used to check if an incoming packet has been
received or not. received or not.
skipping to change at page 5, line 36 skipping to change at page 5, line 40
processed multicast packets, and comparing later received multicast processed multicast packets, and comparing later received multicast
herewith. A duplicate packet detected is silently dropped, and is herewith. A duplicate packet detected is silently dropped, and is
not inserted into the forwarding path of that router, nor is it not inserted into the forwarding path of that router, nor is it
delivered to an application. DPD, as proposed by SMF, supports both delivered to an application. DPD, as proposed by SMF, supports both
IPv4 and IPv6 and for each suggests two duplicate packet detection IPv4 and IPv6 and for each suggests two duplicate packet detection
mechanisms: 1) header content identification-based DPD (I-DPD), using mechanisms: 1) header content identification-based DPD (I-DPD), using
packet headers, in combination with flow state, to estimate temporal packet 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.
As they are distinct mechanisms, the threats to I-DPD and H-DPD are In the following of this section, common threats to packet detection
discussed separately. mechanisms are first discussed. 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 NHDP is used
or not.
4.1. Threats to Identification-based Duplicate Packet Detection 4.1. Common Threats to Duplicate Packet Detection 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 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
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 the TTL hereof. This will inhibit
recipient routers from later forwarding the same multicast packet,
even if received with a different TTL - essentially a compromised SMF
router thus can instruct its neighbors to block 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 the compromised SMF router. In a wireless environment,
jitter is commonly used to avoid systematic collisions in MAC
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 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
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 has access to a "wormhole" through the
network (a directional antenna, a tunnel to a collaborator or a wired
connection, allowing it to bridge parts of a network otherwise
distant), it can make sure that the packets with such an artificially
reduced TTL arrive before their unmodified counterparts.
4.2. Threats to Identification-based Duplicate Packet Detection
I-DPD uses a specific DPD identifier in the packet header to identify I-DPD uses a specific DPD identifier in the packet header to identify
a packet. By default, such packet identification is not provided by a packet. By default, such packet identification is not provided by
the IP packet header (for both IPv4 and IPv6). Therefore, additional the IP packet header (for both IPv4 and IPv6). Therefore, additional
identification header, such as the fragment header, a hop-by-hop identification header, such as the fragment header, a hop-by-hop
header option, or IPSec sequencing, must be employed in order to header option, or IPSec sequencing, must be employed in order to
support I-DPD. The uniqueness of a packet can then be identified by support I-DPD. The uniqueness of a packet can then be identified by
the [source IP address] of the packet originator, and the [sequence the [source IP address] of the packet originator, and the [sequence
number] (from the fragment header, hop-by-hop header option, or number] (from the fragment header, hop-by-hop header option, or
IPsec). By doing so, each intermediate router can keep a record of IPsec). By doing so, each intermediate router can keep a record of
recently received packet, and determine the coming packet has been recently received packets, and determine whether the incoming packet
received or not. has been received or not.
4.1.1. Pre-activation Attacks (Pre-Play) 4.2.1. Pre-activation Attacks (Pre-Play)
In a wireless environment, or across any other shared channel, a In a wireless environment, or across any other shared channel, a
compromised SMF router can perceive the identification tuple [source compromised SMF router can perceive the identification tuple [source
IP, sequence number] of a packet. If sequence number progression is IP address, sequence number] of a packet. It is possible to generate
predictable, then it is trivial to generate and inject invalid packet with the same [source IP address, sequence number] pair with
packets with "future" identification information into the network. invalid content. If sequence number progression is predictable, then
If these invalid packets arrive before the legitimate packets that it is trivial to generate and inject invalid packets with "future"
they're spoofing, the latter will be treated as a duplicates and identification information into the network. If these invalid
discarded. This can prevent multicast packets from reaching parts of packets arrive before the legitimate packets that they're spoofing,
the network. the latter will be treated as a duplicates and discarded. This can
prevent multicast packets from reaching parts of the network.
Figure 1 gives an example of pre-activation attack. A, B, and C are Figure 2 gives an example of pre-activation attack. A, B, and C are
legitimate SMF routers, and X is the compromised SMF router. The legitimate SMF routers, and X is the compromised SMF router. The
line between the routers presents the packet forwarding. Router A is line between the routers presents the packet forwarding. Router A is
the source and originates a multicast packet with sequence number n. the source and originates a multicast packet with sequence number n.
When router X receives the packet, it generates an invalid packet When router X receives the packet, it generates an invalid packet
with the the source address of A, and sequence number n. If the 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, invalid packet arrives at router C before the forwarding of router B,
the valid packet will be dropped by C as duplicate packet. In a the valid packet will be dropped by C as duplicate packet. An
wireless environment, jitter is commonly used to avoid systematic attacker can manipulate jitter to make sure that the invalid packets
collisions at MAC layer [RFC5148], thus an attacker can increase the arrive first. Router X can even generate packet with future sequence
probability that its invalid packets arrive first by retransmitting numbers (if they are predictable), so that the future legitimate
them without jittering. packets with the same sequence numbers will be dropped as duplicate
ones.
.---. .---.
| X | | X |
--'---' __ --'---' __
packet with seq=n / \ invalid packet with seq=n packet with seq=n / \ invalid packet with seq=n
/ \ / \
.---. .---. .---. .---.
| A | | C | | A | | C |
'---' '---' '---' '---'
packet with seq=n \ .---. / packet with seq=n \ .---. /
\-- | B |__/ valid packet with seq=n \-- | B |__/ valid packet with seq=n
'---' '---'
Figure 1 Figure 2
4.1.2. De-activation Attacks (Sequence Number wrangling) As SMF currently does not have any timestamp mechanisms to protect
data packets, there is no viable way to detect such pre-play attacks
by timestamp. Especially, if the attack 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 A compromised SMF router can also seek to de-activate DPD, by
modifying the sequence number in packets that it forwards. Thus, modifying the sequence number in packets that it forwards. Thus,
routers will not be able to detect an actual duplicate packet as a routers will not be able to detect an actual duplicate packet as a
duplicate - rather, they will treat them as new packets, i.e., duplicate - rather, they will treat them as new packets, i.e.,
process and forward them. This is similar to DoS attack. The process and forward them. This is similar to DoS attack. The
consequence of this attack is an increased channel load, the origin consequence of this attack is an increased channel load, the origin
of which appears to be a router other than the compromised SMF of which appears to be a router other than the compromised SMF
router. router.
Given the topology shown in Figure 1, on receiving packet with seq=n, Given the topology shown in Figure 2, on receiving packet with seq=n,
the attacker X can forward the packet with modified sequence number the attacker X can forward the packet with modified sequence number
n+i. This has two consequences: firstly, router C will not be able 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, to detect the packet forwarded by X is a duplicate packet; secondly,
the consequent packet with seq=n+i generated by router A probably the consequent packet with seq=n+i generated by router A probably
will be treated as duplicate packet, and dropped by router C. will be treated as duplicate packet, and dropped by router C.
4.2. Threats to Hash-based Duplicate Packet Detection 4.3. Threats to Hash-based Duplicate Packet Detection
When it is not feasible to have explicit sequence numbers in packet 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 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 fields in the header of and the data payload can be generated, and
recorded at the intermediate routers. A packet can thus be uniquely recorded at the intermediate routers. A packet can thus be uniquely
identified by the source IP address of the packet, and its hash- identified by the source IP address of the packet, and its hash-
value. value.
The hash algorithm used by SMF is being applied only to provide a The hash algorithm used by SMF is being applied only to provide a
reduced probability of collision and is not being used for reduced probability of collision and is not being used for
cryptographic or authentication purposes. Consequently, a digest cryptographic or authentication purposes. Consequently, a digest
collision is still possible. In case the source router or gateway collision is still possible. In case the source router or gateway
identifies that it recently has generated or injected a packet with identifies that it recently has generated or injected a packet with
the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6 the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6
header option into the packet, such that calculating the hash also header option into the packet, such that calculating the hash also
over this HAV will render the resulting value unique. over this HAV will render the resulting value unique.
4.2.1. Replay Attack 4.3.1. Attack on Hash-Assistant Value
A replay attack implies that control traffic from one region of the
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
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 the TTL hereof. This will inhibit
recipient routers from later forwarding the same multicast packet,
even if received with a different TTL - essentially a compromised SMF
router thus can instruct its neighbors to block forwarding of valid
multicast packets.
For example, given the example in Figure 2, 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 the compromised SMF router. Router
X forwards the packet without jittering, and reduces the TTL to 1.
Router C thus records the hash value of the packets, 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 TTL=64 / \ packet with TTL=1
/ \
.---. .---.
| A | | C |
'---' '---'
packet with TTL=64 \ .---. /
\-- | B |__/ packet with TTL=63
'---'
Figure 2
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 has access to a "wormhole" through the network
(a directional antenna, a tunnel to a collaborator or a wired
connection, allowing it to bridge parts of a network otherwise
distant) it can make sure that the packets with such an artificially
reduced TTL arrive before their unmodified counterparts.
4.2.2. Attack on Hash-Assistant Value
The HAV header is helpful when a digest collision happens. However, The HAV header is helpful when a digest collision happens. However,
it also introduces a potential vulnerability. As the HAV option is it also introduces a potential vulnerability. As the HAV option is
only added when the source or the ingressing SMF router detects that only added when the source or the ingressing SMF router detects that
the coming packet has digest collision with previously generated the coming packet has digest collision with previously generated
packets, it actually can be regarded as a "flag" of potential digest packets, it actually can be regarded as a "flag" of potential digest
collision. A compromised SMF router can discover the HAV header, and 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 be able to conclude a hash collision is possible if the HAV header is
removed. By doing so, other SMF routers receiving the modified removed. By doing so, other SMF routers receiving the modified
packet will be treated as duplicate packet, and be dropped because it packet will be treated as duplicate packet, and be dropped because it
skipping to change at page 9, line 27 skipping to change at page 10, line 9
5. Threats to Relay Set Selection 5. Threats to Relay Set Selection
A framework for RSS mechanism, rather than a specific RSS algorithm A framework for RSS mechanism, rather than a specific RSS algorithm
is provided by SMF. It is normally achieved by distributed is provided by SMF. It is normally achieved by distributed
algorithms that can dynamically generate a topological Connected algorithms that can dynamically generate a topological Connected
Dominating Set based on 1-hop and 2-hop neighborhood information. In Dominating Set based on 1-hop and 2-hop neighborhood information. In
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. 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 5.1. Relay Set Selection Common Threats
The common threats to RSS algorithms, including Denial of Service The common threats to RSS algorithms, including Denial of Service
attack, eavesdropping, message timing attack and broadcast storm have attack, eavesdropping, message timing attack and broadcast storm have
been discussed in [RFC7186]. 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]
skipping to change at page 11, line 22 skipping to change at page 11, line 50
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, the vulnerabilities of E-CDS and As MPR-CDS combines E-CDS and S-MPR and the simple combination of the
S-MPR that discussed in Section 5.2 and Section 5.3 apply to MPR-CDS two algorithms does not address the weakness, the vulnerabilities of
also. E-CDS and S-MPR that discussed in Section 5.2 and Section 5.3 apply
to MPR-CDS also.
6. Future Work 6. Future Work
Neither [RFC6621] nor this document propose mechanisms to secure the Neither [RFC6621] nor this document propose mechanisms to secure the
SMF protocol. However, this section aims at discussing possibilities SMF protocol. However, this section aims at discussing possibilities
to secure the protocol in the future and driving new work by to secure the protocol in the future and driving new work by
suggesting which threats discussed in the previous sections could be suggesting which threats discussed in the previous sections could be
addressed. 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 If NHDP is used as the neighborhood discovery protocol, [RFC7183] is
recommended to be implemented to enable integrity protection to NHDP, recommended to be implemented to enable integrity protection to NHDP,
which can help mitigating the threats related to identity spoofing which can help mitigating the threats related to identity spoofing
through the exchange of HELLO messages. through the exchange of HELLO messages.
[RFC7183] provides certain protection against identity spoofing by [RFC7183] provides certain protection against identity spoofing by
admitting only trusted routers to the network using Integrity Check admitting only trusted routers to the network using Integrity Check
Values (ICVs) in HELLO messages. However, using ICVs does not Values (ICVs) in HELLO messages. However, using ICVs does not
address the problem of compromised routers that can generate valid address the problem of compromised routers that can generate valid
ICVs. Detecting such compromised routers could be studied in new ICVs. Detecting such compromised routers could be studied in new
work. [RFC7183] mandates implementation of a security mechanism that work. [RFC7183] mandates implementation of a security mechanism that
is based on shared keys and makes excluding single compromised is based on shared keys and makes excluding single compromised
routers difficult. Work could be done to facilitate revocation routers difficult. Work could be done to facilitate revocation
mechanisms in certain MANET use cases where routers have sufficient mechanisms in certain MANET use cases where routers have sufficient
capabilities to support asymmetric keys. capabilities to support asymmetric keys (such as
[I-D.ietf-manet-ibs]) .
As [RFC7183] does not protect the integrity of the datagram, and no As [RFC7183] does not protect the integrity of the multicast
mechanism is specified to do that for SMF yet, the duplicate packet datagram, and no mechanism is specified to do that for SMF yet, the
detection is still vulnerable to the threats introduced in Section 4. duplicate packet detection is still vulnerable to the threats
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 are to be mitigated, a datagram-level integrity protection value of the multicast datagrams are to be mitigated, a datagram-
mechanism is desired, by taking consideration of the identity field level integrity protection mechanism is desired, by taking
or hash-assistant value. However, this would not be helpful for the consideration of the identity field or hash-assistant value.
attacks on the TTL (or hop limit for IPv6) field, because the mutable However, this would not be helpful for the attacks on the TTL (or hop
fields are generally not considered when ICV is calculated. limit for IPv6) field, because the mutable fields are generally not
considered when ICV is calculated.
7. Security Considerations 7. Security Considerations
This document does not specify a protocol or a procedure. The This document does not specify a protocol or a procedure. The whole
document, however, reflects on security considerations for SMF for document, however, reflects on security considerations for SMF for
packet dissemination in MANETs. packet dissemination in MANETs.
8. IANA Considerations 8. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
9. References [RFC Editor: please remove this section prior to publication.]
9.1. Normative References 9. Acknowledgments
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate The authors would like to thank Christopher Dearlove (BAE Systems
Requirement Levels", BCP 14, RFC 2119, March 1997. ATC) who provided detailed review and valuable comments.
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 10. References
Extension of OSPF Using Connected Dominating Set (CDS)
Flooding", RFC 5614, August 2009. 10.1. Normative References
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
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.
9.2. Informative References 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 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008. RFC 5148, February 2008.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Extension of OSPF Using Connected Dominating Set (CDS)
RFC 6130, April 2011. Flooding", RFC 5614, August 2009.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
RFC 7181, April 2014. 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 [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.
Authors' Addresses Authors' Addresses
Jiazi Yi Jiazi Yi
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
 End of changes. 47 change blocks. 
148 lines changed or deleted 200 lines changed or added

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