Saturday, March 12, 2011

IGMP Filtering - Developer tips

IGMP protocol allows hosts to report their interest in Multicast address membership with adjacent routers.  These adjacent routers in turn propagate the consolidate membership with upstream routers using PIM-SM or using IGMP proxy functionality.

IGMP protocol sits right on top of IP layer, at the same level as ICMP, UDP and TCP.  IGMPv1 and IGMPv2 protocols are older protocols to IGMPv3.  IGMPv1 and IGMPv2 join the multicast membership by providing Multicast address in IGMP report message.  IGMPv3 takes one step further and even ask for membership with respect to source.  That is, there could be  multiple Multicast sources  sending same streams using one Multicast address. Hosts have choice of receiving the Multicast traffic only from some specific sources - It can specifically include the source addresses in the report message or can exclude some specific sources.

Typical firewalls today don't have capability to restrict the hosts on a specific interface from joining specific Multicast stream.  Firewalls today can allow or deny the IGMP packets on a specific interface though. But this is not sufficient.  It should be possible to restrict a given multicast stream on a specific interface.  This is possible only if firewall on the router deny only IGMP reports having restricted Multicast addresses.

IGMP filtering functionality in routers expected to provide following functions.  Some vendors call this 'IGMP filtering for Multicast authentication'.  I never understood why they use term 'Authentication' though.

  • Provide facility for admin user on per interface basis 'Allow Only List' or 'Disallow list'.  Each list contains multiple records. 
    • Multicast Address,  Source address.
    • Source address can be 'ALL'.  
Some implementation considerations:

It is always good to implement this module separate from IGMP Router or IGMP Proxy modules.  In case of IGMPv1 and IGMPv2,  each membership report message only contains one Multicast address.  If this multicast address is to be restricted,  then the complete message can be dropped.  In case of IGMPv3,  one membership report message can contain multiple Group records with each group record having multicast address, source addresses and qualifier to all the source addresses listed in the group record - include or exclude.  IGMP filter module needs to do quite a bit of work to identify the group records and corresponding sources and remove only the affected ones from the message.  Then rest of the message should be allowed to pass through.  If the complete Multicast address is restricted as per configuration, then the complete Group record from the IGMP report message can be removed.  It is not as simple as though.  From the configuration, some times only specific source addresses are to be removed from the group record in the message. That is, IGMP filter is expected to selectively remove not only group records, but also source addresses selectively in the group records.


RaviKanth said...

Assume a scenario where we received a membership report with EXCLUDE(G,s3) which says for Group G allow all sources except s3, and at the same time in IGMP filter if we have a rule which allows only s1and s2 sources for Group G.
In such case shall we change the EXCLUDE(G,s3) report to INCLUDE(G,(s1,s2)).
If we do this, after sometime the route may send a source specific query in the network to check if any host is in INCLUDE state for the sources (s1,s2), there may not be any response for this query as the host is actually in EXCLUDE(G,s3) state.

Srini said...
This comment has been removed by the author.
Srini said...

As you may know, IGMP router normalizes the sources in its Group specific state. That is, it can receive multiple different member reports for same group multicast address with different source IP addresses from different hosts in the network. IGMP router does not store state for each IGMP report it gets. It normalizes the information. It sends queries based on the normalized information. Due to this, hosts can't expect to receive the query with same source IP address (Group record) which it sent in the previous report. IGMP hosts are intelligent enough to generate the reports in response to any kind of queries.

In your example, host would respond with the information it has even if it receives query for S1 and S2.