INTERNET-DRAFT Leonard Giuliano Expires December 2003 Juniper Networks Greg Shepherd Procket Networks Matthew Davy Indiana University June 2003 Framework for Deploying IP Multicast in IPv6 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. Abstract This document describes a simple, scalable, efficient and secure architectural framework for deploying multicast for IPv6. In order to achieve this goal, the deprecation of network-based source discovery is proposed. The architectural components responsible for providing source discovery are also described. 1.0 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.0 Source Discovery The majority of the complexity involved in multicast comes from the assumption that the network is responsible for 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 radically 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 predominant implementations and deployments of 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, the multicast protocols have required mechanisms to support this vision, and these mechanisms generally have been sub-optimal. For example, dense protocols like 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. 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) are 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. The additional deficiencies of MSDP are well known and have been thoroughly described in the MSDP working group. 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 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. Since network-based source-discovery unnecessarily contributes to the cost and complexity of the network infrastructure in a significant way, this document proposes to deprecate network-based multicast source discovery in IPv6. With source discovery provided by the application layer, SSM and Bidirectional-PIM (BiDir-PIM) are the only service models necessary for deploying IPv6 multicast. 3.0 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, MSDP has many well-known deficiencies, and there appears to be little interest for introducing these same problems 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, BGMP is very complex, and there are currently no known implementations of BGMP and little evidence that this will change anytime soon. [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- sending PIM joins toward an RP in another domain- to be investigated and specified. 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. Thus, interdomain multicast for IPv6 requires no changes to any protocols and can be deployed with current implementations of PIM-SM. 4.0 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 no way to provide this functionality in IPv6. [Any-PIM] proposes an extension to the PIM-SM register process to accomplish the internal MSDP functionality of Anycast RP. Many of these intradomain IPv4 deployments are already experiencing the functional upper-boundary of PIM-SM RPs and PIM (S,G) state. These networks are continuing to grow beyond these boundaries either configuring the routers to stay on the shared tree - removing part of the the PIM-SM network-based source discovery - or by migrating to BiDir-PIM - removing ALL network-based source discovery. 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. 5.0 Shared Trees in IPv6 It may still be desirable to build shared trees in IPv6 multicast. BiDir-PIM can be used to support shared trees in IPv6. Further discussion of shared trees is outside the scope of this document. 6.0 Security Considerations IP Multicast is inherently vulnerable to attack because is allows a host to create state within the control and data planes of routers. 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 Slammer and Ramen Worm attacks. 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. 6.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 finite 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 for valid sources during an attack. MSDP has not yet been defined, implemented or deployed for use in 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. The only control plane attack to which SSM is still vulnerable is an (S,G) flood attack. 6.2 Data Plane Vulnerabilities In addition to the control plane vulnerabilities mentioned above, the ASM service model is an easy target 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. 7. Acknowledgements The authors would like to thank Vijay Gill, John Zwiebel and Tom Pusateri for their input. 8. 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. 9. 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-PIM] M. Handley, et. al., "Bi-directional Protocol Independent Multicast", draft-ietf-pim-bidir-04.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 10. 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 Expires December 2003