draft-ietf-mboned-mroutesec-00.txt   draft-ietf-mboned-mroutesec-01.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Expires: October 15, 2004 R. Lehtonen Expires: November 17, 2004 R. Lehtonen
TeliaSonera TeliaSonera
D. Meyer D. Meyer
Apr 16, 2004 May 19, 2004
PIM-SM Multicast Routing Security Issues and Enhancements PIM-SM Multicast Routing Security Issues and Enhancements
draft-ietf-mboned-mroutesec-00.txt draft-ietf-mboned-mroutesec-01.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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at
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 October 15, 2004. This Internet-Draft will expire on November 17, 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 10 skipping to change at page 2, line 11
(ASM) model, Source-Specific Multicast (SSM) model, and the ASM model (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model
enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo
also describes enhancements to the protocol operations to mitigate also describes enhancements to the protocol operations to mitigate
the identified threats. the identified threats.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Threats to Multicast Routing . . . . . . . . . . . . . . . . . 4 3. Threats to Multicast Routing . . . . . . . . . . . . . . . . . 4
3.1 Receiver-based Attacks . . . . . . . . . . . . . . . . . . 4 3.1 Receiver-based Attacks . . . . . . . . . . . . . . . . . . 5
3.1.1 Joins to Different Groups . . . . . . . . . . . . . . 5 3.1.1 Joins to Different Groups . . . . . . . . . . . . . . 5
3.2 Source-based Attacks . . . . . . . . . . . . . . . . . . . 6 3.2 Source-based Attacks . . . . . . . . . . . . . . . . . . . 6
3.2.1 Sending Multicast to Empty Groups . . . . . . . . . . 6 3.2.1 Sending Multicast to Empty Groups . . . . . . . . . . 6
3.2.2 Disturbing Existing Group by Sending to It . . . . . . 7 3.2.2 Disturbing Existing Group by Sending to It . . . . . . 8
3.3 Aggravating Factors to the Threats . . . . . . . . . . . . 8 3.3 Aggravating Factors to the Threats . . . . . . . . . . . . 8
3.3.1 Distant RP/Source Problem . . . . . . . . . . . . . . 9 3.3.1 Distant RP/Source Problem . . . . . . . . . . . . . . 9
3.3.2 No Receiver Information in PIM Joins . . . . . . . . . 9 3.3.2 No Receiver Information in PIM Joins . . . . . . . . . 9
4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Summary of the Threats . . . . . . . . . . . . . . . . . . 9 4.1 Summary of the Threats . . . . . . . . . . . . . . . . . . 9
4.2 Enhancements for Threat Mitigation . . . . . . . . . . . . 10 4.2 Enhancements for Threat Mitigation . . . . . . . . . . . . 10
5. PIM Security Enhancements . . . . . . . . . . . . . . . . . . 11 5. PIM Security Enhancements . . . . . . . . . . . . . . . . . . 11
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 MSDP Source-Active Rate-limiter . . . . . . . . . . . 15 5.3.5 PIM Register 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 . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . 17
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 . . . . . . . . 20
1. Introduction 1. Introduction
skipping to change at page 4, line 28 skipping to change at page 4, line 28
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. In general, the threat model would then be considered in this memo. Also RP discovery mechanisms like BSR and
similar to [5]. Auto-RP are out of the scope. In general, the 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
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 also 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 yourself). 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
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 note that hosts can also originate PIM messages (e.g. PIM
Joins) as long as their source address passes the RPF checks. 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 yourself). The PIM-SM specification,
however, states that these messages should only be accepted from
known PIM neighbors [1]; 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.
One should also note that even if a host joins to a group multiple 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 times, the DR only sends one PIM Join message, without waiting for
any acknowledgement; the next message is only sent after the timer any acknowledgement; the next message is only sent after the timer
expires or the state changes at the DR. expires or the state changes at the DR.
Also, if the host uses IGMPv3 [10] or MLDv2 [11], it is able to join 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 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 same group generates new PIM (S,G) Joins to the DR adjacent to the
source. 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 a Description of the threat: Join Flooding. Join Flooding occurs when
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.
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 a MLD Reports/Leaves). It should also be noted that the host can join
number of different SSM channels with only one IGMPv3/MLDv2 Report as a number of different SSM channels with only one IGMPv3/MLDv2 Report
the protocol allows to include multiple sources in the same message. as the protocol allows to include multiple sources in the same
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 15 skipping to change at page 6, line 27
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 as
possible. Similarly, an explicit (S,G) join goes to the DR, as possible. Similarly, an explicit (S,G) join goes to the DR, as
with SSM above. with SSM above.
That is, SSM and Embedded-RP always enable "inter-domain" state That is, SSM and Embedded-RP always enable "inter-domain" state
creation. ASM defaults to intra-domain, but can be used for creation. ASM defaults to intra-domain, but can be used for
inter-domain state creation as well. inter-domain state creation as well.
If the source or RP does not exist, the multicast routing protocol If the source or RP (only in case of Embedded-RP) does not exist, the
does not have any means to remove the distribution tree if the multicast routing protocol does not have any means to remove the
joining host remains active. Worst case attack could be a host distribution tree if the joining host remains active. Worst case
remaining active to many different groups (containing either attack could be a host remaining active to many different groups
imaginary source or RP). (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 For example, if the host is able to generate 100 IGMPv3 (S,G) joins a
second, each carrying 10 sources, the amount of state after 260 second, each carrying 10 sources, the amount of state after 260
seconds would be 260 000 state entries -- and 100 packets per second seconds would be 260 000 state entries -- and 100 packets per second
is still a rather easily achievable number. is still a rather easily achievable number.
3.2 Source-based Attacks 3.2 Source-based Attacks
These attacks are often referred to as "data plane" attacks; however, These attacks are often referred to as "data plane" attacks; however,
with traditional ASM and MSDP, these also include an MSDP control with traditional ASM and MSDP, these also include an MSDP control
skipping to change at page 7, line 38 skipping to change at page 8, line 4
o As a large amount of data is forwarded on the multicast tree; if o As a large amount of data is forwarded on the multicast tree; if
multicast forwarding is performed on CPU, it may be a serious multicast forwarding is performed on CPU, it may be a serious
performance bottleneck, and a way to perform DoS on the path. performance bottleneck, and a way to perform DoS on the path.
Similarly, the DR must always be capable of processing (and Similarly, the DR must always be capable of processing (and
discarding, if necessary) the multicast packets received from the discarding, if necessary) the multicast packets received from the
source. These are potentially present in every model. source. These are potentially present in every model.
o If the encapsulation is performed on software, it may be a o If the encapsulation is performed on software, it may be a
performance bottleneck, and a way to perform DoS on the DR. performance bottleneck, and a way to perform DoS on the DR.
Similarly, if the decapsulation is performed on software, it may Similarly, if the decapsulation is performed on software, it may
be a performance bottleneck, and a way to perform DoS on the RP. be a performance bottleneck, and a way to perform DoS on the RP.
Note: the decapsulator may know, based on access configuration, a Note: the decapsulator may know, based on access configuration, a
rate-limit or something else, that it doesn't need to decapsulate rate-limit or something else, that it doesn't need to decapsulate
the packet, avoiding bottlenecks. These threats are related to the packet, avoiding bottlenecks. These threats are related to
ASM and Embedded-RP. ASM and Embedded-RP.
3.2.2 Disturbing Existing Group by Sending to It 3.2.2 Disturbing Existing Group by Sending to It
Description of the threat: Group Integrity Violation. Group Integrity Description of the threat: Group Integrity Violation. Group
Violation occurs when a host sends packets to a group or SSM channel, Integrity Violation occurs when a host sends packets to a group or
which already exists, to disturb the users of the existing group/SSM SSM channel, which already exists, to disturb the users of the
channel. existing group/SSM channel.
The SSM service model prevents injection of packets to (S,G) The SSM service model prevents injection of packets to (S,G)
channels, avoiding this problem. However, if the source address can channels, avoiding this problem. However, if the source address can
be spoofed to be a topologically-correct address, it's possible to be spoofed to be a topologically-correct address, it's possible to
get the packet into the distribution tree -- typically only those get the packet into the distribution tree -- typically only those
hosts which are on-link with the source are able to perform this, so hosts which are on-link with the source are able to perform this, so
this is not really relevant in the scope of this memo. this is not really relevant in the scope of this memo.
With ASM and Embedded-RP sources can inject forged traffic through With ASM and Embedded-RP sources can inject forged traffic through
RPs, which provide the source discovery for the group. The RP(s) send RPs, which provide the source discovery for the group. The RP(s)
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 unless (*,G) state). DR then forwards the forged traffic to receivers
the legitimate recipients are able to filter out unwanted sources, unless the legitimate recipients are able to filter out unwanted
e.g., using MSF API [8]. Typically this is not used or supported by sources, e.g., using MSF API [8]. Typically this is not used or
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 unicast-encapsulated in register packets to the RP -- if the RP drops
the packet based on access-list, rate-limiter or something else, it the packet based on access-list, rate-limiter or something else, it
doesn't get injected to an existing group. 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 decreases its applicability. Embedded-RP enables domains, which significantly decreases its applicability.
easier control because source discovery is done through single RP per Embedded-RP enables easier control because source discovery is done
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
This section describes a few factors, which aggravate the threats This section describes a few factors, which aggravate the threats
described in Section 3.1 and Section 3.2. These could also be viewed described in Section 3.1 and Section 3.2. These could also be viewed
as individual threats on their own. as individual threats on their own.
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 also 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 would get
elected to become DR for the subnet, but not perform any of its
functions. These are described at some length in [1], but are also
considered out of scope of this memo.
3.3.1 Distant RP/Source Problem 3.3.1 Distant RP/Source Problem
In the shared tree model, if the RP or a source is distant In the shared tree model, if the RP or a source is distant
(topologically), then joins will travel to the distant RP or source (topologically), then joins will travel to the distant RP or source
and keep the state information in the path active, even if the data and keep the state information in the path active, even if the data
is being delivered locally. is being delivered locally.
Note that this problem will be exacerbated if the RP/source space is Note that this problem will be exacerbated if the RP/source space is
global; if a router is registering to a RP/source that is not in the global; if a router is registering to a RP/source that is not in the
local domain (say, fielded by the site's direct provider), then the local domain (say, fielded by the site's direct provider), then the
skipping to change at page 11, line 33 skipping to change at page 11, line 34
somehow. For example: somehow. For example:
1) At the very least, receiving an ICMP unreachable message (of 1) At the very least, receiving an ICMP unreachable message (of
any flavor) should cause the DR to stop the Register packets -- as any flavor) should cause the DR to stop the Register packets -- as
the RP will not be receiving them anyway. (However, one should the RP will not be receiving them anyway. (However, one should
note that easy spoofing of such ICMP messages could cause a DoS on note that easy spoofing of such ICMP messages could cause a DoS on
legitimate traffic.) legitimate traffic.)
2) An additional method could be implementing a timer on the RPs 2) An additional method could be implementing a timer on the RPs
so that unless nothing is heard back from the RP within a defined so that unless nothing is heard back from the RP within a defined
time period, the flow of Register messages would stop. (Currently, time period, the flow of Register messages would stop.
the RPs are not required to answer back, unless they want to join (Currently, the RPs are not required to answer back, unless they
to the source.) want to join to the source.)
3) An extreme case would be performing some form of return 3) An extreme case would be performing some form of return
routability check prior to starting the register messages: first a routability check prior to starting the register messages: first a
packet would be sent to the RP, testing its existence and packet would be sent to the RP, testing its existence and
willingness to serve, and also proving to the RP that the sender 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 of the "bubble" and the sender of the registers are the same and
the source address is not forged (i.e., the RP would insert a the source address is not forged (i.e., the RP would insert a
cookie in the bubble, and it would have to be present in the cookie in the bubble, and it would have to be present in the
register message.) register message.)
skipping to change at page 14, line 48 skipping to change at page 14, line 49
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 token-bucket -based rate-limiter for unicast-decapsulation, A simple decapsulation rate-limiter protecting the CPU usage in the
limiting the decapsulation to DECAP_MAX new groups per second, with a router, limiting X pps (the need and limit depends on the router
bucket of DECAP_LONG. If the router has restarted recently, a larger architecture), disregarding the source of the registers. This could
initial bucket should be used. Example values could be DECAP_MAX=1 also be an additional check to be used before decapsulation and
and DECAP_LONG=10 (or DECAP_LONG=500 after restart). 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 legimate sessions as well.
5.3.5 PIM Register Rate-limiter
A token-bucket -based rate-limiter for unicast-decapsulation of PIM
Register messages, limiting to REG_MAX new groups per second, with a
bucket of REG_LONG. If the router has restarted recently, a larger
initial bucket should be used. Example values could be REG_MAX=1 and
REG_LONG=10 (or REG_LONG=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.5 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 to SAG_MAX per second, with a bucket of SAG_LONG. Example
values could be SAG_MAX=1 and SAG_LONG=10. values could be SAG_MAX=1 and SAG_LONG=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
skipping to change at page 15, line 38 skipping to change at page 15, line 49
some detail, and proposes enhancements to mitigate the observed some detail, and proposes enhancements to mitigate the observed
threats. threats.
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.
8. Acknowledgements 8. Acknowledgements
Kamil Sarac discussed "return routability" issues at length. Kamil Sarac discussed "return routability" issues at length. Stig
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
Independent Multicast - Sparse Mode PIM-SM): Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol
Specification (Revised)", draft-ietf-pim-sm-v2-new-09 (work in Specification (Revised)", draft-ietf-pim-sm-v2-new-09 (work in
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-02 (work in progress), March 2004. draft-ietf-mboned-embeddedrp-04 (work in progress), April 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 18, line 10 skipping to change at page 18, line 23
requirement is that the neighbor who has enabled PIM in the concerned requirement is that the neighbor who has enabled PIM in the concerned
interface. I.e., in most cases, the threat is limited to attackers interface. I.e., in most cases, the threat is limited to attackers
within the operators in the exchange, not third parties. On the within the operators in the exchange, not third parties. On the
other hand, data plane forwarding has no such checks -- and having other hand, data plane forwarding has no such checks -- and having
such checks would require one to look at the link-layer addresses such checks would require one to look at the link-layer addresses
used; that is, this checking is not as feasible as one might hope. used; that is, this checking is not as feasible as one might hope.
Appendix B. Return Routability Extensions Appendix B. Return Routability Extensions
The multicast state information is built from the receiver side and The multicast state information is built from the receiver side and
it can be currently pruned only by the receiver side DR. If the RP or it can be currently pruned only by the receiver side DR. If the RP
the source for the group is non-existent, the state can't be pruned or the source for the group is non-existent, the state can't be
by the DR without return routability extensions to provide such pruned by the DR without return routability extensions to provide
information. There might be also need to remove the state in some such information. There might be also need to remove the state in
cases when there is no multicast traffic sent to that group. This some cases when there is no multicast traffic sent to that group.
section discusses about the alternative ways to remove the unused This section discusses about the alternative ways to remove the
state information in the routers, so that it can't be used in state unused state information in the routers, so that it can't be used in
based DoS attacks. Note that rate limiting PIM Joins gives some state based DoS attacks. Note that rate limiting PIM Joins gives
protection against the state attacks. some protection against the state attacks.
B.1 Sending PIM-Prune Messages Down the Tree B.1 Sending PIM-Prune Messages Down the Tree
When a router discovers the non-existance of the RP or the source When a router discovers the non-existence of the RP or the source, it
(XXX: does it actually know if there is RP/Source or not), it can can create a PIM-Prune message and send it back to the join
create a PIM-Prune message and send it back to the join originator. originator. However, since it does not know the unicast IP address
However, since it does not know the unicast IP address of join of join originator DR, it cannot directly unicast it to that router.
originator DR, it cannot directly unicast it to that router.
A possible alternative is to use a link-local multicast group address A possible alternative is to use a link-local multicast group address
(e.g., all-pim routers local multicast address) to pass this (e.g., all-pim routers local multicast address) to pass this
information back toward the joining DR. Since the routers from this information back toward the joining DR. Since the routers from this
current router all the way back to the joining DR has forwarding current router all the way back to the joining DR has forwarding
state entry for the group, they can use this state information to see state entry for the group, they can use this state information to see
how to forward the PIM-Prune message back. how to forward the PIM-Prune message back.
Each on-tree router, in addition to forwarding the PIM-Prune message, Each on-tree router, in addition to forwarding the PIM-Prune message,
can also prune the state from their state tables. This way, the can also prune the state from their state tables. This way, the
skipping to change at page 19, line 21 skipping to change at page 19, line 32
and wants to create states in the network, then it can send joins to and wants to create states in the network, then it can send joins to
different groups and create states on routers for each of these different groups and create states on routers for each of these
different groups until the DR decides that the groups are inactive different groups until the DR decides that the groups are inactive
and initiates the prune process. In addition, during the prune and initiates the prune process. In addition, during the prune
process, the routers will again process all these prune messages and process, the routers will again process all these prune messages and
therefore will be spending time. therefore will be spending time.
B.3 Comparison of the Above Approaches B.3 Comparison of the Above Approaches
Both of these solutions have the same problem of renewing the Both of these solutions have the same problem of renewing the
multicast state information. DR shouldn't permanently block the state multicast state information. DR shouldn't permanently block the
building for that group, but to restrict the PIM Joins if it notices state building for that group, but to restrict the PIM Joins if it
that the receiver is abusing the system. One additional option is to notices that the receiver is abusing the system. One additional
block the PIM Joins to the non-existent source/RP for a certain time. 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 In the first approach (sending PIM-Prunes down the tree), part of the
goal was to prune the states in the routers much sooner than in the goal was to prune the states in the routers much sooner than in the
second approach (e.g. goal is to make sure that the routers will not second approach (e.g. goal is to make sure that the routers will not
be keeping unnecessary states for long time). be keeping unnecessary states for long time).
The second approach works also for DoS attacks related to the The second approach works also for DoS attacks related to the
existing source/RP addresses and could be more quickly implemented existing source/RP addresses and could be more quickly implemented
and deployed in the network and does not have any relationship and deployed in the network and does not have any relationship
related to the other deployments (no need to change all PIM routers). related to the other deployments (no need to change all PIM routers).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

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