2.3.12 Multicast & Anycast Group Membership (magma)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-24

Isidor Kouvelas <kouvelas@cisco.com>
Brian Haberman <brian@innovationslab.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Margaret Wasserman <margaret@thingmagic.com>
Mailing Lists:
General Discussion: magma@ietf.org
To Subscribe: magma-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/magma/index.html
Description of Working Group:
Group management protocols are crucial to the operation of multicast within the Internet, and there are some benefits in extending group management protocols to also be able to support anycast. These protocols allow hosts to inform routers of their membership status within groups. This working group will be responsible for developing the functionalities required for group membership reporting and other related actions. This group will also address the initial authentication and access control issues associated with anycast group membership; this is likely to be limited to shared secrets and message authentication codes (MACs) much like current routing protocol security. Other aspects of Anycast, including architecture and routing, are outside the groups scope.

The draft names listed below are the starting point for the work in the WG.

MAGMA specifications will include:

- Core IGMPv3/MLDv2 specifications. These specifications will describe the protocol used between hosts and routers to share group membership information. IGMPv3 and MLDv2 build on IGMPv2 and MLDv1 by adding two types of source-specific filtering; "include" (in which the system tells the router exactly which sources it desires) and "exclude" (in which the system tells the router that it does *not* desire a list of sources).

- IGMPv3: The IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as RFC.

- MLDv2: draft-vida-mld-v2-00.txt

- Multicast Source Filtering API. This specification describes the API used to interact with IGMPv3 and MLDv2 to indicate source filters. - draft-ietf-idmr-msf-api-01.txt

- Host determination of network group membership. In a multicast environment, systems may be interested in learning whether or not there are any group members, in order to save the trouble of sending data that nobody is listening to.

- Multicast Source Notification of Interest Protocol: draft-ietf-idmr-msnip-00

- Multicast forwarding in tree topologies using IGMP/MLD Proxying - Create a single document from: - draft-ietf-idmr-igmp-proxy-00

- draft-he-mixed-igmp-proxy-00

- Source-Specific Multicast (SSM) consideration document. This work will describe the use of IGMPv3/MLDv2 in an SSM environment. - draft-holbrook-idmr-igmpv3-ssm-01.txt

- Considerations for "IGMP snooping" switches (switches that watch IGMP exchanges in order to determine multicast forwarding behavior)

- Multicast Router Discovery: The MAGMA group has taken ownership of this draft over from IDMR. It will be revised and submitted as a Proposed Standard.

- Snooping Considerations: draft-ietf-magma-mrdisc-00.txt (previous revisions draft-ietf-idmr-snoop-XX.txt)

- Group management MIBs - update RFC 2933 for IGMPv3 - update RFC 3019 for MLDv2

- Interaction between IGMP/MLD and routing protocols - draft-ietf-idmr-igmpv3-and-routing-00.txt

- Extensions to MLD supporting anycast group memberships including authentication and access control mechanisms - draft-haberman-ipngwg-host-anycast-00.txt

In addition, this working group will coordinate with other IETF working groups where multicast and anycast group management protocols are utilized as well as coordinating with the Multicast Security WG.

Goals and Milestones:
Done  Submit IGMPv3/MLDv2 Interfactions with Routing Protocols as Informational
Done  Submit IGMP/MLD Proxying Specification as Proposed Standard
Done  Submit IGMP & MLD Snooping Considerations as Informational
Done  Submit SSM considerations for IGMPv3 & MLDv2 as Proposed Standard
Done  Submit Multicast Source Filtering API as Informational
Jul 04  Submit IGMPv3/MLDv2 MIB as Proposed Standard
Sep 04  Submit MRD as Proposed Standard
Sep 04  Submit MSNIP for IPv4 & IPv6 Specification as Proposed Standard
  • - draft-holbrook-idmr-igmpv3-ssm-07.txt
  • - draft-ietf-magma-igmpv3-and-routing-05.txt
  • - draft-ietf-magma-snoop-11.txt
  • - draft-ietf-magma-igmp-proxy-06.txt
  • - draft-ietf-magma-msnip-05.txt
  • - draft-ietf-magma-mgmd-mib-03.txt
  • - draft-ietf-magma-mrdisc-01.txt
  • Request For Comments:
    RFC3228BCPIANA Considerations for IGMP
    RFC3590 PS Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
    RFC3678 I Socket Interface Extensions for Multicast Source Filters
    RFC3810StandardMulticast Listener Discovery Version 2 (MLDv2) for IPv6

    Current Meeting Report

    Multicast and Anycast Group Membership (MAGMA) WG

    Multicast and Anycast Group Membership (MAGMA) WG

    IETF 60 – San Diego

    Brian Haberman

    Isidor Kouvelas


    • Agenda Bashing       Kouvelas        5
    • Document Status      Kouvelas        5
    • MRD Update             Haberman      10
    • MGMD MIB                Haberman      10
    • Security & MLD         Daley              15
    • MSNIP                        Haberman      5


    Document Status

    • Multicast Router Discovery
      Draft adopted by MAGMA from IDMR before Seoul.
      To be submitted for proposed standard.
      Will start WG last-call after meeting.
    • Multicast Listener Discovery Version 2 (MLDv2) for IPv6
      Published as Standards Track RFC3810
    • Multicast Group Membership Discovery MIB
      WG last-call ended on July 22.
      Revision will address comments and will be sent to IESG.
    • Considerations for IGMP and MLD Snooping Switches
      In RFC editor queue. Waiting on MRD normative reference.
    • IGMP/MLD-based Multicast Forwarding
      In RFC editor queue. Waiting on igmpv3-ssm.
    • Using IGMPv3 and MLDv2 For Source-Specific Multicast
      At IESG (AD followup).
    • IGMPv3/MLDv2 and Multicast Routing Protocol Interaction
      In RFC editor queue waiting on idmr-dvmrp, ssm-arch, pim-dm, pim-sm.
      Apart from dvmrp the rest of the drafts are in the editor queue or getting there.
    • Multicast Source Notification of Interest Protocol (MSNIP)
      Looking for volunteer to pick up spec.


    All the drafts are done with the exception of MRD (which will be submitted to the IESG soon) and MSNIP that requires minor mods but has been stalled for a while.


    Multicast Router Discovery

    Jim Martin - Brian Haberman (presenter)


    New version of the spec done just before the deadline. Thank Jim who did most of the edits.


    Editorial Changes:

    • New IPR and copyright text
    • Added RFC 2119 keywords
    • Filled in missing references

    Technical Clarifications:

    • Encoding of Query Interval field
    • No new adverts when Query Interval or Robustness Variable change
    • Cleaned up Security Considerations
    • ICMPv6 code comes from Informational range
    • Explicit mention of IGMP and MLD in abstract
    • Clarified text on discarding Advertisements
    • Cleanup text on parsing messages
    • Any authentication mechanism between routers and hosts is out of scope


    • Addresses all comments from Seoul and mailing list
    • Ready for WG Last Call


    Group agreed (through not objecting :-) to start WG last call after the meeting.


    Group Management MIB

    Julian Chesterfield (Slides provided by Julian presented by Brian pretending to be a tall English guy with short black hair)


    Julian put draft-ietf-magma-mgmd-mib-03.txt through WG last call.


    Updates from –02:

    • Fixed typos and suggestions as previously outlined
    • No significant content changes from -02
    • Version 03 in ‘Last Call’
    • Some feedback already received, new draft version (04) anticipated very soon.

    Outstanding Items:

    • Feedback regarding last call version received, changes to make:
      • Clarify router non-implementation of host tables
      • Clarify Cachestatus variables and implementation impact
      • Update overview
      • CacheAddressType not-accessible
      • InetAddress variables must be followed by InetAddressType
      • RFC 1902 compliancy, review access parameters for each table
      • Some additional typos
    • Any other feedback please contact mailing list and author at:


    Dave Thaler: In an earlier meeting I pointed out that the OIDs conflicted with IGMP. Has that been fixed?

    Brian: Yes it has been fixed.


    MSNIP Status

    Brian Haberman

    Order of presentations was changed so that Greg could have the rest of the available time.


    Where We Stand

    • MSNIP held up on SSM range configuration issue
      • Anyone interested in picking up the work?
    • MRDSSM spec in holding pattern waiting on MRD spec (essentially DEAD)
    • Issues with piggy-backing host-to-router information on a router-to-switch message
    • Consensus to not support configurable SSM ranges
    • MSNIP goes forward with fixed SSM range.



    Brian: MSNIP and MRDSSM documents hanging around. MRDSSM has expired but is still hanging in ID tracker. MSNIP is still hung up on whether the SSM IPv4 range is fixed. As far as I am concerned the ranges are fixed unless Hugh has any issues with that.


    Hugh: Never had any issue with doing this. There was an issue about whether to do SSM in the 239 range. Toerless and Beau were expressing interest in that. I think not having MSNIP in that range would be a reasonable compromise that would allow this draft to go forward.


    Brian: The other issue is that the other draft (MRD-SSM) that talks about advertising configurable ranges is hang-up on the MRD spec but is essentially dead with the fixed range.


    Isidor: Right, it is the fixed range as well as that MRD no longer has support for carrying options.


    Brian: The range is fixed so there is no reason for us to try and push MRD-SSM forward at this point in time. As far as I am concerned the consensus was to not support the configurable SSM range unless someone wants to jump up and work on this problem.


    Hugh: It seems like a reasonable path to take would be to say that we don’t support configurable ranges and let this draft (MSNIP) go forward and if it turns out to be important somebody can write another draft that explains how to do it.

    There is nothing in the documents that prevents doing that.


    Brian: Right. The one issue that comes up is whether we want to use MRD as the one vehicle to advertise this range because we simplified MRD and now it is only a router-to-switch protocol and not a router-to-host.


    Isidor: As far as I remember from the last meeting (Seoul) that if we eventually want to advertise configurable ranges we should come up with another protocol and MRD should go ahead as is currently defined.


    Brian: So unless there is anyone to pick up the configurable range work as far as Isidor and I are concerned we drop the MRD-SSM draft and MSNIP goes forward with an applicability statement.


    Isidor: So MRD-SSM dies and MSNIP goes forward with a fixed range.


    Slides used in the presentation did not match what was said but Brian will fix them before submitting them.


    Trust and security in Multicast Group Management

    Greg Daley <greg.daley@eng.monash.edu.au>

    Gopakumar Kurup <g.kurup@eng.monash.edu.au>

    Monash University CTIE - August 4, 2004


    This presentation had a lot of discussion. Only part of it is covered here. Please listen to the mbone session recording to get the full version. The recording can be found at:



    Brian: Greg is going to talk about a topic that came up in the last meeting and he put together a draft which he is going to present now.


    Greg: Put this draft together with Kurup.


    Survey & Analysis of MLD security

    • Some previous work done by Castelluccia & Montenegro (@ISCC 2003)
      There is also a gsec WG draft that covers the same material.
    • Unlike that work, this draft tries to avoid a solution proposal and it is born out of what we were trying to discuss last time (Seoul) which I didn’t know much about. So if you have in depth security or MLDv2 knowledge and can show that something is wrong please just tell me.
    • Tried to cover Snooping and Proxy environments as well.


    Key issues

    • MLD protects against off-link attacks so we are focusing on On-Link or subscriber attacks only. Subscriber attacks means attacks on links that we are routing to.
      There is an implicit assumption in multicast (which does not exist in unicast) that through the group management protocol we can modify the routing multiple hops back into the network and the forwarding for those devises.
    • Still potential for significant abuse
    • Principally looking at Denial-of-service
    • Effects felt on-link and off-link especially where QoS is not fully integrated.


    Summary of Vulnerabilities

    • Fake Router / Querier can effectively shut off all multicast delivery to a link.
    • Malicious Reporting. Reports for groups that don’t exist…
    • False Multicast Router Advertisement
    • Fake snooping switch for multicast router solicitation


    Fake Router/Querier

    • Effects normally only felt on-link.
    • Routers act on received query at any address, queriers can disappear
    • Trivial to become Querier: Pick Lower Address
    • Hosts must respond to queriers within specified MRC.
    • Increase of leave latency with QQIC (overlap)


    Dave Thaler: Attacks forcing host reports ar slightly worse in MLDv2 because it does not have report suppression.


    George Gross: The question becomes how serious you are about securing the router because if you are you have to be glued to the group controller that actually admits the members into the group.


    Greg: Potentially. You can still have uncontrolled groups and those groups can still be abused.


    Dave: For this specific issue you don’t need control of groups. This is a fake router. So long as you can authenticate the router each individual group is not relevant. The SEND WG is trying to secure router advertisements. The same sorts of threat models apply to this one.


    George: I can solve this problem using MSEC protocols I think if the router was required to have a public / private-key pair. MSEC treats data as a black box and does not think the routing infra but if you wish to have your routers organised as a group and they are admitted to the group by some controller you can.


    George: Where do you think this draft has a home? MSEC or…


    Greg: I have to admit I am not an MSEC person. My background is in neighbour discovery so I thought a neighbour discovery group like MAGMA might be an appropriate place.


    Brian: Greg was the one that mentioned in Seoul that there are relationships between SEND and MLD behaviour that we may want to look at being able to protect the MLD messages both from a router perspective and hopefully from a host perspective. Where that work is going to be done is a good question. I wanted to give him a forum because this issue was brought up in this WG the last time. If I had a choice I would much rather have it in MSEC because that is where the security expertise is. This draft was posted both to MAGMA and to MSEC. My intention is that after this presentation we have a discussion about whether this work is worth doing and what home does it live in.


    Greg: I didn’t ask for time in MSEC because I didn’t know what the role is…


    George: MSEC agenda was full anyway.


    Toerless: I have seen a long list of description of problems. I have been missing some specific solution. What is the point?


    Greg: We are just trying to describe that there will be problems if the multicast infra is worth damaging.


    Toerless: There are solutions like access lists, layer two security etc that are being deployed. The only access network where there are no good solutions is wireless networks.


    Dave: The purpose of this draft is to carve out security issues that are specific to MLD and IGMP and ideally those issues should have been covered in the security considerations of those drafts. I am glad that you are doing this work because this WG needs to know about these issues. Maybe the result should be an updated draft or an updated security considerations section. I think this is a very appropriate WG.


    Greg: Whether or not we want to work on frameworks here and say issues are addressed in MSEC maybe is another idea.


    George: Retrofitting security is really hard.


    Brian: Some of this work can be enhancements to security considerations and can also help to identify items of work going forward.


    George: I suggest you bring it up to MSEC.


    Hugh: Maybe I am simplifying the problem but doesn’t the solution boil down to authenticating the messages? So you have a key management problem about how the receivers get the keys, which you will have no matter what you do. But the backward compatibility issue is not really there.


    Toerless: Authentication is one of the pieces but you also pointed out denial of service attacks, which is a completely different issue.


    Report Hijinx

    • Spoofing / Replay of received reports possible.
    • Route change bombing (report until)
    • State Change Reports cause queries...
    • Requests for large or many streams causes bandwidth depletion.
    • v1 reports may cause ASM fallback


    Multicast Router Discovery

    • Multicast Router Solicitations must be responded to
    • Fake MRS causes routers to send MRAs
    • Multicast Router Advertisements unauthenticated
    • Fake MRA directs all multicast to a port for snooping/DoS.


    Further Work

    • Interest?
    • Requirements / Existing Specifications of interest


    Greg: Are people interested in this work?


    Dave: How much of this is already covered in existing security considerations sections.


    Greg: Some of this stuff is covered in MRD and some basic stuff in IGMPv3 / MLDv2. We just tried to elaborate some sneakier attacks.


    Dave: It would be great if the draft pointed out what parts are updates to security consideration sections versus what parts are references.


    Appendix: Potential Requirements

    • Transport of ’security’ credentials
    • Group Member’s infrastructure requirements (Authorized or Anonymous?)
    • Secured Group IDs? (Castelluccia / Montenegro)
    • Report Message integrity (unicast CGAs / SEND??)
    • Replay protection (Reachability Checks? / Timestamping? / Query Nonces?)
    • Query Authorization (SEND Router Auth??)


    Hugh: I guess some of this may be addressed by layer 2 solutions. Where you may have more of a problem is wireless. But if it is authenticated wireless you got some level of protection and tractability potentially there anyway.


    Appendix: Specifications of Interest

    • SEND
      • draft-ietf-send-ndopt-06.txt
    • Multicast Routing Protocol Security
      • draft-savola-mboned-mroutesec-00.txt


    Appendix: Specifications of Interest

    • Montenegro & Castelluccia MGM security GSEC draft
      • draft-irtf-gsec-sgmv6-01.txt
    • Related Research
      • Castelluccia, C. and G. Montenegro, ”Securing Group Management in IPv6 with Cryptographically Generated Addresses”, IEEE ISCC 2003, July 2003.


    Brian: The question for the group is who is interested in looking at the security issues of the problems that Greg has started looking at from the group management perspective and coming up with more of a survey of the issues as an information doc. Who thinks it is a worthwhile piece of work / not worthwhile?

    Who is going to put cycles into reviewing? Who read the doc? Greg does not count J. Less than 10% have read it. Will not ask the question about adopting it now. Need to talk to AD.


    Toerless: Is it specified what the purpose is? Just collecting? Making a survey?


    Brian: It is just a “what did we miss the first time around?”. Not proposing any solutions. I will talk with Margaret to take this on.


    Thanks everybody for coming.




    Document Status Multicast and Anycast Group Membership (MAGMA)
    Multicast Router Discovery
    Group Management MIB
    Trust and security in Multicast Group Management
    MSNIP Status