Last Modified: 2004-06-24
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
- 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.
|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|
|RFC3228||BCP||IANA Considerations for IGMP|
|RFC3590||PS||Source Address Selection for the Multicast Listener Discovery (MLD) Protocol|
|RFC3678||I||Socket Interface Extensions for Multicast Source Filters|
|RFC3810||Standard||Multicast Listener Discovery Version 2 (MLDv2) for IPv6|
Multicast and Anycast Group Membership (MAGMA) WG
IETF 60 – San Diego
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.
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:
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.
Order of presentations was changed so that Greg could have the rest of the available time.
Where We Stand
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 <firstname.lastname@example.org>
Gopakumar Kurup <email@example.com>
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
Summary of Vulnerabilities
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.
Multicast Router Discovery
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
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
Appendix: Specifications of Interest
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.