Receiver Access Control in IGMP

1. Receiver Access Control in IGMP Thomas Hardjono, Verisign Haixiang He, Nortel Networks Brad Cain, Cereva Networks

2. Motivation of Receiver Access Control • Current Service Model • Current multicast model allow any host to join a group by issuing join message • Data Encryption doesn’t prevent bogus join messages • Problem: Hosts can pull the multicast tree to its subnet when there is no other receivers. • Waste bandwidths • Waste router processing power • Solution to DoS of Multicast. • Maybe a simple solution to protect content on non shared medium.

3. Solution Goals and Requirements • Prevent a host from pulling the distribution tree into the host's subnet when no other members exists in that same subnet. • Does not address the situation when there is already a member in that subnet. • Should be light-weight solution. Provide enough benefits to be turned on.

4. Approach: Use Access Token • Use current key management service to distribute Access Tokens to hosts. • Tokens are signed by GCKS. Only legitimate routers posses the public key of GCKS. • Hosts attach Access Token to the IGMP control message. • Routers only need the public key of GCKS.

5. Access Token • Contains group address (source address for SSM), host IP, expiration time, etc. • Uploaded by hosts for their first IGMP reports and requested by routers. • Routers decrypt the tokens and decide whether to grant access or not. • Group/Source addresses prevent illegal hosts. • Host IP prevents other hosts to use the same token. • Expiration time prevents hosts to reuse the token.

6. IGMP Authentication APIs • Authentication module and IGMP module should be separated. • Use Authentication APIs to communicate. • Bool IGMPAllowed(Token, Group/Source, Host IP, Time). • Authentication module decrypt Token and compare with arguments to make decision.

7. IGMP Authentication Extension • Propose two new messages • Authentication Membership Query • Authentication Membership Report • Access Tokens are attached in the Authentication Membership Reports. • Access Token is per multicast group based and is per group-and-source based for SSM.

8. Host Behavior • In addition to the normal IGMP behavior, host will receive Authentication Query. • Response with Authentication Report that contains Access Token. • For SSM, hosts have to use multicast group records for different sources.

9. Router Behavior • Send General Authentication Query periodically. • When a group record is first created, send Group Specific Authentication Query. • When a source record is first added to the source list, send Group-and-Source Authentication Query. • When receiving State-Change records and need to send Group Specific Query, send Group Specific Authentication Query instead. • When need to send Group-and-Source Specific Query, send Group-and-Source Specific Authentication Query.

10. Router Behavior Cont. • When receiving Current-State records • Update related timers • Send Group or Group-and Source Specific Authentication Query • When receiving State-Change records • Follow the IGMPv3 behavior • Send appropriate Authentication Queries instead of normal queries when needed. • When receiving Authentication Reports • Authentication Reports only has Current-State records • Trigger Authentication Module and updated related timers according to the return values.