draft-ietf-mboned-mroutesec-04.txt   rfc4609.txt 
MBONED WG P. Savola Network Working Group P. Savola
Internet-Draft CSC/FUNET Request for Comments: 4609 CSC/FUNET
Expires: April 12, 2005 R. Lehtonen Category: Informational R. Lehtonen
TeliaSonera TeliaSonera
D. Meyer D. Meyer
October 12, 2004 August 2006
PIM-SM Multicast Routing Security Issues and Enhancements
draft-ietf-mboned-mroutesec-04.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Protocol Independent Multicast - Sparse Mode (PIM-SM)
http://www.ietf.org/ietf/1id-abstracts.txt. Multicast Routing Security Issues and Enhancements
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 12, 2005. 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 Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo describes security threats for the larger (intra-domain, or This memo describes security threats for the larger (intra-domain or
inter-domain) multicast routing infrastructures. Only Protocol inter-domain) multicast routing infrastructures. Only Protocol
Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its
three main operational modes: the traditional Any Source Multicast three main operational modes: the traditional Any-Source Multicast
(ASM) model, Source-Specific Multicast (SSM) model, and the ASM model (ASM) model, the source-specific multicast (SSM) model, and the ASM
enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo model enhanced by the Embedded Rendezvous Point (Embedded-RP)
also describes enhancements to the protocol operations to mitigate group-to-RP mapping mechanism. This memo also describes enhancements
the identified threats. to the protocol operations that mitigate the identified threats.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................4
3. Threats to Multicast Routing . . . . . . . . . . . . . . . . . 4 3. Threats to Multicast Routing ....................................4
3.1 Receiver-based Attacks . . . . . . . . . . . . . . . . . . 5 3.1. Receiver-Based Attacks .....................................5
3.1.1 Joins to Different Groups . . . . . . . . . . . . . . 5 3.1.1. Joins to Different Groups (Join Flooding) ...........5
3.2 Source-based Attacks . . . . . . . . . . . . . . . . . . . 6 3.2. Source-Based Attacks .......................................7
3.2.1 Sending Multicast to Empty Groups . . . . . . . . . . 6 3.2.1. Sending Multicast to Empty Groups (Data Flooding) ...7
3.2.2 Disturbing Existing Group by Sending to It . . . . . . 8 3.2.2. Disturbing Existing Group by Sending to It
3.3 Aggravating Factors to the Threats . . . . . . . . . . . . 9 (Group Integrity Violation)..........................8
3.3.1 Distant RP/Source Problem . . . . . . . . . . . . . . 9 3.3. Aggravating Factors to the Threats .........................9
3.3.2 No Receiver Information in PIM Joins . . . . . . . . . 9 3.3.1. Distant RP/Source Problem ...........................9
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. No Receiver Information in PIM Joins ...............10
4.1 Summary of the Threats . . . . . . . . . . . . . . . . . . 9 4. Threat Analysis ................................................10
4.2 Enhancements for Threat Mitigation . . . . . . . . . . . . 10 4.1. Summary of the Threats ....................................10
5. PIM Security Enhancements . . . . . . . . . . . . . . . . . . 11 4.2. Enhancements for Threat Mitigation ........................10
5.1 Remote Routability Signalling . . . . . . . . . . . . . . 11 5. PIM Security Enhancements ......................................11
5.2 Rate-limiting Possibilities . . . . . . . . . . . . . . . 12 5.1. Remote Routability Signalling .............................11
5.3 Specific Rate-limiting Suggestions . . . . . . . . . . . . 13 5.2. Rate-Limiting Possibilities ...............................12
5.3.1 Group Management Protocol Rate-limiter . . . . . . . . 14 5.3. Specific Rate-limiting Suggestions ........................14
5.3.2 Source Transmission Rate-limiter . . . . . . . . . . . 14 5.3.1. Group Management Protocol Rate-Limiter .............14
5.3.3 PIM Signalling Rate-limiter . . . . . . . . . . . . . 14 5.3.2. Source Transmission Rate-Limiter ...................14
5.3.4 Unicast-decapsulation Rate-limiter . . . . . . . . . . 15 5.3.3. PIM Signalling Rate-Limiter ........................15
5.3.5 PIM Register Rate-limiter . . . . . . . . . . . . . . 15 5.3.4. Unicast-Decapsulation Rate-Limiter .................15
5.3.6 MSDP Source-Active Rate-limiter . . . . . . . . . . . 15 5.3.5. PIM Register Rate-Limiter ..........................15
5.4 Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 15 5.3.6. MSDP Source-Active Rate-Limiter ....................16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5.4. Passive Mode for PIM ......................................16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations ........................................16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements ...............................................17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References .....................................................17
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References ......................................17
9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References ....................................17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. RPF Considers Interface, Not Neighbor ................19
A. RPF Considers Interface, Not Neighbor . . . . . . . . . . . . 18 Appendix B. Return Routability Extensions ........................20
B. Return Routability Extensions . . . . . . . . . . . . . . . . 19 B.1. Sending PIM-Prune Messages Down the Tree ..................20
B.1 Sending PIM-Prune Messages Down the Tree . . . . . . . . . 19 B.2. Analysing Multicast Group Traffic at DR ...................21
B.2 Analysing Multicast Group Traffic at DR . . . . . . . . . 20 B.3. Comparison of the Above Approaches ........................21
B.3 Comparison of the Above Approaches . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
This document describes security threats to the Protocol Independent This document describes security threats to the Protocol Independent
Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures, Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures
and suggests ways to make these architectures more resistant to the and suggests ways to make these architectures more resistant to the
described threats. described threats.
Only attacks which have an effect on the multicast routing Only attacks that have an effect on the multicast routing
infrastructures (whether intra- or inter-domain) are considered. infrastructures (whether intra- or inter-domain) are considered.
"On-link" attacks where the hosts are specifically targeting the "On-link" attacks where the hosts specifically target the Designated
Designated Router (DR) or other routers on the link, or where hosts Router (DR) or other routers on the link, or where hosts disrupt
are disrupting other hosts on the same link, possibly using group other hosts on the same link, possibly using group management
management protocols, are discussed elsewhere (e.g., [10] and [12]). protocols, are discussed elsewhere (e.g., [10] and [12]). These
These attacks are not discussed further in this document. attacks are not discussed further in this document.
Similar to unicast, the multicast payloads may need end-to-end Similar to unicast, the multicast payloads may need end-to-end
security. Security mechanisms to provide confidentiality, security. Security mechanisms to provide confidentiality,
authentication, and integrity are described in other documents (e.g., authentication, and integrity are described in other documents (e.g.,
[9]). These attacks that these security mechanisms protect against [9]). Attacks that these security mechanisms protect against are not
are not discussed further in this document. discussed further in this document.
PIM builds on a model where Reverse Path Forwarding (RPF) checking PIM builds on a model where Reverse Path Forwarding (RPF) checking
is, among other things, used to ensure loop-free properties of the is, among other things, used to ensure loop-free properties of the
multicast distribution trees. As a side effect, this limits the multicast distribution trees. As a side effect, this limits the
impact of an attacker using a forged source address, which is often impact of an attacker using a forged source address, which is often
used as a component in unicast-based attacks. However, a host can 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 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 a unicast-encapsulated PIM Register message, which a host may send on
its own. its own.
We consider PIM-SM [1] operating in the traditional Any Souce We consider PIM-SM [1] operating in the traditional Any Source
Multicast (ASM) model (including the use of Multicast Source Multicast (ASM) model (including the use of Multicast Source
Discovery Protocol (MSDP) [2] for source discovery), in Discovery Protocol (MSDP) [2] for source discovery), in Source-
Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] Specific Multicast [3] (SSM) model, and the Embedded-RP [4]
group-to-RP mapping mechanism in ASM model. Bidirectional-PIM [15] group-to-RP mapping mechanism in ASM model. Bidirectional-PIM [15]
is typically deployed only in intra-domain, and is similar to ASM but is typically deployed only in intra-domain and is similar to ASM but
without register messages. Bidirectional-PIM is not finished as of without register messages. Bidirectional-PIM is not finished as of
this writing, and its considerations are not discussed further in this writing, and its considerations are not discussed further in
this document. this document.
2. Terminology 2. Terminology
ASM ASM
"ASM" [6] is used to refer to the traditional Any Source "ASM" [6] is used to refer to the traditional Any Source Multicast
Multicast model with multiple PIM domains and a signalling model with multiple PIM domains and a signalling mechanism (MSDP)
mechanism (MSDP) to exchange information about active sources to exchange information about active sources between them.
between them.
SSM SSM
"SSM" [7] is used to refer to Source-Specific Multicast. "SSM" [7] is used to refer to Source-Specific Multicast.
SSM channel SSM channel
SSM channel (S, G) identifies the multicast delivery tree SSM channel (S, G) identifies the multicast delivery tree
associated with a source address S and a SSM destination associated with a source address S and a SSM destination address
address G. G.
Embedded-RP Embedded-RP
"Embedded-RP" refers to the ASM model where the Embedded-RP "Embedded-RP" refers to the ASM model where the Embedded-RP
mapping mechanism is used to find the Rendezvous Point (RP) for mapping mechanism is used to find the Rendezvous Point (RP) for a
a group, and MSDP is not used. group, and MSDP is not used.
Target Router Target Router
"Target Router" is used to refer to either the RP processing a "Target Router" is used to refer to either the RP processing a
packet (ASM or Embedded-RP), or the DR that is receiving packet (ASM or Embedded-RP) or the DR that is receiving (Source,
(Source, Group) (or (S,G)) joins, (in all models). Group) (or (S,G)) joins (in all models).
3. Threats to Multicast Routing 3. Threats to Multicast Routing
We make the broad assumption that the multicast routing networks are We make the broad assumption that the multicast routing networks are
reasonably trusted. That is, we assume that the multicast routers reasonably trusted. That is, we assume that the multicast routers
themselves are well-behaved, in the same sense that unicast routers themselves are well-behaved, in the same sense that unicast routers
are expected to behave well. While this assumption is not entirely are expected to behave well. While this assumption is not entirely
correct, it simplifies the analysis of threat models. The threats correct, it simplifies the analysis of threat models. The threats
caused by misbehaving multicast routers (including fake multicast caused by misbehaving multicast routers (including fake multicast
routers) are not considered in this memo -- the generic threat model routers) are not considered in this memo; the generic threat model
would be similar to [5]. RP discovery mechanisms like Bootstrap would be similar to [5]. RP discovery mechanisms like Bootstrap
Router (BSR) and Auto-RP are also considered out of the scope. Router (BSR) and Auto-RP are also considered out of scope.
As the threats described in this memo are mainly Denial of Service 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 (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 to find a scarce resource anywhere in the control or data plane, as
described in [5]. described in [5].
There are multiple threats relating to the use of host-to-router There are multiple threats relating to the use of host-to-router
signalling protocols -- such as Internet Group Management Protocol signalling protocols -- such as Internet Group Management Protocol
(IGMP) or Multicast Listener Discovery (MLD) -- but these are outside (IGMP) or Multicast Listener Discovery (MLD) -- but these are outside
the scope of this memo. the scope of this memo.
PIM-SM can be abused in the cases where RPF checks are not PIM-SM can be abused in the cases where RPF checks are not applicable
applicable, in particular, in the stub LAN networks -- as spoofing (in particular, in the stub LAN networks), as spoofing the on-link
the on-link traffic is very simple. For example, a host could get traffic is very simple. For example, a host could get elected to
elected to become DR for the subnet, but not perform any of its become DR for the subnet, but not perform any of its functions. A
functions. A host can also easily make PIM routers on the link stop host can also easily make PIM routers on the link stop forwarding
forwarding multicast by sending PIM Assert messages. This implies multicast by sending PIM Assert messages. This implies that a
that a willful attacker will be able to circumvent many of the willful attacker will be able to circumvent many of the potential
potential rate-limiting functions performed at the DR (as one can rate-limiting functions performed at the DR (as one can always send
always send the messages yourself). The PIM-SM specification, the messages himself). The PIM-SM specification, however, states
however, states that these messages should only be accepted from that these messages should only be accepted from known PIM neighbors;
known PIM neighbors; if this is performed, the hosts would first have if this is performed, the hosts would first have to establish a PIM
to establish a PIM adjacency with the router. Typically, adjacencies adjacency with the router. Typically, adjacencies are formed with
are formed with anyone on the link, so a willful attacker would have anyone on the link, so a willful attacker would have a high
a high probability of success in forming a protocol adjacency. These probability of success in forming a protocol adjacency. These are
are described at some length in [1], but are also considered out of described at some length in [1], but are also considered out of the
scope of this memo. scope of this memo.
3.1 Receiver-based Attacks 3.1. Receiver-Based Attacks
These attacks are often referred to as control plane attacks and the These attacks are often referred to as control plane attacks, and the
aim of the attacker is usually to increase the amount of multicast aim of the attacker is usually to increase the amount of multicast
state information in routers above a manageable level. state information in routers above a manageable level.
3.1.1 Joins to Different Groups 3.1.1. Joins to Different Groups (Join Flooding)
Description of the threat: Join Flooding. Join Flooding occurs when Join flooding occurs when a host tries to join, once or a couple of
a host tries to join, once or a couple of times, to a group or a SSM times, to a group or an SSM channel, and the DR generates a PIM Join
channel, and the DR generates a PIM Join to the Target Router. The to the Target Router. The group/SSM channel or the Target Router may
group/SSM channel or the Targer Router may or may not exist. or may not exist.
Example of this is a host trying to join different, non-existent 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 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 path with an excessive amount of (*/S,G) state (also referred to as
"PIM State"), or the Target Router with an excessive number of "PIM State"), or the Target Router with an excessive number of
packets. packets.
Note that even if a host joins to a group multiple times, the DR only 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; sends one PIM Join message, without waiting for any acknowledgement;
the next message is only sent after the PIM Join timer expires or the the next message is only sent after the PIM Join timer expires or the
state changes at the DR. state changes at the DR.
This kind of joining causes PIM state to be created, but this state This kind of joining causes PIM state to be created, but this state
is relatively short-lived (260 seconds by default, which is the is relatively short-lived (260 seconds by default, which is the
default time that the state is active at DR in the absence of default time that the state is active at DR in the absence of IGMP/
IGMP/MLD Reports/Leaves). It should also be noted that the host can MLD Reports/Leaves). Note that the host can join a number of
join a number of different ASM groups or SSM channels with only one different ASM groups or SSM channels with only one IGMPv3 [11] or
IGMPv3 [11] or MLDv2 [12] Report as the protocol allows to include MLDv2 [12] Report as the protocol allows multiple sources to be
multiple sources in the same message, resulting in multiple PIM Joins included in the same message, resulting in multiple PIM Joins from
from one IGMPv3/MLDv2 message. one IGMPv3/MLDv2 message.
However, even short-lived state may be harmful when the intent is to 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 cause as much state as possible. The host can continue to send
IGMP/MLD Reports to these groups to make the state attack more IGMP/MLD Reports to these groups to make the state attack more
long-lived. This results in: long-lived. This results in:
o ASM: a (*,G) join is sent to an intra-domain RP, causing state on 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 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 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 in the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly to the
DR of the source, as with SSM, below. DR of the source, as with SSM, below.
o SSM: a (S,G) join is sent inter-domain to the DR of the source S, 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 does not exist, the causing state on that path. If the source S does not exist, the
join goes to the closest router on the path to S as possible. join goes to the closest router using longest prefix matching on
the path to S as possible.
o Embedded-RP: a (*,G) join is sent towards an inter/intra-domain RP o Embedded-RP: An (*,G) join is sent towards an inter/intra-domain
embedded in the group G, causing state on that path. If the RP RP embedded in the group G, causing state on that path. If the RP
does not exist, the join goes to the closest router to the RP does not exist, the join goes to the router that is closest to the
address as possible. Similarly, an explicit (S,G) join goes to RP address. Similarly, an explicit (S,G) join goes to the DR, as
the DR, as with SSM above. with SSM above.
That is, SSM and Embedded-RP always enable "inter-domain" state That is, SSM and Embedded-RP always enable "inter-domain" state
creation. ASM defaults to intra-domain, but can be used for creation. ASM defaults to intra-domain, but can be used for inter-
inter-domain state creation as well. domain state creation as well.
If the source or RP (only in case of Embedded-RP) does not exist, the 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 multicast routing protocol does not have any means to remove the
distribution tree if the joining host remains active. Worst case distribution tree if the joining host remains active. The worst case
attack could be a host remaining active to many different groups attack could be a host remaining active to many different groups
(containing either imaginary source or RP). Please note that the (containing either imaginary source or RP). Please note that the
imaginary RP problem is related to only Embedded-RP, where the RP imaginary RP problem is related to only Embedded-RP, where the RP
address is extracted from the group address, G. address is extracted from the group address, G.
For example, if the host is able to generate 100 IGMPv3 (S,G) joins a 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 second, each carrying 10 sources, the amount of state after 260
seconds would be 260 000 state entries -- and 100 packets per second seconds would be 260 000 state entries -- and 100 packets per second
is still a rather easily achievable number. is still a rather easily achievable number.
3.2 Source-based Attacks 3.2. Source-Based Attacks
These attacks are often referred to as "data plane" attacks; however, These attacks are often referred to as "data plane" attacks; however,
with traditional ASM and MSDP, these also include an MSDP control with traditional ASM and MSDP, these also include an MSDP control
plane threat. plane threat.
3.2.1 Sending Multicast to Empty Groups 3.2.1. Sending Multicast to Empty Groups (Data Flooding)
Description of the threat: Data Flooding. Data Flooding occurs when Data flooding occurs when a host sends data packets to a multicast
a host sends data packets to a multicast group or SSM channel for group or SSM channel for which there are no real subscribers.
which there are no real subscribers.
Note that since register encapsulation is not subject to RPF checks, Note that since register encapsulation is not subject to RPF checks,
the hosts can also craft and send these packets themselves, also the hosts can also craft and send these packets themselves, also
spoofing the source address of the register messages unless ingress spoofing the source address of the register messages unless ingress
filtering [13] has been deployed [14]. That is, as the initial data filtering [13] has been deployed [14]. That is, as the initial data
registering is not subject to the same RPF checks as many other registering is not subject to the same RPF checks as many other
multicast routing procedures, making control decisions based on that multicast routing procedures, making control decisions based on that
data leads to many potential threats. data leads to many potential threats.
Examples of this threat are a virus/worm trying to propagate to Examples of this threat are a virus/worm trying to propagate to
multicast addresses, an attacker trying to crash routers with multicast addresses, an attacker trying to crash routers with
excessive MSDP state, or an attacker wishing to overload the RP with excessive MSDP state, or an attacker wishing to overload the RP with
encapsulated packets or different groups. This results in: encapsulated packets of different groups. This results in:
o ASM: the DR register-encapsulates the packets in Register messages 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 to the intra-domain RP, which may join to the source and issue a
Register-Stop, but continues to get the data. A notification Register-Stop, but which continues to get the data. A
about the active source is sent (unless the group or source is notification about the active source is sent (unless the group or
configured to be local) inter-domain with MSDP and propagated source is configured to be local) inter-domain with MSDP and
globally. propagated globally.
o SSM: the DR receives the data, but the data does not propagate o SSM: The DR receives the data, but the data does not propagate
from the DR unless someone joins the (S,G) channel. from the DR unless someone joins the (S,G) channel.
o Embedded-RP: the DR register-encapsulates the packets to the o Embedded-RP: The DR register-encapsulates the packets to the
intra/inter-domain RP, which may join to the source and issue a intra/inter-domain RP, which may join to the source and issue a
Register-Stop. Data continues to be encapsulated if different Register-Stop. Data continues to be encapsulated if different
groups are used. groups are used.
This yields many potential attacks, especially if at least parts of This yields many potential attacks, especially if at least parts of
the multicast forwarding functions are implemented on a "slow" path the multicast forwarding functions are implemented on a "slow" path
or CPU in the routers, at least: or CPU in the routers:
o The MSDP control plane traffic generated can cause a significant o The MSDP control plane traffic generated can cause a significant
amount of control and data traffic which may overload the routers amount of control and data traffic, which may overload the routers
receiving it. A thorough analysis of MSDP vulnerabilities can be receiving it. A thorough analysis of MSDP vulnerabilities can be
found in [16], and is only related to the ASM. However, this is 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 the most serious threat at the moment, because MSDP will flood the
multicast group information to all multicast domains in Internet multicast group information to all multicast domains in Internet
including the multicast packet encapsulated to MSDP source-active including the multicast packet encapsulated to MSDP source-active
message. This creates a lot of data and state to be shared by all message. This creates a lot of data and state to be shared by all
multicast enabled routers and if the source remains active, the multicast-enabled routers, and if the source remains active, the
flooding will be repeated every 60 seconds by default. flooding will be repeated every 60 seconds by default.
o As a large amount of data is forwarded on the multicast tree; if 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 multicast forwarding is performed on CPU, it may be a serious
performance bottleneck, and a way to perform DoS on the path. performance bottleneck, and a way to perform DoS on the path.
Similarly, the DR must always be capable of processing (and Similarly, the DR must always be capable of processing (and
discarding, if necessary) the multicast packets received from the discarding, if necessary) the multicast packets received from the
source. These are potentially present in every model. source. These are potentially present in every model.
o If the encapsulation is performed on software, it may be a o If the encapsulation is performed on software, it may be a
performance bottleneck, and a way to perform DoS on the DR. performance bottleneck, and a way to perform DoS on the DR.
Similarly, if the decapsulation is performed on software, it may Similarly, if the decapsulation is performed on software, it may
be a performance bottleneck, and a way to perform DoS on the RP. be a performance bottleneck, and a way to perform DoS on the RP.
Note: the decapsulator may know, based on access configuration, a Note: the decapsulator may know (based on access configuration, a
rate-limit or something else, that it doesn't need to decapsulate rate limit, or something else) that it doesn't need to decapsulate
the packet, avoiding bottlenecks. These threats are related to the packet, avoiding bottlenecks. These threats are related to
ASM and Embedded-RP. ASM and Embedded-RP.
3.2.2 Disturbing Existing Group by Sending to It 3.2.2. Disturbing Existing Group by Sending to It (Group Integrity
Violation)
Description of the threat: Group Integrity Violation. Group Group integrity violation occurs when a host sends packets to a group
Integrity Violation occurs when a host sends packets to a group or or SSM channel, which already exists, to disturb the users of the
SSM channel, which already exists, to disturb the users of the
existing group/SSM channel. existing group/SSM channel.
The SSM service model prevents injection of packets to (S,G) The SSM service model prevents injection of packets to (S,G)
channels, avoiding this problem. However, if the source address can channels, avoiding this problem. However, if the source address can
be spoofed to be a topologically-correct address, it's possible to be spoofed to be a topologically-correct address, it's possible to
get the packet into the distribution tree -- typically only those get the packet into the distribution tree. Typically only hosts that
hosts which are on-link with the source are able to perform this, so are on-link with the source are able to perform this, so it is not
this is not really relevant in the scope of this memo. really relevant in the scope of this memo.
With ASM and Embedded-RP sources can inject forged traffic through With ASM and Embedded-RP, sources can inject forged traffic through
RPs, which provide the source discovery for the group. The RP(s) RPs, which provide the source discovery for the group. The RPs send
send the traffic over the shared tree towards receivers (routers with the traffic over the shared tree towards receivers (routers with
(*,G) state). DR then forwards the forged traffic to receivers (*,G) state). DR then forwards the forged traffic to receivers
unless the legitimate recipients are able to filter out unwanted unless the legitimate recipients are able to filter out unwanted
sources, e.g., using MSF API [8]. Typically this is not used or sources, e.g., using Multicast Source Filters (MSF) API [8].
supported by the applications using these protocols. 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 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 control on who can send to a group, as the first packets are
register-encapsulated in register packets to the RP -- if the RP register-encapsulated in register packets to the RP. If the RP drops
drops the packet based on access-list, rate-limiter or something the packet based on an access list, a rate limit, or something else,
else, it doesn't get injected to an existing group.
With ASM this "source control" is distributed across all the PIM 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. domains, which significantly decreases its applicability.
Embedded-RP enables easier control because source discovery is done Embedded-RP enables easier control because source discovery is done
through single RP per group. through a single RP per group.
As a result, for this attack to succeed, the RP must decapsulate the As a result, in addition to possible local disturbance, the RP
packets, causing the propagation of data and the integrity violation. 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 3.3. Aggravating Factors to the Threats
This section describes a few factors, which aggravate the threats This section describes a few factors that aggravate the threats
described in Section 3.1 and Section 3.2. These could also be viewed described in Sections 3.1 and 3.2. These could also be viewed as
as individual threats on their own. individual threats on their own.
3.3.1 Distant RP/Source Problem 3.3.1. Distant RP/Source Problem
In the shared tree model, if the RP or a source is distant In the shared tree model, if the RP or a source is distant
(topologically), then joins will travel to the distant RP or source (topologically), then joins will travel to the distant RP or source
and keep the state information in the path active, even if the data and keep the state information in the path active, even if the data
is being delivered locally. is being delivered locally.
Note that this problem will be exacerbated if the RP/source space is 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 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 local domain (say, fielded by the site's direct provider), then the
routing domain is flat. routing domain is flat.
Also note that PIM assumes that the addresses used in PIM messages Also note that PIM assumes that the addresses used in PIM messages
are valid. However, there is no way to ensure this, and using are valid. However, there is no way to ensure this, and using non-
non-existent S or G in (*,G) or (S,G) -messages will cause the existent S or G in (*,G) or (S,G) messages will cause the signalling
signalling to be set up, even though one cannot reach the address. to be set up, even though one cannot reach the address.
This will be analysed at more length in Section 5.1. This will be analyzed at more length in Section 5.1.
3.3.2 No Receiver Information in PIM Joins 3.3.2. No Receiver Information in PIM Joins
Only DRs, which are directly connected to receivers, know the exact Only DRs, which are directly connected to receivers, know the exact
receiver information (e.g. IP address). PIM does not forward that receiver information (e.g., IP address). PIM does not forward that
information further in the multicast distribution tree. Therefore information further in the multicast distribution tree. Therefore,
individual routers (e.g. domain edge routers) are not able to make individual routers (e.g., domain edge routers) are not able to make
policy decisions on who can be connected to the distribution tree. policy decisions on who can be connected to the distribution tree.
4. Threat Analysis 4. Threat Analysis
4.1 Summary of the Threats 4.1. Summary of the Threats
Trying to summarize the severity of the major classes of threats with Trying to summarize the severity of the major classes of threats with
respect to each multicast usage model, we have a matrix of resistance respect to each multicast usage model, we have a matrix of resistance
to different kinds of threats: to different kinds of threats:
+----------------+------------------+-----------------+ +----------------+------------------+-----------------+
| Forged Join | Being a Source | Group Integrity | | Forged Join | Being a Source | Group Integrity |
+-------------+----------------+------------------+-----------------+ +-------------+----------------+------------------+-----------------+
| ASM | bad 1) | very bad | bad/mediocre | | ASM | bad 1) | very bad | bad/mediocre |
+-------------+----------------+------------------+-----------------+ +-------------+----------------+------------------+-----------------+
| SSM | bad | very good | very good | | SSM | bad | very good | very good |
+-------------+----------------+------------------+-----------------+ +-------------+----------------+------------------+-----------------+
| Embedded-RP | bad 1),2) | good/mediocre 3) | good | | Embedded-RP | bad 1),2) | good/mediocre 3) | good |
+-------------+----------------+------------------+-----------------+ +-------------+----------------+------------------+-----------------+
Notes: Notes:
1) in ASM host can directly join also (S,G) groups with IGMPv3/MLDv2 1) In ASM, the host can directly join also (S,G) groups with
and thus have same characteristics as SSM (also allows inter-domain IGMPv3/MLDv2 and thus have the same characteristics as SSM (also
state to be created). allows inter-domain state to be created).
2) allows inter-domain shared 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 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 (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 register attack. In this case, the host can mount the attack
implementing any of the PIM register machinery. without implementing any of the PIM register machinery.
4.2 Enhancements for Threat Mitigation 4.2. Enhancements for Threat Mitigation
There are several desirable actions ("requirements") which could be There are several desirable actions ("requirements") that could be
considered to mitigate these threats; these are listed below. A few considered to mitigate these threats; these are listed below. A few
more concrete suggestions are presented later in the section. more concrete suggestions are presented later in the section.
o Inter-domain MSDP (ASM) should be retired to avoid attacks; or, if o Inter-domain MSDP (ASM) should be retired to avoid attacks; or, if
this is not reasonable, the DRs should rate-limit the register this is not reasonable, the DRs should rate-limit the register
encapsulation (note that the hosts can circumvent this) and (more encapsulation (note that the hosts can circumvent this). More
importantly) the RPs should rate-limit the register decapsulation importantly, the RPs should rate-limit the register decapsulation
especially from different sources, or MSDP must rate-limit the especially from different sources, or MSDP must rate-limit the
MSDP data generation for new sources. MSDP data generation for new sources.
o DRs should rate-limit PIM Joins and Prunes somehow; there are o DRs should rate-limit PIM Joins and Prunes somehow; there are
multiple possibilities how exactly this should be considered multiple ways this should be considered (i.e., depending on which
(i.e., which variables to take into the consideration). variables are taken into consideration).
o DRs could rate-limit register encapsulation somehow; there are o DRs could rate-limit register encapsulation somehow; there are
multiple ways to perform this. Note that the hosts can avoid this multiple ways to perform this. Note that the hosts can avoid this
by performing the register encapsulation themselves if so by performing the register encapsulation themselves if so
inclined. inclined.
o RPs could rate-limit register decapsulation somehow; there are o RPs could rate-limit register decapsulation somehow; there are
multiple ways to perform this. Note that if the source of the 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 unicast packets is spoofed by the host, this may have an effect on
how e.g. rate-limiters behave. how (for example) rate-limiters behave.
o RPs should rate limit the MSDP SA messages coming from MSDP peers. 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 o RPs could limit or even disable the SA cache size. However, this
could have negative effects on normal operation. could have negative effects on normal operation.
o RPs should provide good interfaces to reject packets which are not o RPs should provide good interfaces to reject packets that are not
interesting; for example, if an Embedded-RP group is not interesting; for example, if an Embedded-RP group is not
configured to be allowed in the RP, the register encapsulated configured to be allowed in the RP, the register encapsulated
packets would not even be decapsulated. packets would not even be decapsulated.
o DRs could rate-limit the multicast traffic somehow to reduce the o DRs could rate-limit the multicast traffic somehow to reduce the
disturbing possibilities; there are multiple possibilities how disturbing possibilities; there are multiple possibilities how
exactly this should be considered. exactly this should be considered.
o DRs should rate-limit the number of groups/SSM channels that can o DRs should rate-limit the number of groups/SSM channels that can
be created by a given source, S. be created by a given source, S.
5. PIM Security Enhancements 5. PIM Security Enhancements
This section includes more in-depth description of the This section includes more in-depth description of the above-
above-mentioned rate-limiting etc. functions as well as description mentioned functions for rate-limiting, etc., as well as a description
of the remote routability signalling issue. of the remote routability signalling issue.
5.1 Remote Routability Signalling 5.1. Remote Routability Signalling
As described in Section 3.3.1, non-existent DRs or RPs may cause some 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 problems when setting up multicast state. There seem to be a couple
of different approaches to mitigate this, especially if rate-limiting of different approaches to mitigate this, especially if rate-limiting
is not extensively deployed. is not extensively deployed.
With ASM and Embedded-RP, Register message delivery could be ensured With ASM and Embedded-RP, Register message delivery could be ensured
somehow. For example: somehow. For example:
1) At the very least, receiving an ICMP unreachable message (of 1) At the very least, receiving an ICMP unreachable message (of
any flavor) should cause the DR to stop the Register packets -- as any flavor) should cause the DR to stop the Register packets,
the RP will not be receiving them anyway. (However, one should as the RP will not be receiving them anyway. (However, one
note that easy spoofing of such ICMP messages could cause a DoS on should note that easy spoofing of such ICMP messages could
legitimate traffic.) 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.)
2) An additional method could be implementing a timer on the RPs
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 3) An extreme case would be performing some form of return
routability check prior to starting the register messages: first a routability check prior to starting the register messages:
packet would be sent to the RP, testing its existence and first, a packet would be sent to the RP, testing its existence
willingness to serve, and also proving to the RP that the sender and willingness to serve, and also proving to the RP that the
of the "bubble" and the sender of the registers are the same and sender of the "bubble" and the sender of the registers are the
the source address is not forged (i.e., the RP would insert a same and the source address is not forged. (That is, the RP
cookie in the bubble, and it would have to be present in the would insert a cookie in the bubble, and it would have to be
register message.) present in the register message.)
It would be desirable to have some kind of state management for PIM It would be desirable to have some kind of state management for PIM
Joins (and other messages) as well, for example, a "Join Ack" which 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 could be used to ensure that the path to the source/RP actually
exists. However, this is very difficult if not impossible with the exists. However, this is very difficult, if not impossible, with the
current architecture: PIM messages are sent hop-by-hop, and there is current architecture: PIM messages are sent hop-by-hop, and there is
not enough information to trace back the replies to e.g., notify the not enough information to trace back the replies, for example, to
routers in the middle to release the corresponding state, and to notify the routers in the middle to release the corresponding state
nofify the DR that the path did not exist. or to notify the DR that the path did not exist.
Appendix B discusses this receiver-based remote routability Appendix B discusses this receiver-based remote routability
signalling in more detail. signalling in more detail.
5.2 Rate-limiting Possibilities 5.2. Rate-Limiting Possibilities
There seem to be many ways to implement rate-limiting (for There seem to be many ways to implement rate-limiting (for
signalling, data encapsulation and multicast traffic) at the DRs or signalling, data encapsulation, and multicast traffic) at the DRs or
RPs -- the best approach likely depends on the threat model; factors RPs. The best approach likely depends on the threat model; for
in the evaluation might be e.g.: example, factors in the evaluation may include:
o Whether the host is willfully maliscious, uncontrolled (e.g., o Whether the host is willfully malicious, uncontrolled (e.g.,
virus/worm), or a regular user just doing something wrong. virus/worm), or a regular user just doing something wrong.
o Whether the threat is aimed towards a single group, a single RP o Whether the threat is aimed towards a single group, a single RP
handling the group, or the (multicast) routing infrastructure in handling the group, or the (multicast) routing infrastructure in
general. general.
o Whether the host on a subnet is spoofing its address (but still as o Whether the host on a subnet is spoofing its address (but still as
one which fulfills the RPF checks of the DR) or not. one that fulfills the RPF checks of the DR).
o Whether the host may generate the PIM join (and similar) messages o Whether the host may generate the PIM join (and similar) messages
itself to avoid rate-limiters at the DR if possible. itself to avoid rate-limiters at the DR, if possible.
o Whether unicast RPF checks are applied on the link (i.e., whether o Whether unicast RPF checks are applied on the link (i.e., whether
the host can send register-encapsulated register-messages on its the host can send register-encapsulated register-messages on its
own). own).
o Whether blocking the misbehaving host on a subnet is allowed to o Whether blocking the misbehaving host on a subnet is allowed to
also block other, legitimate hosts on the same subnet. also block other, legitimate hosts on the same subnet.
o Whether these mechanisms would cause false positives on links with o Whether these mechanisms would cause false positives on links with
only properly working hosts if many of them are receivers or only properly working hosts if many of them are receivers or
senders. senders.
As should be obvious, there are many different scenarios here which As should be obvious, there are many different scenarios here that
seem to call for different kinds of solutions. seem to call for different kinds of solutions.
For example, the rate-limiting could be performed based on: For example, the rate-limiting could be performed based on:
1. multicast address, or the RP where the multicast address maps to 1. multicast address, or the RP where the multicast address maps to
2. source address 2. source address
3. the (source address, multicast address) -pair (or the RP which 3. the (source address, multicast address) pair (or the RP that maps
maps to the multicast address) to the multicast address)
4. data rate in case of rate limiting the source 4. data rate, in case of rate-limiting the source
5. everything (multicast groups and sources would not be 5. everything (multicast groups and sources would not be
distinguished at all) distinguished at all)
In the above, we make an assumption that rate-limiting would be In the above, we assume that rate-limiting would be performed per-
performed per-interface (on DRs) if a more fine-grained filter is not interface (on DRs) if a more fine-grained filter is not being used.
being used.
It should be noted that some of the rate limiting functions can be It should be noted that some of the rate-limiting functions can be
used as a tool for DoS against legimate multicast users. Therefore used as a tool for DoS against legitimate multicast users.
several parameters for rate limiting should be used to prevent such Therefore, several parameters for rate-limiting should be used to
operation. prevent such operation.
5.3 Specific Rate-limiting Suggestions 5.3. Specific Rate-limiting Suggestions
These suggestions take two forms: limiters designed to be run on all These suggestions take two forms: limiters designed to be run on all
the edge networks, preventing or limiting an attack in the first the edge networks, preventing or limiting an attack in the first
place, and the limiters designed to be run at the border of PIM place, and the limiters designed to be run at the border of PIM
domains or at the RPs, which should provide protection in case domains or at the RPs, which should provide protection in case edge-
edge-based limiting fails or was not implemented, or when additional based limiting fails or was not implemented, or when additional
control is required. control is required.
Almost none of the suggested rate-limiters take legitimate users into Almost none of the suggested rate-limiters take legitimate users into
account. That is, for example, being able to allow some hosts on a account. That is, being able to allow some hosts on a link to
link to transmit/receive, while disallowing others, is very transmit/receive, while disallowing others, is very challenging to do
challenging to do right, because the attackers can easily circumvent right, because the attackers can easily circumvent such systems.
such systems. Therefore the intent is to limit the damage to only Therefore, the intent is to limit the damage to only one link, one
one link, one DR, or one RP -- and avoid the more global effects on DR, or one RP -- and avoid the more global effects on the Internet
the Internet multicast architecture. multicast architecture.
It could also be possible to perform white-listing of groups, Also, it is possible to perform white-listing of groups, sources, or
sources, or (S,G) -pairs from the rate-limiters -- so that packets (S,G) pairs from the rate-limiters so that packets related to these
related to these would not be counted towards the limits (e.g., the are not counted towards the limits. This is useful for handling an
case of an aggressive but legitimate source, while not not desiring aggressive but legitimate source without modifying the limiting
to modify the limiting parameters for all the traffic. parameters for all the traffic, for example.
5.3.1 Group Management Protocol Rate-limiter 5.3.1. Group Management Protocol Rate-Limiter
A token-bucket -based rate-limiter to all Group Management Protocols A Group Management Protocol rate-limiter is a token-bucket-based
(IGMP, MLD), which would limit the average rate of accepted groups or rate-limiter to all Group Management Protocols (IGMP, MLD) that would
sources, on the specific interface, with a bucket of depth of limit the average rate of accepted groups or sources on the specific
G_DEPTH, refilling at G_RATE tokens per second. Example values could interface, with a bucket of depth of G_DEPTH, refilling at G_RATE
be G_RATE=1 and G_DEPTH=20. Note that e.g., an IGMPv3 join with two tokens per second. Example values could be G_RATE=1 and G_DEPTH=20.
included sources for one group would count as two groups/sources. 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 This would be the first-order defense against state-creation attacks
from the hosts. However, as it cannot be guaranteed that all the from the hosts. However, as it cannot be guaranteed that all the
routers would implement something like this, other kinds of routers would implement something like this, other kinds of
protections would be useful as well. This harms legitimate receivers protections would be useful as well. This harms legitimate receivers
on the same link as an attacker as well. on the same link as an attacker.
5.3.2 Source Transmission Rate-limiter 5.3.2. Source Transmission Rate-Limiter
A token-bucket -based rate-limiter which would limit the multicast A source transmission rate-limiter is a token-bucket-based rate-
data transmission (excluding link-local groups) on a specific limiter that would limit the multicast data transmission (excluding
interface with a bucket of depth of GSEND_DEPTH, refilling at link-local groups) on a specific interface with a bucket of depth of
GSEND_RATE tokens per second. Example values could be GSEND_RATE=10 GSEND_DEPTH, refilling at GSEND_RATE tokens per second. Example
and GSEND_DEPTH=20. values could be GSEND_RATE=10 and GSEND_DEPTH=20.
This would be the first-order defense against data flooding attacks. This would be the first-order defense against data flooding attacks.
However, as it cannot be guaranteed that all routers would implement 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 something like this, and as the RP (if SSM is not used) could be
loaded from multiple senders, additional protections are needed as loaded from multiple senders, additional protections are needed as
well. This harms legitimate senders on the same link as an attacker well. This harms legitimate senders on the same link as an attacker.
as well. This does not protect from a host sending a lot of traffic This does not prevent a host from sending a lot of traffic to the
to the same group; this only harms the DR and the RP of the group, same group -- an action that would harm only the DR and the RP of the
and is similar to unicast DDoS attacks against one source, and is not group, is similar to unicast DoS attacks against one source, and is
considered critical for the overall security. not considered critical to the overall security.
5.3.3 PIM Signalling Rate-limiter
A token-bucket -based rate-limiter which would limit the all 5.3.3. PIM Signalling Rate-Limiter
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 second-order defense againt PIM state attacks when GMP A PIM signalling rate-limiter is a token-bucket-based rate-limiter
rate-limiters haven't been implemented or haven't been effective. 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 limiter might not need to be active by default, as long as the This would be second-order defense against PIM state attacks when
values are configurable. The main applicability for this filter IGMP/MLD rate-limiters haven't been implemented or haven't been
would be applying it at a border of PIM domain in case PIM state effective. This limiter might not need to be active by default, as
attacks are detected. This harms legitimate receivers as well. 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 5.3.4. Unicast-Decapsulation Rate-Limiter
A simple decapsulation rate-limiter protecting the CPU usage in the A unicast-decapsulation rate-limiter is a simple decapsulation rate-
router, limiting X pps (the need and limit depends on the router limiter that would protect the CPU usage in the router by limiting
architecture), disregarding the source of the registers. This could the packets per second (depending on the router architecture) and
also be an additional check to be used before decapsulation and disregarding the source of the registers. This could also be an
checking the group to throttle the worst of the decapsulation CPU additional check to be used before decapsulation and checking the
consumption. This limit should have to be quite high, and would group to throttle the worst of the decapsulation CPU consumption.
hamper the existing legimate sessions as well. This limit should have to be quite high, and would hamper the
existing legitimate sessions as well.
5.3.5 PIM Register Rate-limiter 5.3.5. PIM Register Rate-Limiter
A token-bucket -based rate-limiter for register decapsulation of PIM A PIM Register rate-limiter is a token-bucket-based rate-limiter that
Register messages, with a bucket of depth of REG_DEPTH, refilling at would limit register decapsulation of PIM Register messages with a
REG_RATE tokens per second. If the router has restarted recently, a bucket of depth of REG_DEPTH, refilling at REG_RATE tokens per
larger initial bucket should be used. Example values could be second. If the router has restarted recently, a larger initial
REG_RATE=1 and REG_DEPTH=10 (or REG_DEPTH=500 after restart). 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 This would be second-order defense against data flooding: if the DRs
would not implement appropriate limiters, or if the total number of would not implement appropriate limiters, or if the total number of
flooded groups rises too high, the RP should be able to limit the flooded groups rises too high, the RP should be able to limit the
rate with which new groups are created. This does not harm rate with which new groups are created. This does not harm
legitimate senders, as long as their group has already been created. legitimate senders, as long as their groups have already been
created.
5.3.6 MSDP Source-Active Rate-limiter 5.3.6. MSDP Source-Active Rate-Limiter
A token-bucket -based, source-based rate-limiter, limiting new groups A MSDP source-active rate-limiter is a token-bucket-based, source-
per source with a bucket of depth of SAG_DEPTH, refilling at based rate-limiter, that would limit new groups per source with a
SAG_RATE tokens per second. Example values could be SAG_RATE=1 and bucket of depth of SAG_DEPTH, refilling at SAG_RATE tokens per
SAG_DEPTH=10. second. Example values could be SAG_RATE=1 and SAG_DEPTH=10.
This would be a second-order defense, both at the MSDP SA sending and This would be second-order defense, at both the MSDP SA sending and
receiving sites, against data flooding and MSDP vulnerabilities in receiving sites, against data flooding and MSDP vulnerabilities in
particular. The specific threat being addressed here is a source (or particular. The specific threat being addressed here is a source (or
multiple different sources) trying to "probe" (e.g., virus or worm) multiple different sources) trying to "probe" (e.g., virus or worm)
different multicast addresses. [16] discusses different MSDP attack different multicast addresses. [16] discusses different MSDP attack
prevention mechanisms at length. prevention mechanisms at length.
5.4 Passive Mode for PIM 5.4. Passive Mode for PIM
As described in the last paragraph of section 3, hosts are also able As described in the last paragraph of Section 3, hosts are also able
to form PIM adjacencies and send disrupting traffic unless great care to form PIM adjacencies and send disrupting traffic unless great care
is observed at the routers. This stems from the fact that most is observed at the routers. This stems from the fact that most
implementations require that stub LANs with only one PIM router must implementations require that stub LANs with only one PIM router must
also have PIM enabled (to enable PIM processing of the sourced data also have PIM enabled (to enable PIM processing of the sourced data,
etc.) Such stub networks however do not require to actually run the etc.) Such stub networks however do not require to actually run the
PIM protocol on the link. Therefore such implementations should PIM protocol on the link. Therefore, such implementations should
provide an option to specify that the interface is "passive" with provide an option to specify that the interface is "passive" with
regard to PIM: no PIM packets are sent or processed (if received), regard to PIM: no PIM packets are sent or processed (if received),
but hosts can still send and receive multicast on that interface. but hosts can still send and receive multicast on that interface.
6. Security Considerations 6. Security Considerations
This memo analyzes the security of PIM routing infrastructures in This memo analyzes the security of PIM routing infrastructures in
some detail, and proposes enhancements to mitigate the observed some detail and proposes enhancements to mitigate the observed
threats. threats.
This document does not discuss adding (strong) authentication to the This document does not discuss adding (strong) authentication to the
multicast protocols. PIM-SM specification [1] describes the multicast protocols. The PIM-SM specification [1] describes the
application of IPsec for routing authentication; it is worth noting application of IPsec for routing authentication; note that being able
that being able to authenticate the register messages and being able to authenticate the register messages and to prevent illegitimate
to prevent illegitimate users from establishing PIM adjacencies would users from establishing PIM adjacencies seem to be the two most
seem to be the two most important goals. IGMPv3 specification [11] important goals. The IGMPv3 specification [11] describes the use of
describes the use of IPsec for group management (similar applies to IPsec for group management (IPsec for MLDv2 may be applied
MLDv2 as well), which is out of scope for this memo; however, it is similarly), which is out of scope for this memo. However, note that
worth noting that being able to control the group memberships might being able to control the group memberships might reduce the
reduce the receiver-based attacks. receiver-based attacks.
However, one should keep in mind two caveats: authentication alone However, one should keep in mind two caveats: authentication alone
might not be sufficient, especially if the user or the host stack might not be sufficient, especially if the user or the host stack
(consider a worm propagation scenario) cannot be expected to "behave (consider a worm propagation scenario) cannot be expected to "behave
well"; and that adding such authentication likely provides new attack well"; and adding such authentication likely provides new attack
vectors, e.g., in the form of a CPU DoS attack with excessive amount vectors, e.g., in the form of a CPU DoS attack with an excessive
of cryptographic operations. amount of cryptographic operations.
7. IANA Considerations
This memo is for informational purposes and does not introduce new
namespaces for the IANA to manage.
[[ Note to the RFC-editor: please remove this section upon
publication ]]
8. Acknowledgements 7. Acknowledgements
Kamil Sarac discussed "return routability" issues at length. Stig Kamil Sarac discussed "return routability" issues at length. Stig
Venaas provided feedback to improve the document quality. Bill Venaas and Bharat Joshi provided feedback to improve the document
Fenner and Russ Housley provided useful comments during the IESG quality. Bill Fenner and Russ Housley provided useful comments
evaluation. during the IESG evaluation.
9. References 8. References
9.1 Normative References 8.1. Normative References
[1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
Independent Multicast - Sparse Mode PIM-SM): Protocol "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Specification (Revised)", draft-ietf-pim-sm-v2-new-10 (work in Protocol Specification (Revised)", RFC 4601, August 2006.
progress), July 2004.
[2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol [2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol
(MSDP)", RFC 3618, October 2003. (MSDP)", RFC 3618, October 2003.
[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", [3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
draft-ietf-ssm-arch-06 (work in progress), September 2004. RFC 4607, August 2006.
[4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) [4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
Address in an IPv6 Multicast Address", (RP) Address in an IPv6 Multicast Address", RFC 3956,
draft-ietf-mboned-embeddedrp-07 (work in progress), July 2004. November 2004.
[5] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing [5] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Protocols", draft-ietf-rpsec-routing-threats-06 (work in Routing Protocols", RFC 4593, July 2006.
progress), April 2004.
9.2 Informative References 8.2. Informative References
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC [6] Deering, S., "Host extensions for IP multicasting", STD 5,
1112, August 1989. RFC 1112, August 1989.
[7] Bhattacharyya, S., "An Overview of Source-Specific Multicast [7] Bhattacharyya, S., "An Overview of Source-Specific Multicast
(SSM)", RFC 3569, July 2003. (SSM)", RFC 3569, July 2003.
[8] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface [8] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678, January Extensions for Multicast Source Filters", RFC 3678,
2004. January 2004.
[9] Hardjono, T. and B. Weis, "The Multicast Group Security [9] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
[10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast [10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast
Listener Discovery", draft-daley-magma-smld-prob-00 (work in Listener Discovery", Work in Progress, July 2004.
progress), July 2004.
[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. [11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[13] Ferguson, P. and D. Senie, "Network Ingress Filtering: [13] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[15] Handley, M., Kouvelas, I., Speakman, T. and L. Vicisano, [15] Handley, M., "Bi-directional Protocol Independent Multicast
"Bi-directional Protocol Independent Multicast (BIDIR-PIM)", (BIDIR-PIM)", Work in Progress, October 2005.
draft-ietf-pim-bidir-07 (work in progress), July 2004.
[16] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and [16] Rajvaidya, P., Ramachandran, K., and K. Almeroth, "Detection
Deflection of DoS Attacks Against the Multicast Source and Deflection of DoS Attacks Against the Multicast Source
Discovery Protocol", UCSB Technical Report, May 2003. Discovery Protocol", UCSB Technical Report, May 2003.
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
Appendix A. RPF Considers Interface, Not Neighbor Appendix A. RPF Considers Interface, Not Neighbor
In most current implementations, the RPF check considers only the In most current implementations, the RPF check considers only the
incoming interface, and not the upstream neighbor (RPF neighbor). incoming interface, and not the upstream neighbor (RPF neighbor).
This can result in accepting packets from the "wrong" 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 (the neighbor is "wrong" since, while the RPF check succeeds and the
packet is forwarded, the unicast policy would not have forwarded the packet is forwarded, the unicast policy would not have forwarded the
packet). packet).
This is a problem in the media where more than two routers can This is a problem in the media where more than two routers can
connect to, in particular, Ethernet-based Internet Exchanges. connect to, in particular, Ethernet-based Internet Exchanges.
Therefore any neighbor on such a link could inject any PIM signalling Therefore, any neighbor on such a link could inject any PIM
as long as a route matching the address used in the signalling is signalling as long as a route matching the address used in the
going through the interface. signalling is going through the interface.
However, one should note that for PIM signalling to be accepted, a Note that for PIM signalling to be accepted, a PIM adjacency must
PIM adjancency must have been established. However, typically, this have been established. However, typically, this does not help much
does not help much against willful attackers, as typically PIM against willful attackers, as PIM adjacencies are usually formed with
adjacencies are formed with anyone on the link. Still, the anyone on the link. Still, the requirement is that the neighbor has
requirement is that the neighbor who has enabled PIM in the concerned enabled PIM in the concerned interface. That is, in most cases, the
interface. I.e., in most cases, the threat is limited to attackers threat is limited to attackers within the operators in the exchange,
within the operators in the exchange, not third parties. On the not third parties. On the other hand, data plane forwarding has no
other hand, data plane forwarding has no such checks -- and having such checks -- and having such checks would require that one look at
such checks would require one to look at the link-layer addresses the link-layer addresses used. That is, this checking is not as
used; that is, this checking is not as feasible as one might hope. feasible as one might hope.
Appendix B. Return Routability Extensions Appendix B. Return Routability Extensions
The multicast state information is built from the receiver side and 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 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 or the source for the group is non-existent, the state can't be
pruned by the DR without return routability extensions to provide pruned by the DR without return routability extensions to provide
such information. There might be also need to remove the state in 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. some cases when there is no multicast traffic sent to that group.
This section discusses about the alternative ways to remove the This section discusses the alternative ways to remove the unused
unused state information in the routers, so that it can't be used in state information in the routers, so that it can't be used in state-
state based DoS attacks. Note that rate limiting PIM Joins gives based DoS attacks. Note that rate-limiting PIM Joins gives some
some protection against the state attacks. protection against the state attacks.
B.1 Sending PIM-Prune Messages Down the Tree B.1. Sending PIM-Prune Messages Down the Tree
When a router discovers the non-existence of the RP or the source, it 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 can create a PIM-Prune message and send it back to the join
originator. However, since it does not know the unicast IP address originator. However, since it does not know the unicast IP address
of join originator DR, it cannot directly unicast it to that router. of join originator DR, it cannot directly unicast it to that router.
A possible alternative is to use a link-local multicast group address A possible alternative is to use a link-local multicast group address
(e.g., all-pim routers local multicast address) to pass this (e.g., all-pim routers local multicast address) to pass this
information back toward the joining DR. Since the routers from this information back toward the joining DR. Since the routers from this
current router all the way back to the joining DR has forwarding 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 state entry for the group, they can use this state information to see
how to forward the PIM-Prune message back. how to forward the PIM-Prune message back.
Each on-tree router, in addition to forwarding the PIM-Prune message, Each on-tree router, in addition to forwarding the PIM-Prune message,
can also prune the state from their state tables. This way, the can also prune the state from its state tables. This way, the PIM-
PIM-Prune message will go back to the DR by following the so far Prune message will go back to the DR by following the multicast
created multicast forwarding state information. In addition, if we forwarding state information created so far. In addition, if we use
use some sort of RPF checks during this process, we can also make it some sort of RPF checks during this process, we can also make it more
more difficult to inject such PIM-Prune messages maliciously. difficult to inject such PIM-Prune messages maliciously.
A potential abuse scenario may involve an attacker having access to a A potential abuse scenario may involve an attacker that has access to
router on the direct path to send such PIM-Prune messages down the a router on the direct path and can send such PIM-Prune messages down
tree branch so as to prune the branch from the tree. But such an the tree branch so as to prune the branch from the tree. But such an
attacker can currently achieve the same effect by sending PIM-Prune 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 message toward the source from the same point on the tree. So, the
proposed mechanism does not really aggravate the situation. proposed mechanism does not really aggravate the situation.
One visible overhead in this new scenario might be that someone can One visible overhead in this new scenario might be that someone can
send bogus join messages to create redundant PIM-Join and PIM-Prune send bogus join messages to create redundant PIM-Join and PIM-Prune
messages in the network. messages in the network.
B.2 Analysing Multicast Group Traffic at DR B.2. Analyzing Multicast Group Traffic at DR
Another possible way to remove the unused state information would be Another possible way to remove the unused state information would be
to analyse individual group traffic at the DR and if there is no to analyze individual group traffic at the DR and if there is no
multicast traffic for a certain group within a certain time limit, multicast traffic for a certain group within a certain time limit,
the state should be removed. In here, if the receiver is malicious 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 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 and create states on routers for each of these
different groups until the DR decides that the groups are inactive different groups until the DR decides that the groups are inactive
and initiates the prune process. In addition, during the prune and initiates the prune process. In addition, during the prune
process, the routers will again process all these prune messages and process, the routers will again process all these prune messages and
therefore will be spending time. therefore will be spending time.
B.3 Comparison of the Above Approaches B.3. Comparison of the Above Approaches
Both of these solutions have the same problem of renewing the Both of these solutions have the same problem of renewing the
multicast state information. DR shouldn't permanently block the multicast state information. The DR shouldn't permanently block the
state building for that group, but to restrict the PIM Joins if it state building for that group, but should restrict the PIM Joins if
notices that the receiver is abusing the system. One additional 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 option is to block the PIM Joins to the non-existent source/RP for a
certain time. certain time.
In the first approach (sending PIM-Prunes down the tree), part of the 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 goal was to prune the states in the routers much sooner than in the
second approach (e.g. goal is to make sure that the routers will not second approach. (That is, the goal is to make sure that the routers
be keeping unnecessary states for long time). will not be keeping unnecessary states for long time.)
The second approach works also for DoS attacks related to the The second approach works also for DoS attacks related to the
existing source/RP addresses and could be more quickly implemented existing source/RP addresses, could be more quickly implemented and
and deployed in the network and does not have any relationship deployed in the network, and does not have any relationship with the
related to the other deployments (no need to change all PIM routers). other deployments (no need to change all PIM routers).
Intellectual Property Statement 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
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 21, line 29 skipping to change at page 23, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 156 change blocks. 
457 lines changed or deleted 429 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/