summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4609.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4609.txt')
-rw-r--r--doc/rfc/rfc4609.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc4609.txt b/doc/rfc/rfc4609.txt
new file mode 100644
index 0000000..3245c6e
--- /dev/null
+++ b/doc/rfc/rfc4609.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group P. Savola
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 1]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 2]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 3]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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].
+
+
+
+
+
+Savola, et al. Informational [Page 4]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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.
+
+
+
+
+
+
+Savola, et al. Informational [Page 5]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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.
+
+
+
+
+Savola, et al. Informational [Page 6]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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
+
+
+
+Savola, et al. Informational [Page 7]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 8]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 9]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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
+
+
+
+Savola, et al. Informational [Page 10]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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.
+
+
+
+
+Savola, et al. Informational [Page 11]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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" that
+ 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:
+
+ o Whether the host is willfully malicious, uncontrolled (e.g.,
+ virus/worm), or a regular user just doing something wrong.
+
+
+
+
+
+
+Savola, et al. Informational [Page 12]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ o Whether the threat is aimed towards a single group, a single RP
+ handling the group, or the (multicast) routing infrastructure in
+ general.
+
+ o Whether the host on a subnet is spoofing its address (but still as
+ one that fulfills the RPF checks of the DR).
+
+ o Whether the host may generate the PIM join (and similar) messages
+ itself to avoid rate-limiters at the DR, if possible.
+
+ o Whether unicast RPF checks are applied on the link (i.e., whether
+ the host can send register-encapsulated register-messages on its
+ own).
+
+ o Whether blocking the misbehaving host on a subnet is allowed to
+ also block other, legitimate hosts on the same subnet.
+
+ o 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.
+
+
+
+
+
+
+Savola, et al. Informational [Page 13]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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.
+
+
+
+
+
+Savola, et al. Informational [Page 14]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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
+
+
+
+Savola, et al. Informational [Page 15]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ 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
+
+ A MSDP source-active rate-limiter is a token-bucket-based, source-
+ based rate-limiter, that would limit new groups per source with a
+ bucket of depth of SAG_DEPTH, refilling at SAG_RATE tokens per
+ second. Example values could be SAG_RATE=1 and SAG_DEPTH=10.
+
+ This would be second-order defense, at both the MSDP SA sending and
+ receiving sites, against data flooding and MSDP vulnerabilities in
+ particular. The specific threat being addressed here 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 are also able
+ to form PIM adjacencies and send disrupting traffic unless great care
+ is observed at the routers. This stems from the fact that most
+ implementations require that stub LANs with only one PIM router must
+ also have PIM enabled (to enable PIM processing of the sourced data,
+ etc.) Such stub networks however do not require to actually run the
+ PIM protocol on the link. Therefore, such implementations should
+ provide an option to specify that the interface is "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.
+
+
+
+
+Savola, et al. Informational [Page 16]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ However, one should keep in mind two caveats: 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"; and 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.
+
+
+
+
+
+Savola, et al. Informational [Page 17]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 18]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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 in the media where more than two routers can
+ connect to, 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 in 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 19]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+Appendix B. Return Routability Extensions
+
+ The multicast state information is built from the receiver side, and
+ it can be currently 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 the 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 the 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 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., 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 entry 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.
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 20]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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 and if there is no
+ multicast traffic for a certain group within a certain time limit,
+ the state should be removed. In here, if the receiver is malicious
+ and wants to create states in the network, then 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 long time.)
+
+ The second approach works also for DoS attacks related to the
+ existing source/RP addresses, could be more quickly implemented and
+ deployed in the network, and does not have any relationship with the
+ other deployments (no need to change all PIM routers).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 21]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 22]
+
+RFC 4609 PIM-SM Multicast Routing Security August 2006
+
+
+Full Copyright Statement
+
+ 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
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Savola, et al. Informational [Page 23]
+