RFC 2588 (rfc2588) - Page 2 of 12


IP Multicast and Firewalls



Alternative Format: Original Text Document



RFC 2588               IP Multicast and Firewalls               May 1999


   upon the existing IP multicast routing/delivery mechanism, rather
   than trying to replace it with unicast.

   This document addresses scenarios where a multicast session is
   carried - via multicast - on both sides of the firewall.  For
   instance, (i) a particular public MBone session may be relayed onto
   the intranet (e.g., for the benefit of employees), or (ii) a special
   internal communication (e.g., announcing a new product) may be
   relayed onto the public MBone.  In contrast, we do not address the
   case of a roaming user - outside the firewall - who wishes to access
   a private internal multicast session, using a virtual private
   network.  (Such "road warrior" scenarios are outside the scope of
   this document.)

   As noted by Freed and Carosso [3], a firewall can act in two
   different ways:

      1/ As a "protocol end point".  In this case, no internal node
         (other than the firewall) is directly accessible from the
         external Internet, and no external node (other than the
         firewall) is directly accessible from within the intranet.
         Such firewalls are also known as "application-level gateways".
      2/ As a "packet filter".  In this case, internal and external
         nodes are visible to each other at the IP level, but the
         firewall filters out (i.e., blocks passage of) certain packets,
         based on their header or contents.

   In the remainder of this document, we assume the first type of
   firewall, as it is the most restrictive, and generally provides the
   most security.  For multicast, this means that:

      (i)  A multicast packet that's sent over the Internet will never
           be seen on the intranet (and vice versa), unless such packets
           are explicitly relayed by the firewall, and
      (ii) The IP source address of a relayed multicast packet will be
           that of the firewall, not that of the packet's original
           sender.  To work correctly, the applications and protocols
           being used must take this into account.  (Fortunately, most
           modern multicast-based protocols - for instance, RTP [4] -
           are designed with such relaying in mind.)

3. Why Multicast is Different

   When considering the security implications of IP multicast, it is
   important to note the fundamental way in which multicast
   communication differs from unicast.





Finlayson                    Informational