Receiver Access Control in IGMP

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.

similar documents