Multicast & Anycast Group Membership WG Minutes
Chairs: Bill Fenner (fenner@research.att.com)
        Brian Haberman (bkhabs@nc.rr.com)

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.