We currently see no way to apply the request-response filtering policy for IP multicast applications. In most multicast applications, it is not even meaningful to attempt to classify packets as either requests or responses. Applications use multicast for a wide range of purposes, such as resource location, one-to-many request-response, information dissemination, and peer-to-peer conferencing. Different applications can use the same multicast address simultaneously without restriction. Even within a single application, a single multicast address can be used simultaneously for different purposes.
Consider Van Jacobson's wb  application as an example. This distributed whiteboard is a peer-to-peer application in which each participant subscribes to, and transmits on, a single multicast address. Though the protocol treats all hosts symmetrically, we can classify individual packets as unsolicited information dissemination (for advertising local additions to the shared whiteboard), one-to-many requests (for requesting the retransmission of a previous dissemination), or one-to-many responses (in which some host near the requesting host re-transmits the requested data). A packet filter cannot discriminate between these different uses of the multicast address without having considerable application-specific knowledge.
Furthermore, filtering any of these three classes of packets would significantly disrupt a wb session. If the dissemination packets are dropped, then local clients only see the locally-contributed whiteboard data. If the retransmission request packets are dropped and only local hosts possess the requested data, then no outside participant will ever see that data. Even if the data is available elsewhere, the inability of local hosts to provide the data introduces an artificial latency into the recovery process because more distant hosts wait to see if hosts near the requester will answer first. Finally, if retransmission responses are dropped, then local hosts may again never see all available whiteboard data. Packet filtering must therefore be all-or-nothing on a per-application basis, meaning that the firewall would need to be informed about the multicast address used by each active application session.
Filtering on a per-multicast address basis is not secure, however. Because multiple applications may coincidentally use the same multicast address simultaneously, multicast applications themselves currently use heuristics to distinguish their own packets from those of other applications. These heuristics typically search for private application and session signatures in every received packet. Packets that do not have the appropriate signatures are dropped. Any packet admitted by the filter may be delivered to several different applications behind the firewall, and we cannot be sure that each of them will properly discard inappropriate packets. Because the application-level signatures are only a heuristic, we face the same masquerading problem as for unicast; however, the number of potential application-level protocol interactions is considerably higher with multicast than with unicast. Consequently, without any further guarantee about how applications handle foreign packets, we must drop all inbound multicast packets.
IP multicast is relatively new, and its implementation and delivery semantics at endpoint hosts are still in flux. In addition, most existing IP multicast-based applications are still undergoing development. We regard this as a perfect opportunity to develop a new non-UDP protocol above IP multicast that provides reliable end-to-end application and session authentication. Only when such a protocol is available can we trust endpoint applications to reliably discard unexpected packets. Development of such a protocol is an area of on-going research.