IP Multicast and Firewalls (RFC2588)
Original Publication Date: 1999-May-01
Included in the Prior Art Database: 2019-Feb-11
Internet Society Requests For Comment (RFCs)
In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.
Network Working Group R. Finlayson Request for Comments: 2588 LIVE.COM Category: Informational May 1999
IP Multicast and Firewalls
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
Many organizations use a firewall computer that acts as a security gateway between the public Internet and their private, internal ’intranet’. In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast.
A firewall is a security gateway that controls access between a private adminstrative domain (an ’intranet’) and the public Internet. This document discusses how a firewall handles IP multicast  traffic.
We assume that the external side of the firewall (on the Internet) has access to IP multicast - i.e., is on the public "Multicast Internet" (aka. "MBone"), or perhaps some other multicast network.
We also assume that the *internal* network (i.e., intranet) supports IP multicast routing. This is practical, because intranets tend to be centrally administered. (Also, many corporate intranets already use multicast internally - for training, meetings, or corporate announcements.) In contrast, some previously proposed firewall mechanisms for multicast (e.g., ) have worked by sending *unicast* packets within the intranet. Such mechanisms are usually inappropriate, because they scale poorly and can cause excessive network traffic within the intranet. Instead, it is better to rely
Finlayson Informational [Page 1]
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 , 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. ...