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.
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.
5.3. Specific Rate-limiting Suggestions
These suggestions take two forms: limiters designed to be run on all
the edge networks, preventing or limiting an attack in the first
place, and the limiters designed to be run at the border of PIM
domains or at the RPs, which should provide protection in case edge-
based limiting fails or was not implemented, or when additional
control is required.
Almost none of the suggested rate-limiters take legitimate users into
account. That is, being able to allow some hosts on a link to
transmit/receive, while disallowing others, is very challenging to do
right, because the attackers can easily circumvent such systems.
Therefore, the intent is to limit the damage to only one link, one
DR, or one RP -- and avoid the more global effects on the Internet
multicast architecture.
Also, it is possible to perform white-listing of groups, sources, or
(S,G) pairs from the rate-limiters so that packets related to these
are not counted towards the limits. This is useful for handling an
aggressive but legitimate source without modifying the limiting
parameters for all the traffic, for example.
5.3.1. Group Management Protocol Rate-Limiter
A Group Management Protocol rate-limiter is a token-bucket-based
rate-limiter to all Group Management Protocols (IGMP, MLD) that would
limit the average rate of accepted groups or sources on the specific
interface, with a bucket of depth of G_DEPTH, refilling at G_RATE
tokens per second. Example values could be G_RATE=1 and G_DEPTH=20.
Note that, e.g., an IGMPv3 join with two included sources for one
group would count as two groups/sources.
This would be the first-order defense against state-creation attacks
from the hosts. However, as it cannot be guaranteed that all the
routers would implement something like this, other kinds of
protections would be useful as well. This harms legitimate receivers
on the same link as an attacker.
5.3.2. Source Transmission Rate-Limiter
A source transmission rate-limiter is a token-bucket-based rate-
limiter that would limit the multicast data transmission (excluding
link-local groups) on a specific interface with a bucket of depth of
GSEND_DEPTH, refilling at GSEND_RATE tokens per second. Example
values could be GSEND_RATE=10 and GSEND_DEPTH=20.
This would be the first-order defense against data flooding attacks.
However, as it cannot be guaranteed that all routers would implement
something like this, and as the RP (if SSM is not used) could be
loaded from multiple senders, additional protections are needed as
well. This harms legitimate senders on the same link as an attacker.
This does not prevent a host from sending a lot of traffic to the
same group -- an action that would harm only the DR and the RP of the
group, is similar to unicast DoS attacks against one source, and is
not considered critical to the overall security.
5.3.3. PIM Signalling Rate-Limiter
A PIM signalling rate-limiter is a token-bucket-based rate-limiter
that would limit all multicast PIM messaging, either through a
specific interface or globally on the router, with a bucket of depth
of PIM_DEPTH, refilling at PIM_RATE tokens per second. Example
values could be PIM_RATE=1000 and PIM_DEPTH=10000.
This would be second-order defense against PIM state attacks when
IGMP/MLD rate-limiters haven’t been implemented or haven’t been
effective. This limiter might not need to be active by default, as
long as the values are configurable. The main applicability for this
filter would be at a border of PIM domain in case PIM state attacks
are detected. This harms legitimate receivers as well.
5.3.4. Unicast-Decapsulation Rate-Limiter
A unicast-decapsulation rate-limiter is a simple decapsulation rate-
limiter that would protect the CPU usage in the router by limiting
the packets per second (depending on the router architecture) and
disregarding the source of the registers. This could also be an
additional check to be used before decapsulation and checking the
group to throttle the worst of the decapsulation CPU consumption.
This limit should have to be quite high, and would hamper the
existing legitimate sessions as well.
5.3.5. PIM Register Rate-Limiter
A PIM Register rate-limiter is a token-bucket-based rate-limiter that
would limit register decapsulation of PIM Register messages with a
bucket of depth of REG_DEPTH, refilling at REG_RATE tokens per
second. If the router has restarted recently, a larger initial
bucket should be used. Example values could be REG_RATE=1 and
REG_DEPTH=10 (or REG_DEPTH=500 after restart).
This would be second-order defense against data flooding: if the DRs
would not implement appropriate limiters, or if the total number of
flooded groups rises too high, the RP should be able to limit the
rate with which new groups are created. This does not harm
legitimate senders, as long as their groups have already been
created.
5.3.6. MSDP Source-Active Rate-Limiter
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.
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.
[9] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast
Listener Discovery", Work in Progress, July 2004.
[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[13] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[15] Handley, M., "Bi-directional Protocol Independent Multicast
(BIDIR-PIM)", Work in Progress, October 2005.
[16] Rajvaidya, P., Ramachandran, K., and K. Almeroth, "Detection
and Deflection of DoS Attacks Against the Multicast Source
Discovery Protocol", UCSB Technical Report, May 2003.
Appendix A. RPF Considers Interface, Not Neighbor
In most current implementations, the RPF check considers only the
incoming interface, and not the upstream neighbor (RPF neighbor).
This can result in accepting packets from the "wrong" RPF neighbor
(the neighbor is "wrong" since, while the RPF check succeeds and the
packet is forwarded, the unicast policy would not have forwarded the
packet).
This is a problem 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.
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.
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).
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
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).