Receiver Access Control in IGMP Thomas Hardjono, Verisign Haixiang He, Nortel Networks Brad Cain, Cereva Networks 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. 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. 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. 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. 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. 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. 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. 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. 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.