Internet DRAFT - draft-giuliano-mboned-v6mcast-framework
draft-giuliano-mboned-v6mcast-framework
INTERNET-DRAFT Leonard Giuliano
draft-giuliano-mboned-v6mcast-framework-01.txt Juniper Networks
Greg Shepherd
Procket Networks
Matthew Davy
Indiana University
Expires: December 2003 June 2003
Framework for Deploying Interdomain IPv6 Multicast
<draft-giuliano-mboned-v6mcast-framework-01.txt>
Status of this Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a product of an individual. Comments are solicited
and should be addressed to the author(s).
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Leonard Giuliano, Greg Shepherd and Matthew Davy [Page 1]
INTERNET-DRAFT Expires: December 2003 June 2003
Abstract
This document describes an architectural framework for deploying
interdomain multicast for IPv6 with simplicity, scalability,
efficiency and security as the primary goals, applying the lessons
learned from deploying IPv4 multicast. In order to achieve this
objective, the deprecation of network-based source discovery, and
therefore Any Source Multicast, is proposed. Source-Specific
Multicast is proposed as the service model supported for deploying
interdomain IPv6 multicast. The architectural components responsible
for providing source discovery are also discussed.
Leonard Giuliano, Greg Shepherd and Matthew Davy [Page 2]
INTERNET-DRAFT Expires: December 2003 June 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Source Discovery . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Network-based vs. Application-based Source
Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Interdomain Multicast for IPv6 . . . . . . . . . . . . . . . . 6
4. Intradomain Multicast for IPv6 . . . . . . . . . . . . . . . . 7
4.1. Other Service Models for Intradomain IPv6 Mul-
ticast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 8
5.1. Control Plane Vulnerabilities . . . . . . . . . . . . . . . 8
5.2. Data Plane Vulnerabilities. . . . . . . . . . . . . . . . . 9
6. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References. . . . . . . . . . . . . . . . . . . 11
9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 13
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 13
Leonard Giuliano, Greg Shepherd and Matthew Davy [Page 3]
INTERNET-DRAFT Expires: December 2003 June 2003
1. Introduction
The deployment of IPv4 multicast has been much slower than initially
predicted. While there are many reasons for this slow adoption, one
of the dominant factors has been the complexity involved in
implementing and deploying multicast. In the past, interim
workarounds were applied to address short-term deficiencies in the
architecture. Unfortunately, many of these temporary fixes have
become integral components that have proven difficult to "undeploy"
and have stifled future developments and enhancements. This document
proposes an architecture for IPv6 that applies the lessons learned
from deploying IPv4 multicast, rather than repeating the mistakes of
the past.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Source Discovery
The majority of the complexity involved in multicast comes from the
assumption that the network is responsible for the discovery of
sources. The receiver of multicast traffic merely requests data for
a given group address. It is the network's job to find all the
sources for this group and deliver their packets to the receiver.
This original model of multicast, where source discovery is a
function of the network layer, is known as Any Source Multicast (ASM)
[RFC1112].
However, with the Source-Specific Multicast [SSM] service model, the
receiving host determines the address of the source(s) through out-
of-band means and requests data for a group from the specified
source(s). By specifying the source in addition to the group, the
network no longer needs to determine all the sources, thus the
function of the network becomes much simpler.
2.1. Network-based vs. Application-based Source Discovery
It should be noted that in the vast majority of cases, the end result
of ASM and SSM is functionally identical. That is, since the
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 2.1. [Page 4]
INTERNET-DRAFT Expires: December 2003 June 2003
predominant implementations and deployments of Protocol Independent
Multicast- Sparse Mode (PIM-SM) [PIM-SM] on the Internet today (the
de facto standard protocol for ASM multicast routing) switchover from
the shared tree to the shortest path tree (SPT) immediately, traffic
is delivered from source to receiver along the SPT. Therefore, since
the end result of ASM and SSM is the same (ie, SPTs), the debate is
not ASM vs. SSM. Rather, the issue is network-based vs. out-of-band
source discovery. For the sake of this discussion, we will assume
the application layer provides this out-of-band function.
Since the original vision of multicast assumes the network will
provide source discovery, multicast protocols have required
mechanisms to support this vision, and these mechanisms generally
have introduced sub-optimal properties. For example, dense protocols
like Distance Vector Multicast Routing Protocol (DVMRP) [DVMRP] and
PIM-DM periodically flood data throughout the domain to inform
routers in the domain of active sources. Sparse protocols like PIM-
SM employ rendezvous points (RPs) so that one router in the domain
will be responsible for being aware of active sources for a given
group range. The mechanisms needed to provision an RP, inform
routers throughout the domain of the identity of the RP, register
sources with the RP, and exchange source information between
different RPs have each contributed a significant amount of
complexity to the architecture. In each case, the primary
disadvantages of these protocols (ie, lack of scalability of flooding
in dense protocols, and the complexity of RP behavior in sparse
protocols) can be attributed to source discovery. Furthermore, IPv4
uses MSDP [MSDP] to distribute active source information between RPs.
With MSDP, all speakers of the protocol must maintain a cache
containing information about every active source on the Internet.
MSDP relies upon an extremely complex set of peer-RPF rules which are
not well understood, are very challenging to troubleshoot and are
often circumvented (for example, by using mesh-groups).
Long ago it was determined that maintaining a list of all the
hostnames or all the websites on the Internet was unwise. This task
was deemed unsuitable even for hosts to provide. However, when the
network provides multicast source discovery, we assume that routers
will provide this exact function.
The main reason why network-based source discovery was deemed
necessary was because it was believed that some multi-source
applications (eg, videoconferencing, online gaming) could only be
supported in this manner. However, Section 1 of [SSM] describes how
even these applications can be supported with application-based
source discovery:
SSM can be used to build multi- source applications where all
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 2.1. [Page 5]
INTERNET-DRAFT Expires: December 2003 June 2003
participants' identities are not known in advance, but the
multi-source "rendezvous" functionality does not occur in the
network layer in this case. Just like in an application that
uses unicast as the underlying transport, this functionality can
be implemented by the application or by an application-layer
library.
[MULT-SSM] and [DISC-SSM] further examine and propose ways to support
multi-source discovery in SSM.
Since network-based source-discovery significantly contributes to the
cost and complexity of the network infrastructure without providing
commensurate functionality and benefit, this document proposes to
deprecate network-based multicast source discovery in IPv6. With
source discovery provided by the application layer, SSM is proposed
as the only service model supported for deploying interdomain IPv6
multicast.
3. Interdomain Multicast for IPv6
The primary issue with interdomain multicast in IPv6 today is the
support for RPs in different domains. In IPv4, MSDP addresses this
problem. However, because of the undesirable properties of MSDP
mentioned earlier, there appears to be little interest for
introducing MSDP to IPv6.
BGMP [BGMP] has been specified as a protocol to provide support for
interdomain multicast in IPv6. Specifically, support for RPs in
different domains is described. However, many believe BGMP is too
complex to be a feasible option for deployment. There are currently
no known implementations of BGMP.
[EMBED] has been proposed to address this issue by embedding the IP
address of the RP within the multicast group address. However, this
would require a new behavior for the PIM-SM protocol, specifically,
sending PIM joins toward an RP in another domain, to be investigated
and specified. And this new behavior would need to be deployed on
all routers over which this multicast traffic would flow.
With network-based source discovery deprecated, there is no longer a
need for PIM-SM RPs in IPv6. Interdomain multicast will work with a
subset of PIM-SM functionality (namely, (S,G) Joins/Prunes). Thus,
interdomain multicast for IPv6 requires no changes to any protocols
and can be deployed with current implementations of PIM-SM.
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 3. [Page 6]
INTERNET-DRAFT Expires: December 2003 June 2003
4. Intradomain Multicast for IPv6
PIM-SM, as defined in [PIM-SM], requires no changes to operate within
an IPv6 domain. Most current intradomain deployments of IPv4
multicast use Anycast RP to provide redundancy and load sharing.
Since Anycast RP relies on MSDP, there is currently no way to provide
this same functionality in IPv6. [Any-PIM] proposes an extension to
the PIM-SM register process to accomplish the internal MSDP
functionality of Anycast RP.
With network-based source discovery deprecated, there is no longer a
need for PIM-SM RPs. Intradomain multicast for IPv6 requires no
changes to any protocols and can be deployed with current
implementations of PIM-SM or BiDir-PIM.
4.1. Other Service Models for Intradomain IPv6 Multicast
There may still be some desire to support other multicast service
models such as ASM and Bidirectional-PIM (BiDir-PIM) [BIDIR] within a
domain. Following the philosophy of "what one does inside one's own
domain is one's own business", this document does not prohibit the
use of ASM or BiDir-PIM for intradomain purposes as long as it does
not leak out to the rest of the Internet. This is somewhat analogous
to using RFC-1918 addressing within a domain.
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 4.1. [Page 7]
INTERNET-DRAFT Expires: December 2003 June 2003
5. Security Considerations
IP Multicast is inherently vulnerable to attack because it allows a
host to create state within the control and data planes of the
network. Network-based source discovery amplifies this problem, as
the mechanisms that enable the network to discover sources generally
increase the likelihood and impact of attacks.
In recent years, IPv4 RPs and other MSDP speakers have been the
victims of DoS attacks during the Ramen and Slammer Worm attacks
[MCAST-DOS]. In both cases, these attacks were not even targeting
the multicast infrastructure. Rather, they inflicted damage
accidentally. Little has been done to harden this infrastructure,
and today IPv4 multicast networks remain vulnerable to attack. This
is because the mechanisms that provide network-based source discovery
are inherently prone to DoS attack.
5.1. Control Plane Vulnerabilities
If, for example, someone on an IPv4 multicast-enabled network
performs a port scan on a /16 multicast range of addresses, the first
hop PIM-SM router will create register messages for each packet sent
to a different group and send these 65k PIM registers to an RP, which
will have to decapsulate and create register state. The RP will then
create MSDP SAs for each s-g tuple and flood 65k SAs to all other
MSDP speakers on the Internet. Even with the strictest of filters in
place, the ASM service model dictates that any host could validly
source multicast traffic for 224.2/16 and 233/8. This means that a
single source could validly create state for 16.8 million different
groups, and the network would have to maintain this state. With
filters in place, the best that could be hoped for is the decreased
probability that an accidental attack (eg, a port scan on a random
multicast address range) will have an impact. For this reason, some
have suggested rate limiting. However, rate limiting control traffic
creates a new vulnerability to DoS attack since it is not possible
(or at least is very difficult) to tell the difference between bad
sources and good ones, and they both must now contend for the
configured limit of resources. Therefore, rate limits reduce the
probability that a router will run out of memory and crash, but
increase the probability that the multicast infrastructure will be
unable to create and maintain state, causing black holes for valid
sources during an attack.
MSDP has not yet been defined, implemented or deployed for use in
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 5.1. [Page 8]
INTERNET-DRAFT Expires: December 2003 June 2003
IPv6, however the DR-RP PIM register process is the same for IPv6 and
IPv4 ASM. Of course the IPv6 group range is much larger. For
example, the IPv6 group range is FF::0/8, so a single host could
validly source to nearly 2^120 groups and the network would be
responsible for maintaining this state.
With network-based source discovery deprecated, there is no need for
PIM-SM RPs, MSDP or the PIM-SM register process. This significantly
reduces the opportunities for a malicious attack. While state
creation is driven both by sources and receivers in ASM, only
receivers can create state in the network with SSM. SSM, like ASM,
is still vulnerable to an (S,G) flood attack, but is not vulnerable
to any of the other control plane attacks mentioned above.
5.2. Data Plane Vulnerabilities
In addition to the control plane vulnerabilities mentioned above, ASM
and BiDir-PIM provide easy targets for DoS attacks in the data plane.
When a receiving host reports interest in a group, it requests and is
delivered packets from ALL sources for that group. There is no way
to prevent delivery of unwanted sources. For example, one malicious
attacker (or misconfigured host) could transmit a high data rate of
unwanted traffic to a group, and all receivers of this group would be
flooded with this traffic.
Since an SSM subscriber explicitly specifies the source, data from
unwanted sources will not be delivered. In order to launch a data
plane attack, a malicious host must spoof the source address of the
SSM channel AND must be on the shortest path from the subscriber to
the source. While this is technically possible, it is significantly
less likely.
6. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 6. [Page 9]
INTERNET-DRAFT Expires: December 2003 June 2003
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
7. Acknowledgments
The authors would like to thank Vijay Gill, John Zwiebel, Tom
Pusateri, Nidhi Bhaskar and Toerless Eckert for their input. Dave
Meyer provided extensive comments on the initial version of this
draft.
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 7. [Page 10]
INTERNET-DRAFT Expires: December 2003 June 2003
8. References
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
[SSM] Holbrook, H., and B. Cain, "Source-Specific Multicast
for IP", draft-ietf-ssm-arch-03.txt. Work in Progress.
8.2. Informative References
[RFC1112] S. Deering, "Host Extensions for IP Multicasting", RFC
1112, August 1989
[PIM-SM] B. Fenner, et. al., "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification
(Revised)", Work in Progress.
[MSDP] Meyer, D., and B. Fenner (Editors), "The Multicast
Source Discovery Protocol (MSDP)",
draft-ietf-msdp-spec-20.txt. Work in Progress.
[BIDIR] M. Handley, et. al., "Bi-directional Protocol
Independent Multicast", draft-ietf-pim-bidir-05.txt,
Work in Progress.
[BGMP] D. Thaler, "Border Gateway Multicast Protocol (BGMP):
Protocol Specification", draft-ietf-bgmp-spec-05.txt,
Work in Progress.
[EMBED] Savola, P., and B. Haberman, "Embedding the Address of
RP in IPv6 Multicast Address",
draft-savola-mboned-mcast-rpaddr-03.txt, Work in
Progress
[Any-PIM] Farinacci, D., and Y. Cai, "Anycast-RP using PIM",
draft-farinacci-pim-anycast-rp-00.txt, Work in
Progress
[MULT-SSM] M. Hoerdt, et al., "Multi-source communications over
SSM networks",
draft-hoerdt-mboned-multisource-ssm-00.txt, Work in
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 8.2. [Page 11]
INTERNET-DRAFT Expires: December 2003 June 2003
Progress
[DISC-SSM] F. Beck, et al., "Source Discovery Protocol in SSM
Networks",
draft-beck-mboned-ssm-source-discovery-protocol-00.txt,
Work in Progress
[MCAST-DOS] T. Pusateri, "Multicast DoS", In Proceedings of MBONED
Working Group, IETF56, March 2003
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol",
draft-ietf-idmr-dvmrp-v3-10.txt, Work in Progress
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 8.2. [Page 12]
INTERNET-DRAFT Expires: December 2003 June 2003
9. Author's Addresses
Leonard Giuliano
Juniper Networks
Email: lenny@juniper.net
Greg Shepherd
Procket Networks
Email: shep@procket.com
Matthew Davy
Indiana University
Email: mpd@iu.edu
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Leonard Giuliano, Greg Shepherd and Matthew Davy Section 10. [Page 13]
