GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4609

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4609.txt · Last modified: 2006/07/27 23:52 (external edit)