Browse Prior Art Database

IP Multicast and Firewalls (RFC2588)

IP.com Disclosure Number: IPCOM000003175D
Original Publication Date: 1999-May-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 12 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Finlayson: AUTHOR

Related Documents

10.17487/RFC2588: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 12% of the total text.

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 Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Abstract

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.

2. Introduction

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 [1] 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., [2]) 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 [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. ...

Processing...
Loading...