Internet Engineering Task Force (IETF) J. Yi Request for Comments: 7985 T. Clausen Updates: 7186 Ecole Polytechnique Category: Informational U. Herberg ISSN: 2070-1721 November 2016 Security Threats to Simplified Multicast Forwarding (SMF)
AbstractThis document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130). Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7985.
Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. SMF Threat Overview . . . . . . . . . . . . . . . . . . . . . 4 4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5 4.1. Attack on the Hop Limit Field . . . . . . . . . . . . . . 6 4.2. Threats to Identification-Based Duplicate Packet Detection . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Pre-Activation Attacks (Pre-Play) . . . . . . . . . . 7 4.2.2. De-activation Attacks (Sequence Number Wrangling) . . 8 4.3. Threats to Hash-Based Duplicate Packet Detection . . . . 9 4.3.1. Attack on the Hash-Assistant Value . . . . . . . . . 9 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . 10 5.1. Common Threats to Relay Set Selection . . . . . . . . . . 10 5.2. Threats to the E-CDS Algorithm . . . . . . . . . . . . . 10 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . 11 5.4. Threats to the MPR-CDS Algorithm . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
RFC6621]. SMF aims at providing basic Internet Protocol (IP) multicast forwarding in a way that is suitable for wireless mesh and Mobile Ad Hoc Networks (MANET). SMF consists of two major functional components: duplicate packet detection (DPD) and relay set selection (RSS). SMF is typically used in decentralized wireless environments and is potentially exposed to various attacks and misconfigurations. In a wireless environment, some of these attacks and misconfigurations represent threats of particular significance as compared to what they would do in wired networks. [RFC6621] briefly discusses several of these, but does not define any explicit security measures for protecting the integrity of the protocol. This document is based on the assumption that no additional security mechanism, such as IPsec, is used in the IP layer, as not all MANET deployments may be able to support deployment of such common IP protection mechanisms (e.g., because MANET routers may have limited resources for supporting the IPsec stack). It also assumes that there is no lower-layer protection. The document analyzes possible attacks on, and misconfigurations of, SMF and outlines the consequences of such attacks/misconfigurations to the state maintained by SMF in each router. In the Security Considerations section of [RFC6621], denial-of- service-attack scenarios are briefly discussed. This document further analyzes and describes the potential vulnerabilities of, and attack vectors for, SMF. While completeness in such analysis is always a goal, no claims of being complete are made. The goal of this document is to be helpful when deploying SMF in a network and for understanding the risks incurred, as well as for providing a reference to and documented experience with SMF as input for possible future developments of SMF. This document is not intended to propose solutions to the threats described. [RFC7182] provides a framework that can be used with SMF, and depending on how it is used, may offer some degree of protection against the threats related to identity spoofing described in this document. This document also updates [RFC7186], specifically with respect to threats to relay set selection (RSS) mechanisms that are using MANET NHDP [RFC6130].
RFC5444], [RFC6130], [RFC6621], and [RFC4949]. Additionally, this document introduces the following terminology: SMF router: A MANET router, running SMF as specified in [RFC6621]. Attacker: A device that is present in the network and intentionally seeks to compromise the information bases in SMF routers. It may generate syntactically correct SMF control messages. Legitimate SMF router: An SMF router that is correctly configured and not compromised by an attacker. RFC7181]) or by explicitly using the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130]. If NHDP is used for both 1-hop and 2-hop neighborhood discovery by SMF, SMF implicitly inherits the vulnerabilities of NHDP discussed in [RFC7186]. As SMF relies on NHDP to assist in network-layer 2-hop neighborhood discovery (no matter if other lower-layer mechanisms are used for 1-hop neighborhood discovery), this document assumes that NHDP is used in SMF. The threats that are NHDP specific are indicated explicitly. Based on neighborhood discovery mechanisms, [RFC6621] specifies two principal functional components: duplicate packet detection (DPD) and relay set selection (RSS). DPD is required by SMF in order to be able to detect duplicate packets and eliminate their redundant forwarding. An attacker has two ways in which to harm the DPD mechanisms. Specifically, it can: o "deactivate" DPD, making it such that duplicate packets are not correctly detected. As a consequence, they are (redundantly) transmitted, which increases the load on the network, drains the batteries of the routers involved, etc.
o "pre-activate" DPD, making DPD detect a later arriving (valid) packet as being a duplicate and will, therefore, not be forwarded. Attacks on DPD can be achieved by replaying existing packets, wrangling sequence numbers, manipulating hash values, etc.; these are detailed in Section 4. RSS produces a reduced relay set for forwarding multicast data packets across a MANET. For use in SMF, [RFC6621] specifies several relay set algorithms including E-CDS (Essential Connected Dominating Set) [RFC5614], S-MPR (Source-Based Multipoint Relay, as known from [RFC3626] and [RFC7181]), and MPR-CDS (Multipoint Relay Connected Dominating Set) [MPR-CDS]. An attacker can disrupt the RSS algorithm, and thereby the SMF operation, by degrading it to classical flooding or by "masking" certain parts of the network from the multicasting domain. Attacks on RSS algorithms are detailed in Section 5. Other than the attacks on DPD and RSS, a common vulnerability of MANETs is "jamming", i.e., a device generates massive amounts of interfering radio transmissions, which will prevent legitimate traffic (e.g., control traffic as well as data traffic) on part of a network. The attacks on DPD and RSS can be further enhanced by jamming.
In the Security Considerations section of [RFC6621], a selection of threats to DPD are briefly introduced. This section expands on that discussion and describes how to effectively launch the attacks on DPD -- for example, by way of manipulating jitter and/or the Hash- Assistant Value. In the remainder of this section, common threats to packet detection mechanisms are discussed first; then, the threats to I-DPD and H-DPD are introduced separately. The threats described in this section are applicable to general SMF implementations, regardless of whether NHDP is used. Figure 1, router A forwards a multicast packet with a TTL of 64 to the network. A, B, and C are legitimate SMF routers, and X is an attacker. In a wireless environment, jitter is commonly used to avoid systematic collisions in Media Access Control (MAC) protocols [RFC5148]. An attacker can thus increase the probability that its invalid packets arrive first by retransmitting them without applying jitter. In this example, router X forwards the packet without applying jitter and reduces the TTL to 1. Router C thus records the duplicate detection value (hash value for H-DPD or the header content of the packets for I-DPD) but does not forward the packet (due to TTL == 1). When a second copy of the same packet, with a non-maliciously manipulated TTL value (63 in this case), arrives from router B, it will be discarded as a duplicate packet. .---. | X | --'---' __ packet with TTL=64 / \ packet with TTL=1 / \ .---. .---. | A | | C | '---' '---' packet with TTL=64 \ .---. / \-- | B |__/ packet with TTL=63 '---' Figure 1
As the TTL of a packet is intended to be manipulated by intermediaries forwarding it, classic methods such as integrity check values (e.g., digital signatures) are typically calculated by setting TTL fields to some predetermined value (e.g., 0) -- for example, the case for IPsec Authentication Headers -- rendering such an attack more difficult to both detect and counter. If the attacker has access to a "wormhole" through the network (a directional antenna, a tunnel to a collaborator, 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. Figure 2 gives an example of a pre-activation attack. A, B, and C are legitimate SMF routers, and X is the attacker. The line between the routers presents the packet forwarding. Router A is the source and originates a multicast packet with sequence number n. When router X receives the packet, it generates an invalid packet with the source address of A and sequence number n. If the invalid packet arrives at router C before the forwarding of router B, the valid
packet will be dropped by C as a duplicate packet. An attacker can manipulate jitter to make sure that the invalid packets arrive first. Router X can even generate packets with future sequence numbers (if they are predictable), so that the future legitimate packets with the same sequence numbers will be dropped as duplicate ones. .---. | X | --'---' __ packet with seq=n / \ invalid packet with seq=n / \ .---. .---. | A | | C | '---' '---' packet with seq=n \ .---. / \-- | B |__/ valid packet with seq=n '---' Figure 2 As SMF does not currently have any timestamp mechanisms to protect data packets, there is no viable way to detect such pre-play attacks by way of timestamps. Especially, if the attack is based on manipulation of jitter, the validation of the timestamp would not be helpful because the timing is still valid (but, much less valuable). MOBICOM99]. The consequence of this attack is an increased channel load, the origin of which appears to be a router other than the attacker. Given the topology shown in Figure 2, on receiving a packet with seq=n, the attacker X can forward the packet with a modified sequence number n+i. This has two consequences: firstly, router C will not be able to detect that the packet forwarded by X is a duplicate packet; secondly, the consequent packet with seq=n+i generated by router A will probably be treated as a duplicate packet and will be dropped by router C.
Figure 3, routers A and B are legitimate SMF routers; X is an attacker. Router A generates two packets, P1 and P2, with the same hash value h(P1)=h(P2)=x. Based on the SMF specification, a HAV is added to the latter packet P2, so that h(P2+HAV)=x' avoids digest collision. When the attacker X detects the HAV of P2, it is able to conclude that a collision is possible by removing the HAV header. By doing so, packet P2 will be treated as a duplicate packet by router B and will be dropped. P2 P1 P2 P1 .---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---. | A |---------------------------> | X | ----------------------> | B | `---' `---' `---' Figure 3
RFC6621] are analyzed. As the relay set selection is based on 1-hop and 2-hop neighborhood information, which rely on NHDP, the threats described in this section are NHDP specific. RFC7186]. RFC5614] forms a single CDS mesh for an SMF operating region. This algorithm requires 2-hop neighborhood information (the identity of the neighbors, the link to the neighbors, and the neighbors' priority information), as collected through NHDP or another process. An SMF router will select itself as a relay, if: o The SMF router has a higher priority than all of its symmetric neighbors, or o A path from the neighbor with the largest priority to any other neighbor via neighbors with greater priority than the current router does not exist. An attacker can disrupt the E-CDS algorithm by link spoofing or identity spoofing.
Section 5.1 of [RFC7186].
Sections 5.2 and 5.3 apply to MPR-CDS also. RFC6621] nor this document propose mechanisms to secure the SMF protocol, there are several possibilities to secure the protocol in the future and drive new work by suggesting which threats discussed in the previous sections could be addressed. For the I-DPD mechanism, employing randomized packet sequence numbers can avoid some pre-activation attacks based on sequence number prediction. If predicable sequence numbers have to be used, applying timestamps can mitigate pre-activation attacks. For the H-DPD mechanism, applying cryptographically strong hashes can make the digest collisions effectively impossible, and it can avoid the use of a HAV. [RFC7182] specifies a framework for representing cryptographic Integrity Check Values (ICVs) and timestamps in MANETs. Based on [RFC7182], [RFC7183] specifies integrity and replay protection for NHDP using shared keys as a mandatory-to-implement security mechanism. If SMF is using NHDP as the neighborhood discovery protocol, implementing [RFC7183] remains advisable so as to enable integrity protection for NHDP control messages. This can help mitigate threats related to identity spoofing through the exchange of HELLO messages and provide some general protection against identity spoofing by admitting only trusted routers to the network using ICVs in HELLO messages.
Using ICVs does not, of course, address the problem of attackers able to also generate valid ICVs. Detection and exclusion of such attackers is, in general, a challenge that is not unrelated to how [RFC7182] is used. If, for example, it is used with a shared key (as per [RFC7183]), excluding single attackers generally is not aided by the use of ICVs. However, if routers have sufficient capabilities to support the use of asymmetric keys (as per [RFC7859]), part of addressing this challenge becomes one of providing key revocation in a way that does not in itself introduce additional vulnerabilities. As [RFC7183] does not protect the integrity of the multicast user datagram, and as no mechanism is specified by SMF for doing so, duplicate packet detection remains vulnerable to the threats introduced in Section 4. If pre-activation/de-activation attacks and attacks on the HAV of the multicast datagrams are to be mitigated, a datagram-level integrity protection mechanism is desired, by taking consideration of the identity field or HAV. However, this would not be helpful for the attacks on the TTL (or Hop Limit for IPv6) field, because the mutable fields are generally not considered when ICV is calculated. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>. [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, May 2012, <http://www.rfc-editor.org/info/rfc6621>. [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", RFC 7186, DOI 10.17487/RFC7186, April 2014, <http://www.rfc-editor.org/info/rfc7186>. [MOBICOM99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The broadcast storm problem in a mobile ad hoc network", MobiCom '99 Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, DOI 10.1145/313451.313525, 1999.
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing Connected Dominating Sets with Multipoint Relays", Journal of Ad Hoc and Sensor Wireless Networks 2002, January 2002. [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, <http://www.rfc-editor.org/info/rfc3626>. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>. [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, DOI 10.17487/RFC5148, February 2008, <http://www.rfc-editor.org/info/rfc5148>. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <http://www.rfc-editor.org/info/rfc5444>. [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, <http://www.rfc-editor.org/info/rfc5614>. [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>. [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, <http://www.rfc-editor.org/info/rfc7182>. [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, <http://www.rfc-editor.org/info/rfc7183>. [RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols", RFC 7859, DOI 10.17487/RFC7859, May 2016, <http://www.rfc-editor.org/info/rfc7859>.
http://www.jiaziyi.com/ Thomas Heide Clausen Ecole Polytechnique 91128 Palaiseau Cedex France Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.thomasclausen.org/ Ulrich Herberg Email: email@example.com URI: http://www.herberg.name/