draft-finlayson-mcast-firewall

Last Version:	draft-finlayson-mcast-firewall-00.txt		Tracker Entry
Date:	09-Apr-2002
Disposition:	expired

HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:54:06 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 27 Apr 1998 14:30:00 GMT
ETag: "2e9963-4dd3-35449668"
Accept-Ranges: bytes
Content-Length: 19923
Connection: close
Content-Type: text/plain


Network Working Group                                   Ross Finlayson
Internet-Draft                                          Live Networks
Expire in six months                                    1998/03/05
Category: Informational

                       IP Multicast and Firewalls

                   <draft-finlayson-mcast-firewall-00.txt>

. Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or
   ftp.isi.edu (US West Coast).

. 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.

. 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 "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 upon the existing IP multicast routing/delivery mechanism,
rather than trying to replace it with unicast.

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.)

. 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.

Unicast communication consists of a 'conversation' between an explicit pair
of participants.  It therefore makes sense for the security of unicast
communication to be based upon these participants (e.g., by authenticating
each participant).  Furthermore, 'trust' within unicast communication can
be based upon trust in each participant, as well as upon trust in the data.

Multicast communication, on the other hand, involves a arbitrary sized,
potentially varying set of participants, whose membership might never be
fully known.  (This is a feature, not a bug!)  Because of this, the
security of multicast communication is based not upon its participants, but
instead, upon its *data*.  In particular, multicast communication is
authenticated by authenticating packet data - e.g., using digital
signatures - and privacy is obtained by encrypting this data.  And 'trust'
within multicast communication is based solely upon trust in the data.

. Multicast-Related Threats and Countermeasures

The primary threat arising from relaying multicast across a firewall is
therefore "bad data" - in particular:
	(i) damaging data flowing from the Internet onto the intranet, or
	(ii) sensitive data inadvertently flowing from the intranet onto the
             external Internet.

To avert this threat, the intranet's security administrator must establish,
in advance, a security policy that decides:
	(i) Which multicast groups (and corresponding UDP ports) contain data
that can safely be relayed from the Internet onto the intranet.  For example,
the security administrator might choose to permit the relaying of an MBone
lecture, knowing that the data consists only of audio/video (& to safe ports).
	(ii) Which multicast groups (and corresponding UDP ports) will not
contain sensitive internal information (that should therefore not be relayed
from the intranet onto the Internet).  This, of course, requires placing
trust in the applications that internal users will use to participate in
these groups.  For example, if users use an audio/video 'viewer' program to
participate in an MBone session, then this program must be trusted not to
be a "Trojan Horse".  (This requirement for "trusted applications" is by no
means specific to multicast, of course.)

Once such a security policy has been established, it is then the job of the
firewall to implement this policy.

. What Firewalls Need to Do

In short, a firewall must do three things in order to handle multicast:

1/ Support the chosen multicast security policy (which establishes
   particular multicast groups as being candidates to be relayed),
2/ Determine (dynamically) when each candidate group should be relayed, and 
3/ Relay each candidate group's data across the firewall (and then
   re-multicast it at the far end).

These three tasks are described in more detail in the next three sections.

Note that because a firewall is often a convenient place to centralize the
administration of the intranet, some firewalls might also perform
additional administrative functions - for example, auditing, accounting,
and resource monitoring.  These additional functions, however, are outside
the scope of this document, because they are not specifically
*firewall*-related.  They are equally applicable to an administrative
domain that is not firewalled.

. Supporting a Multicast Security Policy

As noted above, a multicast security policy consists of specifying the set
of allowed multicast groups (& corresponding UDP ports) that are candidates
to be relayed across the firewall.  There are three basic ways in which a
firewall can support such a policy:
	1/ Static configuration.  The firewall could be configured, in advance,
with the set of candidate groups/ports - for example, in a configuration file.
	2/ Explicit dynamic configuration.  The set of candidate groups/ports
could be set (and updated) dynamically, based upon an explicit request from
one or more trusted clients (presumably internal).  For example, the
firewall could contain a 'remote control' mechanism that allows these
trusted clients - upon authentication - to update the set of candidate
groups/ports.
	3/ Implicit dynamic configuration.  The set of candidate groups/ports
could be determined implicitly, based upon the contents of some
pre-authorized multicast group/port, such as a "session directory".
Suppose, for example, that the security policy decides that the default
MBone SAP/SDP session directory [5] may be relayed, as well as any sessions
that are announced in this directory.  A 'watcher' process, associated with
the firewall, would watch this directory, and use its contents to
dynamically update the set of candidates.

Notes:
	(i) Certain ranges of multicast addresses are defined to be
"administratively scoped" [6].  Even though the firewall does not act as a
true multicast router, the multicast security policy should set up and
respect administrative scope boundaries.
	(ii) As noted in [2], certain privileged UDP ports may be considered
dangerous, even with multicast.  The multicast security policy should check
that such ports do not become candidates for relaying.
	(iii) Even if sessions announced in a session directory are considered
automatic candidates for relaying (i.e., case 3/ above), the firewall's
'watcher' process should still perform some checks on incoming
announcements.  In particular, it should ensure that each session's 'group'
address really is a multicast address, and (as noted above) it should also
check that the port number is within a safe range.  Depending on the
security policy, it may also wish to prevent any *locally* created session
announcements from becoming candidates (or being relayed).

. Determining When to Relay Candidate Groups

If a multicast group becomes a candidate to be relayed across the firewall,
the actual relaying should *not* be done continually, but instead should be
done only when there is actual interest in having this group relayed.  The
reason for this is two-fold.  First, relaying a multicast group requires
that one or both sides of the firewall join the group; this establishes
multicast routing state within the network.  This is inefficient if there
is no current interest in having the group relayed (especially for
Internet->intranet relaying).  Second, the act of relaying an unwanted
multicast group consumes unnecessary resources in the firewall itself.

The best way for the firewall to determine when a candidate group should be
relayed is for it to use actual multicast routing information, thereby
acting much as if it were a real 'inter-domain' multicast router.  If the
intranet consists of a single subnet only, then the firewall could listen
to IGMP requests to learn when a candidate group has been joined by a node
on this subnet.  If, however, the intranet consists of more than one
subnet, then the firewall can learn about candidate group memberships by
listening to "Domain Wide Multicast Group Membership Reports" [7].
Unfortunately, this mechanism has only recently been defined, and is not
yet used by most routers.  

Another, albeit less desirable, way for the firewall to learn when
candidate multicast groups have been joined is for the firewall to
periodically 'probe' each of these groups.  Such a probe can be performed
by sending an ICMP ECHO request packet to the group, and listening for a
response (with some timeout interval).  This probing scheme is practical
provided that the set of candidate groups is reasonably small, but it
should be used only on the intranet, not on the external Internet.  One
significant drawback of this approach is that some operating systems - most
notably Windows 95 - do not respond to multicast ICMP ECHOs.  However, this
approach has been shown to work on a large, all-Unix network.

Another possibility - less desirable still - is for each node to explicitly
notify the firewall whenever it joins, or leaves, a multicast group.  This
requires changes to the node's operating system or libraries, or
cooperation from the application.  Therefore this technique, like the
previous one, is applicable only within the intranet, not the external
Internet.  Note that if multicast applications are always launched from a
special "session directory" or "channel guide" application, then this
application may be the only one that need be aware of having to contact the
firewall.

What makes the latter two approaches ("probing" and "explicit
notification") undesirable is that they duplicate some of the existing
functionality of multicast routing, and in a way that scales poorly for
large networks.  Therefore, if possible, firewalls should attempt to make
use of existing multicast routing information: either IGMP (for a
single-subnet intranet), or "Domain Wide Multicast Group Membership Reports".

. Relaying Candidate Groups

The actual mechanism that's used to relay multicast packets will depend
upon the nature of the firewall.  One common firewall configuration is to
use two nodes: one part of the intranet; the other part of the external
Internet.  In this case, multicast packets would be relayed between these
two nodes (and then re-multicast on the other side) using a tunneling
protocol.

A tunneling protocol for multicast should *not* run on top of TCP, because
the reliability and ordering guarantees that TCP provides are unnecessary
for multicast communication (where any reliability is provided at a higher
level), yet would add latency.  Instead, a UDP-based tunneling protocol is
a better fit for relaying multicast packets.  (If congestion avoidance is a
concern, then the tunnel traffic could be rate-limited, perhaps on a
per-group basis.)

One possible tunneling protocol is the "UDP Multicast Tunneling Protocol"
(UMTP) [8].  Although this protocol was originally designed as a mechanism
for connecting individual client machines to the MBone, it is also a
natural fit for for use across firewalls.  UMTP uses only a single UDP
port, in each direction, for its tunneleling, so an existing firewall can
easily be configured to support multicast relaying, by adding a UMTP
implementation at each end, and enabling the UDP port for tunneling.

Notes:
	(i) When multicast packets are relayed from the intranet onto the
external Internet, they should be given the same TTL that they had when
they arrived on the firewall's internal interface (except decremented by 1).
Therefore, the internal end of the multicast relay mechanism needs to be
able to read the TTL of incoming packets.  (This may require special
privileges.)  In contrast, the TTL of packets being relayed in the other
direction - from the external Internet onto the intranet - is usually less
important; some default value (sufficient to reach the whole intranet) will
usually suffice.  Thus, the Internet end of the multicast relay mechanism -
which might be less trusted than the intranet end - need not run with special
privileges. 
	(ii) One end of the multicast tunnel - usually the intranet end - will
typically act as the controller (i.e., "master") of the tunnel, with the
other end - usually the Internet end - acting as a "slave".  For security,
the "master" end of the tunnel should be configured not to accept any
commands from the "slave" (which will often be less trusted).

. Why SOCKS is Less Appropriate for Multicast

SOCKS [9] is a mechanism for transparently performing unicast communication
across a firewall.  A special client library - simulating the regular
'sockets' library - sits between applications and the transport level.  A
conversation between a pair of nodes is implemented (transparently) as a
pair of conversations: one between the first node and a firewall; the other
between the firewall and the second node.

In contrast, because multicast communication does not involve a
conversation between a pair of nodes, the SOCKS model is less appropriate.
Although multicast communication across a firewall is implemented as two
separate multicast communications (one inside the firewall; the other
outside), the *same* multicast address(es) and port(s) are used on both
sides of the firewall.  Thus, multicast applications running inside the
firewall see the same environment as those running outside, so there is no
need for them to use a special library.

Chouinard [10] has proposed extensions to SOCKS V5 that aim to support
multicast.  His proposal includes two possible modes of communication:
	(i) "MU-mode", which involves using *unicast* communication within the
           intranet (between the firewall and each internal group member), and
	(ii) "MM-mode", which involves using multicast communication within the
           intranet.
As noted in section 3 above, "MU-mode" would be a poor choice (unless, for
some reason, the intranet does not support multicast routing at all).  If
multicast routing is available, there should rarely be a compelling reason
to replace multicast with 'multiple-unicast'.  Not only does this scale
badly, but it also requires (otherwise unnecessary) changes to each
application node, because the multicast service model is different from
that of unicast.

On the other hand, "MM-mode" (or some variant thereof) *might* be useful in
environments where a firewall can learn about group membership only via
"explicit notification".  In this case each node might use SOCKS to notify
the firewall whenever it joins and leaves a group.  However, as we
explained above, this should only be considered as a last resort - a far
better solution is to leverage off the existing multicast routing mechanism.

. Summary

Bringing IP multicast across a firewall requires that the intranet first
establish a multicast security policy that defines which multicast groups
(& corresponding UDP ports) are candidates to be relayed across the
firewall.  The firewall implements this policy by dynamically determining
when each candidate group/port needs to be relayed, and then by doing the
actual relaying.  This document has outlined how a firewall can perform
these tasks.

. References

[] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
    August 1989. 
[2] Djahandari, K., Sterne, D. F.,
    "An MBone Proxy for an Application Gateway Firewall"
    IEEE Symposium on Security and Privacy, 1997.
[3] Freed, N., Carosso, K.,
    "An Internet Firewall Transparency Requirement",
    Work-in-Progress, Internet-Draft "draft-freed-firewall-req-02.txt",
    December, 1997.
[4] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V.,
    "RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
    January, 1996.
[5] Handley, M.,
    "Session Announcement Protocol",
    Work-in-Progress, Internet-Draft "draft-ietf-mmusic-sap-00.txt,.ps"
[6] Meyer, D.,
    "Administratively Scoped IP Multicast",
    Work-in-Progress,
    Internet-Draft "draft-ietf-mboned-admin-ip-space-04.txt", November, 1997.
[7] Fenner, B.,
    "Domain Wide Multicast Group Membership Reports",
    Work-in-Progress,
    Internet-Draft draft-ietf-idmr-membership-reports-00.txt, November, 1997.
[8] Finlayson, R.,
    "The UDP Multicast Tunneling Protocol",
    Work-in-Progress, Internet-Draft "draft-finlayson-umtp-02.txt",
    February, 1998.
[9] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Joned, L.,
    "SOCKS Protocol Version 5",
    RFC 1928, April, 1996.
[10] Chouinard, D.,
    "SOCKS V5 UDP and Multicast Extensions",                   
    Work-in-Progress,
    Internet-Draft "draft-chouinard-aft-socksv5-mult-00.txt", July, 1997.

. Author's Address

	Ross Finlayson,
	Live Networks, Inc.,
	email: finlayson@lvn.com
	WWW: http://www.lvn.com/