INTERNET-DRAFT Scoping Filters for SSM H. Holbrook Expires Apr 19, 2004 Cisco Systems 19 Oct 2003 Scoping Filters for Source-Specific Multicast Status of this Memo 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. 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 [RFC 2119]. Holbrook [Page 1] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 Abstract This document describes a method of providing scope-limited Source- Specific Multicast (SSM) channels by filtering at boundary routers. The filtering prevents SSM traffic from being forwarded through a scope boundary. Each administrative domain that wishes to enforce scoping can choose the sub-range of SSM channels that it wishes to scope -- no globally-scoped address range is defined. The method described here does not require extending the current SSM range allocation to include a new "scoped SSM" range. The method described is primarily intended to provide scoping for IPv4 SSM channels, since IPv6 integrates multicast scoping into the basic addressing architecture. 1. Introduction Source-specific multicast [SSM] provides a number of benefits for hosts and network administrators. It greatly increases the number of available multicast addresses, and in doing so allows hosts to autonomously allocate addresses without deferring to a global allocation authority. Its more straightforward protocol operation (when compared with Any-Source Multicast or ASM) is expected to allow for more transparent network management and easier debugging. RFC 2365 [RFC2365] describes a scheme by which Any-Source Multicast addresses can be "scoped" so that they are unique within a single topological subset of the Internet. [IPV6-SCOPE] describes a similar scheme for IPv6. As of this writing, IPv4 addresses in the range 239/8 are allocated by IANA as scoped ASM multicast addresses. Scoped addresses are essential for many reasons with ASM (particularly for IPv4) -- they allow multicast address allocation to be performed locally within the scoped domain, relying on a purely local allocation policy, and they avoid the need to defer to an Internet-wide address allocation mechanism to ensure that addresses are uniquely assigned to applications. (Today, allocations of globally-routable addresses are either done manually or using GLOP [RFC3180].) In addition to providing localized allocation, any traffic sent to a scoped address must be contained within some region of the network that is "close to" the originator of the traffic. Unlike ASM, scoping is not required for SSM in order to ease the address allocation problem. SSM solves this problem by allowing the same channel destination addresses to be simultaneously used by different sources. The traffic containment provided by the use of scoped addresses is useful for SSM in some cases. Some example scenarios where it may be useful are: SSM traffic is not allowed to exit an enterprise network except when sourced by some set of "blessed" externally-visible servers. Holbrook [Page 2] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 SSM channels are used internally to distribute routing information internally within a routing domain. This traffic must not be allowed to exit the routing domain. This document describes how the administrator of a network can scope some subset (possibly all) of the existing SSM address range for traffic sourced within that network without impacting the ability to receive externally-sourced channels. This solution does not require extending the existing SSM address space. 2. Defining Scoping for SSM A set of router interfaces is used to define a "scope boundary." Each interface that is part of the scope boundary is called a "boundary interface." A set of channel addresses R ("the scoped channel range") is associated with the scope boundary. Filtering at each boundary router ensures that no packet sent on any channel in R is allowed to pass out of any of the boundary interfaces. If the set of boundary interfaces completely encloses a region (i.e., there are no "holes" in the boundary) then no SSM traffic from R can escape the region. This solution has the following properties: 2.1. Flexible egress filtering It allows the scope boundary to filter all outgoing SSM traffic matching a range of source addresses, a range of destination addresses, or both. 2.2. No ingress filtering It does not limit the ability of systems inside the scope boundary to receive SSM traffic sent by sources outside the domain. It is important to emphasize that SSM scope filtering blocks traffic going *out of* the scoped region, but not traffic coming into it. This is distinct from ASM scope zones in which bidirectional filtering is applied at a scope boundary. 2.3. No global agreement It does not require any global agreement of the SSM scoped range. It is not necessary for the IETF to designate one specific range as a "blessed" SSM scoped range. Scoping can be applied within the existing allocated SSM range. Holbrook [Page 3] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 2.4. No extension of the IPv4 SSM address range Scoping can be performed withing the existing IPv4 address range allocated to SSM (232/8). This simplifies hosts and routers (compared to a solution in which a new scoped range is allocated) by avoiding the need to communicate, agree upon, and configure some new address range not in 232/8 to have SSM semantics. 3. Specifying the scoped channel range A scoped channel range R defines a subset of all possible SSM channels. A scoped range may be defined by specifying a set of source addresses, a set of destination addresses, or a set of channels. Some possible scoped ranges: All channels with destination address in 232.0.0.0/8 All channels with destination address in 232.239.0.0/16 All channels with source address in 10.0.0.0/8 All channels with source address in 192.168.0.0/16 or 192.168.239.0/24 All channels with source address not in 192.168.0.0/16 All channels with source address in 192.168.0.0/16 and destination address in 232.239.0.0/16 4. Implementing SSM scoping Traffic scoping is ensured by simply configuring the scope boundary routers to prevent traffic in the scoped range R from exiting the scoped region. A boundary router ignores any reception request (PIM-SSM join and/or IGMP/MLD reports) for any channel in the scoped range R that arrives on any interface that is part of the scope boundary. A reception request (joins and IGMP/MLD messages) for a channel in the scoped range R is permitted out a boundary interface without hindrance, and any SSM traffic received on a scoped interface is allowed to pass into the scoped region normally. 4.1. Scoping for a stub region A set of boundary interfaces enclose a "stub region" if they do not provide transit for multicast traffic. That is, there exists no SSM Holbrook [Page 4] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 channel with a source outside the scoped region for which the delivery path to some receiver also outside the scoped region passes through some boundary interface. In a stub region, there are no restrictions on the allowed form of the scoped channel range R. The scope boundary may include the entire SSM destination address range, some subset of the SSM destination address range, or some subset of the SSM channels selected by sources and destinations. 4.2. Scoping for a transit network A group of scope boundary interfaces are part of a transit network if some SSM channel may be required to pass through the scoped region on its way to some potential receiver. In this case, the traffic must enter through one boundary interface and exit through another. If the scoped region is also a transit network, the scoped range R must be qualified by a set of source addresses that are known to be contained within the scoped region. If the scoped range is not thus qualified, then SSM traffic sent by sources outside the region will not be allowed to transit the region. 5. Deployment considerations It is expected that the network administrator who defines an SSM scoped region knows whether the region is a stub or transit region, and can thus properly select the channel range. Similarly, it is expected that the internal host address range is known. In a stub network, it may be desirable to prevent *any* traffic from exiting through the scoped boundary except that from a small number of "blessed" sources. These might represent servers that specifically provide externally-visible content, similar to an externally-facing web server. A simple method to advertise the scoped (or unscoped) address range might be to place it on a web page. In order to implement a complete solution of scoping, an address allocation API for SSM is required that allows an application to request a channel address from within the scoped address range. As the operating system has (as of yet) no means to know the scoped range, an application that wishes to source scoped SSM traffic must provide the scoped range to the operating system when requesting a channel address. This API is defined in a related document [TBD]. Holbrook [Page 5] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 6. Security Considerations This document does not consider mechanisms that ensure that there are no "leaks" from the scoped region, or that ensure all border routers are consistently configured like [MZAP]. Thus, the "tightness" of the scope boundary depends on proper configuration by the network administrator. The mere act of advertising that some range R is scoped (on a web page, for instance) does not ensure that the scoped range is actually enforced. Thus if scoping is used as a security mechanism, an attacker may attempt to elicit a source to send confidential information to an unscoped address by trying to trick a sender to sending to a an unscoped address. The method described in this document should not be considered as an alternative to strong encryption techniques [IPSEC] when strong guarantees of traffic containment are required. Rather, it may be used in addition to such techniques or as a way of limiting the usage of network resources on some interfaces. 7. IANA Considerations This document defines no new address spaces and does not impact IANA. 8. IPv6 Considerations (Note: this section will be integrated with the document in a later revision.) IPv6 provides administrative scoping through the use of the "scope" field in the SSM channel destination address [RFC3513, RFC3306]. An application that wishes to scope-limit its IPv6 SSM traffic can select an appropriately scoped address. A configured multicast scope boundary blocks traffic sent to a scoped address, per the rules in [IPV6-SCOPE]. The scoping rules for the source (unicast) IPv6 address are only defined for link-local and global addresses, to date. The address scoping methods described in RFCs 3513 and 3306 block all SSM channels of a particular scope at a boundary router for that scope. By contrast, the methods described in this document selectively block only a subset of all channel addresses at a scope boundary. The method described here applies to addresses with no inherent scope (other than the global scope) -- the range over which a channel is routed is determined only by the scope boundaries that filter it. It remains to be decided if the mechanisms described in this document will be useful for IPv6, or if the existing methods of [IPV6-SCOPE] are sufficient. For example, it remains to be decided if it is desirable to Holbrook [Page 6] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 scope-limit an (S,G) channel when S is a global IPv6 address and G is a multicast address with global scope, 9. Summary This document describes a simple mechanism to ensure that systems outside of the scope boundary cannot receive SSM traffic sourced from inside it. It requires configuration of unidirectional traffic filters on the set of boundary routers that form the scoped region boundary. Scoping can be applied to any subset of the SSM destination address range without compromising the ability of hosts inside the scoped boundary to receive SSM traffic sent by outside sources. The scoped channel range need not be qualified to a particular set of source addresses, except in the case of a transit network. The source address range can be chosen autonomously by the network that desires scoping within the existing allocated SSM range. 10. Acknowledgments 11. Normative References [RFC3306] B. Haberman, D. Thaler. Unicast-Prefix-based IPv6 Multicast Addresses. August 2002. [RFC3513] R. Hinden, S. Deering. Internet Protocol Version 6 (IPv6) Addressing Architecture. April 2003. [SSM] H. Holbrook, B. Cain. Source-Specific Multicast. Work in Progress. October 2003. 12. Informative References [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol.", RFC 2401. [IPV6-SCOPE] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, A. Onoe, B. Zill. IPv6 Scoped Address Architecture. Work in Progress. June 2003. [RFC2365] D. Meyer. Administratively Scoped IP Multicast. July 1998. [RFC2776] M. Handley, D. Thaler, R. Kermode. Multicast-Scope Zone Announcement Protocol (MZAP). February 2000. [RFC3180] D. Meyer, P. Lothberg. GLOP Addressing in 233/8. September 2001, RFC 3180. Holbrook [Page 7] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 Authors' Addresses Hugh Holbrook Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 holbrook@cisco.com Intellectual Property Rights Notice 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 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. Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Holbrook [Page 8] INTERNET-DRAFT Scoping Filters for SSM 19 Oct 2003 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. This document expires Apr 19, 2004. Holbrook [Page 9]