MAGMA Working Group G. Daley Internet-Draft G. Kurup Expires: January 7, 2005 Monash University CTIE July 9, 2004 Trust Models and Security in Multicast Listener Discovery draft-daley-magma-smld-prob-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 Internet-Draft will expire on January 7, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Multicast Listener Discovery (MLD) is used by IPv6 routers to discover the presence of multicast listeners (i.e. nodes that wish to receive multicast packets) on their directly attached links, and to discover which multicast addresses are of interest to those neighbouring nodes. The existing protocol specification (MLDv2) discusses the effects of on-link forgery of MLD packets but provides no protection from on-link attacks. By taking advantage of or abusing Multicast Listener Discovery, bogus Daley & Kurup Expires January 7, 2005 [Page 1] Internet-Draft Trust and Security in MLD July 2004 devices may cause incorrect state and disruption to multicast or unicast packet delivery. This memo considers the trust models for the MLD protocols, and their interaction as well as their interaction with link-layer and multicast proxy devices. It provides a security and threat analysis for each model. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Previous Work . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Structure of this Document . . . . . . . . . . . . . . . . 6 2. Trust Models in Multicast Group Management Signalling . . . . 7 2.1 Routers' Trust of Hosts . . . . . . . . . . . . . . . . . 7 2.2 Hosts' Trust of Routers . . . . . . . . . . . . . . . . . 9 2.3 Routers' trust of Routers . . . . . . . . . . . . . . . . 9 2.4 Hosts' trust of Hosts . . . . . . . . . . . . . . . . . . 10 2.5 Threats Specific to MLDv1 . . . . . . . . . . . . . . . . 10 3. Trust Models for Link Layer devices (Snoopers) . . . . . . . . 11 3.1 Switches' Trust of Routers . . . . . . . . . . . . . . . . 11 3.2 Switches' Trust of Hosts . . . . . . . . . . . . . . . . . 12 3.3 Switches' Trust of Switches . . . . . . . . . . . . . . . 12 3.4 Hosts' Trust of Switches . . . . . . . . . . . . . . . . . 13 4. Trust Models for Proxied Multicast Group Management . . . . . 13 4.1 Proxies' trust of Routers . . . . . . . . . . . . . . . . 13 4.2 Routers' trust of Proxies . . . . . . . . . . . . . . . . 14 4.3 Hosts' trust of Proxies . . . . . . . . . . . . . . . . . 14 4.4 Proxies' trust of Hosts . . . . . . . . . . . . . . . . . 15 4.5 Proxy's trust of Topology . . . . . . . . . . . . . . . . 15 5. Summary of Threats to Multicast Group Management . . . . . . . 15 5.1 Bogus Querier . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Bogus Group Member . . . . . . . . . . . . . . . . . . . . 15 5.3 Bogus Switch . . . . . . . . . . . . . . . . . . . . . . . 16 5.4 SSM to ASM bid-down . . . . . . . . . . . . . . . . . . . 16 6. Existing protocol formats and messages . . . . . . . . . . . . 16 6.1 MLDv2 Report Messages . . . . . . . . . . . . . . . . . . 16 6.2 MLD Query Messages . . . . . . . . . . . . . . . . . . . . 17 6.3 Multicast Router Solicitation Messages . . . . . . . . . . 17 6.4 Multicast Router Advertisement Messages . . . . . . . . . 17 6.5 Multicast Router Termination Messages . . . . . . . . . . 18 6.6 Summary of Messages and formats . . . . . . . . . . . . . 18 7. Comparisons to other Signalling Protocols . . . . . . . . . . 18 7.1 Routing Protocols . . . . . . . . . . . . . . . . . . . . 19 7.2 Dynamic Host Configuration Protocols . . . . . . . . . . . 19 7.3 Neighbour Discovery . . . . . . . . . . . . . . . . . . . 20 8. Comparisons to other Multicast Security Mechanisms . . . . . . 20 9. Discussion of Possible Security Mechanisms . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . 21 Daley & Kurup Expires January 7, 2005 [Page 2] Internet-Draft Trust and Security in MLD July 2004 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 13.2 Informative References . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 24 Daley & Kurup Expires January 7, 2005 [Page 3] Internet-Draft Trust and Security in MLD July 2004 1. Introduction Multicast Signalling is required to support subscription and management of multicast listeners in IPv6 networks. Abuse of the existing trust used in multicast signalling may have effects significant not only on the local link, but for multiple hops in the Internet. Multicast data streams are touted as a mechanism for providing scalable deployments of multi-consumer oriented applications on the Internet. In IPv6, multicast hosts and routers communicate their multicast capabilities and group membership using Multicast Listener Discovery (MLDv2 or MLD) [5]. Although Multicast Listener Discovery only operates within a single IP link, interaction between hosts and routers and change in states due to MLD reports may cause routing changes in multicast routers beyond the current link, when associated with non-link-local groups. Additional considerations for Multicast Listener Discovery in different access network environments are provided in [6], [7] and [8]. Since multicast is touted as a mechanism to handle large bandwidth data streams, malicious modifications of data streams on other subnets is a significant cause for concern. Additionally, the limited feedback mechanisms provided for multicast data streams (many of which use UDP) mean that service theft and network denial-of-service are easier than in bidirectional streams oriented communication. Multicast Listener Discovery protects from off-link attacks through prevention of forwarding and use of link-local source addresses[5]. This means that all attacks caused by MLD originate from hosts either on a target link, or in the case of routing changes, a device which is in the recipient for a particular group or source. While identifying the source of an attacker is certainly possible, this does not mitigate the potential of attacks, nor the consequences in the case of abuse. Of particular interest in this analysis are several characteristics of MLD which lend it to attacks. Mandatory Query response: While MLD doesn't have any particular message authentication, any device which is acting as a router may force mandatory signalling responses from other hosts on-link. Queries Elect the Querier Router: Sending of MLD queries can be used to elect or de-select a Querying multicast router. This may be used to modify parameters on a network and conceivably support Daley & Kurup Expires January 7, 2005 [Page 4] Internet-Draft Trust and Security in MLD July 2004 denial-of-service. MLDv1 can bid down MLDv2: Backward compatibility mechanisms for interworking between the current MLD (MLDv2) and Multicast Listener Discovery Version 1 (MLDv1) allow hosts to change the MLD compatibility state on a router by sending reports [5]. This may be used to force changes in the source model used for off-link multicast routing. Reports cause off-link changes: The reports which are sent for joining arbitrary multicast groups cause changes to off link routing state when new groups are joined, or when routing halts after a group or source is excluded. Reporting can cause Querying: Host transmitted report messages can be used to instigate queries from a router when the last group member leaves a group. Unprivileged multicast API: Access to arbitrary multicast groups is typically available through the host API. This allows generic tasks on a host computer to join or abuse multicast groups. This document discusses the effect of these features in a variety of network environments, and discusses attack scenarios which arise in these environments. Particularly, it covers the trust models in the following areas: o Trust between hosts and routers for multicast group management. o Trust between access network components, especially where multicast snooping is required. o Trust in proxied multicast networks. This document compares the signalling in MLD and related protocols with other signalling protocols, with similar trust models. As part of this comparison, discussion of security methods applied to those protocols and their applicability to MLD is provided. Finally, while IPv4 is the prevalent networking technology today, this document provides analysis of the trust models for multicast group management signaling in IPv6 only (MLDv1 and MLDv2). If sufficient interest and timing resources are available, assessment of trust in IPv4 multicast group management may be attempted in a later version of the draft [3]. Daley & Kurup Expires January 7, 2005 [Page 5] Internet-Draft Trust and Security in MLD July 2004 1.1 Previous Work Previous attempts to secure Multicast groups have focussed on access and abuse of multicast group data[18] while not protecting signalling, or have relied upon group signalling keys, which have trust scalability and deployment issues. Security considerations for IGMPv3 in IPv4 (Section 9 [3] ) proposes a security mechanism for multicast group management based on IPSec AH [11][10]. It provides signalling and message integrity based on shared keys where any possessor of the shared key can undertake transmission of 'authenticated' messages. Similarly, it proposed the application of to-be-developed key exchange procedures to ensure that Query and Leave messages could be authenticated. To date no such key exchange mechanisms are deployed for IPv4. In either case (key exchange or shared key) host multicast group management reporting is unsecured, since at the time, IPSec AH security associations weren't capable of binding to arbitrary multicast destinations. Such mechanisms are clearly not extensible to an arbitrary group of users, and require manual configuration. Such manual configuration is out of the spirit of IPv6 autoconfiguration, and may not be possible to fix in MLD. A comparable protocol to Multicast Group Management is IPv6 Neighbour Discovery, which resolves last hop link-layer address mappings and routing between hosts and routers [12]. It is noteworthy that at a similar period, IPv6 Neighbour Discovery proposed similar systems for authentication of message exchanges. Since both multicast group management and Neighbour Discovery are involved in the automatic configuration there are serious chicken-and-egg problems for IPv6 systems to use IPSec based key exchanges [16][17]. 1.2 Structure of this Document This document provides trust models and threat descriptions for MLD hosts, routers, proxies and snooping switches. Multicast group management trust model analysis has been broken down into three sections within this document. We analyse the base protocol as specified by the Multicast Listener Discovery version 2 RFC-3810 [5]. We then extend the considerations to include Daley & Kurup Expires January 7, 2005 [Page 6] Internet-Draft Trust and Security in MLD July 2004 link-layer snooping effects [8][6] and MLD Proxying [7]. Traditional signalling directly between hosts and routers is tackled within Section 2. This subsumes the election of routers for Querying operation and refers mainly to the MLDv2 and MLDv1 base specifications. Link-layer multicast snooping effects are discussed in Section 3, especially in the additional requirements and implicit trust developed with link-layer switching hardware. This corresponds primarily to the definitions provided in the multicast snooping specification [8]. Trust for multicast group management signal proxying is handled in Section 4. This describes the differences between the trust models available in the direct signalling from Section 2 due to the placement of multicast group management proxies. A summary of the classes of threats is offered in section Section 5. After reviewing trust and threats within the group management protocols, the existing message formats for MLDv2, and Multicast Router Discovery are described in Section 6. Particular attention is paid to the specification of message lengths and how additional space within messages is treated. 2. Trust Models in Multicast Group Management Signalling Direct Multicast Listener Discovery signaling between hosts and routers consists of Queries, sent by routers, and Reports which are sent by hosts[5]. Actions may be taken by routers or hosts upon receiving either of these messages. These actions exhibit implicit trust relationships, which may be the subject of abuse. 2.1 Routers' Trust of Hosts MLDv2 signalling is used by routers to determine if a set of multicast data is of interest to hosts on a link. The router receives reports from when hosts add to, subtract from or modify the listening state of their set of sources or groups. Also hosts report multicast Group and (Source,Group) status periodically, in response to router queries. When a router receives a single report message, changes to multicast Daley & Kurup Expires January 7, 2005 [Page 7] Internet-Draft Trust and Security in MLD July 2004 routing tables of off-link routers may occur (for non link-local groups). This may cause attack amplification effects to occur when a device causes routing change at multiple levels of the multicast routing topology. Additionally, reports which requests for multicast groups or sources may have an effect on the perceived quality of service for other devices, since multicast data streams do not undertake end-to-end rate limiting. Addition of multicast data streams effectively reduce the available bandwidth on all links where the data are received. If the multicast routing infrastructure is not aware of topological bandwidth constraints, hosts may cause denial-of-service by spuriously (or accidentally) requesting many large data streams. Additionally, for some types of messages (MLDv2 State Change Reports, MLDv1 Done Reports) Query messages are required to be sent from the Querier router upon their reception. A node which produces such Report messages may be able to cause multiple transmissions by the Querier router (up to the Querier's robustness value) from a single report message. With these messages though, a bogus device is unable to end transmission to legitimate group members. This is because the group members will reply to the queries generated upon State Change Report reception (increasing the signalling load). Bogus or replayed reports for the current state of a multicast data stream may be used to maintain the transmission of a particular multicast data stream for a longer period than is necessary. This may either be used to drain network resources or to flood routing state changes from the router when multiple groups are dropped simultaneously from the interest list upon expiry of Multicast Address Listening Intervals. The existence of the MLDv1 compatibility mode may cause a router to lose source specific information on particular groups, though it continues to send V2 Queries. In this case it may be possible to cause the router to use Any-Source-Multicast (ISM) routing instead of Single-Source-Multicast in the short term. This is described in the security considerations section (10) of the MLDv2 specification [5]. This is especially critical when existing listeners EXCLUDE specific sources and the abused bid down causes the data which originates from this source to be delivered. No authentication or authorization of multicast hosts and their multicast group management signalling is client requests is defined in IPv6. Most of the attacks defined may be performed without impersonating other nodes or defying the MLD specifications. Since joining groups and modifying source filters are defined as part of Daley & Kurup Expires January 7, 2005 [Page 8] Internet-Draft Trust and Security in MLD July 2004 the user-level APIs for MLDv2, it is plausible to believe that applications may cause these effects without requiring privileged access to operating systems [5]. 2.2 Hosts' Trust of Routers In multicast group management, the reception of a Query message requires response from a multicast listener. This response is typically a current state report of the groups or sources and groups which the client is interested in listening to. This response is required, otherwise the host may lose multicast delivery for any or all of the multicast streams which are queried. Where host suppression is not in use [5], a router specifying a very small Maximum Response Code (Timer) in its Query may cause multicast report bombing at fine granularity with a single message. In some cases, this may have severe consequences in terms of packet loss or delay on other data sources or signalling. Hosts have no idea which is a valid Query, since no authentication or authorization of routers is undertaken. Even choosing to respond to queries from the router with the lowest source address may not help, since it is trivial for non-routers to create such addresses. 2.3 Routers' trust of Routers In multicast group management, only one router per link is responsible for eliciting reports from multicast clients. This Querier Router is elected through an address identifier. Modifications of a router's address may make it a favoured router in querier election. Election occurs when a router with an address lower than any seen in a recent Query sends a Query message on the link. Upon reception of a Query from a router with a lower address, all routers should stop Querying. This system assumes that the router which transmits with the lower address is a legitimate router, and that the other routers will cease transmission upon receiving such a Query. While there is no direct service disruption in the case that a non-authorized router continues Querying, this device may now vary the Query interval and timeout parameters. This may have an impact on packet delivery by increasing the signalling load on the link. By increasing the Querier's Robustness Value, the leave latency for Daley & Kurup Expires January 7, 2005 [Page 9] Internet-Draft Trust and Security in MLD July 2004 multicast packet delivery is increased on the link. This may lead to congestion, as new multicast delivery streams overlap with those for devices no longer on a link. Legitimate routers, once downgraded to Non-Querier by the presence of a fake Querier, can remove Groups to be forwarded if it has not received a report from listeners within its Multicast Address Listening Interval. Since a router is required to accept and process queries directed to any of its listener addresses (Section 5.1.15 of MLDv2) it is possible that routers will stop sending queries without hosts ever receiving the Query message. This is because the Querier election strategy ensures that a Querier Router stops sending Queries as soon as it receives any Query from a preferred router. In this fashion a router may continue to receive general queries advertised only to itself, and no responding reports will be received from listener hosts. In the case that the unauthorized router sends queries only once and then stops, the other routers will stop Querying for the duration of the Other Querier Present Timeout [5]. As this is based on the Querier's Robustness Value and Query Interval advertised in the false Query, Querier re-election may be halted for a long time [5]: = max[Robustness Variable] * max[Query Interval] + (max[Maximum Response Delay]/2000 ) = ( 7 * 31744 + (6290432/2000)) = 225353 seconds. If a router exists which doesn't stop Querying when a router with a lower address exists, then even more packets will be transmitted on the link. Hosts will receive both sets of queries and will have to respond to both. Therefore, the presence of any misbehaving device (using any address) is similarly harmful to the case where a false router is elected. 2.4 Hosts' trust of Hosts Hosts do not trust other hosts' reports except in MLDv1, where they are used for host suppression[4]. 2.5 Threats Specific to MLDv1 Report messages which respond to queries are delayed over a random interval specified by the Querier router. Hosts may avoid transmitting a response packet if they are configured to use MLDv1, if it has already seen a response [4]. This is called host suppression, and is discussed further in Section 2.4. Hosts may suppress their own reporting in the case that they receive Daley & Kurup Expires January 7, 2005 [Page 10] Internet-Draft Trust and Security in MLD July 2004 an MLDv1 report for the same group. As mentioned in section Section 3.4, the use of host-suppression may have negative consequences on snooping networks. Therefore, it may be possible to engineer situations where hosts are denied service by being tricked into host suppression on snooping networks. 3. Trust Models for Link Layer devices (Snoopers) Multicast listener snooping mechanisms [8] and Multicast Router Discovery [6] can be used to control local delivery of multicast traffic within the last IP hop. Interference with multicast snooping operation can be used to modify multicast packet flow within a link. In this case, not only off-link multicast reception from the router is involved, but link-local packet delivery such as is used in IPv6 Neighbour Discovery[12]. Switches must be informed using multicast group management reports so that multicast packets are distributed to interested listeners in the link-layer domain. 3.1 Switches' Trust of Routers Multicast Routers need to know of the presence of every group and source within the IP hop. Therefore, snooping switches need to include routers' switch ports as receivers of all groups. There is trust implied in switches' monitoring of routers, which may be abused. Switches' monitoring of router presence ensures that non-local routing occurs for multicast streams originating on-link, and allows reception of multicast group management messages for local listeners. Switches therefore need to identify routers to include them in all multicast transmission groups for off-link traffic. Monitoring Query messages is ineffective, since only one router will Query. Multicast Router Discovery provides a mechanism where all routers with multicast capabilities should advertise their presence when solicited by switches [6]. Periodic updates from multicast routers serve to update state, sending to the link-local all-snoopers group. This is similar to unicast IPv6 Router Discovery and potentially could be done using Neighbour Discovery Options [12]. Daley & Kurup Expires January 7, 2005 [Page 11] Internet-Draft Trust and Security in MLD July 2004 Currently no mechanism exists to determine if a responding device is a router, and therefore whether all multicast traffic should be sent to the switch port. Additionally, bogus Multicast Router Terminate messages received on the same port as a router may be used to halt reception of all multicast data by the router[6]. For IPv6 Router Discovery, Securing Neighbour Discovery[15] procedures have been proposed, to provide authorization for delegated trust of routing operation. This mechanism has been proposed as a model for authenticating Multicast Router Discovery, even where the message formats differ from Neighbour Discovery. Without a similar mechanism, a host may pretend to be a router by sending bogus Multicast Router Advertisements and swamp a LAN segment with all off-link multicast traffic until a snooping timeout occurs. 3.2 Switches' Trust of Hosts Snoopers are required to modify forwarding state to include those switch ports and LAN segments which have interested listeners. Reception of reports or done messages are used to change group delivery state within the multicast domain. Changes to snoopers' port state may be assumed by switches to only be possible from the port attached to the host. In some environments, though, it may be possible to steal service from legitimate owners by moving listener state from one port to another within a link, using impersonation or report replay. Another issue is when inappropriate traffic is sent over a particular switch port. For example, it may not be appropriate for the all-routers' or all-snoopers' group messages to be sent across a wireless link. Access control of certain classes of groups therefore should be considered. 3.3 Switches' Trust of Switches Routers receiving multicast router solicitations should respond so that snoopers send all multicast packets to them. Since not all LAN segments are snooping segments, responses to Multicast Router Discovery Solicitations may be transmitted across multiple LAN segments (though sent to all-snoopers group). Therefore, in order to avoid excess transmission to unnecessary LAN segments, it would be useful to ensure that the solicitor has some Daley & Kurup Expires January 7, 2005 [Page 12] Internet-Draft Trust and Security in MLD July 2004 authority to send multicast router solicitations. In some snooping environments, the snooping switches act as MLD signalling proxies, in which case the trust models which apply are defined in Section 4. 3.4 Hosts' Trust of Switches When host-suppression is in use, it is well known that multicast snooping may have difficulties in maintaining multicast snoop state. Actually this was one of the scenarios which led to removal of this feature from modern multicast group management protocols [5]. Nevertheless, some multicast snooping devices seek to prevent this issue occurring by never forwarding multicast group management reports to ports where a router isn't attached. Also, these switches may forge group membership queries in order to generate multicast snoop state. In this case, the hosts will receive queries from devices which aren't a part of the network layer routing infrastructure, and may not be 'authorized' to send queries. Such switches share many attributes in common with MLD proxies (Section 4). 4. Trust Models for Proxied Multicast Group Management Some networks will not have explicit multicast routing protocol exchange between devices on the multicast forwarding path. These networks trust a proxy to perform necessary Multicast Listener Discovery Signalling to cause packet delivery onto the local link. In this case, it is necessary to send messages received from requesting multicast clients toward multicast routing infrastructure through proxied intermediate routing hops. A proxying device undertakes MLD signalling on the interface closer to the multicast infrastructure, requesting the aggregates of the groups and sources that hosts on other of its interfaces request. Thus on one interface, the proxy acts as a host (toward a router) and on another, the proxy acts as a router (to multicast clients). 4.1 Proxies' trust of Routers Proxies talk to multicast routers on their upstream interface in a manner which mimics current host-to-router interactions for multicast group management. Daley & Kurup Expires January 7, 2005 [Page 13] Internet-Draft Trust and Security in MLD July 2004 The proxy multicast group management specification requires that the elected Querier device act as the forwarding proxy device. Therefore any device elected as the Querier router is assumed to be able to provide forwarding support [7]. When interacting with a Querier router, the proxy makes no further assumptions about the authorization of the router except those made in Section 2.1. 4.2 Routers' trust of Proxies The proxy sends multicast group management reports to the router on behalf of devices which aren't on an interface connected to the router. In this case, since the proxy isn't the eventual destination of the multicast stream, decisions as to access control cannot be undertaken when summarized information is passed to routers[7]. In the case that the proxy is able to supply credentials for each of the requesting hosts on the other interface, transparency may be restored, at the cost of protocol change. Additionally, on the proxies' downstream interfaces, it may be that there is a proxy which attempts to undertake Querying function in the presence of a real multicast router. [7] encourages setting the address of the proxy to a very low value in order to guarantee Querier election. Clearly, when a multicast router which is connected to the Internet exists, it should be elected instead. At this time, there is no mechanism which allows the router or proxy to determine precedence other than administrative choice of router/ proxy address. 4.3 Hosts' trust of Proxies On links where services are proxied further up a network, hosts undertake signalling with the proxy instead of to a router. Interactions and authorization are based on the host-to-router model in Section 2.1, although the proxy may not be part of the authorized network-layer routing infrastructure. Authorization for routers to proxy may be assigned by an upstream router or proxy, except that this may be difficult if the devices do not have some pre-existing trust. Daley & Kurup Expires January 7, 2005 [Page 14] Internet-Draft Trust and Security in MLD July 2004 As such, a host should always prefer a router with authorization over one without, which may just be proxying. Currently, though, there is no way to determine whether a Querier is actually a proxy or not. The proxy acts as a router in the case that it is the Querier, and hosts rely upon the fact that their responses to queries mean that listener tables for their network are set up appropriately. In the case that the Querier fails to generate appropriate listener reports on upstream interfaces, though, packet flow may fail. 4.4 Proxies' trust of Hosts Proxies which are Queriers have the same trust of end-hosts which exists for the router-to-host model in Section 2.1. In this case though, the host may in itself be a proxy and the notes from section 4.2 also apply. 4.5 Proxy's trust of Topology Multicast proxies rely upon the idea that there are no loops in the forwarding topology for multicast. Since no routing protocols are used between proxies to detect loops, it is possible for an attacker to set up forwarding loops which will cause damage to packet transmission on multiple links[7]. 5. Summary of Threats to Multicast Group Management The threats in MLD can be summarized by the role assumed by an attacker. Below are summaries of attacks ascribed to particular attacker roles, which are pertinent regardless of the access network topology. 5.1 Bogus Querier Any device may become a bogus querier, whether a router or not. The effects of being a bogus querier are that Querier election may be preempted, or that multicast group management signalling may be elevated. 5.2 Bogus Group Member An attacker may be able to join many groups, potentially subscribing many fake members to a particular group. In MLDv2, all group members are tracked by multicast routers and snooping switches, and bogus membership may cause such state to be Daley & Kurup Expires January 7, 2005 [Page 15] Internet-Draft Trust and Security in MLD July 2004 exhausted. The subscription and unsubscription of bogus group members (even to bogus groups or sources) may cause signalling off-link to other multicast routers. Where multicast routing of packets occurs based on bogus membership or source filtering, bandwidth resources may be consumed. 5.3 Bogus Switch Whether or not multicast snooping is taking place, the presence of Multicast Router Solicitations may make routers send Multicast Router Advertisements. These forced advertisements may be used by bogus switches to consume network bandwidth. 5.4 SSM to ASM bid-down Where an attacker can send an MLDv1 report for a group which is being SSM routed, the router will switch to any-source-multicast, possibly causing significantly higher bandwidth utilization [5]. 6. Existing protocol formats and messages Message definitions for MLDv2 [5] and Multicast Router Discovery [6] are described. 6.1 MLDv2 Report Messages The MLDv2 report message currently consists of an ICMPv6 header, with the protocol (ICMPv6) and length of the datagram described in previous network layer headers, followed by a sequence of multicast address records. The number of multicast address records is described in a field of the fixed MLDv2 Report header, although the address records themselves are of variable length. Each Multicast address record contains two length indicators: one of which indicates the number of 16 octet source addresses, and an Auxiliary data length specification. Using these values, the message receiver is able to locate the end of the multicast address record. MLDv2 [5] specifies that data beyond the end of the last multicast address record is ignored, except for the purpose of checksum calculation (Section 5.2.11 of [5]). Daley & Kurup Expires January 7, 2005 [Page 16] Internet-Draft Trust and Security in MLD July 2004 6.2 MLD Query Messages MLD Query Messages share the same, initial message format, having the same ICMPv6 code[4][5]. Therefore they have common format up until the end of the MLDv1 Query. MLDv2 [5] specifies that the algorithm used to distinguish if a Query is v1 or v2 is to inspect the length of the Query and if it is greater than 22 octets, the message is an MLDv2 Query. MLDv1 messages therefore may not have additional information placed at the end of them. The additional room requirement in the MLD Query is to add fixed fields describing Query semantics and timing, as well as a specified number of multicast stream source addresses. [5] specifies that data beyond the end of the base Query fields are ignored, except for the purpose of checksum calculation (Section 5.1.12 of [5]). 6.3 Multicast Router Solicitation Messages Multicast Router Solicitation messages are used by switches to request Advertisement from multicast routers. There are no configuration related parameters in this 4 octet message, and no explicit delays required by responding routers. Responding routers are asked to rate limit response advertisements, though [6]. Recent discussion at IETF 59 on this message format seemed to agree that data after the end of a message should be ignored (although not for ICMPv6 checksums). In this case, the additional length would be implied by the length of the IP datagram minus the fixed message portion and IP headers. 6.4 Multicast Router Advertisement Messages Multicast Router Advertisement Messages are defined with a common format in both IPv4 and IPv6. Within IPv6, the message belongs to the set of ICMPv6 messages (as do MLD messages), and have the same general checksum requirements. The message itself is 8 octets long as defined in section 3.2 of [6], containing fixed fields for a checksum and the router's multicast advertisement interval. It also has fields for Query intervals and robustness variables derived from the router's multicast group management configuration. Daley & Kurup Expires January 7, 2005 [Page 17] Internet-Draft Trust and Security in MLD July 2004 No fields correlating between solicitation and advertisement are made, nor is there any indication of the freshness of the message (no sequence numbers or timestamps). Replay of previously received messages is therefore trivial if a malicious node is on the path. Recent discussion at IETF 59 on this message format seemed to agree that data after the end of a message should be ignored (although not for ICMPv6 Checksums). In this case, the additional length would be implied by the length of the IP datagram minus the fixed message portion and IP headers. 6.5 Multicast Router Termination Messages While Multicast Router Discovery currently defines a Terminate message, for Multicast Listener Discovery, Terminate messages are only used as explicit done messages in MLDv1 [4] and not MLDv2 [5]. No configuration related parameters exist for this 4 octet message. Recent discussion at IETF 59 on this message format seemed to agree that data after the end of a message should be ignored (although not for ICMPv6 Checksums). In this case, the additional length would be implied by the length of the IP datagram minus the fixed message portion and IP headers. 6.6 Summary of Messages and formats The IPv6 versions of all messages discussed provide some extra space at the end of the message except for MLDv1 queries. If the room at the end of the message was used for security information such as a signature, freshness information and explicit identification of the signer, this may be used to provide some authenticity and traceability to the messaging. Existing implementations would be able to read the messages, but not interpret the security information. Due to the inability to add information to the MLDv1 Query, it may be impossible to provide any security for MLDv1 devices. Since this protocol is superceded by MLDv2, devices wishing to support security have a potential alternative though. 7. Comparisons to other Signalling Protocols The development of other signalling protocols within the IETF may give some pointers as to pitfalls in the allocation of trust within multicast group management signalling, as well as indications of how Daley & Kurup Expires January 7, 2005 [Page 18] Internet-Draft Trust and Security in MLD July 2004 such mechanisms themselves' achieve more reliable security. The following sections describe other signalling protocols and highlight relevant similarities to Multicast Group Management protocols such as MLD. 7.1 Routing Protocols Original unicast routing protocol specifications for IPv4 such as the Routing Information Protocol allowed hosts to participate in routing decisions. In fact, some workstation implementations shipped with the RIP routing daemon switched on by default. One of the basic issues with a system which allows hosts to make routing changes, is that it is both open to abuse and subject to changes in host status for routing changes. Subsequent definitions of routing protocols and their discovery mechanisms have separated these functions. See the next two subsections for descriptions of such discovery mechanisms. In the case that routers wish to ensure that routing infrastructure changes are not at the whim of attackers, it is either necessary to share a configuration which allows mutual authentication between routers, or segregates routing protocol decisions from access networks. While Multicast Group Management segregates the roles of listening host from multicast router, hosts may still cause direct routing change through the addition or subtraction of groups on a link. This may be used to cause rapid change within the routing topology, without traceability, in a manner which may be used to defeat existing routing protocol hysteresis mechanisms. A secure multicast group management mechanism would be either be able to determine when an attack on the routing infrastructure is in operation, or prevent its effects on off-link devices. 7.2 Dynamic Host Configuration Protocols Dynamic Host configuration protocol allows devices to receive link-specific configuration information, and routing configuration. Typically, this allows the host to receive and transmit unicast packets from an assigned IP address. The router in this state, keeps track of information about the configuring host and its addresses. Numerous simultaneous attempts Daley & Kurup Expires January 7, 2005 [Page 19] Internet-Draft Trust and Security in MLD July 2004 at configuration may be used to exhaust resources (such as address pools). Additionally, Dynamic Host Configuration protocol relays may not actually provide address allocation services themselves, and rely upon a central server elsewhere in the network[13][14]. This leads to the potential that local signalling (or co-ordinated local signalling) can be used to cause changes rapidly enough to impair the central server's operation. This may be analogous to effects achievable in an unsecured multicast group management environment. 7.3 Neighbour Discovery IPv6 Neighbour Discovery provides mechanisms by which nodes show their reachability and constructs unicast network layer to link-layer bindings, for the purposes of local packet delivery within a link. Additionally, Router Discovery provides automatic configuration of default unicast routing, based on periodic advertisement to multicast link-local destinations[12]. Securing Neighbour Discovery is a protocol which provides authentication of Neighbour Discovery bindings for particular subclasses of unicast addresses, based on Cryptographically Generated Addresses[15]. All of the changes caused by Neighbour Discovery are local to the configuration state of hosts within the link, since the off-link IPv6 unicast routing topology is unchanged by Neighbour Discovery. While this is the case, there is still some validity to the mechanisms employed by SEND to provide some authentication for routing discovery, where devices advertise not only their presence but their authorization to route. It is notable that no proposal to handle secure proxying of neighbour discovery messages [9][15]. A similar mechanism would likely be needed for both SEND and multicast group management on proxies. 8. Comparisons to other Multicast Security Mechanisms There has been a slew of work within the IRTF and IETF on multicast. Within the security domain, the work of GSAKMP and MSEC groups has been principally on managing access to the data content within a multicast data stream, rather than the routing updates to prevent actual flow reception[18]. Daley & Kurup Expires January 7, 2005 [Page 20] Internet-Draft Trust and Security in MLD July 2004 In an environment where the presence of multicast flows and signalling cause resource exhaustion, the readability of the content stream doesn't particularly matter. In this case, it may be valuable to ensure that devices aren't allowed to request traffic without being traceable or accountable to the routing infrastructure. 9. Discussion of Possible Security Mechanisms At this stage the level of interest in work on group management signalling security is minimal. The existence of specifications to secure local delivery of IPv6 unicast packets though, indicates that at least it may be worth determining if similar security is desirable or applicable for multicast group membership management. 10. IANA Considerations There are no IANA actions specified in this document. 11. Security Considerations This document describes threat and trust models for multicast group management, primarily from the point of view of IPv6 Networks. There may be inaccuracies in the described trust arrangements particularly in the case of IPv4. The Authors welcome any feedback which would clarify, correct or update such information. 12. Acknowledgments 13. References 13.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [3] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [4] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Daley & Kurup Expires January 7, 2005 [Page 21] Internet-Draft Trust and Security in MLD July 2004 Discovery (MLD) for IPv6", RFC 2710, October 1999. [5] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [6] Haberman, B. and J. Martin, "Multicast Router Discovery", draft-ietf-magma-mrdisc-00 (work in progress), February 2004. [7] Fenner, B., He, H., Haberman, B. and H. Sandick, "IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", draft-ietf-magma-igmp-proxy-06 (work in progress), April 2004. [8] Christensen, M., Kimball, K. and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11 (work in progress), May 2004. 13.2 Informative References [9] Thaler, D. and M. Talwar, "Bridge-like Neighbor Discovery Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy-02 (work in progress), February 2004. [10] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [11] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [12] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [13] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [14] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [15] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 (work in progress), April 2004. [16] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [17] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-09 (work in progress), May 2004. Daley & Kurup Expires January 7, 2005 [Page 22] Internet-Draft Trust and Security in MLD July 2004 [18] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. Authors' Addresses Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical adn Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 EMail: greg.daley@eng.monash.edu.au Gopi Kurup Centre for Telecommunications and Information Engineering Department of Electrical adn Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 XXXX EMail: gopakumar.kurup@eng.monash.edu.au Daley & Kurup Expires January 7, 2005 [Page 23] Internet-Draft Trust and Security in MLD July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Daley & Kurup Expires January 7, 2005 [Page 24]