IP Multicast and Firewalls
RFC 2588
|
| Document |
Type |
|
RFC - Informational
(May 1999; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 2588 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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.
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 [Page 2]
Show full document text