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 IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as RFC. - Snooping Considerations: draft-ietf-idmr-snoop-00.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.
| Aug 01 | Submit SSM considerations for IGMPv3 specification as Proposed Standard. | |
| Dec 01 | Submit IGMPv3 Interactions with routing protocols document as Informational. | |
| Dec 01 | Submit MLDv2 specification as Proposed Standard. | |
| Dec 01 | Submit Extensions to MLD for Anycast as Proposed Standard. | |
| Dec 01 | Submit IGMP Snooping Considerations document as Informational. | |
| Dec 01 | Submit Multicast Source Filtering API as Informational | |
| Dec 01 | Submit Mixed-version IGMP Proxying as Proposed Standard. | |
| Dec 01 | Submit SSM considerations for MLD specification as Proposed Standard | |
| Mar 02 | Submit IGMPv3 MIB as Proposed Standard. | |
| Mar 02 | Submit MSNIP for IPv4 specification as Proposed Standard. | |
| Mar 02 | Submit MLD Snooping Considerations document as Informational. | |
| Mar 02 | Submit MLDv2 MIB as Proposed Standard. | |
| Mar 02 | Submit MSNIP for IPv6 specification as Proposed Standard. | |
| Mar 02 | Submit MLDv2 Interactions with routing protocols document as Informational. | |
| Mar 02 | Submit MLD Proxying specification as Proposed Standard. |
Current Meeting Report
Minutes of MAGMA WG at IETF 52
------------------------------
Document Status - Haberman
draft-ietf-magma-igmp-iana-01.txt approved by IESG, to be published shortly.
Several documents adopted by MAGMA
draft-ietf-idmr-msnip-01.txt
draft-holbrook-idmr-igmpv3-ssm-02.txt
draft-vida-mld-v2-01.txt
---
draft-he-magma-igmpv3-auth-00.txt - H. He
Based on IRTF work to do multicast receiver access control. It was proposed to IRTF SMUG to use IGMP v3 to upload access control.
People suggested in London to change IGMP and it was suggested that they let MAGMA and IDMR know about these changes.
Idea - want to protect the multicast infrastructure
core - protected by routing protocol
edge - protected by IGMP
Just protecting routing protocol itself is not enough. The routing protocol does not know if IGMP subscription is valid or not even if multicast data is encrypted, an illegal host can start a DOS by starting bogus join requests
This can happen even if there is no actual sender, as was discussed in Eubanks presentations in MBONED in IETF 50 & 51.
In a shared network, its easier to protect routers, but access control may still be a better solution than others. In a non-shared network, access control can prevent an authorized host from receiving encrypted data for later decryption
Audience member - the distinction between a shared and a non-shared network is not so clear. Ethernet can be snooped and spoofed, for example.
Mark Handley - what do you mean by legal? In terms of infrastructure protection, the data may be legal but if the bandwidth is much too large, the effects may be just as bad as a DOS.
Does the sender or the receiving network care? There are two people who might authorize you - the two ISP?s at each end. You cannot use one token to satisfy both.
Thomas Hardjono- I think that by legal he means with a token.
Dave Thaler - allowed by whom ?
Thomas Hardjono - I think that if the content is broadcast by the sender he doesn't care who gets it.
Dave Thaler - If it is allowed by the source there is nothing that the router can do.
Thomas Hardjono - There are three pieces required for full security:
1.) Protection of routers
2.) Send and receiver access control
3.) Key management for access to content of value
this is intended to solve a piece of problem number 2 the security piece of the draft was presented in Msec.
The host has to get a key and a token, the token gives you the ability to join the tree. So, the access ISP has to be involved.
Mark Handley - The access ISP does not care about this.
Thomas Hardjono. I know what you are saying and it is a problem - the access ISP isn't going to help you.
Dave Thaler - This is similar to when you first get onto the Internet, when you negotiate with your ISP for access.
Thomas Hardjono There will be several ISPs involved in setting up any distribution tree. These guys should perhaps all be concerned.
Dave Thaler - Today, if you can get access to the network, you can join any group you want today.
Thomas Hardjono - Today, if the host issues a join, it has to go all the way up the distribution tree. If you want to use an aggregator then you need a token to make sure it is a legit user issuing the join.
Dave Thaler - Are you trying to prevent an unauthorized group-specific join? Why not use IPSEC ?
Thomas Hardjono - If that is an acceptable solution, then fine, every host has to use a certificate with its next hop router. This is basically the same solution.
Tom Pusateri - Once you have authenticated who you are the provider will just bill you, and that will throttle excess traffic.
He - Even if there is no traffic you can still create a DOS attack by creating excess multicast join state.
Holbrook - There are legitimate cases where you might want to do something like access control, like where you only want legitimate TV studios to receive your feed.
He - Why protect IGMP states? These are used to trigger routing protocol and forward traffic downstream.
How to protect ?
One solution
Every IGMP request has authentication information. This can be a waste as it imposes a large overhead even when not needed.
The cost in router CPU may be very high.
We propose authentication on demand. Router asks for authentication only when
- a new record is needed (i.e., when state is created)
- a leave request is received
To do this, new message types
0x31 - Authentication Membership Query
0x32 - Authentication Membership Report
Propose new fields.
Also will need an authentication interface timer
Will receive {general, (*,G) , (S,G)} authentication queries
Will be soft state - router sends General authentication queries
Group and source specific information
They propose to split the group record with a single source request - cannot do this with current EXCLUDE mode.
4 different proposals to do this so far.
He wants Magma to take on as a formal document.
Brian Haberman - Before we can adopt this we need the security requirements document first.
He - Should this be here or in GSEC or Msec ?
Fenner - we need not just requirements but agreement on the necessity of the requirement.
Haberman - we have been discussing with RMT how to secure the multicast infrastructure. Until the requirements are worked out between RMT, MAGMA, and MSEC, this document can not be adopted.
---
draft-ietf-magma-snoop-00.txt - Morten Christensen
Inspired by Bill Fenner in IETF49 Was a draft in IETF 50 & 51.
Now a Magma draft in its third iteration - therefore renamed.
New in third draft
- intellectual property notice - he did a search
- current practices
- clarification of snooping requirements.
Sent a questionnaire to companies doing IGMP snooping, and got 3 responses. Also sent questions to IEEE 802 committee but without repines.
Resolved issues
if you mix IGMP v2 and v3, you must administratively configure everything to v2.
New issues - Addition of IGMP proxying option
Use 0.0.0.0 as Source IP for proxy?
Got 3 answers to snooping questionnaire - probably will not get any more. All are very consistent.
Patent issue is unclear. Authors are not so entangled, but who knows what's out there.
Questions - Should the WG wait for more responses?
Wait for IEEE response (after 6 months ?)?
Needs more thought on IPv6. Have not received any IPv6 comments yet.
What next?
Dave Thaler - If I understood you, the switch only covers IGMPv2.
Morten - No, we cover IGMPv3 and MLDv2.
Mark Handley - RFC1812 says router must not forward or originate any datagram with address of 0.0.0.0.
Bill Fenner - Routers have IP addresses, switches may not. I interpreted RFC1812 to allow it. RFC1122 says that 0.0.0.0 can be used until you get an address, which you could take to be never.
Bill Fenner - speaking as the chair - the IETF does have a formal review process with external standards bodies. You could initiate this with the IEEE.
Morten - I viewed this as a courtesy.
Holbrook - It is my opinion that you will not get any comments from the IEEE that are as close to useful as what you will get here.
Audience Member. I am part of the IEEE and there have been no discussion of this there that I am aware of.
Fenner - Send this to the IEEE mailing list saying here is the spec that we plan to publish in four months.
Brian Haberman - About IPv6, we can send a request to the IPv6 mailing list for comments.
--
draft-ietf-magma-igmp-proxy-00.txt - Bill Fenner
IGMP Proxying in draft 01 - updates
Forward everything towards the root of the tree - routers at the root must treat proxy sources as directly connected.
The routers are the root of the tree have to treat traffic from within the tree as though the source was directly connected.
Does there need to be more protocol specific wording?
This info is likely to be manually configured, but if the proxy topology is congruent with some routing topology, the route may treat all data coming from some interface as
No comments from audience
-------
draft-ietf-ngtrans-mtp-00.txt - Kazuaki
IPv6/IPv4 MTP - multicast translation mechanism - presented at NGtrans WG.
Here for approval.
Motivation - long transition period. - Need to have v4 and v6 nodes to interact.
MTP received IPv4 multicast packets and joins the IPv6 multicast group as a IGMP proxy - could work in reverse.
Dave Thaler - thinks the basic idea is good. Remove discussion of multicast techniques.
Bill Fenner - This is not a router. It is more like an application layer gateway.
Dave Thaler - this is more like a NAT translator.
Fenner - if I have a given IPv4 multicast address, what is the corresponding IPv6 address?
IPv6 client - group join request - MTP box - sends IGMP join request. MTP joins the group and sends it back with new IPv6 addresses.
Fenner - the problem is getting rid of http as the request mechanism.
Thaler - separate into two functionalities.
Audience member 2 - if you have multiple proxies are there possibilities for loops?
Haberman - In section 2.2 you talk about static address mappings. In section 4 you specify how to create a IPv6 address from a IPv4 address.
Problems - what are the scopes? Do you use v4 multicast scoping to build scope field?
If you build an address in one domain, how does the other domain know the addresses?
He - This is not applicable to large network systems.
Haberman - You cannot assume that all addresses are globally scoped. How do you scope those? How can you do RPF checks without translating the source addresses?
Fenner - What is the IPv4 source address in the v6 domain? Is the address mapped or is it the address of the proxy?
Document needs more review on mailing list.
---
draft-ietf-idmr-msnip-01.txt - I. Kouvelas
MSNIP only provides transmission control within the SSM address space.
The idea is to have routers than listen to each other and send notice to operators of any misconfigurations.
No comments from group
Other option is capability negotiation - If one router cannot send MSNIP requests, a router behind it can.
Question - how do we let hosts know if MSNIP is active on the link?
If even ONE router cannot send MSNIP , then all must configure to turn it off.
Minimal configuration on a link without routers. Interim solution is to support legacy receivers
Audience question - Why do you restrict this operation to SSM range if you are on a link without routers.
Fenner - If an application does an SSM style join in a Zeroconf environment it could use MSNIP.
Thaler - Host needs to know when to fail.
Fenner - This is not a critical issue.
Kouvelas - An application can specify what it wants to do.
Tom Pusateri - People do not use continuous group ranges that are a power of two. I think that a range should have a start and a count.
Fenner - A range instead of a mask gives you more flexibility.
Audience Member - I think there is a hole in the current draft. Which IP address is used for the informational message?
Kouvelas - The original idea of advertising ASM range to validate that hosts were using the right addresses before they started.
Audience Member - Do you intend to do the range negotiations between the routers ?
Kouvelas - It's not a negotiation.
Audience Member - But what if the range changes?
Kouvelas - The range messages will go away eventually.
IPv6 Support has been added to the todo list.
----
Mobile SSM sources - Dave Thaler
a hole in 3 specs, sent to list with little response
(magma/mobile-ip/ssm)
Mobile IP v6 review - 2 primary requirements
it should be transparent to applications and protocols sessions survive without the application knowing the difference in actual underlying IP addresses.
Mobile IP has ability to have route optimization after first packet burst
Usual scheme
Home agent (a router)
Mobile Node - has correspondant node list
Starts with a tunnel to the home agent
Correspondant Node - with binding cache - this is the thing wanting to communicate with the MN.
The MN sends a binding update to the corresponding node and then optimizes the path.
Routing sees packets are if they as destined for the care of address (COA).
Application sees packets are if they as destined for the home address (HA).
As the mobile node moves, the care of address moves, the home address does not.
For multicast sources, the mobile node keeps sending multicast traffic, and the MN sends traffic in turn from the new COA address.
The problem - the mobile node keeps trying to send as the COA changes. In SSM, the routing is done using the (COA,G), which is translated to (HA,G) at the correspondant node.
When the COA changes, how does the correspondant node know to join to the new (COA,G)?
All the correspondant node application knows know is that it is trying to send out a (S,G) join.
3 solutions
1.) don't use mobile IP HA - make it the APIs problem.
Then the correspondant node application would have to keep track of the changing COA.
2.) Always tunnel from the HA using the HAagent
- ignores route optimization - equivalent to no SPT PIM-SM.
3.) Add a mechanism - as described below.
What is the real problem here? At the receiver the binding cache insures the mapping between the HA (upper level) and COA (lower level).
BUT, for multicast, the BC is ignored.
Obvious answer is to use the BC (which can keep the (SA,G) translated to (COA,G)).
BUT, the Binding Cache is not a MUST of the current Mobile IP spec.
Points - will have to redo this periodically
-will have to authenticate binding update (by the spec)
- as the source moves
As the next binding update comes down (after a move), the old data get dropped on the floor.
SO - MLDv2 receiver is always joined to a particular (S,G) to BOTH the home agent and the COA.
So, when the receiver moves, it gets the data tunneled briefly before the binding cache is updated.
This does require a binding cache.
Today in IPv6 multicast, the source does not know if the receiver is in include or exclude mode (i.e., SSM or ASM mode). In solution 3, the source will have to know the difference.
Audience Question -- Isn't there an SSM address range
Answer - yes, but there could be SSM (or include modes) from outside this.
Audience Member - how does authentication work? Why is it needed?
Answer - so that you cannot hijack a users mobile session.
This is a problem in both unicast and multicast.
Ross Finlayson - what about renumbering?
Answer - that's outside the scope of this.
Audience Member - there has been a lot of work on mobile IP multicast - maybe there is a solution in there.
Audience Member 2 - there has been work recently on context transfer. This may make it possible for transfer multicast sessions rapidly.
(Rough consensus seemed to favor solution 3, but with more study & thought needed.)
Slides
Agenda
IGMP Proxying Update
Mobile SSM Sources
Multicast Source Notification of Interest Protocol (MSNIP)
An IPv6/IPv4 Multicast Proxy - Translator
IGMP and MLD Snooping Switches