< draft-ietf-magma-msnip-01.txt   draft-ietf-magma-msnip-02.txt >
Internet Engineering Task Force MAGMA WG Internet Engineering Task Force MAGMA WG
INTERNET-DRAFT Bill Fenner/AT&T INTERNET-DRAFT Bill Fenner/AT&T
draft-ietf-magma-msnip-01.txt Brian Haberman/Caspian Networks draft-ietf-magma-msnip-02.txt Brian Haberman/Caspian Networks
Hugh Holbrook/Cisco Hugh Holbrook/Cisco
Isidor Kouvelas/Cisco Isidor Kouvelas/Cisco
2 November 2002 1 March 2003
Expires: May 2003 Expires: September 2003
Multicast Source Notification of Interest Protocol (MSNIP) Multicast Source Notification of Interest Protocol (MSNIP)
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3
2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3
3. Service Interface for Requesting Membership Noti- 3. Service Interface for Requesting Membership Noti-
fication . . . . . . . . . . . . . . . . . . . . . . . . . 4 fication . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Application Operation. . . . . . . . . . . . . . . . 5 3.1. Application Operation. . . . . . . . . . . . . . . . 5
4. MSNIP Managed Address Range Negotiation . . . . . . . . 6 4. MSNIP Managed Address Range Negotiation . . . . . . . . 6
4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6
4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6
4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7
4.2. Communicating Range to Source Systems. . . . . . . . 7 4.2. Communicating Range to Source Systems. . . . . . . . 7
5. Requesting and Receiving Notifications. . . . . . . . . 8 5. Requesting and Receiving Notifications. . . . . . . . . 9
5.1. Host Interest Solicitation . . . . . . . . . . . . . 9 5.1. Host Interest Solicitation . . . . . . . . . . . . . 9
5.2. Router Receiver Membership Reports . . . . . . . . . 10 5.2. Router Receiver Membership Reports . . . . . . . . . 10
6. Application Notification. . . . . . . . . . . . . . . . 11 6. Application Notification. . . . . . . . . . . . . . . . 11
7. Router Processing . . . . . . . . . . . . . . . . . . . 13 7. Router Processing . . . . . . . . . . . . . . . . . . . 13
8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14
8.1. Host Interest Solicitation Packet. . . . . . . . . . 15 8.1. Host Interest Solicitation Packet. . . . . . . . . . 15
8.2. Receiver Membership Report Packet. . . . . . . . . . 16 8.2. Receiver Membership Report Packet. . . . . . . . . . 16
8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 18 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 18
8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 18 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 18
9. Constants Timers and Default Values . . . . . . . . . . 18 9. Constants Timers and Default Values . . . . . . . . . . 18
10. Possible Optimisations . . . . . . . . . . . . . . . . 19 10. Possible Optimisations . . . . . . . . . . . . . . . . 19
10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 19 10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 19
10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 19 10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 19
10.3. Responding to Unexpected IGMP Queries . . . . . . . 19 10.3. Responding to Unexpected IGMP Queries . . . . . . . 19
10.4. Host and Router Startup . . . . . . . . . . . . . . 20 10.4. Host and Router Startup . . . . . . . . . . . . . . 20
11. Security Considerations. . . . . . . . . . . . . . . . 20 11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20
11.1. Receiver Membership Report attacks. . . . . . . . . 21 12. Security Considerations. . . . . . . . . . . . . . . . 21
11.2. Host Interest Solicitation attacks. . . . . . . . . 21 12.1. Receiver Membership Report attacks. . . . . . . . . 21
11.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22 12.2. Host Interest Solicitation attacks. . . . . . . . . 22
12. IANA Considerations. . . . . . . . . . . . . . . . . . 23 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 23
13. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23 13. IANA Considerations. . . . . . . . . . . . . . . . . . 23
14. Authors' Addresses . . . . . . . . . . . . . . . . . . 23 14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 24
15. References . . . . . . . . . . . . . . . . . . . . . . 24 15. Authors' Addresses . . . . . . . . . . . . . . . . . . 24
16. Normative References . . . . . . . . . . . . . . . . . 24
17. Informative References . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Multicast Source Notification of Interest Protocol (MSNIP) is The Multicast Source Notification of Interest Protocol (MSNIP) is
an extension to version 3 of the Internet Group Membership Protocol an extension to version 3 of the Internet Group Membership Protocol
(IGMPv3 [1] ) and version 2 of the Multicast Listener Discovery Protocol (IGMPv3 [1] ) and version 2 of the Multicast Listener Discovery Protocol
(MLDv2 [8] ). MSNIP operates between multicast sources and their first- (MLDv2 [2] ). MSNIP operates between multicast sources and their first-
hop routers to provide information on the presence of receivers to the hop routers to provide information on the presence of receivers to the
source systems. Using the services offered by MSNIP an application on an source systems. Using the services offered by MSNIP an application on an
IP system wishing to source multicast data can register to be notified IP system wishing to source multicast data can register to be notified
when receivers join and leave the session. This enables multicast when receivers join and leave the session. This enables multicast
sources to avoid the work of transmitting packets onto their first-hop sources to avoid the work of transmitting packets onto their first-hop
link when there are no joined receivers. link when there are no joined receivers.
A common scenario where MSNIP may be useful is one where there is a A common scenario where MSNIP may be useful is one where there is a
multicast server offering a large pool of potential flows that map onto multicast server offering a large pool of potential flows that map onto
separate multicast destination addresses but receivers exist only for a separate multicast destination addresses but receivers exist only for a
skipping to change at page 3, line 49 skipping to change at page 3, line 49
transmission control for applications that use multicast destination transmission control for applications that use multicast destination
addresses that are routed using Source Specific Multicast (SSM). addresses that are routed using Source Specific Multicast (SSM).
Many currently deployed multicast routing protocols, require data Many currently deployed multicast routing protocols, require data
from an active source to be propagated past the first-hop router before from an active source to be propagated past the first-hop router before
information on the existence of receivers becomes available on the information on the existence of receivers becomes available on the
first-hop. In addition, such protocols require that this activity is first-hop. In addition, such protocols require that this activity is
repeated periodically to maintain source liveness state on remote repeated periodically to maintain source liveness state on remote
routers. All dense-mode protocols fall under this category as well as routers. All dense-mode protocols fall under this category as well as
sparse-mode protocols that use shared trees for source discovery (such sparse-mode protocols that use shared trees for source discovery (such
as PIM-SM [3] ). In order to provide receiver interest notification for as PIM-SM [9] ). In order to provide receiver interest notification for
such protocols, the default mode of operation would require that the such protocols, the default mode of operation would require that the
source IP system periodically transmits on all potential destination source IP system periodically transmits on all potential destination
addresses and the first-hop routers prune the traffic back. Such a addresses and the first-hop routers prune the traffic back. Such a
flood-and-prune behaviour on the first-hop link significantly diminishes flood-and-prune behaviour on the first-hop link significantly diminishes
the benefits of managing source transmission. the benefits of managing source transmission.
In contrast, with source-specific sparse-mode protocols such as In contrast, with source-specific sparse-mode protocols such as
PIM-SSM [3] availability of receiver membership information on the PIM-SSM [9] availability of receiver membership information on the
first-hop routers is independent of data transmission. Such protocols first-hop routers is independent of data transmission. Such protocols
use an external mechanism for source discovery (like source-specific use an external mechanism for source discovery (like source-specific
IGMPv3 membership reports) to build source-specific multicast trees. IGMPv3 membership reports) to build source-specific multicast trees.
Clearly these two classes of routing protocols require different Clearly these two classes of routing protocols require different
handling for the problem MSNIP is trying to solve. In addition the handling for the problem MSNIP is trying to solve. In addition the
second type covers the majority of applications that MSNIP is targeted second type covers the majority of applications that MSNIP is targeted
at. MSNIP avoids the extra complication in supporting routing protocols at. MSNIP avoids the extra complication in supporting routing protocols
that require a flood and prune behaviour. that require a flood and prune behaviour.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
the teardown of the associated socket state. the teardown of the associated socket state.
4. MSNIP Managed Address Range Negotiation 4. MSNIP Managed Address Range Negotiation
With current multicast deployment in the Internet, different With current multicast deployment in the Internet, different
multicast routing protocols coexist and operate under separate parts of multicast routing protocols coexist and operate under separate parts of
the multicast address space. Multicast routers are consistently the multicast address space. Multicast routers are consistently
configured with information that maps specific multicast address ranges configured with information that maps specific multicast address ranges
to multicast routing protocols. Part of this configuration describes the to multicast routing protocols. Part of this configuration describes the
subset of the address space that is used by source-specific multicast subset of the address space that is used by source-specific multicast
(SSM) [4]. As described in section 2 MSNIP only tries to control (SSM) [10]. As described in section 2 MSNIP only tries to control
application transmission within the SSM address range. application transmission within the SSM address range.
It is desirable for applications within an IP system that supports It is desirable for applications within an IP system that supports
MSNIP to have a consistent service interface for multicast transmission MSNIP to have a consistent service interface for multicast transmission
that does require the application to be aware of the SSM address range. that does require the application to be aware of the SSM address range.
MSNIP supports this by allowing applications to use the service MSNIP supports this by allowing applications to use the service
interface described in section 3 for multicast destination addresses interface described in section 3 for multicast destination addresses
that are outside its operating range. When an application registers for that are outside its operating range. When an application registers for
notifications for a destination address that is not managed by MSNIP it notifications for a destination address that is not managed by MSNIP it
is immediately notified to start transmitting. This is equivalent to the is immediately notified to start transmitting. This is equivalent to the
default behaviour of IP multicast without MSNIP support which forces default behaviour of IP multicast without MSNIP support which forces
multicast applications to assume that there are multicast receivers multicast applications to assume that there are multicast receivers
present in the network. present in the network.
4.1. Router Coordination 4.1. Router Coordination
In order for MSNIP to operate on a shared link where more than one In order for MSNIP to operate on a shared link where more than one
multicast routers may be present all multicast routers must be MSNIP multicast routers may be present all multicast routers must be MSNIP
capable and have a consistent configuration for the SSM address range. capable and have a consistent configuration for the SSM address range.
MSNIP enforces these requirements by using two new options for IPv4 in MSNIP enforces these requirements by using two new options for IPv4 in
the Multicast Router Discovery protocol [5] and one new option for IPv6 the Multicast Router Discovery protocol [3] and one new option for IPv6
in Neighbor Discovery / ICMPv6 protocol. in Neighbor Discovery / ICMPv6 protocol.
4.1.1. MSNIP Operation Option 4.1.1. MSNIP Operation Option
A multicast router advertises that it is participating in MSNIP A multicast router advertises that it is participating in MSNIP
using the MSNIP Operation option in either the Multicast Router using the MSNIP Operation option in either the Multicast Router
Discovery protocol for IPv4 and the Neighbor Discovery / ICMPv6 protocol Discovery protocol for IPv4 or the Neighbor Discovery / ICMPv6 protocol
for IPv6. This option MUST be included in all router advertisement for IPv6. This option MUST be included in all router advertisement
messages of a router that is configured for MSNIP. The format of the messages of a router that is configured for MSNIP. The format of the
option is as follows: option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=0 | | Type | Length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type field is set to WW (TBD by IANA) in IPv4 and ZZ (TBA by Type The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by
IANA) in IPv6. IANA) for IPv6.
A multicast router uses received Multicast Router Advertisement and A multicast router uses received Multicast Router Advertisement and
Neighbor Discovery / ICMPv6 messages to determine if all live neighbour Neighbor Discovery / ICMPv6 messages to determine if all live neighbour
multicast routers on each interface are participating in MSNIP. When a multicast routers on each interface are participating in MSNIP. When a
router advertisement message not containing an MSNIP option is received router advertisement message not containing an MSNIP option is received
by a router participating in MSNIP, a miss-configuration SHOULD be by a router participating in MSNIP, a miss-configuration SHOULD be
logged to the operator in a rate-limited manner. logged to the operator in a rate-limited manner.
If even one multicast router on a link does not have MSNIP capability If even one multicast router on a link does not have MSNIP capability
then ALL routers on that link MUST be configured to not provide MSNIP then ALL routers on that link MUST be configured to not provide MSNIP
services and to not advertise the MSNIP Operation option. services and to not advertise the MSNIP Operation option.
4.1.2. SSM Range Option 4.1.2. SSM Range Option
The SSM Range Multicast Router Discover option advertises the SSM The SSM Range Multicast Router Discover option advertises the SSM
Range with which the router is configured. The option is defined in [7]. Range with which the router is configured. The option is defined in [4].
This option is only valid in IPv4. SSM support in IPv6 does not allow This option is only valid in IPv4. SSM support in IPv6 does not allow
for alternative SSM address ranges. for alternative SSM address ranges.
4.2. Communicating Range to Source Systems 4.2. Communicating Range to Source Systems
When an application in an IP system uses the MSNIP service When an application in an IP system uses the MSNIP service
interface to register for notification, the IP system must behave interface to register for notification, the IP system must behave
differently depending on whether or not the destination address for differently depending on whether or not the destination address for
which the application registered is operating under SSM (and is being which the application registered is operating under SSM (and is being
managed by MSNIP). For SSM channels, the IP system should only instruct managed by MSNIP). For SSM channels, the IP system should only instruct
skipping to change at page 8, line 30 skipping to change at page 8, line 30
Multicast Router Discovery Advertisements provide the Multicast Router Discovery Advertisements provide the
differentiation between the first two cases. If the MRD Advertisements differentiation between the first two cases. If the MRD Advertisements
contain the MSNIP Operation option then the IP system knows that routers contain the MSNIP Operation option then the IP system knows that routers
on that interface are configured for MSNIP operation. on that interface are configured for MSNIP operation.
In each of the three cases the MSNIP managed range is defined as In each of the three cases the MSNIP managed range is defined as
follows: follows:
MSNIP capable multicast routers: MSNIP capable multicast routers:
The IP system should use as the MSNIP range the SSM range provided The IP system should use as the MSNIP range the SSM range provided
by the last SSM Range option [7] received in a Multicast Router by the last SSM Range option [4] received in a Multicast Router
Discovery message. Discovery message.
Multicast routers not participating in MSNIP: Multicast routers not participating in MSNIP:
The IP system should use an empty MSNIP managed range. This The IP system should use an empty MSNIP managed range. This
provides a compatibility mode where all group ranges default to provides a compatibility mode where all group ranges default to
flooding. flooding.
Link without multicast routing: Link without multicast routing:
The IP system should use as the MSNIP managed range the default SSM To ensure backwards compatibility with existing receivers, MSNIP
range of 232/8 defined in [6]. This allows directly connected does not try to control traffic on a router-less link. It does so
receivers to perform the router side of the MSNIP protocol and by defining the MSNIP managed range to be empty. Although it would
control the source transmission within the default SSM range. be possible to control multicast transmission on a shared link not
connected to a multicast routed infrastructure, MSNIP operation
would require that receivers were capable of actively participating
in the protocol. Source control would work by defining an address
range within which sources would not transmit until directly
contacted by a receiver (for example the default IPv4 SSM range of
232/8 [6]). The drawback would be that a non MSNIP capable receiver
joining a group through IGMP would have no way of getting the
source to transmit. Relying on triggered IGMP messages from legacy
receivers to control transmission would not be robust either.
5. Requesting and Receiving Notifications 5. Requesting and Receiving Notifications
Like IGMP, MSNIP is an asymmetric protocol specifying different Like IGMP, MSNIP is an asymmetric protocol specifying different
behaviour for systems wishing to source traffic and for multicast behaviour for systems wishing to source traffic and for multicast
routers. Host IP systems multicast Host Interest Solicitation messages routers. Host IP systems multicast Host Interest Solicitation messages
to register for notification with their first-hop routers. Routers to register for notification with their first-hop routers. Routers
unicast Router Receiver Membership Reports to IP systems to notify them unicast Router Receiver Membership Reports to IP systems to notify them
of the arrival of the first or departure of the last receivers for a of the arrival of the first or departure of the last receivers for a
session. Note that a system may perform at the same time both of the session. Note that a system may perform at the same time both of the
skipping to change at page 18, line 15 skipping to change at page 18, line 15
8.3. IPv4 Header Fields 8.3. IPv4 Header Fields
Like all other IGMP messages, MSNIP messages are encapsulated in Like all other IGMP messages, MSNIP messages are encapsulated in
IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message
described in this document is sent with an IP Time-to-Live of 1, and described in this document is sent with an IP Time-to-Live of 1, and
carries an IP Router Alert option [RFC-2113] in its IP header. carries an IP Router Alert option [RFC-2113] in its IP header.
8.4. IPv6 Header Fields 8.4. IPv6 Header Fields
MLD messages are a sub-protocol of the Internet Control Message MLD messages are a sub-protocol of the Internet Control Message
Protocol (ICMPv6 [9] ). MSNIP messages are identified in IPv6 packets by Protocol (ICMPv6 [5] ). MSNIP messages are identified in IPv6 packets by
a preceding Next Header value of 58. All MSNIP messages described in a preceding Next Header value of 58. All MSNIP messages described in
this document are this document are
sent with a link-local IPv6 Source Address (or the unspecified address, sent with a link-local IPv6 Source Address (or the unspecified address,
if a valid link-local address is not available), an IPv6 Hop Limit of 1, if a valid link-local address is not available), an IPv6 Hop Limit of 1,
and an IPv6 Router Alert option .CITE RAv6 in a Hop-by-hop Options and an IPv6 Router Alert option .CITE RAv6 in a Hop-by-hop Options
header. header.
9. Constants Timers and Default Values 9. Constants Timers and Default Values
Robustness Variable Robustness Variable
skipping to change at page 19, line 16 skipping to change at page 19, line 16
The interval used by routers to send out a set of Membership Report The interval used by routers to send out a set of Membership Report
messages when the receiver membership changes for a specific messages when the receiver membership changes for a specific
system. Default: 1 second. system. Default: 1 second.
10. Possible Optimisations 10. Possible Optimisations
10.1. Suppressing HIS Messages 10.1. Suppressing HIS Messages
A possible optimisation for MSNIP is to suppress the transmission A possible optimisation for MSNIP is to suppress the transmission
of Host Interest Solicitation messages from the source address of an IP of Host Interest Solicitation messages from the source address of an IP
system for which no local application has registered interest. Apart system for which no local application has registered interest. In
from the saving is wasted bandwidth, not transmitting HIS messages addition to conserving bandwidth, not transmitting HIS messages prevents
prevents remote receivers for groups with no matching source application remote receivers for groups with no matching source application from
from creating transmission record state in the host system. creating transmission record state in the host system.
10.2. Host Stack Filtering 10.2. Host Stack Filtering
Legacy applications that have not been coded with MSNIP support can Legacy applications that have not been coded with MSNIP support can
still be prevented from waisting first-hop link bandwidth by filtering still be prevented from waisting first-hop link bandwidth by filtering
transmitted packets at the operating system level. Even though such transmitted packets at the operating system level. Even though such
applications will not register for MSNIP notifications with the host applications will not register for MSNIP notifications with the host
operating system, if the OS is MSNIP capable and the application is operating system, if the OS is MSNIP capable and the application is
transmitting data to an MSNIP managed group for which there are no transmitting data to an MSNIP managed group for which there are no
transmit records, the OS can safely filter the packets and not transmit transmit records, the OS can safely filter the packets and not transmit
skipping to change at page 20, line 33 skipping to change at page 20, line 33
Discovery protocol. Discovery protocol.
This temporary flooding can be avoided if the host OS holds off This temporary flooding can be avoided if the host OS holds off
notifying MSNIP capable applications that they can transmit until it notifying MSNIP capable applications that they can transmit until it
receives an MRD advertisement and learns the SSM configuration for the receives an MRD advertisement and learns the SSM configuration for the
network. This behaviour has the drawback that it is not compatible with network. This behaviour has the drawback that it is not compatible with
legacy networks with no MRD deployment. In such a network the host OS legacy networks with no MRD deployment. In such a network the host OS
has to be able to determine after a configurable period that MRD is not has to be able to determine after a configurable period that MRD is not
enabled and hence all multicast applications wishing to source traffic enabled and hence all multicast applications wishing to source traffic
should be notified to transmit. A good default value for this period is should be notified to transmit. A good default value for this period is
the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [7]. the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [4].
Late router startup is harder to deal with. Hosts that start up Late router startup is harder to deal with. Hosts that start up
before the multicast router may time out waiting for an MRD before the multicast router may time out waiting for an MRD
advertisement and instruct all MSNIP capable multicast source advertisement and instruct all MSNIP capable multicast source
applications to transmit data. One way to work around this problem is to applications to transmit data. One way to work around this problem is to
configure the host OS to wait forever for an MRD advertisement before configure the host OS to wait forever for an MRD advertisement before
instructing MSNIP applications to transmit. instructing MSNIP applications to transmit.
11. Security Considerations 11. Inter-operation with IGMP / MLD Proxying
MSNIP is intended for use on networks with multicast servers
offering a large number of potential sessions. Although unlikely it is
possible to deploy such a server behind an IGMP / MLD Proxy [12].
If a device performing IGMP / MLD Proxying wishes to proxy MSNIP,
it MUST forward MSNIP Host Interest Solicitation messages that are
received on downstream interfaces to its upstream interface. No special
treatment is required for MSNIP Receiver Membership Reports as they are
unicast to the target host.
In addition to the forwarding of MSNIP messages, an IGMP proxy MUST
operate the Multicast Router Discovery protocol [3] on all its
downstream interfaces and advertise the MSNIP capability option (section
4.1.1) and SSM address range option (section 4.1.2). The MSNIP
capability option should be advertised on downstream interfaces only if
it is included in MRD messages received on the upstream interface. The
address range to be included in the SSM Range option MUST be determined
by MRD and IGMP messages received on the upstream interface of the proxy
according to the rules in section 4.2.
In addition to the forwarding of MSNIP messages, an MLD proxy MUST
operate the IPv6 Neighbor Discovery protocol. The MSNIP capability
option should be advertised on downstream interfaces when it is included
in IPv6 Neighbor Discovery messages received on the upstream interface.
12. Security Considerations
We consider the ramifications of a forged message of each type. As We consider the ramifications of a forged message of each type. As
described in [1] IPSEC AH can be used to authenticate IGMP messages if described in [1] IPSEC AH can be used to authenticate IGMP messages if
desired. desired.
11.1. Receiver Membership Report attacks 12.1. Receiver Membership Report attacks
A DoS attack on a host could be staged through forged Receiver A DoS attack on a host could be staged through forged Receiver
Membership Report messages. The attacker can send a large number of Membership Report messages. The attacker can send a large number of
reports, each with a large number of TRANSMIT records and a holdtime reports, each with a large number of TRANSMIT records and a holdtime
field set to a large value. The host will have to store and maintain the field set to a large value. The host will have to store and maintain the
transmission records specified in all of those reports for the duration transmission records specified in all of those reports for the duration
of the holdtime. This would consume both memory and CPU cycles in the of the holdtime. This would consume both memory and CPU cycles in the
host. host.
Forged Receiver Membership Report messages from the local network Forged Receiver Membership Report messages from the local network
skipping to change at page 21, line 40 skipping to change at page 22, line 23
involved and are left up to the routing protocol security. involved and are left up to the routing protocol security.
HOLD records in forged Receiver Membership Report messages are not HOLD records in forged Receiver Membership Report messages are not
a significant threat as hosts track the individual interests of each a significant threat as hosts track the individual interests of each
first-hop router separately. Only by forging the source address of the first-hop router separately. Only by forging the source address of the
report message so that is appears to have originated from a real first- report message so that is appears to have originated from a real first-
hop router can the attacker cause the source to stop transmitting to a hop router can the attacker cause the source to stop transmitting to a
group that has valid receivers. Such forged messages can be detected by group that has valid receivers. Such forged messages can be detected by
the router itself. the router itself.
11.2. Host Interest Solicitation attacks 12.2. Host Interest Solicitation attacks
Forged Host Interest Solicitation messages can have two effects: Forged Host Interest Solicitation messages can have two effects:
o When non-existent source addresses are used the solicitation messages o When non-existent source addresses are used the solicitation messages
can create unwanted host record state on attached routers for the can create unwanted host record state on attached routers for the
duration of the holdtime specified in the message. duration of the holdtime specified in the message.
o When a source address corresponding to an existing host is used in the o When a source address corresponding to an existing host is used in the
forged HIS message, receipt of the message by attached routers will forged HIS message, receipt of the message by attached routers will
cause them to transmit Receiver Membership Reports messages for any cause them to transmit Receiver Membership Reports messages for any
multicast destination addresses with receivers for the target host. multicast destination addresses with receivers for the target host.
Although no additional state will be created in routers or hosts from Although no additional state will be created in routers or hosts from
this attack, bandwidth and CPU is wasted in both the first-hop routers this attack, bandwidth and CPU is wasted in both the first-hop routers
and the target host. and the target host.
Just like for the Receiver Membership Report message, attacks using Just like for the Receiver Membership Report message, attacks using
the Host Interest Solicitation message can be reduced by requiring the the Host Interest Solicitation message can be reduced by requiring the
use of the Router-Alert option on the message. use of the Router-Alert option on the message.
11.3. MSNIP Managed Range Discovery 12.3. MSNIP Managed Range Discovery
As discussed in [7] it is possible for directly connected systems As discussed in [4] it is possible for directly connected systems
to send forged Multicast Router Advertisement messages containing the to send forged Multicast Router Advertisement messages containing the
SSM Range Discovery option. As the SSM Range Discovery option determines SSM Range Discovery option. As the SSM Range Discovery option determines
the MSNIP managed range under IPv4, such forged messages can temporarily the MSNIP managed range under IPv4, such forged messages can temporarily
replace the managed range map with incorrect information in receiving replace the managed range map with incorrect information in receiving
hosts. An incorrect mapping can have two effects: hosts. An incorrect mapping can have two effects:
o Applications using a multicast destination address within the real SSM o Applications using a multicast destination address within the real SSM
range that have no valid receivers can be tricked into thinking that range that have no valid receivers can be tricked into thinking that
their chosen destination address is no longer an SSM address and will their chosen destination address is no longer an SSM address and will
therefore start transmitting data. therefore start transmitting data.
o Applications using group addresses outside the valid SSM range can be o Applications using group addresses outside the valid SSM range can be
tricked into thinking that they are using an SSM destination address tricked into thinking that they are using an SSM destination address
and therefore prevented from transmitting data. and therefore prevented from transmitting data.
The Multicast Router Discovery SSM Range Option specification The Multicast Router Discovery SSM Range Option specification
suggests that a router receiving a Multicast Router Advertisement with suggests that a router receiving a Multicast Router Advertisement with
an inconsistent SSM Range Option log the event to the operator. Such an inconsistent SSM Range Option log the event to the operator. Such
logging will enable tracking of this type of attack. logging will enable tracking of this type of attack.
12. IANA Considerations 13. IANA Considerations
This document introduces the following new types and options that This document introduces the following new types and options that
require allocation by IANA: require allocation by IANA:
o Two new IGMP messages for Host Interest Solicitation and Receiver o Two new IGMP messages for Host Interest Solicitation and Receiver
Membership Report. Each of these messages requires a new IGMP type Membership Report. Each of these messages requires a new IGMP type
value to be assigned by IANA [11]. value to be assigned by IANA [11].
o The new MSNIP Operation option for the Multicast Router Discovery o The new MSNIP Operation option for the Multicast Router Discovery
protocol. This option requires a new MRD type value to be assigned by protocol. This option requires a new MRD type value to be assigned by
IANA. IANA.
o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6 o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6
protocol. This option requires a new NDP / ICMPv6 type value to be protocol. This option requires a new NDP / ICMPv6 type value to be
assigned by IANA. assigned by IANA.
13. Acknowledgments 14. Acknowledgments
The authors would like to thank Dave Thaler and Jon Crowcroft for their The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless
contribution to this specification. Eckert and Haixiang He for their contribution to this specification.
14. Authors' Addresses 15. Authors' Addresses
Bill Fenner Bill Fenner
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
One Park Drive, Suite 400 One Park Drive, Suite 400
skipping to change at page 24, line 4 skipping to change at page 24, line 23
AT&T Labs - Research AT&T Labs - Research
75 Willow Road 75 Willow Road
Menlo Park, CA 94025 Menlo Park, CA 94025
fenner@research.att.com fenner@research.att.com
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
One Park Drive, Suite 400 One Park Drive, Suite 400
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
bkhabs@nc.rr.com bkhabs@nc.rr.com
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
holbrook@cisco.com holbrook@cisco.com
Isidor Kouvelas Isidor Kouvelas
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
kouvelas@cisco.com kouvelas@cisco.com
15. References 16. Normative References
[1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet
Group Management Protocol, Version 3", RFC 3376. Group Management Protocol, Version 3", RFC 3376.
[2] S. Kent, R. Atkinson, "Security Architecture for the Internet [2] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for
Protocol.", RFC 2401. IPv6", work in progress, <draft-vida-mld-v2-??.txt>, October 2002.
[3] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In
Independent Multicast - Sparse Mode (PIM-SM): Protocol Progress, <draft-ietf-idmr-igmp-mrdisc-08.txt>, 2001.
Specification (Revised)", Work In Progress, <draft-ietf-pim-sm-
v2-new-??.txt>, 2002.
[4] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 [4] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in
Multicast Address Allocation", Best Current Practices, <draft-ietf- progress, <draft-ietf-magma-mrdssm-02.txt>, November 2002.
iana-IPv4-mcast-guidelines-00.txt>, 2001.
[5] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In [5] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6)
Progress, <draft-ietf-idmr-igmp-mrdisc-08.txt>, 2001. for the Internet Protocol Version 6 (IPv6)", RFC 2463.
[6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in [6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in
progress, <draft-ietf-ssm-arch-00.txt>, 21 November 2001. progress, <draft-ietf-ssm-arch-00.txt>, 21 November 2001.
[7] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in [7] S. Kent, R. Atkinson, "Security Architecture for the Internet
progress, <draft-ietf-magma-mrdssm-02.txt>, November 2002. Protocol.", RFC 2401.
[8] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for [8] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711.
IPv6", work in progress, <draft-vida-mld-v2-05.txt>, October 2002.
[9] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) 17. Informative References
for the Internet Protocol Version 6 (IPv6)", RFC 2463.
[10] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711. [9] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress, <draft-ietf-pim-sm-
v2-new-??.txt>, 2002.
[11] Fenner, W., "IANA Considerations for IGMP", [10] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4
Multicast Address Allocation", Best Current Practices, <draft-ietf-
iana-IPv4-mcast-guidelines-00.txt>, 2001.
[11] W. Fenner, "IANA Considerations for IGMP",
http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP
57), February 2002. 57), February 2002.
[12] W. Fenner, H. He, B. Haberman, H. Sandick, "IGMP / MLD-based
Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp-
proxy-01.txt, November, 2002.
 End of changes. 38 change blocks. 
62 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/