RFC 4609

Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements

📅 published October 2006, from ietf

Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements 💖

Okay bestie, let's get into it 🧚. This is RFC 4609, and it's an Informational doc from the Network Working Group, published in August 2006. The authors are P. Savola (CSC/FUNET), R. Lehtonen (TeliaSonera), and D. Meyer 🎀. It doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅.

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2006).

Abstract 💜

Okay so this memo is all about security threats for the bigger multicast routing infrastructures, whether they're intra-domain or inter-domain 🌈. It only looks at Protocol Independent Multicast - Sparse Mode (PIM-SM), in its three main operational modes: the classic Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model with the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism 🔥. It also describes enhancements to the protocol operations that help mitigate the threats it identifies. Iconic behaviour, honestly 👑.

Table of Contents 🍓

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Threats to Multicast Routing ....................................4
   3.1. Receiver-Based Attacks .....................................5
        3.1.1. Joins to Different Groups (Join Flooding) ...........5
   3.2. Source-Based Attacks .......................................7
        3.2.1. Sending Multicast to Empty Groups (Data Flooding) ...7
        3.2.2. Disturbing Existing Group by Sending to It
               (Group Integrity Violation)..........................8
   3.3. Aggravating Factors to the Threats .........................9
        3.3.1. Distant RP/Source Problem ...........................9
        3.3.2. No Receiver Information in PIM Joins ...............10
4. Threat Analysis ................................................10
   4.1. Summary of the Threats ....................................10
   4.2. Enhancements for Threat Mitigation ........................10
5. PIM Security Enhancements ......................................11
   5.1. Remote Routability Signalling .............................11
   5.2. Rate-Limiting Possibilities ...............................12
   5.3. Specific Rate-limiting Suggestions ........................14
        5.3.1. Group Management Protocol Rate-Limiter .............14
        5.3.2. Source Transmission Rate-Limiter ...................14
        5.3.3. PIM Signalling Rate-Limiter ........................15
        5.3.4. Unicast-Decapsulation Rate-Limiter .................15
        5.3.5. PIM Register Rate-Limiter ..........................15
        5.3.6. MSDP Source-Active Rate-Limiter ....................16
   5.4. Passive Mode for PIM ......................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................17
8. References .....................................................17
   8.1. Normative References ......................................17
   8.2. Informative References ....................................17
Appendix A.  RPF Considers Interface, Not Neighbor ................19
Appendix B.  Return Routability Extensions ........................20
  B.1.  Sending PIM-Prune Messages Down the Tree ..................20
  B.2.  Analysing Multicast Group Traffic at DR ...................21
  B.3.  Comparison of the Above Approaches ........................21

1. Introduction ✨

This doc describes security threats to PIM-SM multicast routing infrastructures and suggests ways to make these architectures more resistant to those threats 🛡️.

We're only looking at attacks that affect the multicast routing infrastructures, whether intra- or inter-domain 🎯.

"On-link" attacks are a different story. These are where hosts specifically target the Designated Router (DR) or other routers on the link, or where hosts disrupt other hosts on the same link, possibly using group management protocols. Those are discussed elsewhere (e.g., [10] and [12]), and this doc won't go into them further 🙈.

Similar to unicast, multicast payloads may need end-to-end security. Security mechanisms that provide confidentiality, authentication, and integrity are described in other documents (e.g., [9]). The attacks those mechanisms protect against aren't discussed further here, bestie 🫶.

PIM builds on a model where Reverse Path Forwarding (RPF) checking is, among other things, used to keep the multicast distribution trees loop-free 🌀. As a side effect, this limits the impact of an attacker using a forged source address, which is often a component in unicast-based attacks. But ngl, a host can still spoof an address within the same subnet, or spoof the source of a unicast-encapsulated PIM Register message, which a host may send on its own 😭.

We're considering PIM-SM [1] in the traditional Any Source Multicast (ASM) model, including the use of Multicast Source Discovery Protocol (MSDP) [2] for source discovery. We're also looking at Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] group-to-RP mapping mechanism in the ASM model 💖. Bidirectional-PIM [15] is typically deployed only in intra-domain setups. It's similar to ASM but without register messages. Bidirectional-PIM isn't finished as of this writing, so its considerations aren't discussed further in this document 🥲.

2. Terminology 🎀

ASM

"ASM" [6] is used to refer to the traditional Any Source Multicast model with multiple PIM domains and a signalling mechanism (MSDP) to exchange information about active sources between them 🌸.

SSM

"SSM" [7] is used to refer to Source-Specific Multicast 🦋.

SSM channel

An SSM channel (S, G) identifies the multicast delivery tree associated with a source address S and an SSM destination address G 🌈.

Embedded-RP

"Embedded-RP" refers to the ASM model where the Embedded-RP mapping mechanism is used to find the Rendezvous Point (RP) for a group, and MSDP is not used 🧚.

Target Router

"Target Router" is used to refer to either the RP processing a packet (ASM or Embedded-RP), or the DR that is receiving (Source, Group) (or (S,G)) joins (in all models). Main character energy 👑.

3. Threats to Multicast Routing 💅

Okay so we make the broad assumption that multicast routing networks are reasonably trusted 🫶. That means we assume the multicast routers themselves are well-behaved, in the same sense that unicast routers are expected to behave well. Is that assumption entirely correct? Not really, but it makes threat modelling way simpler ✨. Threats caused by misbehaving multicast routers (including fake multicast routers) aren't considered in this memo. The generic threat model would be similar to [5] 🔥. RP discovery mechanisms like Bootstrap Router (BSR) and Auto-RP are also out of scope 🙈.

As the threats in this memo are mainly Denial-of-Service (DoS) attacks, it's useful to note that attackers will try to find a scarce resource anywhere in the control or data plane, as described in [5] 💀.

There are multiple threats relating to host-to-router signalling protocols, like Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD). But those are outside the scope of this memo 🌈.

PIM-SM can be abused where RPF checks aren't applicable (in particular, on stub LAN networks), because spoofing on-link traffic is very simple 😭. For example, a host could get elected to become the DR for the subnet, but not perform any of its functions. A host can also easily make PIM routers on the link stop forwarding multicast by sending PIM Assert messages. This means a willful attacker can get around many of the potential rate-limiting functions performed at the DR, since they can always send those messages themselves 💀. The PIM-SM specification does say these messages should only be accepted from known PIM neighbors. If that's done, the hosts would first have to establish a PIM adjacency with the router. But adjacencies are typically formed with anyone on the link, so a willful attacker would have a high probability of success in forming a protocol adjacency 🍓. These are described at some length in [1], but they're also considered out of scope for this memo 🦋.

3.1. Receiver-Based Attacks 🎀

These attacks are often called control plane attacks, and the attacker's aim is usually to push the amount of multicast state information in routers above a manageable level 🌪️.

3.1.1. Joins to Different Groups (Join Flooding) 🌸

okay so join flooding is when a host tries to join a group or an SSM channel once or a couple of times, and the DR ends up generating a PIM Join to the Target Router 🫶 the group/SSM channel or the Target Router might exist or might not, and it's giving chaos either way 💀

like, picture a host joining a bunch of different, non-existent groups super fast 🏃‍♀️ trying to overload the routers on the path with way too much (*/S,G) state (aka "PIM State"), or the Target Router with way too many packets. not the vibe 😤

ngl the DR only sends one PIM Join even if the host joins the same group multiple times 💅 it doesn't wait for any acknowledgement. the next message only goes out after the PIM Join timer expires or the state changes at the DR. so it's very efficient, lowkey 🧚

this kind of joining does create PIM state, but it's relatively short-lived ⏳ 260 seconds by default, which is how long the state stays active at the DR when there are no IGMP/MLD Reports or Leaves. but here's the thing: the host can join a bunch of different ASM groups or SSM channels with just one IGMPv3 [11] or MLDv2 [12] Report, because the protocol lets multiple sources be included in the same message. so one IGMPv3/MLDv2 message can turn into multiple PIM Joins 😭

even short-lived state can be harmful when the goal is to cause as much state as possible 🙈 and the host can keep sending IGMP/MLD Reports to these groups to make the state attack last longer. so what happens?

  • ASM: An (*,G) join is sent to an intra-domain RP, which creates state on that path. then that RP joins to the DR of the source, if the source is active. if the host specified the source address in the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly to the DR of the source, same as with SSM below.
  • SSM: An (S,G) join is sent inter-domain to the DR of the source S, creating state on that path. if the source S doesn't exist, the join goes to the closest router using longest prefix matching on the path to S as possible.
  • Embedded-RP: An (*,G) join is sent towards an inter/intra-domain RP that's embedded in the group G, creating state on that path. if the RP doesn't exist, the join goes to the router that's closest to the RP address. similarly, an explicit (S,G) join goes to the DR, same as with SSM above.

so basically SSM and Embedded-RP always enable "inter-domain" state creation 🌍 ASM defaults to intra-domain, but it can be used for inter-domain state creation too, so keep your eyes open 👀

if the source (or the RP, but only in the Embedded-RP case) doesn't exist, the multicast routing protocol has no way to remove the distribution tree while the joining host stays active 😩 the worst-case attack is a host that stays active on lots of different groups containing imaginary sources or RPs. and fyi the imaginary RP problem is only related to Embedded-RP, since that's where the RP address gets pulled out of the group address, G 💖

for example, if the host can generate 100 IGMPv3 (S,G) joins a second, each carrying 10 sources, the state after 260 seconds would be 260 000 state entries 💀 and 100 packets per second is still a rather easily achievable number. not okay 🫠

3.2. Source-Based Attacks 🔥

these are often called "data plane" attacks 💅 however, with traditional ASM and MSDP, they also include an MSDP control plane threat. two threats for the price of one, bestie 😭

3.2.1. Sending Multicast to Empty Groups (Data Flooding) 🍓

data flooding happens when a host sends data packets to a multicast group or SSM channel that has no real subscribers 📦

ngl this one is spicy 🌶️ register encapsulation isn't subject to RPF checks, so hosts can craft and send these packets themselves, and they can even spoof the source address of the register messages unless ingress filtering [13] has been deployed [14]. so because the initial data registering skips the same RPF checks as lots of other multicast routing procedures, making control decisions based on that data leads to a ton of potential threats 🙃

examples of this threat include a virus/worm trying to propagate to multicast addresses, an attacker trying to crash routers with excessive MSDP state, or an attacker wanting to overload the RP with encapsulated packets for different groups. here's how it plays out:

  • ASM: The DR register-encapsulates the packets in Register messages to the intra-domain RP. the RP may join to the source and issue a Register-Stop, but it keeps getting the data anyway. a notification about the active source gets sent inter-domain with MSDP and propagated globally (unless the group or source is configured to be local) 📣
  • SSM: The DR receives the data, but the data doesn't propagate from the DR unless someone joins the (S,G) channel ✨
  • Embedded-RP: The DR register-encapsulates the packets to the intra/inter-domain RP. the RP may join to the source and issue a Register-Stop. data keeps getting encapsulated if different groups are used 🌈

this opens up a bunch of attacks, especially if at least parts of the multicast forwarding functions run on a "slow" path or CPU in the routers 😬

  • the MSDP control plane traffic generated can cause a significant amount of control and data traffic, which may overload the routers receiving it. a thorough analysis of MSDP vulnerabilities can be found in [16], and it only relates to ASM. however, this is the most serious threat right now, because MSDP floods the multicast group information to all multicast domains in the Internet, including the multicast packet encapsulated in the MSDP source-active message. that creates a lot of data and state to be shared by every multicast-enabled router, and if the source stays active, the flooding repeats every 60 seconds by default ⚠️
  • as a large amount of data is forwarded on the multicast tree, if multicast forwarding is performed on CPU, it may be a serious performance bottleneck and a way to perform DoS on the path. similarly, the DR must always be capable of processing (and discarding, if necessary) the multicast packets it receives from the source. these are potentially present in every model 🫠
  • if the encapsulation is performed in software, it may be a performance bottleneck and a way to perform DoS on the DR. similarly, if the decapsulation is performed in software, it may be a performance bottleneck and a way to perform DoS on the RP. note: the decapsulator may know (based on access configuration, a rate limit, or something else) that it doesn't need to decapsulate the packet, which avoids bottlenecks 🙌 these threats relate to ASM and Embedded-RP.

3.2.2. Disturbing Existing Group by Sending to It (Group Integrity Violation) 💜

group integrity violation happens when a host sends packets to a group or SSM channel that already exists, to disturb the users of that existing group/SSM channel 😤

the SSM service model prevents injection of packets into (S,G) channels, so this problem is avoided 🙌 however, if the source address can be spoofed to a topologically-correct address, it's possible to get the packet into the distribution tree. typically only hosts that are on-link with the source can do this, so it's not really relevant in the scope of this memo 🤷‍♀️

with ASM and Embedded-RP, sources can inject forged traffic through RPs, since the RPs provide the source discovery for the group. the RPs send the traffic over the shared tree toward receivers (routers with (*,G) state). the DR then forwards the forged traffic to receivers, unless the legitimate recipients are able to filter out unwanted sources, e.g., using the Multicast Source Filters (MSF) API [8]. typically this isn't used or supported by the applications using these protocols 🥲

note that with ASM and Embedded-RP, the RP may exert some form of control over who can send to a group, because the first packets are register-encapsulated in register packets to the RP. if the RP drops the packet based on an access list, a rate limit, or something else, it doesn't get injected into an existing group. however, if the DR has existing (*,G) state, the data will also be forwarded on those interfaces 👀

with ASM, this "source control" is distributed across all the PIM domains, which significantly decreases how useful it is. Embedded-RP makes control easier, because source discovery is done through a single RP per group ✨

so as a result, in addition to possible local disturbance, the RP decapsulates the register packets and forwards them to the receivers in the multicast distribution tree, which causes an integrity violation 💔

3.3. Aggravating Factors to the Threats 🎀

this section describes a few factors that make the threats in Sections 3.1 and 3.2 even worse 😩 they could also be viewed as individual threats on their own.

3.3.1. Distant RP/Source Problem 🔭

in the shared tree model, if the RP or a source is distant (topologically), then joins travel all the way to the distant RP or source and keep the state along that path active, even when the data is being delivered locally 🙃

this problem gets worse if the RP/source space is global. if a router is registering to an RP/source that isn't in the local domain (say, it's fielded by the site's direct provider), then the routing domain is flat 🥴

also, PIM assumes the addresses used in PIM messages are valid. however, there's no way to make sure of that, and using non-existent S or G in (*,G) or (S,G) messages will cause the signalling to be set up, even though nobody can reach that address 💀

this will be analyzed at more length in Section 5.1 🧐

3.3.2. No Receiver Information in PIM Joins 🕵️‍♀️

only DRs, which are directly connected to receivers, know the exact receiver information (e.g., IP address). PIM doesn't forward that information further into the multicast distribution tree. so individual routers (e.g., domain edge routers) can't make policy decisions about who gets connected to the distribution tree 🙅‍♀️

4. Threat Analysis 🧠

4.1. Summary of the Threats 📊

okay so trying to summarize how bad the major classes of threats are for each multicast usage model, we get a matrix of resistance to different kinds of threats. bestie, look at this 😭

                 +----------------+------------------+-----------------+
                 | Forged Join    |   Being a Source | Group Integrity |
   +-------------+----------------+------------------+-----------------+
   | ASM         |    bad 1)      |      very bad    |   bad/mediocre  |
   +-------------+----------------+------------------+-----------------+
   | SSM         |    bad         |     very good    |    very good    |
   +-------------+----------------+------------------+-----------------+
   | Embedded-RP |    bad 1),2)   | good/mediocre 3) |      good       |
   +-------------+----------------+------------------+-----------------+

Notes:

  1. In ASM, the host can also join (S,G) groups directly with IGMPv3/MLDv2, so it has the same characteristics as SSM (and also allows inter-domain state to be created).
  2. allows inter-domain shared state to be created.
  3. Embedded-RP allows a host to determine the RP for a given group (or set of groups), which in turn allows that host to mount a PIM register attack. in this case, the host can mount the attack without implementing any of the PIM register machinery 🫣

4.2. Enhancements for Threat Mitigation 🛡️✨

Okay bestie, so there are a bunch of desirable actions ("requirements") that could be considered to mitigate these threats 💅 A few more concrete suggestions show up later in the section 🫶

  • Inter-domain MSDP (ASM) should be retired to avoid attacks 💀; or, if this is not reasonable, the DRs should rate-limit the register encapsulation (note that the hosts can circumvent this). More importantly, the RPs should rate-limit the register decapsulation especially from different sources, or MSDP must rate-limit the MSDP data generation for new sources 🔥
  • DRs should rate-limit PIM Joins and Prunes somehow; there are multiple ways this should be considered (i.e., depending on which variables are taken into consideration) 🎀
  • DRs could rate-limit register encapsulation somehow; there are multiple ways to perform this. Note that the hosts can avoid this by performing the register encapsulation themselves if so inclined 🙈
  • RPs could rate-limit register decapsulation somehow; there are multiple ways to perform this. Note that if the source of the unicast packets is spoofed by the host, this may have an effect on how (for example) rate-limiters behave 🦋
  • RPs should rate-limit the MSDP SA messages coming from MSDP peers 💜
  • RPs could limit or even disable the SA cache size. However, this could have negative effects on normal operation 🍓
  • RPs should provide good interfaces to reject packets that are not interesting; for example, if an Embedded-RP group is not configured to be allowed in the RP, the register encapsulated packets would not even be decapsulated 🧚
  • DRs could rate-limit the multicast traffic somehow to reduce the disturbing possibilities; there are multiple possibilities how exactly this should be considered ⭐
  • DRs should rate-limit the number of groups/SSM channels that can be created by a given source, S 👑

5. PIM Security Enhancements 🔐

Okay so this section goes deeper into the rate-limiting functions I just mentioned, plus the remote routability signalling issue 🧠

5.1. Remote Routability Signalling 📡

As described in Section 3.3.1, non-existent DRs or RPs may cause some problems when setting up multicast state 😭 There seem to be a couple of different approaches to mitigate this, especially if rate-limiting is not extensively deployed.

With ASM and Embedded-RP, Register message delivery could be ensured somehow. For example:

  1. At the very least, receiving an ICMP unreachable message (of any flavor) should cause the DR to stop the Register packets, as the RP will not be receiving them anyway. (However, one should note that easy spoofing of such ICMP messages could cause a DoS on legitimate traffic. 🚨)
  2. An additional method could be implementing a timer on the DRs so that unless nothing is heard back from the RP within a defined time period, the flow of Register messages would stop. (Currently, the RPs are not required to answer back, unless they want to join to the source. 🙃)
  3. An extreme case would be performing some form of return routability check prior to starting the register messages: first, a packet would be sent to the RP, testing its existence and willingness to serve, and also proving to the RP that the sender of the "bubble" and the sender of the registers are the same and the source address is not forged. (That is, the RP would insert a cookie in the bubble, and it would have to be present in the register message. 🍪)

It would be desirable to have some kind of state management for PIM Joins (and other messages) as well 💖 For example, a "Join Ack" could be used to ensure that the path to the source/RP actually exists. However, this is very difficult, if not impossible, with the current architecture 😩 PIM messages are sent hop-by-hop, and there is not enough information to trace back the replies, for example, to notify the routers in the middle to release the corresponding state or to notify the DR that the path did not exist.

Appendix B discusses this receiver-based remote routability signalling in more detail 📚

5.2. Rate-Limiting Possibilities 🚦

There seem to be many ways to implement rate-limiting (for signalling, data encapsulation, and multicast traffic) at the DRs or RPs ✨ The best approach likely depends on the threat model; for example, factors in the evaluation may include:

  • Whether the host is willfully malicious, uncontrolled (e.g., virus/worm), or a regular user just doing something wrong 🤔
  • Whether the threat is aimed towards a single group, a single RP handling the group, or the (multicast) routing infrastructure in general 🎯
  • Whether the host on a subnet is spoofing its address (but still as one that fulfills the RPF checks of the DR) 🫣
  • Whether the host may generate the PIM join (and similar) messages itself to avoid rate-limiters at the DR, if possible 🕵️
  • Whether unicast RPF checks are applied on the link (i.e., whether the host can send register-encapsulated register-messages on its own) 🔍
  • Whether blocking the misbehaving host on a subnet is allowed to also block other, legitimate hosts on the same subnet 🥺
  • Whether these mechanisms would cause false positives on links with only properly working hosts if many of them are receivers or senders 😬

As should be obvious, there are many different scenarios here that seem to call for different kinds of solutions 💅

For example, the rate-limiting could be performed based on:

  1. multicast address, or the RP where the multicast address maps to
  2. source address
  3. the (source address, multicast address) pair (or the RP that maps to the multicast address)
  4. data rate, in case of rate-limiting the source
  5. everything (multicast groups and sources would not be distinguished at all)

In the above, we assume that rate-limiting would be performed per-interface (on DRs) if a more fine-grained filter is not being used.

It should be noted that some of the rate-limiting functions can be used as a tool for DoS against legitimate multicast users 😭 Therefore, several parameters for rate-limiting should be used to prevent such operation.

5.3. Specific Rate-limiting Suggestions 🎀

These suggestions take two forms: limiters designed to be run on all the edge networks, preventing or limiting an attack in the first place, and the limiters designed to be run at the border of PIM domains or at the RPs, which should provide protection in case edge-based limiting fails or was not implemented, or when additional control is required 🏰

Almost none of the suggested rate-limiters take legitimate users into account 💀 That is, being able to allow some hosts on a link to transmit/receive, while disallowing others, is very challenging to do right, because the attackers can easily circumvent such systems. Therefore, the intent is to limit the damage to only one link, one DR, or one RP -- and avoid the more global effects on the Internet multicast architecture 🌍

Also, it is possible to perform white-listing of groups, sources, or (S,G) pairs from the rate-limiters so that packets related to these are not counted towards the limits. This is useful for handling an aggressive but legitimate source without modifying the limiting parameters for all the traffic, for example 🫶

5.3.1. Group Management Protocol Rate-Limiter 🚪

A Group Management Protocol rate-limiter is a token-bucket-based rate-limiter to all Group Management Protocols (IGMP, MLD) that would limit the average rate of accepted groups or sources on the specific interface, with a bucket of depth of G_DEPTH, refilling at G_RATE tokens per second. Example values could be G_RATE=1 and G_DEPTH=20. Note that, e.g., an IGMPv3 join with two included sources for one group would count as two groups/sources 🧮

This would be the first-order defense against state-creation attacks from the hosts. However, as it cannot be guaranteed that all the routers would implement something like this, other kinds of protections would be useful as well. This harms legitimate receivers on the same link as an attacker 😤

5.3.2. Source Transmission Rate-Limiter 📤

A source transmission rate-limiter is a token-bucket-based rate-limiter that would limit the multicast data transmission (excluding link-local groups) on a specific interface with a bucket of depth of GSEND_DEPTH, refilling at GSEND_RATE tokens per second. Example values could be GSEND_RATE=10 and GSEND_DEPTH=20.

This would be the first-order defense against data flooding attacks. However, as it cannot be guaranteed that all routers would implement something like this, and as the RP (if SSM is not used) could be loaded from multiple senders, additional protections are needed as well. This harms legitimate senders on the same link as an attacker. This does not prevent a host from sending a lot of traffic to the same group -- an action that would harm only the DR and the RP of the group, is similar to unicast DoS attacks against one source, and is not considered critical to the overall security 🌸

5.3.3. PIM Signalling Rate-Limiter 📶

A PIM signalling rate-limiter is a token-bucket-based rate-limiter that would limit all multicast PIM messaging, either through a specific interface or globally on the router, with a bucket of depth of PIM_DEPTH, refilling at PIM_RATE tokens per second. Example values could be PIM_RATE=1000 and PIM_DEPTH=10000.

This would be second-order defense against PIM state attacks when IGMP/MLD rate-limiters haven't been implemented or haven't been effective. This limiter might not need to be active by default, as long as the values are configurable. The main applicability for this filter would be at a border of PIM domain in case PIM state attacks are detected. This harms legitimate receivers as well 😩

5.3.4. Unicast-Decapsulation Rate-Limiter 🧯

A unicast-decapsulation rate-limiter is a simple decapsulation rate-limiter that would protect the CPU usage in the router by limiting the packets per second (depending on the router architecture) and disregarding the source of the registers. This could also be an additional check to be used before decapsulation and checking the group to throttle the worst of the decapsulation CPU consumption. This limit should have to be quite high, and would hamper the existing legitimate sessions as well 🥲

5.3.5. PIM Register Rate-Limiter 🌷

A PIM Register rate-limiter is a token-bucket-based rate-limiter that would limit register decapsulation of PIM Register messages with a bucket of depth of REG_DEPTH, refilling at REG_RATE tokens per second. If the router has restarted recently, a larger initial bucket should be used. Example values could be REG_RATE=1 and REG_DEPTH=10 (or REG_DEPTH=500 after restart) 🔄

This would be second-order defense against data flooding: if the DRs would not implement appropriate limiters, or if the total number of flooded groups rises too high, the RP should be able to limit the rate with which new groups are created. This does not harm legitimate senders, as long as their groups have already been created 🫶✨

5.3.6. MSDP Source-Active Rate-Limiter ✨

okay so an MSDP source-active rate-limiter is a token-bucket-based, source-based rate-limiter 🪣 that limits new groups per source. The bucket has a depth of SAG_DEPTH and refills at SAG_RATE tokens per second. Example values could be SAG_RATE=1 and SAG_DEPTH=10 💅.

This would be a second-order defense at both the MSDP SA sending and receiving sites, against data flooding and MSDP vulnerabilities in particular 🛡️. The specific threat it's built for is a source (or multiple different sources) trying to "probe" (e.g., virus or worm 🦠) different multicast addresses. [16] discusses different MSDP attack prevention mechanisms at length 📚.

5.4. Passive Mode for PIM 🌸

As described in the last paragraph of Section 3, hosts can also form PIM adjacencies and send disrupting traffic, unless great care is taken at the routers 😬. This happens because most implementations require that stub LANs with only one PIM router also have PIM enabled (to enable PIM processing of the sourced data, etc.). But these stub networks don't actually need to run the PIM protocol on the link 🙅‍♀️. So such implementations should provide an option to mark the interface as "passive" with regard to PIM: no PIM packets are sent or processed (if received), but hosts can still send and receive multicast on that interface 🦋.

6. Security Considerations 🔐

This memo analyzes the security of PIM routing infrastructures in some detail and proposes enhancements to mitigate the observed threats 🕵️‍♀️.

This document does not discuss adding (strong) authentication to the multicast protocols 🙈. The PIM-SM specification [1] describes the application of IPsec for routing authentication. Note that being able to authenticate the register messages and to prevent illegitimate users from establishing PIM adjacencies seem to be the two most important goals 🎯. The IGMPv3 specification [11] describes the use of IPsec for group management (IPsec for MLDv2 may be applied similarly), which is out of scope for this memo. However, note that being able to control the group memberships might reduce the receiver-based attacks 🚫.

However, one should keep in mind two caveats ⚠️. First, authentication alone might not be sufficient, especially if the user or the host stack (consider a worm propagation scenario) cannot be expected to "behave well" 🪱. Second, adding such authentication likely provides new attack vectors, e.g., in the form of a CPU DoS attack with an excessive amount of cryptographic operations 🔥.

7. Acknowledgements 🫶

Kamil Sarac discussed "return routability" issues at length 💜. Stig Venaas and Bharat Joshi provided feedback to improve the document quality 🌷. Bill Fenner and Russ Housley provided useful comments during the IESG evaluation 🎀.

8. References 📚

8.1. Normative References

[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.

[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.

[5] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, July 2006.

8.2. Informative References

[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.

[7] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.

[8] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.

[9] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.

[10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", Work in Progress, July 2004.

[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.

[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.

[15] Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Work in Progress, October 2005.

[16] Rajvaidya, P., Ramachandran, K., and K. Almeroth, "Detection and Deflection of DoS Attacks Against the Multicast Source Discovery Protocol", UCSB Technical Report, May 2003.

Appendix A. RPF Considers Interface, Not Neighbor 🔍

In most current implementations, the RPF check considers only the incoming interface, and not the upstream neighbor (RPF neighbor) 🧐.

This can result in accepting packets from the "wrong" RPF neighbor (the neighbor is "wrong" since, while the RPF check succeeds and the packet is forwarded, the unicast policy would not have forwarded the packet) 🙃.

This is a problem on media where more than two routers can connect to each other, in particular Ethernet-based Internet Exchanges 🌐. Therefore, any neighbor on such a link could inject any PIM signalling, as long as a route matching the address used in the signalling is going through the interface 📨.

Note that for PIM signalling to be accepted, a PIM adjacency must have been established. However, typically, this does not help much against willful attackers, as PIM adjacencies are usually formed with anyone on the link 🤷‍♀️. Still, the requirement is that the neighbor has enabled PIM on the concerned interface. That is, in most cases, the threat is limited to attackers within the operators in the exchange, not third parties 🏢. On the other hand, data plane forwarding has no such checks, and having such checks would require that one look at the link-layer addresses used. That is, this checking is not as feasible as one might hope 😅.

Appendix B. Return Routability Extensions 🔁

The multicast state information is built from the receiver side, and it can currently be pruned only by the receiver-side DR 🌳. If the RP or the source for the group is non-existent, the state can't be pruned by the DR without return routability extensions to provide such information. There might also be a need to remove the state in some cases when there is no multicast traffic sent to that group. This section discusses alternative ways to remove the unused state information in the routers, so that it can't be used in state-based DoS attacks 🧹. Note that rate-limiting PIM Joins gives some protection against state attacks 💪.

B.1. Sending PIM-Prune Messages Down the Tree 🌲

When a router discovers the non-existence of the RP or the source, it can create a PIM-Prune message and send it back to the join originator. However, since it does not know the unicast IP address of the join originator DR, it cannot directly unicast it to that router 🤔.

A possible alternative is to use a link-local multicast group address (e.g., the all-pim routers local multicast address) to pass this information back toward the joining DR 📡. Since the routers from this current router all the way back to the joining DR have forwarding state entries for the group, they can use this state information to see how to forward the PIM-Prune message back 🗺️.

Each on-tree router, in addition to forwarding the PIM-Prune message, can also prune the state from its state tables. This way, the PIM-Prune message will go back to the DR by following the multicast forwarding state information created so far 🦶. In addition, if we use some sort of RPF checks during this process, we can also make it more difficult to inject such PIM-Prune messages maliciously 🚧.

A potential abuse scenario may involve an attacker that has access to a router on the direct path and can send such PIM-Prune messages down the tree branch so as to prune the branch from the tree 🥀. But such an attacker can currently achieve the same effect by sending a PIM-Prune message toward the source from the same point on the tree. So, the proposed mechanism does not really aggravate the situation 🙆‍♀️.

One visible overhead in this new scenario might be that someone can send bogus join messages to create redundant PIM-Join and PIM-Prune messages in the network 📦.

B.2. Analyzing Multicast Group Traffic at DR 📊

Another possible way to remove the unused state information would be to analyze individual group traffic at the DR. If there is no multicast traffic for a certain group within a certain time limit, the state should be removed ⏰. Here, if the receiver is malicious and wants to create states in the network, it can send joins to different groups and create states on routers for each of these different groups until the DR decides that the groups are inactive and initiates the prune process 😤. In addition, during the prune process, the routers will again process all these prune messages, and therefore will be spending time 🐢.

B.3. Comparison of the Above Approaches ⚖️

Both of these solutions have the same problem of renewing the multicast state information. The DR shouldn't permanently block the state building for that group, but should restrict the PIM Joins if it notices that the receiver is abusing the system. One additional option is to block the PIM Joins to the non-existent source/RP for a certain time 🚫.

In the first approach (sending PIM-Prunes down the tree), part of the goal was to prune the states in the routers much sooner than in the second approach. (That is, the goal is to make sure that the routers will not be keeping unnecessary states for a long time 🕰️.)

The second approach also works for DoS attacks related to the existing source/RP addresses. It could be more quickly implemented and deployed in the network, and it does not have any relationship with the other deployments (no need to change all PIM routers) 🚀.

Authors' Addresses 💌

Pekka Savola CSC/FUNET Espoo Finland

EMail: psavola@funet.fi

Rami Lehtonen TeliaSonera Hataanpaan valtatie 20 Tampere 33100 Finland

EMail: rami.lehtonen@teliasonera.com

David Meyer

EMail: dmm@1-4-5.net

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ⚖️

okay so the IETF is taking zero position on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this document are valid, or how far they reach 🙃 It also isn't saying whether you could even get a license, and it hasn't done any independent digging to find those rights either. So no promises, bestie 💅 If you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat, any assurances that licenses will be made available, and the results of anyone trying to get a general license or permission to use those proprietary rights for implementers or users of this spec can all be found in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️✨

The IETF also invites any interested party to tell them about any copyrights, patents or patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to ietf-ipr@ietf.org 📬💌 the IETF really wants to know, so don't be shy! 🎀

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 💖 the quiet heroes keeping the lights on for everyone 🌸

📦 where this page comes from