RFC 7985

Security Threats to Simplified Multicast Forwarding (SMF)

📅 published November 2016, from ietf

RFC 7985: Security Threats to Simplified Multicast Forwarding (SMF) 🎀

Okay bestie, here's the vibe check first 💅

  • Number and title: RFC 7985, Security Threats to Simplified Multicast Forwarding (SMF)
  • Authors: J. Yi, T. Clausen, and U. Herberg, with the affiliation Ecole Polytechnique listed in the header 🧚
  • Category: Informational, so it's for information, not an Internet Standards Track spec 📚
  • Date: November 2016
  • ISSN: 2070-1721
  • Updates: RFC 7186 (it's a threat-analysis update, see the Abstract below) 🔄
  • Obsoletes: nothing listed in the header

Abstract

So this doc goes through the security threats to SMF 🦋 It covers the weak spots in duplicate packet detection and in relay set selection. It is not trying to propose fixes for any of them, just to map out the risks.

It also updates RFC 7186 when it comes to threats against relay set selection mechanisms that run on the MANET Neighborhood Discovery Protocol (NHDP), which is RFC 6130 🌸

Status of This Memo

Not a Standards Track spec, just published for info purposes ✨ It's a product of the IETF and was approved for publication by the IESG. Being approved by the IESG doesn't mean something is a candidate for any level of Internet Standard, so go check Section 2 of RFC 7841 if you want the details 🙈

Want the current status, errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc7985.

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) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶

Table of Contents

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

1. Introduction ✨

This doc analyzes security threats to Simplified Multicast Forwarding (SMF) [RFC6621]. SMF's whole job is basic IP multicast forwarding, and it's designed to work for wireless mesh and Mobile Ad Hoc Networks (MANET) 🌈 It has two main parts: duplicate packet detection (DPD) and relay set selection (RSS).

SMF usually lives in decentralized wireless environments, which means it can get hit by all sorts of attacks and misconfigurations 😭 Over wireless, some of these are a much bigger deal than they'd be on a wired network. [RFC6621] briefly talks about a few of them, but it doesn't define any explicit security measures for protecting the protocol's integrity.

This doc assumes no extra security mechanism, like IPsec, is running at the IP layer. Not every MANET deployment can handle something like that (for example, MANET routers might not have enough resources to run an IPsec stack) 💀 It also assumes there's no lower-layer protection. The doc goes through possible attacks on, and misconfigurations of, SMF, and it lays out what those do to the state SMF keeps in each router 🔥

The Security Considerations of [RFC6621] briefly cover denial-of-service scenarios. This doc goes deeper into the vulnerabilities of SMF and the attack vectors against it 🦋 Completeness is always the goal, but this doc doesn't claim to be complete. The real aim is to help you deploy SMF and understand the risks, and to serve as a reference and a record of real experience with SMF, which can feed into any future SMF work 🌸

This doc is not trying to propose solutions to the threats it describes. [RFC7182] provides a framework that can be used with SMF, and depending on how you use it, it might give some protection against the identity spoofing threats covered here 🧚

This doc also updates [RFC7186], specifically for threats to relay set selection (RSS) mechanisms that use MANET NHDP [RFC6130] 👑

2. Terminology

This doc uses the terminology and notation defined in [RFC5444], [RFC6130], [RFC6621], and [RFC4949] 📚

It also introduces these terms:

  • SMF router: A MANET router that runs SMF as specified in [RFC6621].
  • Attacker: A device that's present in the network and intentionally tries 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. ✅

3. SMF Threat Overview

An SMF router needs an external dynamic neighborhood discovery mechanism so it can maintain good topological info about its immediate neighborhood. That info is what lets it pick reduced relay sets for forwarding multicast data traffic 🧠 That external mechanism can come from lower-layer interface info, from a MANET routing protocol that's already running and keeping that info (for example, [RFC7181]), or from 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] 🫠 SMF leans on NHDP for network-layer 2-hop neighborhood discovery no matter what lower-layer mechanisms handle 1-hop discovery. So this doc assumes NHDP is used in SMF. The threats that are specific to NHDP are called out explicitly 💅

Based on the neighborhood discovery mechanisms, [RFC6621] specifies two principal functional components: duplicate packet detection (DPD) and relay set selection (RSS) 🌈

DPD is required by SMF so it can detect duplicate packets and get rid of the redundant forwarding. An attacker has two ways to harm the DPD mechanisms. Specifically, it can:

  • "deactivate" DPD, so duplicate packets aren't detected correctly. As a result, they get (redundantly) transmitted, which increases network load, drains the batteries of the routers involved, and so on 🔋
  • "pre-activate" DPD, so DPD flags a later arriving (valid) packet as a duplicate, and that packet then doesn't get forwarded 🙈

Attacks on DPD can be done by replaying existing packets, wrangling sequence numbers, manipulating hash values, and so on. 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: 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 mess with the RSS algorithm, and therefore with 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 💀

Beyond the attacks on DPD and RSS, a common MANET vulnerability is "jamming". That's when a device generates massive amounts of interfering radio transmissions, which stops legitimate traffic (both control and data traffic) on part of a network 📡 Jamming can make attacks on DPD and RSS even worse.

4. Threats to Duplicate Packet Detection 🦋

Duplicate packet detection (DPD) is required for packet dissemination in MANETs for two reasons: (1) packets may be retransmitted via the same physical interface they were received on, and (2) a router may receive multiple copies of the same packet (on the same or different interfaces) from different neighbors 🔁 So DPD is used to check whether an incoming packet has already been received before.

DPD works by keeping a record of recently processed multicast packets and comparing later-received multicast packets against it. A detected duplicate is silently dropped. It doesn't get inserted into that router's forwarding path, and it isn't delivered to an application 🤫 SMF's DPD supports both IPv4 and IPv6 and suggests two duplicate detection mechanisms for each:

  1. IP packet header content identification-based DPD (I-DPD), combined with flow state, to estimate the temporal uniqueness of a packet 🎀
  2. Hash-based DPD (H-DPD), which hashes selected IP packet header fields and the payload to get the same effect 🧚

The Security Considerations of [RFC6621] briefly introduce a selection of threats to DPD. This section expands on that and describes how to actually launch attacks on DPD, for example by manipulating jitter and/or the Hash-Assistant Value 🙈 In the rest of this section, common threats to packet detection mechanisms come first, and then the threats to I-DPD and H-DPD are introduced separately. The threats in this section apply to general SMF implementations, whether or not NHDP is used 💜

4.1. Attack on the Hop Limit Field 💅

Okay bestie, the first DoS move is messing with the TTL (for IPv4) or Hop Limit (for IPv6) field 🙈 Routers only forward a packet when its TTL is above 1, so an attacker can send a totally legit packet with the TTL slammed way down. After that, the neighbours can't forward that same multicast packet later, even when a healthy copy shows up with a different TTL. So the attacker basically tells its neighbours to block valid multicast packets. Rude 💀

Here's how it plays out in Figure 1. Router A sends a multicast packet with a TTL of 64 into the network. A, B, and C are legit SMF routers, and X is the attacker 😈 In wireless setups, jitter is commonly used to stop systematic collisions in Media Access Control (MAC) protocols [RFC5148]. X knows this, so it retransmits its invalid packets without jitter to make sure they land first. X forwards the packet with no jitter and drops the TTL to 1. C records the duplicate detection value (the hash value for H-DPD, or the header content of the packet for I-DPD) but doesn't forward it, because TTL == 1. Then the second copy, the non-sketchy one with TTL 63, arrives from B and gets discarded as a duplicate 💔

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

                                 Figure 1

Here's the tricky part 🧐 The TTL is meant to be changed by whoever forwards the packet, so classic integrity checks (like digital signatures) are usually calculated with the TTL fields set to some predetermined value (e.g., 0). IPsec Authentication Headers are a good example of that. Because of this, the attack is way harder to detect and counter.

It gets worse if the attacker has a "wormhole" through the network (a directional antenna, a tunnel to a collaborator, or a wired connection that bridges parts of a network that would otherwise be far apart) 🕳️ With that, the packets with the artificially reduced TTL can 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 figure out which packet is which. By default, the IP packet header (for both IPv4 and IPv6) doesn't give you that kind of identification. So you need extra identification headers, like the fragment header, a hop-by-hop header option, or IPsec sequencing, to make I-DPD work. A packet's uniqueness can then be identified by the source IP address of the originator plus the sequence number (from the fragment header, hop-by-hop header option, or IPsec). With that, each intermediate router can keep a record of recently received packets and check whether an incoming packet has already been received ✨

4.2.1. Pre-Activation Attacks (Pre-Play) 🧚

In a wireless environment, or across any other shared channel, an attacker can see the identification tuple (source IP address, sequence number) of a packet. It can then generate a packet with the same (source IP address, sequence number) pair but with invalid content. If the sequence number progression is predictable, it's super easy to generate and inject invalid packets with "future" identification information into the network. If these invalid packets arrive before the legit packets they're spoofing, the legit ones get treated as duplicates and thrown away. That can stop multicast packets from reaching parts of the network 😭

Figure 2 shows a pre-activation attack. A, B, and C are legit SMF routers, and X is the attacker. The lines between the routers show packet forwarding. Router A is the source and sends out a multicast packet with sequence number n. When router X receives it, X generates an invalid packet with A's source address and sequence number n. If that invalid packet reaches router C before the forwarding from router B, C drops the valid packet as a duplicate. X can manipulate jitter to make sure its invalid packets arrive first. And X can even generate packets with future sequence numbers (if they're predictable), so the future legit packets with those same sequence numbers get dropped as duplicates too 💀

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

                                 Figure 2

Here's the problem: SMF doesn't currently have any timestamp mechanisms to protect data packets, so there's no viable way to catch pre-play attacks with timestamps. Especially when the attack is based on manipulating jitter, checking the timestamp wouldn't help, because the timing still looks valid. It's just way less valuable 🙃

4.2.2. De-activation Attacks (Sequence Number Wrangling) 🌈

An attacker can also try to switch DPD off by changing the sequence number in packets it forwards. That way, routers can't spot an actual duplicate packet as a duplicate. Instead, they treat it as a brand new packet and process and forward it. This is a lot like a DoS attack, since every packet that looks unique gets multicasted. For a network with n routers, that means n-1 retransmissions. This can easily cause the "broadcast storm" problem discussed in [MOBICOM99]. The result is more channel load, and it looks like it's coming from some router other than the attacker 🌪️

Using the topology in Figure 2, when X receives a packet with seq=n, it can forward the packet with a modified sequence number of n+i. That has two effects. First, router C can't tell that the packet forwarded by X is a duplicate. Second, the packet with seq=n+i that router A generates later will probably be treated as a duplicate and dropped by router C. Chaotic but make it make sense 💅

4.3. Threats to Hash-Based Duplicate Packet Detection 💜

When explicit sequence numbers in packet headers aren't wanted, hash-based DPD can be used instead. A hash of the non-mutable fields in the header of the data payload can be generated and recorded at the intermediate routers. A packet can then be uniquely identified by its source IP address and its hash value 🔐

The hash algorithm SMF uses is only there to lower the probability of collisions. It's not used for cryptographic or authentication purposes. So a digest collision is still possible. If the source router or gateway notices it recently generated or injected a packet with the same hash value, it adds a "Hash-Assist Value (HAV)" IPv6 header option to the packet. That way, calculating the hash over the HAV makes the resulting value unique ✨

4.3.1. Attack on the Hash-Assistant Value 🫶

The HAV header is super helpful when a digest collision happens. But it also opens up a potential vulnerability 👀 The HAV option only gets added when the source or ingress SMF router detects that an incoming packet collides in digest with previously generated packets. So it can actually act as a "flag" for a potential digest collision. An attacker who finds the HAV header can conclude that a hash collision is possible if the HAV header is removed. Then the modified packet, received by other SMF routers, gets treated as a duplicate and dropped, because it has the same hash value as a previously received packet 😤

In Figure 3, routers A and B are legit SMF routers, and X is the attacker. Router A generates two packets, P1 and P2, with the same hash value, h(P1)=h(P2)=x. Following the SMF specification, a HAV is added to the later packet, P2, so that h(P2+HAV)=x' avoids the digest collision. When X spots the HAV on P2, it can conclude a collision is possible and strip the HAV header. Doing that means router B treats P2 as a duplicate and drops it 💔

              P2            P1                P2         P1
   .---.  h(P2+HAV)=x'    h(P1)=x    .---.  h(P2)=x     h(P1)=x    .---.
   | A |---------------------------> | X | ----------------------> | B |
   `---'                             `---'                         `---'

                                 Figure 3

5. Threats to Relay Set Selection 👑

SMF gives you a framework for an RSS mechanism rather than one specific RSS algorithm 🧩 Relay Set Selection is usually handled by distributed algorithms that can dynamically build a topological Connected Dominating Set, using 1-hop and 2-hop neighbourhood information. In this section, we first go over common threats to the RSS framework. Then we analyse specific threats to the three algorithms that [RFC6621] explicitly lists: Essential Connection Dominating Set (E-CDS), Source-Based Multipoint Relay (S-MPR), and Multipoint Relay Connected Dominating Set (MPR-CDS). Since relay set selection depends on 1-hop and 2-hop neighbourhood information, which relies on NHDP, the threats in this section are NHDP-specific 🎀

5.1. Common Threats to Relay Set Selection 🌸

Threats that aren't specific to any one RSS algorithm, including DoS attacks, eavesdropping, message timing attacks, and broadcast storms, are covered in [RFC7186] 📚

5.2. Threats to the E-CDS Algorithm 🦋

The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] builds a single CDS mesh for an SMF operating region. It needs 2-hop neighbourhood information (the identity of the neighbours, the link to each neighbour, and each neighbour's priority information), which gets collected through NHDP or another process 🧠

An SMF router selects itself as a relay if:

  • The SMF router has a higher priority than all of its symmetric neighbours, or
  • A path from the neighbour with the largest priority to any other neighbour, via neighbours with greater priority than the current router, does not exist.

An attacker can disrupt the E-CDS algorithm through link spoofing or identity spoofing 🥺

Okay so link spoofing is when an attacker advertises links that don't exist to another router 🫣 (and those routers may or may not even be in the network, lol).

The attacker can declare itself to have high route priority and then spoof links to as many legitimate SMF routers as possible, so it looks super connected 💅. Doing this can stop legitimate SMF routers from selecting themselves as relays. And once the attacker is the "super" relay in the network, it can manipulate the traffic it relays 😈✨.

5.2.2. Identity Spoofing 🎭

Identity spoofing is when an attacker finds out and uses the identity of other legitimate routers, even though it isn't authorized to do so 🙈. It can learn those identities by eavesdropping on control messages or on the source and destination addresses in datagrams. Then the attacker can send control or datagram traffic while pretending to be a legitimate router 👀.

Here's the messy part 💀. E-CDS self-selection is based on the router priority value, so an attacker can spoof another legitimate router's identity and declare a different router priority value for it. If it declares that the spoofed router has a higher priority, it can stop other routers from selecting themselves as relays. On the other hand, if the attacker declares that the spoofed router has a lower priority, it can force other routers to select themselves as relays, which degrades multicast forwarding back to classical flooding 📉.

5.3. Threats to S-MPR Algorithm 🌸

The S-MPR set selection algorithm lets individual routers pick relays from their neighboring routers, using 2-hop topology information 🧠. Each router selects MPRs so that a message it generates, relayed only by its MPRs, will reach all of its 2-hop neighbors 🎀.

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

  • the packet has not been received before, and
  • the neighbor from which the packet was received has selected the router as MPR.

MPR calculation depends on the willingness declared by SMF routers and on how well-connected the routers are. That means it can be messed up by both link spoofing and identity spoofing 😭. These threats and their impacts are illustrated in Section 5.1 of [RFC7186] 📚.

5.4. Threats to the MPR-CDS Algorithm 🧚

MPR-CDS is a derivative of S-MPR 💜. The main difference is that while S-MPR forms a different broadcast tree for each source in the network, MPR-CDS forms one unique broadcast tree for all sources in the network 🌈.

Because MPR-CDS combines E-CDS and S-MPR, and the simple combination of the two algorithms doesn't address their weaknesses, the vulnerabilities of E-CDS and S-MPR discussed in Sections 5.2 and 5.3 also apply to MPR-CDS 🙃.

6. Security Considerations 🔥

This document does not specify a protocol or a procedure. The whole document, however, reflects on security considerations for SMF regarding packet dissemination in MANETs 🛡️. The two main functional components of SMF, duplicate packet detection and relay set selection, are analyzed and the possible attacks on them are documented 🕵️‍♀️.

Neither [RFC6621] nor this document proposes mechanisms to secure the SMF protocol. But there are several possibilities to secure the protocol in the future, and the threats discussed in the previous sections suggest which ones could be addressed, which can drive new work 🚀✨.

For the I-DPD mechanism, employing randomized packet sequence numbers can avoid some pre-activation attacks based on sequence number prediction. If predictable sequence numbers have to be used, applying timestamps can mitigate pre-activation attacks ⏰.

For the H-DPD mechanism, applying cryptographically strong hashes can make 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 uses NHDP as its neighborhood discovery protocol, implementing [RFC7183] is still advisable, so that integrity protection is enabled for NHDP control messages. This can help mitigate threats related to identity spoofing through the exchange of HELLO messages, and it provides 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 who are also able to generate valid ICVs 😬. Detecting and excluding 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 isn't helped by the use of ICVs. However, if routers have enough capabilities to support asymmetric keys (as per [RFC7859]), part of addressing this challenge becomes providing key revocation in a way that doesn't 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 and de-activation attacks, and attacks on the HAV of multicast datagrams, are to be mitigated, a datagram-level integrity protection mechanism is desired, taking into consideration the identity field or HAV. However, this would not help with attacks on the TTL (or Hop Limit for IPv6) field, because the mutable fields are generally not considered when the ICV is calculated 🚨.

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgments 💖

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

Authors' Addresses 💌

Jiazi Yi Ecole Polytechnique 91128 Palaiseau Cedex France

Phone: +33 1 77 57 80 85 Email: jiazi@jiaziyi.com URI: http://www.jiaziyi.com/

Thomas Heide Clausen Ecole Polytechnique 91128 Palaiseau Cedex France

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

Ulrich Herberg

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

📦 where this page comes from