draft-ietf-manet-smf-sec-threats-04.txt   draft-ietf-manet-smf-sec-threats-05.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: August 18, 2016 U. Herberg Expires: September 9, 2016 U. Herberg
February 15, 2016 March 8, 2016
Security Threats for Simplified Multicast Forwarding (SMF) Security Threats for Simplified Multicast Forwarding (SMF)
draft-ietf-manet-smf-sec-threats-04 draft-ietf-manet-smf-sec-threats-05
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 34 skipping to change at page 1, line 34
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 August 18, 2016. This Internet-Draft will expire on September 9, 2016.
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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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. Common Threats to Duplicate Packet Detection Mechanisms . 5 4.1. Common Threats to Duplicate Packet Detection Mechanisms . 5
4.1.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . 8
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 . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 11
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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
skipping to change at page 4, line 38 skipping to change at page 4, line 38
lower-layer mechanisms are used for 1-hop neighborhood discovery), lower-layer mechanisms are used for 1-hop neighborhood discovery),
this document assumes that NHDP is used in SMF. The threats that are this document assumes that NHDP is used in SMF. The threats that are
NHDP-specific are indicated explicitly. 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: two 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,
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 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 can be achieved by replay existed packets, wrangle The attacks on DPD can be achieved by replaying existed packets,
sequence numbers, manipulate hash values, etc. They are detailed in wrangle sequence numbers, manipulate hash values, etc. They are
Section 4. 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. SMF supports the use of 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]. An Attacker can
disrupt the RSS algorithm by degrading it to classical flooding, or disrupt the RSS algorithm by degrading it to classical flooding, or
by "masking" certain parts of the routers from the multicasting by "masking" certain parts of the routers from the multicasting
domain. The attacks to RSS algorithms are illustrated in Section 5. domain. The attacks to RSS algorithms are detailed in Section 5.
Other than the attacks on DPD and RSS, a common vulnerability of
MANETs is "jamming", i.e., a device generates massive amounts of
interfering radio transmissions, which will prevent legitimate
traffic (e.g., control traffic as well as data traffic) on part of a
network. The attacks on DPD and RSS can be further enhanced by
jamming.
4. Threats to Duplicate Packet Detection 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) the 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; (2) a
router may also receive multiple copies of the same packet from router may also receive multiple copies of the same packet from
different neighbors. DPD is thus used to check if an incoming packet different neighbors. DPD is thus used to check if an incoming packet
has been previously received or not. has been previously received or not.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
by way of timestamps. Especially, if the attack is based on by way of timestamps. Especially, if the attack is based on
manipulation of jitter, the validation of timestamp would not be manipulation of jitter, the validation of timestamp would not be
helpful because the timing is still valid (but with much less value). helpful because the timing is still valid (but with much less value).
4.2.2. De-activation Attacks (Sequence Number wrangling) 4.2.2. De-activation Attacks (Sequence Number wrangling)
An attacker can also seek to de-activate DPD, by modifying the An attacker can also seek to de-activate DPD, by modifying the
sequence number in packets that it forwards. Thus, routers will not sequence number in packets that it forwards. Thus, routers will not
be able to detect an actual duplicate packet as a duplicate - rather, be able to detect an actual duplicate packet as a duplicate - rather,
they will treat them as new packets, i.e., process and forward them. they will treat them as new packets, i.e., process and forward them.
This is similar to DoS attacks. The consequence of this attack is an This is similar to DoS attacks, as each packet that is considered
increased channel load, the origin of which appears to be a router unique will be multicasted: for a network with n routers, there will
be n-1 retransmissions. This can easily cause the "broadcast storm"
problem discussed in [MOBICOM99]. The consequence of this attack is
an increased channel load, the origin of which appears to be a router
other than the attacker. other than the attacker.
Given the topology shown in Figure 2, on receiving a packet with Given the topology shown in Figure 2, on receiving a packet with
seq=n, the attacker X can forward the packet with modified sequence 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 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; able to detect the packet forwarded by X is a duplicate packet;
secondly, the consequent packet with seq=n+i generated by router A secondly, the consequent packet with seq=n+i generated by router A
probably will be treated as duplicate packet, and dropped by router probably will be treated as duplicate packet, and dropped by router
C. C.
skipping to change at page 12, line 18 skipping to change at page 12, line 19
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 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.
If NHDP is used as the neighborhood discovery protocol, [RFC7183] is For the H-DPD mechanism, applying cryptographically strong hashes can
make the digest collisions effectively impossible, and avoid the use
of hash-assistant value.
[RFC7182] specifies a framework for representing cryptographic ICVs
and timestamps in MANETs. Based on [RFC7182], [RFC7183] specifies
integrity and replay protection for NHDP using shared keys. 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. It provides certain through the exchange of HELLO messages. It provides certain
protection against identity spoofing by admitting only trusted protection against identity spoofing by admitting only trusted
routers to the network using Integrity Check Values (ICVs) in HELLO routers to the network using ICVs in HELLO messages.
messages based on shared keys.
However, using ICVs does not address the problem of attackers that However, using ICVs does not address the problem of attackers that
can generate valid ICVs. Detecting such attackers could be studied can generate valid ICVs. Detecting such attackers could be studied
in new work. The shared key mechanism makes excluding single in new work. If [RFC7183] is used, the shared key mechanism will
attackers routers difficult. Work could be done to facilitate make excluding single attackers routers more difficult. Work could
revocation mechanisms in certain MANET use cases where routers have be done to facilitate revocation mechanisms in certain MANET use
sufficient capabilities to support asymmetric keys (such as cases where routers have sufficient capabilities to support
[I-D.ietf-manet-ibs]). asymmetric keys (such as [I-D.ietf-manet-ibs], which is an extension
of [RFC7182]).
As [RFC7183] does not protect the integrity of the multicast As [RFC7183] does not protect the integrity of the multicast
datagram, and no mechanism is specified to do that for SMF yet, the datagram, and no mechanism is specified to do that for SMF yet, the
duplicate packet detection is still vulnerable to the threats duplicate packet detection is still 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.
skipping to change at page 13, line 35 skipping to change at page 13, line 45
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 10.2. Informative References
[I-D.ietf-manet-ibs] [I-D.ietf-manet-ibs]
Dearlove, C., "Identity-Based Signatures for MANET Routing Dearlove, C., "Identity-Based Signatures for MANET Routing
Protocols", draft-ietf-manet-ibs-03 (work in progress), Protocols", draft-ietf-manet-ibs-04 (work in progress),
September 2014. November 2015.
[MOBICOM99]
Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast
Storm Problem in a Mobile Ad Hoc Network", Proceedings of
the 5th annual ACM/IEEE international conference on Mobile
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.
[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.
 End of changes. 14 change blocks. 
24 lines changed or deleted 47 lines changed or added

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