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
- 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.
| 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 |
| RFC | Status | Title |
|---|---|---|
| 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 Brian Haberman Isidor Kouvelas Agenda
Document Status
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 DiscoveryJim Martin - Brian Haberman (presenter) New version of the spec done just before
the deadline. Thank Jim who did most of the edits. Editorial Changes:
Technical Clarifications:
Conclusions:
Group agreed (through not objecting :-) to start WG last call after the meeting. Group Management MIBJulian 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:
Outstanding Items:
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 StatusBrian Haberman Order of presentations was changed so that
Greg could have the rest of the available time. Where We Stand
Thoughts? 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 ManagementGreg 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: ftp://limestone.uoregon.edu/pub/videolab/video/ietf60/ 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
Key issues
Summary of
Vulnerabilities
Fake
Router/Querier
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
Multicast Router
Discovery
Further Work
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. |