Controlled Multicast Framework

Controlled Multicast Framework Rami Lehtonen Sonera Corporation, Hatanpään valtatie 20, 33100 Tampere, Finland rami.lehtonen@sonera.com Jarmo Harju Tampere University of Technology, Institute of Communications Engineering P.O.Box 553, FIN-33101 Tampere, Finland harju@cs.tut.fi Abstract The IP multicast has not been widely used by current internet service operators, and part of this relates to the nature of multicast, which is designed to allow any host to receive or send multicast traffic to the network. Internet service operators do not want to risk their network operation without sufficient control of the multicast sources and receivers and protection against the Denial of Service (DoS) attacks. In this paper we propose a scheme, which allows operators to add this control part to the existing networks. The solution is lightweight, independent of multicast routing protocols and it does not need modifications to the host interface, namely IGMP or MLD. 1. Introduction There are plenty of audio and video services already available to users in the Internet, and most of them use unicast communication to transport the data between hosts. Many of these services exploit a single source model, where the data originates from a common server to be delivered to end users. Especially in a single source model the IP multicasting can be used to reduce the network bandwidth consumption and to free the server resources for other services by delivering the data to many users with a single transmission. The situation is not always this perfect, because in addition to the possible multicast application specific problems like forward error correction or retransmission of lost packets there are many multicast infrastructure problems unresolved as well. Many of these problems can be categorized under multicast security and control area, and because of these problems, there are still many internet service operators and content/media providers which do not currently support IP multicast in their networks and services. Internet service operators want to protect their networks against uncontrolled multicast and thus real multicast services will be unavailable until most of the current problems are solved. This paper describes a controlled multicast framework, which can be used by the internet service operators to control the multicast receivers and sources. The control mechanisms can be used to improve network performance and to protect the network from DoS attacks. The paper also presents several generic problem areas within the IP multicast that must be solved before actual deployment of multicast services can begin in large scale. We also discuss about internet service operators goals and requirements for the IP multicast network. 2. IP Multicast Model The current multicast model is based on the Steve Deering s [1] seminal work in the late 1980 s. In this model the multicast traffic is sent to a specific multicast group address (G), which can be listened by interested receivers. The network forwards the multicast packets to all members of the multicast group by replicating multicast packets at suitable junctions (e.g. at routers and switches). In general the multicast communication can be divided to three entities; source, receiver and network. Source: The multicast source can start sending traffic to a multicast group without any signalling to the network. Because the destination address contains only the multicast group address, the source does not have any control over the receivers of the multicast traffic. It is purely a multicast network problem to deliver the packets to correct receivers. The multicast address space that identifies the group is 224.0.0.0 239.255.255.255 for IPv4. IPv6 multicast addresses are distinguished from unicast addresses by the value of the high-order octet of the addresses. A value of 0xFF (binary 11111111) identifies an address as a multicast address.

Receiver: The multicast receiver can join any multicast group by using an Internet Group Management Protocol (IGMP) or a Multicast Listener Discovery (MLD) in case of an IPv6 host. Currently IGMP version 2 (comparable to MLDv1 for IPv6 hosts) is commonly in use, which offers the host a possibility to indicate that it wishes to receive multicast packets sent to a specific group address. Version 3 of IGMP [2] (comparable to MLDv2 [3] for IPv6 hosts) allows the host to specify also the multicast source, which can be used to filter specific sources or to join a sourcespecific multicast group [4]. IGMP is used between the receiver and multicast enabled subnet-router. The multicast receiver information is not forwarded further by the multicast routers. Network: The multicast network consists of multicast capable routers that support one or more multicast routing protocols. Examples of such protocols are PIM (SM [5] and DM [6]), DVMRP [7], CBT [8] and MOSPF [9]. The routing protocols react to IGMP messages and create the multicast tree towards the multicast source within the network. The multicast tree is signalled and maintained with these routing protocols. From a single router point of view, it must keep state information regarding each multicast group, which consists mainly of incoming and outgoing interfaces for the multicast traffic. The multicast signalling bears some resemblance to circuit switched signalling in telecommunication networks that opens up the channel between the caller and called party. Due to the facts that any host can receive multicast traffic and the source can send multicast packets without any signalling, the multicast network is rather scalable but very vulnerable e.g. for DoS attacks. It is obvious that there is a need for operators to control multicast source and receiver behaviour. For some applications there is a need for securing the multicast communication by encrypting the multicast traffic or authenticating the multicast source. However, it is rather obvious that for such secure multicast there is also a need for key management, authentication and authorization mechanisms. Things can get rather complicated, which slows down the actual multicast usage. We have taken the approach to keep the control mechanisms as simple as possible and to avoid cryptographic stuff where it is not needed. [10] 3. Operator s View on Multicasting This section covers issues regarding internet service operator as a multicast service provider. First we discuss about operator s goals and requirements for enabling multicast services and then we concentrate on current problems within multicast deployment. 3.1 Goals and Requirements It is obvious that most internet service operators are interested about multicast usage in their networks. Multicast model fits quite nicely to many existing and future multimedia services like for videoconferencing and Internet radio service. Network resources can be used optimally, if one multicast feed serves the need of many customers. Better multicast support in networks would also encourage content and media providers to offer such services and thus increase the amount of service users. The multicast traffic could be priced so that it would be cheaper to access multicast services than traditional unicast services. This would also have an increasing effect on user s consumption of services and potential customers. Currently network management tasks for operators are quite complex issues and enabling multicast in the network could cause some more trouble if the management staff is not fully aware about multicast specific features. One common goal for operators regarding multicast deployment would be easier management of multicast features and rules. What comes to the multicast network operation and control, the operator wants full control for multicast traffic in their own network. Currently this can not be easily achieved due to the open nature of multicast. DoS attacks must be prevented or at least noticed and blocked. Operator should be able to control multicast address space usage as well as the valid receivers and sources within its own network area. From the multicast network point of view the operator must have tools to control multicast state information creation in routers and limit this to only active multicast groups. Currently one way to make a DoS attack is to join many imaginary multicast groups, and the network does not have the means to know whether the group is valid or not. This kind of extra state information in routers would be catastrophic in large scale. Our approach for group control is that the operator has always knowledge about active multicast groups (where active means at least one active source per group). In addition to the active multicast groups the operator could have information about valid sources and receivers per active multicast group. Then it would be possible to control incoming multicast traffic to the operator s network by reducing/filtering inappropriate joins from invalid customers. With the same information the operator could restrict invalid sources from the operator s network to send multicast traffic. Such information can be created by the operator itself or the origin of this information can be an application specific issue. Then it would be also possible to charge for multicast usage, depending on the business model in use. If we want to go further, which we don t do in this paper, we might want to control even the

multicast traffic sent to other operator s network (in addition to multicast scoping) by controlling e.g. the sending of MSDP [11] Source Active messages. To sum up, the operator wants control over multicast groups and its members as well as over the multicast network. Depending on the application in question additional security requirements for the actual multicast traffic and members might be needed. 3.2 Current Problems Before the mass market for multicast applications opens up, several problems need to be solved. Current problems in multicast deployment can be roughly categorized into three areas; service, network management and device problems. Currently the biggest problem around multicast service problems is the lack of services. The internet service operators and content and media providers are certainly interested about multicast usage, but the user does not care whether the transport is unicast or multicast, if the service quality, response time and bandwidth usage are within certain limits. Knowing this is important when services that currently use unicast transport are transformed to multicast transport. Also the pricing must be in line with the quality and the fact that most of the multicast services can not scale to individual needs and requirements of the user, which is possible for unicast services. In addition to these problems the content rights for digital media is a difficult issue, especially in multicast environment. There are political issues, e.g. the multicast source does not know the number of hosts receiving the multicast stream and still the copyright owners must be paid by the number of receiving hosts. Other unresolved technical difficulties include issues from group key management to multicast payment problems. Network management for multicast is demanding, because monitoring, controlling and securing multicast traffic and network is not straightforward. One example of configuration problems is an unconfigured switch that floods multicast traffic out from every port. Even one 2 Mbit/s multicast video stream coming to the switch can halt the other traffic from all ADSL users connected to the switch, even if they are not interested about the stream. Internet service operators need also service level agreements about how they handle multicast routing and exchange information on active sources with other operators. Active sources can be announced with MSDP protocol where source information is sent to MSDP peers (operators). However, MSDP has severe scaling problems if multicasting gets more audience, and already DoS attacks can utilize MSDP Source Active messages to harm the multicast network. Operators also need to filter certain multicast groups in the border routers. What comes to the device problems, computer operating systems and Ethernet adapters are usually already multicast-enabled. The multicast support is also available in many standard routers and could be easily enabled in network, if there would be a desire to launch the service. Multicasting brings problems to the operators with large switched LANs, because not all Ethernet switches are multicast aware. If the Ethernet switch does not support IGMP Snooping [12], Cisco-specific CGMP [13] or similar mechanism to prevent unwanted multicast traffic flooding out from all ports, the network and switch can easily go down with few multicast streams. Similar problem with broader consequences can be happen with Ethernet switches, which are used to connect backbone routers in Internet exchange point. In that case the switch is not able to rely on IGMP messages, because IGMP is not used between routers. The problem must be solved differently, using VLANs, Cisco-specific RGMP [14] or spoofing the multicast routing protocol messages e.g. PIM-SM. In addition to common switches, the cheap ADSL-modems are not always multicast capable. 4. Controlled Multicast Framework Currently in IP multicast networks a source for a certain multicast group or internet service operator do not have much control over the receivers for that multicast group. All hosts that join a multicast group will receive the multicast traffic assuming that multicasting is supported in general. The idea behind controlled multicast framework is to control the multicast receivers and sources for certain multicast groups. This control can be done by the internet service operator or it can be done based on application specific needs e.g. by the multicast source. This is not limited in any way. This section describes the basic mechanisms of controlled multicast, discusses about the requirements for such systems and finally depicts the Multicast Control Protocol () [15], which is used for communication between the network elements in the controlled multicast environment. 4.1 Related Work Several papers around controlling the multicast receivers have been published by IETF as Internet Drafts [16, 17, and 18]. SIM [16] and Xcast [17] approach this problem from the perspective of multicast source and thus do not consider the source control as equally important feature as receiver control. Both these ideas basically try to solve the problem by including a receiver list in multicast packet(s). However, this limits the number of receivers, because the receiver list and the multicast data share the same IP packet, and these solutions also add

heavy packet processing requirements for routers. SGMv6 [18] defines cryptographic mechanisms to control multicast group joins, but it does currently suit for dynamic source-specific groups, because it does not have a possibility to remove members from the multicast tree once they have been registered as a valid receiver. It also requires modifications to MLDv2. 4.2 Main Requirements One possibility to control receivers is to encrypt the multicast traffic. Then we can be sure that only valid receivers (who have the corresponding key) can decrypt those packets, but we have no control over the multicast state creation in routers and thus all interested hosts can join the multicast group and start receiving the encrypted multicast traffic. Also unnecessary state information will be created in routers when a host joins an imaginary multicast group (DoS attacks). Thus one requirement is that the multicast control must be separate from the encryption of the multicast traffic. In some cases it might be also wise to have some control over the multicast sources and let only selected sources send multicast traffic to a certain multicast group. The multicast control system should enable the control of multicast sources and receivers with an accuracy of a single host. Maintaining of the control information should be centralized as much as possible. This simplifies the configuration of the network elements and security associations between them where needed. The routers involved in multicast control and multicast routing must be able to verify the individual multicast receiver or source status without cryptographic means. The multicast routing does not take individual multicast receiver and source status into account when building the shortest path tree (e.g. PIM-SM). This means that the control functionality must be located in edge routers that have direct connection to the hosts. The core routers in the network should not need any modifications what comes to the multicast control, and the multicast control functionality should be independent of multicast routing in general. In addition to that, the host interface should be kept as simple as possible, and our approach aims to keep the host interface (IGMP or MLD) unmodified. 4.3 Network Elements Controlled multicast framework consists of three separate entities; host, router and MCA. All these entities and their mutual relationships are described in this section. Host entity represents either multicast source or multicast receiver. Our aim was to keep the host behaviour unmodified and thus we don t propose any changes to the host interface towards the multicast network. In fact the host is unaware of the multicast control that is applied in the network. We recommend the use of versions 3 of IGMP and 2 of MLD for best possible accuracy in multicast control, because the earlier versions of these protocols do not support individual reporting of multicast group interests, source-specific multicast groups and source filtering. (Multicast Control Protocol) Router can be considered as a normal router with multicast control support. Router is responsible of controlling multicast traffic within directly connected hosts. Control is applied to a certain multicast address range specified by the MCA (Multicast Control Agent). Router filters out IGMP/MLD Reports from invalid hosts that do not have rights to join a requested multicast group. Additionally the Router can apply the filtering for the directly connected multicast sources. The filtering layer processes multicast traffic and control packets before they are delivered to the multicast routing process. This makes the feature multicast protocol independent, see Figure 1. PIM-SM PIM-DM CBT MOSPF other IGMPv3/MLDv2 processing or multicast traffic forwarding processing (filtering layer) IP packet processing Figure 1. Protocol stack for Router. Because the Router does not have information about the access rights of individual hosts, it must query this information from the MCA. The protocol designed for this process is called (Multicast Control Protocol), which is explained in the next subsection. The multicast control support can be also implemented as a transparent filtering bridge between multicast router and directly connected hosts that understands IGMP/MLD messages and filters them appropriately from the multicast router. This is very useful feature for testing purposes as the router implementation and multicast routing can be kept verifiably separate from the multicast control. MCA (Multicast Control Agent) maintains information about active multicast groups that are controlled by the Routers. This information consists mainly of valid receivers and sources for every multicast group. Router that does not know the status of a host that wishes to be part of the multicast group, queries the group status from the MCA. While the information may dynamically change, MCA is responsible for updating the information to the Routers. MCA s control information can be configured manually or it can be gathered by some automatic means. If the host wants to be part of the valid receivers, it must either

contact MCA administrator or use some application specific means (e.g. subscribe access to the group communication, where the service system updates the receiver status automatically) to get the information updatedtothemca. 4.4 Multicast Control Protocol () is used mainly for transferring multicast control information between MCA and Routers. It can be also used by Routers to discover MCA s IP address, if the configuration is not done manually. uses either TCP or UDP transport depending on the messages. The discovery procedure uses UDP, but the actual communication between Router and MCA is built on the top of TCP. defines 6 messages: Discover, Offer, Init, Validate, Result and Reset. Discover and Offer messages are used by the Router to find out the address of the MCA. Discover message is sent to a well-known multicast address, which is listened by MCA. MCA answers with Offer message directly to the Router. Discovery procedure is not mandatory and for security reasons it is preferable to configure MCA s IP address manually. After the Router knows the IP address of the MCA, it creates a TCP connection between them. Init message, which is sent by MCA, is the first message carried over that TCP connection and it identifies the controlled multicast addresses. According to this address information the Router starts to control directly connected multicast hosts. If a host wants to join a multicast group, which belongs to the controlled multicast addresses, Router is responsible for validating the host status before the IGMP packet is processed further. The same applies also to new multicast sources. The validating can be either local or remote. If the local information does not exist, the Router queries the information remotely from MCA. Validate message is used to query control information for a certain multicast group. MCA answers with Result message, which identifies the valid sources and receivers for the queried multicast group. According to this information Router can filter the hosts appropriately. This information is also stored locally for future use, which consists of periodic IGMP Reports (if receiver continues listening to the multicast group), new hosts joining the same group and new sources sending traffic to the same group. If there is a change in the group information in MCA, it must forward this information also to local cache at the Routers. This is done by unsolicited Result messages, which change the current local information in Routers. Reset message is used to inform MCA that the group information is not needed anymore and the local information is removed. Then MCA knows that it can remove that Router from the list of routers, which must be informed about group changes. 4.5 Example Scenario This example shows how the multicast control system is involved in the normal receiver join case. The Routers have been configured earlier with Init message to apply control for all source-specific groups including both sources and receivers. The source S starts to send traffic to multicast address G, which belongs to the range of source-specific multicast addresses. Therefore router A must validate the source status before it forwards the traffic further. Because this information does not exist locally, Router A sends an Validate message to query this information from MCA. MCA responds with an Result message, which contains information that the S is a valid source for this multicast group. Now the Router A is able to process the traffic further. In this case the list of multicast enabled outgoing interfaces is empty and the traffic is discarded at Router A, see Figure 2. PIM Join core router router B IGMP/MLD Join for (S, G). PIM Join R Multicast traffic to group G. router A S.2 Result G: +130.230.52.2 Validate G: 130.230.16.0/24 Result G: +130.230.16.0/24.10 130.230.16.0/24 130.230.52.0/25 Validate G: 130.230.52.0/25 MCA Figure 2. Multicast control applied for both receiver and source. Then the receiver R wants to join a source-specific multicast group (S, G) and sends an IGMP/MLD Report to the Router B. Again the Router B must query the control information from MCA, because local information does not exist. MCA answers with a Result message, which informs the Router B that the whole subnetwork 130.230.16.0/24 is able to join that specific multicast group, see Figure 2. Router B continues to process IGMP/MLD message further and eventually multicast routing protocols take care of establishing the shortest path tree towards the source S. After that the multicast traffic can flow down to

the receiver R, see Figure 3. Router B continues to process IGMP/MLD messages from R to react to group status changes. Periodic PIM Joins core router Periodic PIM Joins Multicast traffic to group G. router A S.2 130.230.52.0/25 The controlled multicast framework can be used in applications, which need strict control on building the multicast tree. It can be also used to protect some multicast groups from DoS attacks by limiting the valid sources. In both cases we might want to link MCA s information with the application specific authorization data. Therefore a common interface between the applications and MCA is needed. However, this paper does not address this issue. Generally the framework is most suitable to limiting the active multicast hosts to the minimum, because that keeps the network functional under heavy multicast traffic. router B MCA 5.2 Features and Known Limitations Periodic IGMP/MLD Joins for (S, G). Figure 3. PIM messages and multicast traffic flow. 5. Usage and Analysis of Controlled Multicast This section discusses about the usage of controlled multicast and gives a brief analysis of the features as well as known limitations of the framework. 5.1 Usage Environment R.10 130.230.16.0/24 Host and multicast network control within the Internet is not currently possible because of scalability and generic multicast specific problems. The model where the multicast source can just begin transmitting packets to a multicast group and the interested receivers pull the stream from the network is quite hard to control efficiently. Therefore the controlled multicast framework is designed to work as an intra-as or as an internet service provider specific method for controlling multicast hosts. Even though the control is applied internally within some domain, it has wider scale properties as well. By restricting the unauthorized hosts from joining a multicast group, the network operator can be sure that unwanted multicast traffic is never coming from other (nonmalicious) operators networks to the domain. This, however, assumes that flood and prune mechanisms are not used. By controlling multicast sources operators can also control the multicast traffic that is originated inside the domain. If the active multicast sources are announced with MSDP, we cannot control receivers, who can join the multicast group, if they reside in other domains. Therefore the control applies only internally. Controlled multicast framework does not enable Internet wide control for multicast sources and receivers, but it can be used to limit the multicast traffic to the acceptable level when the multicast support is turned on in routers. Our solution for controlled multicast framework is light-weight and easy to implement in current routers. It can be used to network level as well as host level control of multicast receivers and sources. Host level control can identify the valid hosts based on the host s IP address. This type of control could be used in multicast applications, which want to limit access to the group communication to specific hosts. Alternatively the network level control can be used by network administrators to control the multicast network usage e.g. by restricting the sending of multicast traffic from some subnetwork. The protocol supports address aggregation, so the network wide control can be communicated very efficiently. Our scheme does not need any modifications to the existing host interface, namely IGMP/MLD. The only restriction is that if we want host level control of multicast traffic, all hosts in a shared network must support the version 3 of IGMP or version 2 of MLD. Otherwise the control is limited to subnetwork level. The controlled multicast mechanism is also independent of multicast routing protocols, which is a huge advantage when deploying the control to the existing networks. It also supports both IPv4 and IPv6. For testing purposes we can implement the mechanism with a standalone filtering bridge, which is also a big advantage. Currently the framework cannot restrict an unauthorized host to listen to the multicast traffic on a shared network if one or more valid hosts are receiving the traffic for the same multicast group. Cisco specific CGMP [13] protocol can be used to overcome this limitation, but this is not a generic solution due to the vendor specific mechanism. If this limitation is not tolerable by the specific application, the multicast traffic can be always encrypted. Another shortcoming with the

current architecture is that the control is limited to the IP addresses. On network level this is always acceptable, but the host level control could be more scalable if some other mechanism like certificates will be used. Certificates do not, however, offer a light-weight solution to the problem, because that requires modifications to the host interface, routers need to process the certificates and other certificate related mechanisms are needed as well. 6. Further Work The Multicast Control Protocol (), which is described briefly in this paper, has been specified and delivered to the IETF and published as an Internet Draft. In order to get real life measurements and experience of the controlled multicast framework, it will be implemented and tested thoroughly at the Tampere University of Technology in Institute of Communications Engineering laboratory. 7. Conclusions Controlled multicast framework described in this paper allows us to control the hosts who are able to join or send traffic to a certain multicast group. This effectively prevents malicious hosts from joining a certain multicast group and it significantly reduces unnecessary multicast state information in routers (non-existing multicast group, invalid receiver, etc.). It also prevents other Denial of Service attacks like sending unwanted traffic to a certain multicast group. The full potential of controlled multicast framework can be achieved by combining it with some encryption framework for IP multicast. Acknowledgements Authors like to express their gratitude to the Jyrki Soini, Heikki Vatiainen and Juha Majalainen who took part to the actual specification of the protocol and provided many helpful suggestions and improvements to the actual controlled multicast framework. References [1] S. Deering, Host Extensions for IP Multicasting, RFC 1112, IETF, 1989. [2] B. Cain, S. Deering, B. Fenner, I. Kouvelas and A. Thyagarajan, Intenet Group Management Protocol, Version 3, Internet Draft, April 2002, Work in [4] H. Holbrook and B. Cain, Source-Specific Multicast for IP, Internet Draft, November 2001, Work in [5] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas, Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification (Revised), Internet Draft, March 2002, Work in [6] A. Adams, J. Nicholas and W. Siadak, Protocol Independent Multicast Dense Mode (PIM-DM): Protocol Specification (Revised), Internet Draft, February 2002, Work in [7] T. Pusateri, Distance Vector Multicast Routing Protocol, Internet Draft, August 2000, Work in [8] A. Ballardie, Core Based Trees (CBT version 2) Multicast Routing, RFC 2189, IETF, 1997. [9]J.Moy, Multicast Extensions to OSPF, RFC 1584, IETF, 1994. [10] T. Hardjono, R. Canetti, M. Baugher and P. Dinsmore, Secure IP Multicast: Problem Areas, Framework and Building Blocks, IRTF Draft, September 2000, Work in [11] D. Meyer and B. Fenner, Multicast Source Discovery Protocol (MSDP), Internet Draft, November 2001, Work in [12] M. Christensen and F. Solensky, IGMP and MLD Snooping Switches, Internet Draft, January 2002, Work in [13] Cisco Tech Notes, Multicast In a Campus Network: CGMP and IGMP Snooping, http://www.cisco.com/warp/public/473/22.html [14] I. Wu and T. Eckert, Router-port Group Management Protocol, Internet Draft, July 2001, Work in [15] R. Lehtonen, J. Soini, J. Majalainen and H. Vatiainen, Multicast Control Protocol (), Internet Draft, June 2002, Work in [16] V. Visoottiviseth, Y. Takahashi and N. Demizu, Sender Initiated Multicast (SIM), Internet Draft, July 2001, Work in [17] R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms and O. Paridaens, Explicit Multicast (Xcast) Basic Specification, Internet Draft, October 2001, Work in [18] C. Castelluccia and G. Montenegro, Securing Group Management in IPv6 with Cryptographically Generated Addresses, Internet Draft, February 2002, Work in [3] R. Vida, L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas and B. Haberman, Multicast Listener Discovery Version 2 (MLDv2) for IPV6, Internet Draft, January 2002, Work in