to ensure that each sender uses a unique destination address or SPI.
A problem arises if a receiver subscribes simultaneously to two
unrelated channels using IPsec whose sources happen to be using the
same IP destination address (IPDA) and the same IPsec SPI. Because
the channel destination addresses are allocated autonomously by the
senders, any two hosts can simultaneously use the same destination
address, and there is no reasonable means to ensure that this does
not happen. The <IPDA,SPI> tuple, however, consists of 56 bits that
are generally randomly chosen (24 bits of the IP destination and 32
bits of the SPI), and a conflict is unlikely to occur through random
chance.
If such a collision occurs, a receiver will not be able to
simultaneously receive IPsec-protected traffic from the two colliding
sources. A receiver can detect this condition by noticing that it is
receiving traffic from two different sources with the same SPI and
the same SSM destination address.
7.3. Denial of Service
A subscription request creates (S,G) state in a router to record the
subscription, invokes processing on that router, and possibly causes
processing at neighboring routers. A host can mount a denial-of-
service attack by requesting a large number of subscriptions. Denial
of service can result if:
- a large amount of traffic arrives when it was otherwise
undesired, consuming network resources to deliver it and host
resources to drop it;
- a large amount of source-specific multicast state is created in
network routers, using router memory and CPU resources to store
and process the state; or
- a large amount of control traffic is generated to manage the
source-specific state, using router CPU and network bandwidth.
To reduce the damage from such an attack, a router MAY have
configuration options to limit, for example, the following items:
- The total rate at which all hosts on any one interface are
allowed to initiate subscriptions (to limit the damage caused by
forged source-address attacks).
- The total number of subscriptions that can be initiated from any
single interface or host.
Any decision by an implementor to artificially limit the rate or
number of subscriptions should be taken carefully, however, as future
applications may use large numbers of channels. Tight limits on the
rate or number of channel subscriptions would inhibit the deployment
of such applications.
A router SHOULD verify that the source of a subscription request is a
valid address for the interface on which it was received. Failure to
do so would exacerbate a spoofed-source address attack.
We note that these attacks are not unique to SSM -- they are also
present for any-source multicast.
7.4. Spoofed Source Addresses
By forging the source address in a datagram, an attacker can
potentially violate the SSM service model by transmitting datagrams
on a channel belonging to another host. Thus, an application
requiring strong authentication should not assume that all packets
that arrive on a channel were sent by the requested source without
higher-layer authentication mechanisms. The IPSEC Authentication
Header [RFC2401, RFC4301] may be used to authenticate the source of
an SSM transmission, for instance.
Some degree of protection against spoofed source addresses in
multicast is already fairly widespread, because the commonly deployed
IP multicast routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a
"reverse-path forwarding check" that validates that a multicast
packet arrived on the expected interface for its source address.
Routing protocols used for SSM SHOULD incorporate such a check.
Source Routing [RFC791] (both Loose and Strict) in combination with
source address spoofing may be used to allow an impostor of the true
channel source to inject packets onto an SSM channel. An SSM router
SHOULD by default disallow source routing to an SSM destination
address. A router MAY have a configuration option to allow source
routing. Anti-source spoofing mechanisms, such as source address
filtering at the edges of the network, are also strongly encouraged.
7.5. Administrative Scoping
Administrative scoping should not be relied upon as a security
measure [ADMIN-SCOPE]; however, in some cases it is part of a
security solution. It should be noted that no administrative scoping
exists for IPv4 source-specific multicast. An alternative approach
is to manually configure traffic filters to create such scoping if
necessary.
Furthermore, for IPv6, neither source nor destination address scoping
should be used as a security measure. In some currently-deployed
IPv6 routers (those that do not conform to [SCOPINGv6]), scope
boundaries are not always applied to all source address (for
instance, an implementation may filter link-local addresses but
nothing else). Such a router may incorrectly forward an SSM channel
(S,G) through a scope boundary for S.
8. Transition Considerations
A host that complies with this document will send ONLY source-
specific host reports for addresses in the SSM range. As stated
above, a router that receives a non-source-specific (e.g., IGMPv1 or
IGMPv2 or MLDv1 [RFC2710]) host report for a source-specific
multicast destination address MUST ignore these reports. Failure to
do so would violate the SSM service model promised to the sender:
that a packet sent to (S,G) would only be delivered to hosts that
specifically requested delivery of packets sent to G by S.
During a transition period, it would be possible to deliver SSM
datagrams in a domain where the routers do not support SSM semantics
by simply forwarding any packet destined to G to all hosts that have
requested subscription of (S,G) for any S. However, this
implementation risks unduly burdening the network infrastructure by
delivering (S,G) datagrams to hosts that did not request them. Such
an implementation for addresses in the SSM range is specifically not
compliant with Section 5.2 of this document.
9. IANA Considerations
IANA allocates IPv4 addresses in the range 232.0.0.1 through
232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to
FF3x::7FFF:FFFF. These addresses are allocated according to IETF
Consensus [IANA-CONSID]. These address ranges are reserved for
services with wide applicability that either require that or would
strongly benefit if all hosts use a well-known SSM destination
address for that service. Any proposal for allocation must consider
the fact that, on an Ethernet network, all datagrams sent to any SSM
destination address will be transmitted with the same link-layer
destination address, regardless of the source. Furthermore, the fact
that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same
link-layer addresses as the reserved IP multicast group range
224.0.0.0/24 must also be considered. Similar consideration should
be given to the IPv6 reserved multicast addresses. 232.0.0.0 and
FF3x::4000:0000 should not be allocated, as suggested above.
Except for the aforementioned addresses, IANA SHALL NOT allocate any
SSM destination address to a particular entity or application. To do
so would compromise one of the important benefits of the source-
specific model: the ability for a host to simply and autonomously
allocate a source-specific multicast address from a large flat
address space.
10. Acknowledgements
The SSM service model draws on a variety of prior work on alternative
approaches to IP multicast, including the EXPRESS multicast model of
Holbrook and Cheriton [EXPRESS], Green’s [SMRP], and the Simple
Multicast proposal of Perlman, et al. [SIMPLE]. We would also like
to thank Jon Postel and David Cheriton for their support in
reassigning the 232/8 address range to SSM. Brian Haberman
contributed to the IPv6 portion of this document. Thanks to Pekka
Savola for a careful review.
11. Normative References
[ETHERv6] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[GMP-SSM] Holbrook, H. and B. Cain, "Using Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for
Source-Specific Multicast", RFC 4604, August 2006.
[IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[IPv6-UBM] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[IPv6-MALLOC] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas.
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August
2006.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD
5, RFC 1112, August 1989.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
12. Informative References
[ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[DVMRP] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, November
1988.
[EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested
Source-Specific Multicast: EXPRESS support for Large-
scale Single-source Applications." Proceedings of ACM
SIGCOMM ’99, Cambridge, MA, September 1999.
[IANA-ALLOC] Internet Assigned Numbers Authority,
http://www.iana.org/assignments/multicast-addresses.
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IGMPv2] Fenner, W., "Internet Group Management Protocol,
Version 2", RFC 2236, November 1997.
[MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678,
January 2004.
[PIM-DM] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000.
[SCOPINGv6] Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
and B. Zill, "IPv6 Scoped Address Architecture", RFC
4007, March 2005.
[SIMPLE] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z.
Wang, T. Maufer, C. Diot, and M. Green, "Simple
Multicast: A Design for Simple, Low-Overhead
Multicast", Work in Progress, October 1999.
[SMRP] Green, M. "Method and System of Multicast Routing for
Groups with a Single Transmitter." United States
Patent Number 5,517,494.
Authors’ Addresses
Brad Cain
Acopia Networks
EMail: bcain99@gmail.com
Hugh Holbrook
Arastra, Inc.
P.O. Box 10905
Palo Alto, CA 94303
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).