draft-ietf-mboned-mroutesec-03.txt   draft-ietf-mboned-mroutesec-04.txt 
MBONED WG P. Savola MBONED WG P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Expires: February 17, 2005 R. Lehtonen Expires: April 12, 2005 R. Lehtonen
TeliaSonera TeliaSonera
D. Meyer D. Meyer
August 19, 2004 October 12, 2004
PIM-SM Multicast Routing Security Issues and Enhancements PIM-SM Multicast Routing Security Issues and Enhancements
draft-ietf-mboned-mroutesec-03.txt draft-ietf-mboned-mroutesec-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 February 17, 2005. This Internet-Draft will expire on April 12, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . 5 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 . . . . . . 8 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 . . . . . . . . . . . . 9
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 . . . . . . . . 14
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 . . . . . . . . . . 15
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
5.4 Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 15 5.4 Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
A. RPF Considers Interface, Not Neighbor . . . . . . . . . . . . 18 A. RPF Considers Interface, Not Neighbor . . . . . . . . . . . . 18
B. Return Routability Extensions . . . . . . . . . . . . . . . . 18 B. Return Routability Extensions . . . . . . . . . . . . . . . . 19
B.1 Sending PIM-Prune Messages Down the Tree . . . . . . . . . 19 B.1 Sending PIM-Prune Messages Down the Tree . . . . . . . . . 19
B.2 Analysing Multicast Group Traffic at DR . . . . . . . . . 19 B.2 Analysing Multicast Group Traffic at DR . . . . . . . . . 20
B.3 Comparison of the Above Approaches . . . . . . . . . . . . 20 B.3 Comparison of the Above Approaches . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
This memo describes security threats to the Protocol Independent This document describes security threats to the Protocol Independent
Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures, Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures,
and suggests ways to make these architectures more resistant to the and suggests ways to make these architectures more resistant to the
described threats. described threats.
Only attacks which have an effect on the multicast routing (whether Only attacks which have an effect on the multicast routing
intra- or inter-domain) are considered. For example, attacks where infrastructures (whether intra- or inter-domain) are considered.
the hosts are specifically targeting the Designated Router (DR) or
other routers on the link, or where hosts are disrupting other hosts
on the same link are out of scope. Similarly, ensuring
confidentiality, authentication and integrity of multicast groups and
traffic is out of scope; instead, see [9].
PIM builds on a model where Reverse Path Forwarding (RPF) check is "On-link" attacks where the hosts are specifically targeting the
(among other things) used to ensure loop-free properties of the Designated Router (DR) or other routers on the link, or where hosts
are disrupting other hosts on the same link, possibly using group
management protocols, are discussed elsewhere (e.g., [10] and [12]).
These attacks are not discussed further in this document.
Similar to unicast, the multicast payloads may need end-to-end
security. Security mechanisms to provide confidentiality,
authentication, and integrity are described in other documents (e.g.,
[9]). These attacks that these security mechanisms protect against
are not discussed further in this document.
PIM builds on a model where Reverse Path Forwarding (RPF) checking
is, among other things, used to ensure loop-free properties of the
multicast distribution trees. As a side effect, this limits the multicast distribution trees. As a side effect, this limits the
effect of using forged source addresses, which is often used as a impact of an attacker using a forged source address, which is often
component in unicast-based attacks. However, a host can still spoof used as a component in unicast-based attacks. However, a host can
an address within the same subnet, or spoof the source of a still spoof an address within the same subnet, or spoof the source of
unicast-encapsulated PIM Register messages, which a host may send on a unicast-encapsulated PIM Register message, which a host may send on
its own. its own.
We consider PIM-SM [1] operating in the traditional Any Souce We consider PIM-SM [1] operating in the traditional Any Souce
Multicast (ASM) model (including the use of Multicast Source Multicast (ASM) model (including the use of Multicast Source
Discovery Protocol (MSDP) [2] for source discovery), in Discovery Protocol (MSDP) [2] for source discovery), in
Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4]
group-to-RP mapping mechanism in ASM model. If the Bidirectional-PIM group-to-RP mapping mechanism in ASM model. Bidirectional-PIM [15]
enhancements are globally significant, and have implications, they is typically deployed only in intra-domain, and is similar to ASM but
could also be considered, but are out of scope for now. without register messages. Bidirectional-PIM is not finished as of
this writing, and its considerations are not discussed further in
this document.
2. Terminology 2. Terminology
ASM ASM
"ASM" [6] is used to refer to the traditional Any Source "ASM" [6] is used to refer to the traditional Any Source
Multicast model with multiple PIM domains and a signalling Multicast model with multiple PIM domains and a signalling
mechanism (MSDP) to exchange information about active sources mechanism (MSDP) to exchange information about active sources
between them. between them.
skipping to change at page 4, line 24 skipping to change at page 4, line 33
"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. While this assumption is not entirely
abuse. While this assumption is not entirely correct, it simplifies correct, it simplifies the analysis of threat models. The threats
the analysis of threat models. The threats caused by misbehaving caused by misbehaving multicast routers (including fake multicast
multicast routers (including fake multicast routers) are not routers) are not considered in this memo -- the generic threat model
considered in this memo. Also RP discovery mechanisms like Bootstrap would be similar to [5]. RP discovery mechanisms like Bootstrap
Router (BSR) and Auto-RP are out of the scope. In general, the Router (BSR) and Auto-RP are also considered out of the scope.
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.
skipping to change at page 5, line 38 skipping to change at page 5, line 46
"PIM State"), or the Target Router with an excessive number of "PIM State"), or the Target Router with an excessive number of
packets. packets.
Note that even if a host joins to a group multiple times, the DR only Note that even if a host joins to a group multiple times, the DR only
sends one PIM Join message, without waiting for any acknowledgement; sends one PIM Join message, without waiting for any acknowledgement;
the next message is only sent after the PIM Join timer expires or the the next message is only sent after the PIM Join timer expires or the
state changes at the DR. state changes at the DR.
This kind of joining causes PIM state to be created, but this state This kind of joining causes PIM state to be created, but this state
is relatively short-lived (260 seconds by default, which is the is relatively short-lived (260 seconds by default, which is the
default time that the state is active at DR in the absence of IGMP/ default time that the state is active at DR in the absence of
MLD Reports/Leaves). It should also be noted that the host can join IGMP/MLD Reports/Leaves). It should also be noted that the host can
a number of different ASM groups or SSM channels with only one IGMPv3 join a number of different ASM groups or SSM channels with only one
[10] or MLDv2 [11] Report as the protocol allows to include multiple IGMPv3 [11] or MLDv2 [12] Report as the protocol allows to include
sources in the same message, resulting in multiple PIM Joins from one multiple sources in the same message, resulting in multiple PIM Joins
IGMPv3/MLDv2 message. 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
MLD Reports to these groups to make the state attack more long-lived. IGMP/MLD Reports to these groups to make the state attack more
This results in: long-lived. This results in:
o ASM: a (*,G) join is sent to an intra-domain RP, causing state on o ASM: 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
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.
skipping to change at page 6, line 50 skipping to change at page 7, line 9
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 register encapsulation is not subject to RPF checks, Note that since register encapsulation is not subject to RPF checks,
the hosts can also craft and send these packets themselves, also the hosts can also craft and send these packets themselves, also
spoofing the source address of the register messages unless ingress spoofing the source address of the register messages unless ingress
filtering [12] has been deployed [13]. That is, as the initial data filtering [13] has been deployed [14]. That is, as the initial data
registering is not subject to the same RPF checks as many other registering is not subject to the same RPF checks as many other
multicast routing procedures, making control decisions based on that multicast routing procedures, making control decisions based on that
data leads to many potential threats. data leads to many potential threats.
Examples of this threat are a virus/worm trying to propagate to Examples of this threat are a virus/worm trying to propagate to
multicast addresses, an attacker trying to crash routers with multicast addresses, an attacker trying to crash routers with
excessive MSDP state, or an attacker wishing to overload the RP with excessive MSDP state, or an attacker wishing to overload the RP with
encapsulated packets or different groups. This results in: encapsulated packets or different groups. This results in:
o ASM: the DR register-encapsulates the packets in Register messages o ASM: the DR register-encapsulates the packets in Register messages
skipping to change at page 7, line 34 skipping to change at page 7, line 41
Register-Stop. Data continues to be encapsulated if different Register-Stop. Data continues to be encapsulated if different
groups are used. groups are used.
This yields many potential attacks, especially if at least parts of This yields many potential attacks, especially if at least parts of
the multicast forwarding functions are implemented on a "slow" path the multicast forwarding functions are implemented on a "slow" path
or CPU in the routers, at least: or CPU in the routers, at least:
o The MSDP control plane traffic generated can cause a significant o The MSDP control plane traffic generated can cause a significant
amount of control and data traffic which may overload the routers amount of control and data traffic which may overload the routers
receiving it. A thorough analysis of MSDP vulnerabilities can be receiving it. A thorough analysis of MSDP vulnerabilities can be
found in [14], and is only related to the ASM. However, this is found in [16], and is only related to the ASM. However, this is
the most serious threat at the moment, because MSDP will flood the the most serious threat at the moment, because MSDP will flood the
multicast group information to all multicast domains in Internet multicast group information to all multicast domains in Internet
including the multicast packet encapsulated to MSDP source-active including the multicast packet encapsulated to MSDP source-active
message. This creates a lot of data and state to be shared by all message. This creates a lot of data and state to be shared by all
multicast enabled routers and if the source remains active, the multicast enabled routers and if the source remains active, the
flooding will be repeated every 60 seconds by default. flooding will be repeated every 60 seconds by default.
o As a large amount of data is forwarded on the multicast tree; if o As a large amount of data is forwarded on the multicast tree; if
multicast forwarding is performed on CPU, it may be a serious multicast forwarding is performed on CPU, it may be a serious
performance bottleneck, and a way to perform DoS on the path. performance bottleneck, and a way to perform DoS on the path.
skipping to change at page 14, line 35 skipping to change at page 14, line 48
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, with a bucket of depth of PIM_DEPTH, globally on the router, with a bucket of depth of PIM_DEPTH,
refilling at PIM_RATE tokens per second. Example values could be refilling at PIM_RATE tokens per second. Example values could be
1000 and 10000. PIM_RATE=1000 and PIM_DEPTH=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
skipping to change at page 15, line 30 skipping to change at page 15, line 45
A token-bucket -based, source-based rate-limiter, limiting new groups A token-bucket -based, source-based rate-limiter, limiting new groups
per source with a bucket of depth of SAG_DEPTH, refilling at 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_RATE tokens per second. Example values could be SAG_RATE=1 and
SAG_DEPTH=10. 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. [16] discusses different MSDP attack
prevention mechanisms at length. prevention mechanisms at length.
5.4 Passive Mode for PIM 5.4 Passive Mode for PIM
As described in the last paragraph of section 3, hosts are also able As described in the last paragraph of section 3, hosts are also able
to form PIM adjacencies and send disrupting traffic unless great care to form PIM adjacencies and send disrupting traffic unless great care
is observed at the routers. This stems from the fact that most is observed at the routers. This stems from the fact that most
implementations require that stub LANs with only one PIM router must implementations require that stub LANs with only one PIM router must
also have PIM enabled (to enable PIM processing of the sourced data also have PIM enabled (to enable PIM processing of the sourced data
etc.) Such stub networks however do not require to actually run the etc.) Such stub networks however do not require to actually run the
skipping to change at page 16, line 8 skipping to change at page 16, line 23
This memo analyzes the security of PIM routing infrastructures in This memo analyzes the security of PIM routing infrastructures in
some detail, and proposes enhancements to mitigate the observed some detail, and proposes enhancements to mitigate the observed
threats. threats.
This document does not discuss adding (strong) authentication to the This document does not discuss adding (strong) authentication to the
multicast protocols. PIM-SM specification [1] describes the multicast protocols. PIM-SM specification [1] describes the
application of IPsec for routing authentication; it is worth noting application of IPsec for routing authentication; it is worth noting
that being able to authenticate the register messages and being able that being able to authenticate the register messages and being able
to prevent illegitimate users from establishing PIM adjacencies would to prevent illegitimate users from establishing PIM adjacencies would
seem to be the two most important goals. IGMPv3 specification [10] seem to be the two most important goals. IGMPv3 specification [11]
describes the use of IPsec for group management (similar applies to 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 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 worth noting that being able to control the group memberships might
reduce the receiver-based attacks. reduce the receiver-based attacks.
However, one should keep in mind two caveats: authentication alone However, one should keep in mind two caveats: authentication alone
might not be sufficient, especially if the user or the host stack might not be sufficient, especially if the user or the host stack
(consider a worm propagation scenario) cannot be expected to "behave (consider a worm propagation scenario) cannot be expected to "behave
well"; and that adding such authentication likely provides new attack well"; and that adding such authentication likely provides new attack
vectors, e.g., in the form of a CPU DoS attack with excessive amount vectors, e.g., in the form of a CPU DoS attack with excessive amount
skipping to change at page 16, line 32 skipping to change at page 16, line 47
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 [[ Note to the RFC-editor: please remove this section upon
publication ]] 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. Bill
Fenner and Russ Housley provided useful comments during the IESG
evaluation.
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-10 (work in Specification (Revised)", draft-ietf-pim-sm-v2-new-10 (work in
progress), July 2004. progress), July 2004.
[2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol [2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol
(MSDP)", RFC 3618, October 2003. (MSDP)", RFC 3618, October 2003.
[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", [3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
draft-ietf-ssm-arch-05 (work in progress), July 2004. draft-ietf-ssm-arch-06 (work in progress), September 2004.
[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-07 (work in progress), July 2004. draft-ietf-mboned-embeddedrp-07 (work in progress), July 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
skipping to change at page 17, line 21 skipping to change at page 17, line 40
[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.
[7] Bhattacharyya, S., "An Overview of Source-Specific Multicast [7] Bhattacharyya, S., "An Overview of Source-Specific Multicast
(SSM)", RFC 3569, July 2003. (SSM)", RFC 3569, July 2003.
[8] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface [8] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678, January Extensions for Multicast Source Filters", RFC 3678, January
2004. 2004.
[9] Hardjono, T. and B. Weis, "The Multicast Security [9] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", draft-ietf-msec-arch-05 (work in progress), Architecture", RFC 3740, March 2004.
January 2004.
[10] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. [10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast
Listener Discovery", draft-daley-magma-smld-prob-00 (work in
progress), July 2004.
[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002. RFC 3376, October 2002.
[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[12] Ferguson, P. and D. Senie, "Network Ingress Filtering: [13] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[13] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[14] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and [15] Handley, M., Kouvelas, I., Speakman, T. and L. Vicisano,
"Bi-directional Protocol Independent Multicast (BIDIR-PIM)",
draft-ietf-pim-bidir-07 (work in progress), July 2004.
[16] 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
Espoo Espoo
Finland Finland
 End of changes. 

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