Last Modifield: 05/30/2002
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 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 IGMP Snooping Considerations document as Informational.|
|DEC 01||Submit Extensions to MLD for Anycast as Proposed Standard.|
|DEC 01||Submit Mixed-version IGMP Proxying as Proposed Standard.|
|DEC 01||Submit Multicast Source Filtering API as Informational|
|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 MLDv2 MIB as Proposed Standard.|
|MAR 02||Submit MLD Snooping Considerations document as Informational.|
|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.|
|RFC3228||BCP||IANA Considerations for IGMP|
Multicast & Anycast Group Membership WG Minutes Chairs: Bill Fenner (email@example.com) Brian Haberman (firstname.lastname@example.org) Document status - MLDv1 source address selection is in last call - proposed standard - MLDv2 specification is at the IESG - Source filtering API is awaiting author response to comments Dave Thaler - I'll take the action item on that - Ready for last call MSNIP (experimental) draft-ietf-magma-msnip-01.txt MRD SSM Range Option (proposed standard) draft-ietf-magma-mrdssm-01.txt Proxy (proposed standard) draft-ietf-magma-igmp-proxy-01.txt Snooping (informational) draft-ietf-magma-snoop-04.txt IGMPv3/MLDv2 for SSM (proposed standard) draft-holbrook-idmr-igmpv3-ssm-03.txt Q. Problems with the MSNIP spec - I tried to understand the design rational for the host state. If you have 2 or more router, the host state information is router based, so you have to double or triple your information. And what if there is no router but lots of hosts - the state information could be used by lots of hosts? Audience - How many hosts would be a problem - a million ? How much state is really kept? What's the problem - the computation or the storage? A second concern - the scenario is SSM based - what about proxy based? If you want to run MSNIP on a proxy, this is not addressed. IGMP does not have receiver subscription information. Answer - This is not an MSNIP issue, but a proxying issue. The proxy will be responsible for proxying MSNIP information. Charter update Originally, wanted to do v4 first, v6 afterwards. Now, given the speed of developments, the chairs cajoled the authors to include v6 as well. The only issue is the IGMPv3/MLDv2 MIB - whether these can/should be combined. Bill Fenner - there are benefits both ways. If separate, each can be extensions of the existing MIBs. If together, then the old managers would not be able to get any information from the new MIBs. Brian Haberman - Also the names of the variables and the granularity of time variables would be different. Dave Thaler - There are other changes to the MIBs that are ongoing so it may make more sense to combine them. Bill Fenner - I agree that neither the naming or the granularity is a show stopper. It just has to be taken care of. Snooping draft Need a baseline of what to do - this is a strictly informational document. the 6th version of the draft is answers to open issues etc. from switch vendors. ready for last call. Beau Williamson - when you have a conflict between include and exclude draft says the first person "rules" - whereas IGMPv3 says, includes override. Bill Fenner - This sounds wrong. Audience member - What happens to snooping switches when we upgrade IGMP or MLD? Brian Haberman - There is some sentiment in the MBONE working group that snooping is not aa good idea. Audience member - Yes, we should document this stuff but say that snooping is not a good idea. MCOP How it works: - Receiver sends igmp/ mld as normal. - Router sends a MCOP validate message to a MCA with a Database. - Once it is validated, a verify message is sent back and the join can go as normal. This may be implemented over Diameter once this is published. Receivers should use RFC3122 inverse NDP to find out global scope address of the client when used with MLD. Open issues: - How is the client informed that access is denied? Could use ICMP "administratively prohibited" messages but these are supposed to have TTL-1. Should this be changed ? Next steps: - Finalize implementation - MCA+database protocol Want to publish as experimental. Dave Thaler - didn't talk about what the actual threat model is The threat model is something like the Ramen worm. Beau Williamson - I am constantly getting requests from network administrators to limit the groups or the number of groups that users are allowed to join or send. Dave Thaler - What do you when the MCA doesn't know anything about the group accept or deny? Answer - We could do either as a policy issue - it's policy not protocol. Dave Thaler - Why can't you use an existing protocol? Also, is the right WG for this? Daniel Senie - I think that some means of access control is needed. Whether this is the right one is another question. Also, I am not convinced that the clients IP address will be enough for an identifier. Beau Williamson - I would like to see something like this move forward - it is desperately needed. However, at the very least the authentication needs to move beyond IP address, and there needs to be more on rate limiting. Brian Haberman - If you get these addresses dynamically (e.g. DHCP), then you should have a token, which you could pass to the authenticating router. There is not a clear definition of the threat model. Authentication is not in our charter, and this model may or may not involve IGMP/MLD. Let's first figure out the problem and then figure out the protocol. IGAP IGMP for user Authentication Protocol Architecture - ISP/NSP connection to Internet - A CDN both attached to edge router IP Multicast in CDP - Successful services need - access control - limit to intra domain multicast to avoid interprovider issues - collaborations between content providers and network providers At present - No user access control - no user usage information mechanism - multicast content security is being developed, but does not provide all needed functionality. IGAP adds a protocol framework to transport user information to IGMP enables providers to - enforce access control by a group - collect per user usage information IGAP is only used between edge router and end user. Initial IGAP is based on IGMPv2 Edge router connects to a AAA server Request to make this a WG draft Marshall Eubanks - why does IGAP need a modification to the user/edge router interaction? Answer - User authentication is based on more than the User IP address. Toerless Eckart - I do not think that the working group should accept any draft based on IGMPv2, unless it is historical only. Audience member - This seems strong as it implies as IGMPv2 is harmful, and any way IGMPv3 is still in draft status. Response - No, IGMPv3 is an RFC. Beau Williamson - This is effectively IGMPv4, and the chances of getting it deployed is very low. And what happens when a user sends IGMP instead of IGAP? Brian Haberman - This is not really a network layer functionality - it has been done before at a higher layer in unicast, and that would be appropriate here. Audience - This is a piggy back protocol. IGMP happens to be a protocol to register interest, and we have seen elsewhere in the IETF attempts to use this functionality to do other things just because it exists. Toerless Eckart - Multicast is different, as you can be sent traffic that you cannot use. Audience member - And I do not see any attempts to synchronize all of these proposals. Thomas Hardjono - I think we need a requirements document and also need to worry about layers - some of this stuff should not be done at the transport layers. Non IGMP Specific Authentication General Internet case - Receiver node gets a group key from the group key server - hop by hop transmission between all the ISP's in the chain. - Why hop by hop - because you can only assume a security relationship between neighboring ISP's In general, there is no security relationship between a user and the ISP. General Case needs: - An ISP needs to - do some sort of accounting per client - needs to use ACL's, for ingress filtering, say. Content provider needs to control who views the content These goals are not multicast specific One solution: - When the receiver "connects" you can place ACL's based on relationship at connect time. - You can secure hop by hop messages in the same fashion. Port ACL's can change over time. Per group security and keys can be done between apps and group key servers; also data can be encrypted. Protecting bandwidth - You can charge the users - The _same_ problem exists with unicast data and is not solved there - If the receiver and content provider are on the same network, the content authorizer can cause the ACL to be updated Conclusions: - Group specific security in IGMP is not reasonable - Other solutions appear to solve this general case - No Need to change IGMP/MLD Audience - I would argue that having a full mesh security solution does more for you than the existing piecemeal solutions. Dave Thaler - In the general case you do not have a full mesh security solution because ISP's do _not_ trust one another. Toerless Eckart - There should be some message back to the receiver if access is denied. Greg Shepard - People lining up expectations of multicast so that nothing gets deployed is a problem. However, the problem is not multicast but UDP. Audience member - What we want to do is to control access. Dave Thaler - there are two people who have an interest - the content provider and the network operator. The content provider should authenticate and encrypt, the network operator cares about bandwidth and therefore can apply "ACL's" (in a generic sense - they might be port filters, source filters, etc.). These are different problems. Beau Williamson - The IGAP protocol may solve the multicast UDP problem, but not the unicast UDP problem, so this does not solve the general problem. Tom Pusateri - If we have a general solution to the general problem, why do we need a specific solution to a subset of the general problem. IGAP presenter - What is the specific solution for the special case where the content provider and the receiver are on the same network ? Toerless Eckart - Do you mean that there will never be a need for this ? Dave Thaler - I never would say never. I am just saying that I do not see it right now. Audience member - Two solutions from an ISP point of view - we pay for each bit that passes from another ISP - BAD - or, encryption. Brian Haberman - Before we get out of hand, we need to see what the requirements are. People interested in working on this problem should collaborate on THAT draft and then we can assess where the work belongs.