Request for Comments: 4609 CSC/FUNET
Category: Informational R. Lehtonen
TeliaSonera
D. Meyer
August 2006
Protocol Independent Multicast - Sparse Mode (PIM-SM)
Multicast Routing Security Issues and Enhancements
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 Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes security threats for the larger (intra-domain or
inter-domain) multicast routing infrastructures. Only Protocol
Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its
three main operational modes: the traditional Any-Source Multicast
(ASM) model, the source-specific multicast (SSM) model, and the ASM
model enhanced by the Embedded Rendezvous Point (Embedded-RP)
group-to-RP mapping mechanism. This memo also describes enhancements
to the protocol operations that mitigate the identified threats.
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 document describes security threats to the Protocol Independent
Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures
and suggests ways to make these architectures more resistant to the
described threats.
Only attacks that have an effect on the multicast routing
infrastructures (whether intra- or inter-domain) are considered.
"On-link" attacks where the 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, are discussed elsewhere (e.g., [10] and [12]). These
attacks are not discussed further in this document.
Similar to unicast, the multicast payloads may need end-to-end
security. Security mechanisms to provide confidentiality,
authentication, and integrity are described in other documents (e.g.,
[9]). Attacks that these security mechanisms protect against are not
discussed further in this document.
PIM builds on a model where Reverse Path Forwarding (RPF) checking
is, among other things, used to ensure loop-free properties of the
multicast distribution trees. As a side effect, this limits the
impact of an attacker using a forged source address, which is often
used as a component in unicast-based attacks. However, 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 consider PIM-SM [1] operating in the traditional Any Source
Multicast (ASM) model (including the use of Multicast Source
Discovery Protocol (MSDP) [2] for source discovery), in Source-
Specific Multicast [3] (SSM) model, and the Embedded-RP [4]
group-to-RP mapping mechanism in ASM model. Bidirectional-PIM [15]
is typically deployed only in intra-domain and is similar to ASM but
without register messages. Bidirectional-PIM is not finished as of
this writing, and its considerations are not 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
SSM channel (S, G) identifies the multicast delivery tree
associated with a source address S and a 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).
3. Threats to Multicast Routing
We make the broad assumption that the multicast routing networks are
reasonably trusted. That is, we assume that the multicast routers
themselves are well-behaved, in the same sense that unicast routers
are expected to behave well. While this assumption is not entirely
correct, it simplifies the analysis of threat models. The threats
caused by misbehaving multicast routers (including fake multicast
routers) are not 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 considered out of scope.
As the threats described in this memo are mainly Denial-of-Service
(DoS) attacks, it may be useful to note that the 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 the use of host-to-router
signalling protocols -- such as Internet Group Management Protocol
(IGMP) or Multicast Listener Discovery (MLD) -- but these are outside
the scope of this memo.
PIM-SM can be abused in the cases where RPF checks are not applicable
(in particular, in the stub LAN networks), as spoofing the on-link
traffic is very simple. For example, a host could get elected to
become 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 implies that a
willful attacker will be able to circumvent many of the potential
rate-limiting functions performed at the DR (as one can always send
the messages himself). The PIM-SM specification, however, states
that these messages should only be accepted from known PIM neighbors;
if this is performed, the hosts would first have to establish a PIM
adjacency with the router. Typically, adjacencies are 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 are also considered out of the
scope of this memo.
3.1. Receiver-Based Attacks
These attacks are often referred to as control plane attacks, and the
aim of the attacker is usually to increase the amount of multicast
state information in routers above a manageable level.
3.1.1. Joins to Different Groups (Join Flooding)
Join flooding occurs when a host tries to join, once or a couple of
times, to a group or an SSM channel, and the DR generates a PIM Join
to the Target Router. The group/SSM channel or the Target Router may
or may not exist.
An example of this is a host trying to join different, non-existent
groups at a very rapid pace, trying to overload the routers on the
path with an excessive amount of (*/S,G) state (also referred to as
"PIM State"), or the Target Router with an excessive number of
packets.
Note that even if a host joins to a group multiple times, the DR only
sends one PIM Join message, without waiting for any acknowledgement;
the next message is only sent after the PIM Join timer expires or the
state changes at the DR.
This kind of joining causes PIM state to be created, but this state
is relatively short-lived (260 seconds by default, which is the
default time that the state is active at DR in the absence of IGMP/
MLD Reports/Leaves). Note that the host can join a number of
different ASM groups or SSM channels with only one IGMPv3 [11] or
MLDv2 [12] Report as the protocol allows multiple sources to be
included in the same message, resulting in multiple PIM Joins from
one IGMPv3/MLDv2 message.
However, even short-lived state may be harmful when the intent is to
cause as much state as possible. The host can continue to send
IGMP/MLD Reports to these groups to make the state attack more
long-lived. This results in:
o ASM: An (*,G) join is sent to an intra-domain RP, causing state on
that path; in turn, that RP joins to the DR of the source if the
source is active. If the source address was specified by the host
in the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly to the
DR of the source, as with SSM, below.
o SSM: An (S,G) join is sent inter-domain to the DR of the source S,
causing state on that path. If the source S does not exist, the
join goes to the closest router using longest prefix matching on
the path to S as possible.
o Embedded-RP: An (*,G) join is sent towards an inter/intra-domain
RP embedded in the group G, causing state on that path. If the RP
does not exist, the join goes to the router that is closest to the
RP address. Similarly, an explicit (S,G) join goes to the DR, as
with SSM above.
That is, SSM and Embedded-RP always enable "inter-domain" state
creation. ASM defaults to intra-domain, but can be used for inter-
domain state creation as well.
If the source or RP (only in case of Embedded-RP) does not exist, the
multicast routing protocol does not have any means to remove the
distribution tree if the joining host remains active. The worst case
attack could be a host remaining active to many different groups
(containing either imaginary source or RP). Please note that the
imaginary RP problem is related to only Embedded-RP, where the RP
address is extracted from the group address, G.
For example, if the host is able to generate 100 IGMPv3 (S,G) joins a
second, each carrying 10 sources, the amount of state after 260
seconds would be 260 000 state entries -- and 100 packets per second
is still a rather easily achievable number.
3.2. Source-Based Attacks
These attacks are often referred to as "data plane" attacks; however,
with traditional ASM and MSDP, these also include an MSDP control
plane threat.
3.2.1. Sending Multicast to Empty Groups (Data Flooding)
Data flooding occurs when a host sends data packets to a multicast
group or SSM channel for which there are no real subscribers.
Note that since register encapsulation is not subject to RPF checks,
the hosts can also craft and send these packets themselves, also
spoofing the source address of the register messages unless ingress
filtering [13] has been deployed [14]. That is, as the initial data
registering is not subject to the same RPF checks as many other
multicast routing procedures, making control decisions based on that
data leads to many potential threats.
Examples of this threat are a virus/worm trying to propagate to
multicast addresses, an attacker trying to crash routers with
excessive MSDP state, or an attacker wishing to overload the RP with
encapsulated packets of different groups. This results in:
o ASM: The DR register-encapsulates the packets in Register messages
to the intra-domain RP, which may join to the source and issue a
Register-Stop, but which continues to get the data. A
notification about the active source is sent (unless the group or
source is configured to be local) inter-domain with MSDP and
propagated globally.
o SSM: The DR receives the data, but the data does not propagate
from the DR unless someone joins the (S,G) channel.
o Embedded-RP: The DR register-encapsulates the packets to the
intra/inter-domain RP, which may join to the source and issue a
Register-Stop. Data continues to be encapsulated if different
groups are used.
This yields many potential attacks, especially if at least parts of
the multicast forwarding functions are implemented on a "slow" path
or CPU in the routers:
o 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 is only related to the ASM. However, this is
the most serious threat at the moment, because MSDP will flood the
multicast group information to all multicast domains in Internet
including the multicast packet encapsulated to MSDP source-active
message. This creates a lot of data and state to be shared by all
multicast-enabled routers, and if the source remains active, the
flooding will be repeated every 60 seconds by default.
o 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 received from the
source. These are potentially present in every model.
o If the encapsulation is performed on software, it may be a
performance bottleneck, and a way to perform DoS on the DR.
Similarly, if the decapsulation is performed on 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, avoiding bottlenecks. These threats are related to
ASM and Embedded-RP.
3.2.2. Disturbing Existing Group by Sending to It (Group Integrity
Violation)
Group integrity violation occurs when a host sends packets to a group
or SSM channel, which already exists, to disturb the users of the
existing group/SSM channel.
The SSM service model prevents injection of packets to (S,G)
channels, avoiding this problem. However, if the source address can
be spoofed to be 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 are able to perform this, so it is not
really relevant in the scope of this memo.
With ASM and Embedded-RP, sources can inject forged traffic through
RPs, which provide the source discovery for the group. The RPs send
the traffic over the shared tree towards receivers (routers with
(*,G) state). DR then forwards the forged traffic to receivers
unless the legitimate recipients are able to filter out unwanted
sources, e.g., using Multicast Source Filters (MSF) API [8].
Typically this is not used or supported by the applications using
these protocols.
Note that with ASM and Embedded-RP, the RP may exert some form of
control on who can send to a group, as 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 to 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 its applicability.
Embedded-RP enables easier control because source discovery is done
through a single RP per group.
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, resulting in an integrity
violation.
3.3. Aggravating Factors to the Threats
This section describes a few factors that aggravate the threats
described in Sections 3.1 and 3.2. These 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 will travel to the distant RP or source
and keep the state information in the path active, even if the data
is being delivered locally.
Note that this problem will be exacerbated if the RP/source space is
global; if a router is registering to a RP/source that is not in the
local domain (say, fielded by the site’s direct provider), then the
routing domain is flat.
Also note that PIM assumes that the addresses used in PIM messages
are valid. However, there is no way to ensure this, and using non-
existent S or G in (*,G) or (S,G) messages will cause the signalling
to be set up, even though one cannot reach the 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 does not forward that
information further in the multicast distribution tree. Therefore,
individual routers (e.g., domain edge routers) are not able to make
policy decisions on who can be connected to the distribution tree.
4. Threat Analysis
4.1. Summary of the Threats
Trying to summarize the severity of the major classes of threats with
respect to each multicast usage model, we have a matrix of resistance
to different kinds of threats:
+----------------+------------------+-----------------+
| 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 directly join also (S,G) groups with
IGMPv3/MLDv2 and thus have the same characteristics as SSM (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
There are several desirable actions ("requirements") that could be
considered to mitigate these threats; these are listed below. A few
more concrete suggestions are presented later in the section.
o 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.
o 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).
o 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.
o 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.
o RPs should rate-limit the MSDP SA messages coming from MSDP peers.
o RPs could limit or even disable the SA cache size. However, this
could have negative effects on normal operation.
o 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.
o DRs could rate-limit the multicast traffic somehow to reduce the
disturbing possibilities; there are multiple possibilities how
exactly this should be considered.
o DRs should rate-limit the number of groups/SSM channels that can
be created by a given source, S.
5. PIM Security Enhancements
This section includes more in-depth description of the above-
mentioned functions for rate-limiting, etc., as well as a description
of 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