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

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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 7, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   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

   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

   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

   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


   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

   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

   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

   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

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

   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

   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

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.  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

   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

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

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


   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

   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

   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

   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

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

   Phone: +61 3 9905 4655

   Gopi Kurup
   Centre for Telecommunications and Information Engineering
   Department of Electrical adn Computer Systems Engineering
   Monash University
   Clayton, Victoria  3800

   Phone: +61 3 9905 XXXX

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Daley & Kurup           Expires January 7, 2005                [Page 24]