draft-ietf-mboned-mroutesec-01.txt   draft-ietf-mboned-mroutesec-02.txt 
Internet Engineering Task Force P. Savola MBONED WG P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Expires: November 17, 2004 R. Lehtonen Expires: December 23, 2004 R. Lehtonen
TeliaSonera TeliaSonera
D. Meyer D. Meyer
May 19, 2004 June 24, 2004
PIM-SM Multicast Routing Security Issues and Enhancements PIM-SM Multicast Routing Security Issues and Enhancements
draft-ietf-mboned-mroutesec-01.txt draft-ietf-mboned-mroutesec-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 17, 2004. This Internet-Draft will expire on December 23, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5.1 Remote Routability Signalling . . . . . . . . . . . . . . 11 5.1 Remote Routability Signalling . . . . . . . . . . . . . . 11
5.2 Rate-limiting Possibilities . . . . . . . . . . . . . . . 12 5.2 Rate-limiting Possibilities . . . . . . . . . . . . . . . 12
5.3 Specific Rate-limiting Suggestions . . . . . . . . . . . . 13 5.3 Specific Rate-limiting Suggestions . . . . . . . . . . . . 13
5.3.1 Group Management Protocol Rate-limiter . . . . . . . . 13 5.3.1 Group Management Protocol Rate-limiter . . . . . . . . 13
5.3.2 Source Transmission Rate-limiter . . . . . . . . . . . 14 5.3.2 Source Transmission Rate-limiter . . . . . . . . . . . 14
5.3.3 PIM Signalling Rate-limiter . . . . . . . . . . . . . 14 5.3.3 PIM Signalling Rate-limiter . . . . . . . . . . . . . 14
5.3.4 Unicast-decapsulation Rate-limiter . . . . . . . . . . 14 5.3.4 Unicast-decapsulation Rate-limiter . . . . . . . . . . 14
5.3.5 PIM Register Rate-limiter . . . . . . . . . . . . . . 15 5.3.5 PIM Register Rate-limiter . . . . . . . . . . . . . . 15
5.3.6 MSDP Source-Active Rate-limiter . . . . . . . . . . . 15 5.3.6 MSDP Source-Active Rate-limiter . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
9.2 Informative References . . . . . . . . . . . . . . . . . . . 16 9.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. RPF Considers Interface, Not Neighbor . . . . . . . . . . . . 17 A. RPF Considers Interface, Not Neighbor . . . . . . . . . . . . 18
B. Return Routability Extensions . . . . . . . . . . . . . . . . 18 B. Return Routability Extensions . . . . . . . . . . . . . . . . 18
B.1 Sending PIM-Prune Messages Down the Tree . . . . . . . . . 18 B.1 Sending PIM-Prune Messages Down the Tree . . . . . . . . . 18
B.2 Analysing Multicast Group Traffic at DR . . . . . . . . . 19 B.2 Analysing Multicast Group Traffic at DR . . . . . . . . . 19
B.3 Comparison of the Above Approaches . . . . . . . . . . . . 19 B.3 Comparison of the Above Approaches . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
This memo describes security threats to the Protocol Independent This memo 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 (whether Only attacks which have an effect on the multicast routing (whether
intra- or inter-domain) are considered. For example, attacks where intra- or inter-domain) are considered. For example, attacks where
the hosts are specifically targeting the Designated Router (DR) or the hosts are specifically targeting the Designated Router (DR) or
other routers on the link, or where hosts are disrupting other hosts other routers on the link, or where hosts are disrupting other hosts
on the same link are out of scope. Similarly, ensuring on the same link are out of scope. Similarly, ensuring
confidentiality, authentication and integrity of multicast groups and confidentiality, authentication and integrity of multicast groups and
traffic is out of the scope [9]. traffic is out of scope; instead, see [9].
PIM builds on a model where Reverse Path Forwarding (RPF) check is PIM builds on a model where Reverse Path Forwarding (RPF) check is
(among other things) used to ensure loop-free properties of the (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
effect of using forged source addresses, which is often used as a effect of using forged source addresses, which is often used as a
component in unicast-based attacks. However, a host can still spoof component in unicast-based attacks. However, a host can still spoof
an address within the same subnet, or spoof the source of a an address within the same subnet, or spoof the source of a
unicast-encapsulated PIM Register messages, which a host may send on unicast-encapsulated PIM Register messages, which a host may send on
its own. its own.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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 G. address 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 RP for a group, and MSDP mapping mechanism is used to find the Rendezvous Point (RP) for
is not used. a 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, Group) (or (S,G)) joins, (in all models). (Source, 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, and are not a significant source of are expected to behave well, and are not a significant source of
abuse. While this assumption is not entirely correct, it simplifies abuse. While this assumption is not entirely correct, it simplifies
the analysis of threat models. The threats caused by misbehaving the analysis of threat models. The threats caused by misbehaving
multicast routers (including fake multicast routers) are not multicast routers (including fake multicast routers) are not
considered in this memo. Also RP discovery mechanisms like BSR and considered in this memo. Also RP discovery mechanisms like Bootstrap
Auto-RP are out of the scope. In general, the threat model would Router (BSR) and Auto-RP are out of the scope. In general, the
then be similar to [5]. threat model would then be similar to [5].
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 also be abused in the cases where RPF checks are not PIM-SM can be abused in the cases where RPF checks are not
applicable, in particular, in the stub LAN networks -- as spoofing applicable, in particular, in the stub LAN networks -- as spoofing
the on-link traffic is very simple. For example, a host could get 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 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 functions. A host can also easily make PIM routers on the link stop
forwarding multicast by sending PIM Assert messages. This implies forwarding multicast by sending PIM Assert messages. This implies
that a willful attacker will be able to circumvent many of the that a willful attacker will be able to circumvent many of the
potential rate-limiting functions performed at the DR (as one can potential rate-limiting functions performed at the DR (as one can
always send the messages yourself). The PIM-SM specification, always send the messages yourself). The PIM-SM specification,
however, states that these messages should only be accepted from however, states that these messages should only be accepted from
known PIM neighbors; if this is performed, the hosts would first have known PIM neighbors; if this is performed, the hosts would first have
skipping to change at page 5, line 18 skipping to change at page 5, line 18
a high probability of success in forming a protocol adjacency. These a high probability of success in forming a protocol adjacency. These
are described at some length in [1], but are also considered out of are described at some length in [1], but are also considered out of
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.
One should also 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 timer
expires or the state changes at the DR.
Also, if the host uses IGMPv3 [10] or MLDv2 [11], it is able to join
multiple sources for the same group and each of these joins for the
same group generates new PIM (S,G) Joins to the DR adjacent to the
source.
3.1.1 Joins to Different Groups 3.1.1 Joins to Different Groups
Description of the threat: Join Flooding. Join Flooding occurs when Description of the threat: Join Flooding. Join Flooding occurs when
a host tries to join, once or a couple of times, to a group or a SSM a host tries to join, once or a couple of times, to a group or a SSM
channel, and the DR generates a PIM Join to the Target Router. The channel, and the DR generates a PIM Join to the Target Router. The
group/SSM channel or the Targer Router may or may not exist. group/SSM channel or the Targer Router may or may not exist.
Example of this is a host trying to join different, non-existent 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
sends one PIM Join message, without waiting for any acknowledgement;
the next message is only sent after the PIM Join timer expires or the
state changes at the DR.
This kind of joining causes PIM state to be created, but this state 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 IGMP/ default time that the state is active at DR in the absence of IGMP/
MLD Reports/Leaves). It should also be noted that the host can join MLD Reports/Leaves). It should also be noted that the host can join
a number of different SSM channels with only one IGMPv3/MLDv2 Report a number of different ASM groups or SSM channels with only one IGMPv3
as the protocol allows to include multiple sources in the same [10] or MLDv2 [11] Report as the protocol allows to include multiple
message. sources 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 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/ 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. MLD Reports to these groups to make the state attack more long-lived.
This results in: This results in:
o ASM: a (*,G) join is sent to an intra-domain RP, causing state on o ASM: a (*,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: a (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 does not exist, the
skipping to change at page 6, line 19 skipping to change at page 6, line 14
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: a (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 does not exist, the
join goes to the closest router on the path to S as possible. join goes to the closest router on the path to S as possible.
o Embedded-RP: a (*,G) join is sent towards an inter/intra-domain RP o Embedded-RP: a (*,G) join is sent towards an inter/intra-domain RP
embedded in the group G, causing state on that path. If the 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 as does not exist, the join goes to the closest router to the RP
possible. Similarly, an explicit (S,G) join goes to the DR, as address as possible. Similarly, an explicit (S,G) join goes to
with SSM above. the DR, as 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-domain state creation as well. inter-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. 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
skipping to change at page 6, line 52 skipping to change at page 6, line 47
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
Description of the threat: Data Flooding. Data Flooding occurs when Description of the threat: Data Flooding. Data Flooding occurs when
a host sends data packets to a multicast group or SSM channel for a host sends data packets to a multicast group or SSM channel for
which there are no real subscribers. which there are no real subscribers.
Note that since unicast-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 [12] has been deployed [13]. filtering [12] has been deployed [13]. 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 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 or different groups. This results in:
o ASM: the DR unicast-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 continues to get the data. A notification
about the active source is sent (unless the group or source is about the active source is sent (unless the group or source is
configured to be local) inter-domain with MSDP and propagated configured to be local) inter-domain with MSDP and propagated
globally. 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
skipping to change at page 8, line 36 skipping to change at page 8, line 34
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 RP(s)
send the traffic over the shared tree towards receivers (routers with send 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 MSF API [8]. Typically this is not used or
supported by the applications using these protocols. 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
unicast-encapsulated in register packets to the RP -- if the RP drops register-encapsulated in register packets to the RP -- if the RP
the packet based on access-list, rate-limiter or something else, it drops the packet based on access-list, rate-limiter or something
doesn't get injected to an existing group. else, it doesn't get injected to an existing group.
With ASM this "source control" is distributed across all the PIM 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 single RP per group.
As a result, for this attack to succeed, the RP must decapsulate the As a result, for this attack to succeed, the RP must decapsulate the
packets, causing the propagation of data and the integrity violation. packets, causing the propagation of data and the integrity violation.
3.3 Aggravating Factors to the Threats 3.3 Aggravating Factors to the Threats
skipping to change at page 10, line 23 skipping to change at page 10, line 21
register attack. In this case, the host can mount the attack without register attack. In this case, the host can mount the attack without
implementing any of the PIM register machinery. 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") which 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 this is not reasonable, the DRs should rate-limit the register
unicast-encapsulation (note that the hosts can circumvent this) encapsulation (note that the hosts can circumvent this) and (more
and (more importantly) the RPs should rate-limit the importantly) the RPs should rate-limit the register decapsulation
unicast-decapsulation especially from different sources, or MSDP especially from different sources, or MSDP must rate-limit the
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 possibilities how exactly this should be considered
(i.e., which variables to take into the consideration). (i.e., which variables to take into the consideration).
o DRs could rate-limit unicast-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 unicast-encapsulation themselves if so inclined. by performing the register encapsulation themselves if so
inclined.
o RPs could rate-limit unicast-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 e.g. 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 which 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 unicast-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
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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 which fulfills the RPF checks of the DR) or not.
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 unicast-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 which
skipping to change at page 13, line 21 skipping to change at page 13, line 21
In the above, we make an assumption that rate-limiting would be In the above, we make an assumption that rate-limiting would be
performed per-interface (on DRs) if a more fine-grained filter is not performed per-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 legimate multicast users. Therefore
several parameters for rate limiting should be used to prevent such several parameters for rate limiting should be used to prevent such
operation. operation.
The next revisions of this document (or separated in other documents,
if appropriate) will include more explicit discussion of the best
ways to perform rate-limiting, especially considering the effects on
the legimate traffic.
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-based limiting fails or was not implemented, or when additional edge-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
skipping to change at page 14, line 5 skipping to change at page 13, line 48
It could also be possible to perform white-listing of groups, It could also be possible to perform white-listing of groups,
sources, or (S,G) -pairs from the rate-limiters -- so that packets sources, or (S,G) -pairs from the rate-limiters -- so that packets
related to these would not be counted towards the limits (e.g., the related to these would not be counted towards the limits (e.g., the
case of an aggressive but legitimate source, while not not desiring case of an aggressive but legitimate source, while not not desiring
to modify the limiting parameters for all the traffic. to modify the limiting parameters for all the traffic.
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 token-bucket -based rate-limiter to all Group Management Protocols
(IGMP, MLD), which would limit the average rate of accepted groups or (IGMP, MLD), which would limit the average rate of accepted groups or
sources, on the specific interface, to G_MAX per second, with a sources, on the specific interface, with a bucket of depth of
bucket of G_LONG. Example values could be G_MAX=1 and G_LONG=20. G_DEPTH, refilling at G_RATE tokens per second. Example values could
Note that e.g., an IGMPv3 join with two included sources for one be G_RATE=1 and G_DEPTH=20. Note that e.g., an IGMPv3 join with two
group would count as two groups/sources. 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 as well.
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 token-bucket -based rate-limiter which would limit the multicast
data transmission (excluding link-local groups) on a specific data transmission (excluding link-local groups) on a specific
interface to GSEND_MAX groups per second, with a bucket of interface with a bucket of depth of GSEND_DEPTH, refilling at
GSEND_LONG. Example values could be GSEND_MAX=10 and GSEND_LONG=20. 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. 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 as well. This does not protect from a host sending a lot of traffic
to the same group; this only harms the DR and the RP of the group, to the same group; this only harms the DR and the RP of the group,
and is similar to unicast DDoS attacks against one source, and is not and is similar to unicast DDoS attacks against one source, and is not
considered critical for the overall security. considered critical for the overall security.
5.3.3 PIM Signalling Rate-limiter 5.3.3 PIM Signalling Rate-limiter
A token-bucket -based rate-limiter which would limit the all A token-bucket -based rate-limiter which would limit the all
multicast PIM messaging, either through a specific interface or multicast PIM messaging, either through a specific interface or
globally on the router, to PIM_MAX new entries per second, with a globally on the router, with a bucket of depth of PIM_DEPTH,
bucket of PIM_LONG. Example values could be 1000 and 10000. refilling at PIM_RATE tokens per second. Example values could be
1000 and 10000.
This would second-order defense againt PIM state attacks when GMP This would second-order defense againt PIM state attacks when GMP
rate-limiters haven't been implemented or haven't been effective. 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 This limiter might not need to be active by default, as long as the
values are configurable. The main applicability for this filter values are configurable. The main applicability for this filter
would be applying it at a border of PIM domain in case PIM state would be applying it at a border of PIM domain in case PIM state
attacks are detected. This harms legitimate receivers as well. 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 simple decapsulation rate-limiter protecting the CPU usage in the
router, limiting X pps (the need and limit depends on the router router, limiting X pps (the need and limit depends on the router
architecture), disregarding the source of the registers. This could architecture), disregarding the source of the registers. This could
also be an additional check to be used before decapsulation and also be an additional check to be used before decapsulation and
checking the group to throttle the worst of the decapsulation CPU checking the group to throttle the worst of the decapsulation CPU
consumption. This limit should have to be quite high, and would consumption. This limit should have to be quite high, and would
hamper the existing legimate sessions as well. hamper the existing legimate sessions as well.
5.3.5 PIM Register Rate-limiter 5.3.5 PIM Register Rate-limiter
A token-bucket -based rate-limiter for unicast-decapsulation of PIM A token-bucket -based rate-limiter for register decapsulation of PIM
Register messages, limiting to REG_MAX new groups per second, with a Register messages, with a bucket of depth of REG_DEPTH, refilling at
bucket of REG_LONG. If the router has restarted recently, a larger REG_RATE tokens per second. If the router has restarted recently, a
initial bucket should be used. Example values could be REG_MAX=1 and larger initial bucket should be used. Example values could be
REG_LONG=10 (or REG_LONG=500 after restart). 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 group has 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 token-bucket -based, source-based rate-limiter, limiting new groups
per source to SAG_MAX per second, with a bucket of SAG_LONG. Example per source with a bucket of depth of SAG_DEPTH, refilling at
values could be SAG_MAX=1 and SAG_LONG=10. SAG_RATE tokens per 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 a second-order defense, both at 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. [14] discusses different MSDP attack different multicast addresses. [14] discusses different MSDP attack
prevention mechanisms at length. prevention mechanisms at length.
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
multicast protocols. PIM-SM specification [1] describes the
application of IPsec for routing authentication; it is worth noting
that being able to authenticate the register messages and being able
to prevent illegitimate users from establishing PIM adjacencies would
seem to be the two most important goals. IGMPv3 specification [10]
describes the use of IPsec for group management (similar applies to
MLDv2 as well), which is out of scope for this memo; however, it is
worth noting 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 that adding such authentication likely provides new attack
vectors, e.g., in the form of a CPU DoS attack with excessive amount
of cryptographic operations.
7. IANA Considerations 7. IANA Considerations
This memo is for informational purposes and does not introduce new This memo is for informational purposes and does not introduce new
namespaces for the IANA to manage. namespaces for the IANA to manage.
[[ Note to the RFC-editor: please remove this section upon
publication ]]
8. Acknowledgements 8. 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. Venaas provided feedback to improve the document quality.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol [1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol
skipping to change at page 16, line 22 skipping to change at page 16, line 38
progress), February 2004. progress), February 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-04 (work in progress), October 2003. draft-ietf-ssm-arch-04 (work in progress), October 2003.
[4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) [4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address", Address in an IPv6 Multicast Address",
draft-ietf-mboned-embeddedrp-04 (work in progress), April 2004. draft-ietf-mboned-embeddedrp-05 (work in progress), June 2004.
[5] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing [5] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing
Protocols", draft-ietf-rpsec-routing-threats-06 (work in Protocols", draft-ietf-rpsec-routing-threats-06 (work in
progress), April 2004. progress), April 2004.
9.2 Informative References 9.2 Informative References
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC [6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989. 1112, August 1989.
skipping to change at page 16, line 49 skipping to change at page 17, line 18
[9] Hardjono, T. and B. Weis, "The Multicast Security [9] Hardjono, T. and B. Weis, "The Multicast Security
Architecture", draft-ietf-msec-arch-05 (work in progress), Architecture", draft-ietf-msec-arch-05 (work in progress),
January 2004. January 2004.
[10] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. [10] 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.
[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", draft-vida-mld-v2-08 (work in progress), (MLDv2) for IPv6", RFC 3810, June 2004.
December 2003.
[12] Ferguson, P. and D. Senie, "Network Ingress Filtering: [12] 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.
[13] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [13] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", draft-savola-bcp38-multihoming-update-03 (work in Networks", BCP 84, RFC 3704, March 2004.
progress), December 2003.
[14] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and [14] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and
Deflection of DoS Attacks Against the Multicast Source Deflection of DoS Attacks Against the Multicast Source
Discovery Protocol", UCSB Technical Report, May 2003. Discovery Protocol", UCSB Technical Report, May 2003.
Authors' Addresses Authors' Addresses
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/