draft-ietf-mboned-mcast-firewall-02.txt   rfc2588.txt 
Network Working Group Ross Finlayson Network Working Group R. Finlayson
Internet-Draft LIVE.COM Request for Comments: 2588 LIVE.COM
Expire in six months 1998.11.18 Category: Informational May 1999
Category: Informational
IP Multicast and Firewalls IP Multicast and Firewalls
<draft-ietf-mboned-mcast-firewall-02.txt> Status of this Memo
1. 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.
This document is an Internet-Draft. Internet-Drafts are working Copyright Notice
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 Copyright (C) The Internet Society (1999). All Rights Reserved.
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 1. Abstract
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), ftp.ietf.org (US East Coast ), or
ftp.isi.edu (US West Coast).
2. 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.
Many organizations use a firewall computer that acts as a security gateway 2. Introduction
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.
3. 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.
A firewall is a security gateway that controls access between a private We assume that the external side of the firewall (on the Internet)
adminstrative domain (an 'intranet') and the public Internet. This has access to IP multicast - i.e., is on the public "Multicast
document discusses how a firewall handles IP multicast [1] traffic. Internet" (aka. "MBone"), or perhaps some other multicast network.
We assume that the external side of the firewall (on the Internet) has We also assume that the *internal* network (i.e., intranet) supports
access to IP multicast - i.e., is on the public "Multicast Internet" IP multicast routing. This is practical, because intranets tend to
(aka. "MBone"), or perhaps some other multicast network. 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.
We also assume that the *internal* network (i.e., intranet) supports IP This document addresses scenarios where a multicast session is
multicast routing. This is practical, because intranets tend to be carried - via multicast - on both sides of the firewall. For
centrally administered. (Also, many corporate intranets already use instance, (i) a particular public MBone session may be relayed onto
multicast internally - for training, meetings, or corporate announcements.) the intranet (e.g., for the benefit of employees), or (ii) a special
In contrast, some previously proposed firewall mechanisms for multicast internal communication (e.g., announcing a new product) may be
(e.g., [2]) have worked by sending *unicast* packets within the intranet. relayed onto the public MBone. In contrast, we do not address the
Such mechanisms are usually inappropriate, because they scale poorly and case of a roaming user - outside the firewall - who wishes to access
can cause excessive network traffic within the intranet. Instead, it is a private internal multicast session, using a virtual private
better to rely upon the existing IP multicast routing/delivery mechanism, network. (Such "road warrior" scenarios are outside the scope of
rather than trying to replace it with unicast. this document.)
This document addresses scenarios where a multicast session is carried - As noted by Freed and Carosso [3], a firewall can act in two
via multicast - on both sides of the firewall. For instance, (i) a different ways:
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
1/ As a "protocol end point". In this case, no internal node (other (other than the firewall) is directly accessible from the
than the firewall) is directly accessible from the external Internet, and no external Internet, and no external node (other than the
external node (other than the firewall) is directly accessible from within firewall) is directly accessible from within the intranet.
the intranet. Such firewalls are also known as "application-level gateways". Such firewalls are also known as "application-level gateways".
2/ As a "packet filter". In this case, internal and external nodes are 2/ As a "packet filter". In this case, internal and external
visible to each other at the IP level, but the firewall filters out (i.e., nodes are visible to each other at the IP level, but the
blocks passage of) certain packets, based on their header or contents. 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 In the remainder of this document, we assume the first type of
it is the most restrictive, and generally provides the most security. For firewall, as it is the most restrictive, and generally provides the
multicast, this means that: 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.)
4. Why Multicast is Different (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.)
When considering the security implications of IP multicast, it is important 3. Why Multicast is Different
to note the fundamental way in which multicast communication differs from
unicast.
Unicast communication consists of a 'conversation' between an explicit pair When considering the security implications of IP multicast, it is
of participants. It therefore makes sense for the security of unicast important to note the fundamental way in which multicast
communication to be based upon these participants (e.g., by authenticating communication differs from unicast.
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, Unicast communication consists of a 'conversation' between an
potentially varying set of participants, whose membership might never be explicit pair of participants. It therefore makes sense for the
fully known. (This is a feature, not a bug!) Because of this, the security of unicast communication to be based upon these participants
security of multicast communication is based not upon its participants, but (e.g., by authenticating each participant). Furthermore, 'trust'
instead, upon its *data*. In particular, multicast communication is within unicast communication can be based upon trust in each
authenticated by authenticating packet data - e.g., using digital participant, as well as upon trust in the data.
signatures - and privacy is obtained by encrypting this data. And 'trust'
within multicast communication is based solely upon trust in the data.
5. Multicast-Related Threats and Countermeasures 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.
The primary threat arising from relaying multicast across a firewall is 4. Multicast-Related Threats and Countermeasures
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, The primary threat arising from relaying multicast across a firewall
in advance, a security policy that decides: is therefore "bad data" - in particular:
(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 (i) damaging data flowing from the Internet onto the intranet, or
firewall to implement this policy. (ii) sensitive data inadvertently flowing from the intranet onto
the external Internet.
6. What Firewalls Need to Do To avert this threat, the intranet's security administrator must
establish, in advance, a security policy that decides:
In short, a firewall must do three things in order to handle multicast: (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.)
1/ Support the chosen multicast security policy (which establishes Once such a security policy has been established, it is then the job
particular multicast groups as being candidates to be relayed), of the firewall to implement this policy.
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. 5. What Firewalls Need to Do
Note that because a firewall is often a convenient place to centralize the In short, a firewall must do three things in order to handle
administration of the intranet, some firewalls might also perform multicast:
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.
7. Supporting a Multicast Security Policy 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).
As noted above, a multicast security policy consists of specifying the set These three tasks are described in more detail in the next three
of allowed multicast groups (& corresponding UDP ports) that are candidates sections.
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: Note that because a firewall is often a convenient place to
(i) Certain ranges of multicast addresses are defined to be centralize the administration of the intranet, some firewalls might
"administratively scoped" [6]. Even though the firewall does not act as a also perform additional administrative functions - for example,
true multicast router, the multicast security policy should set up and auditing, accounting, and resource monitoring. These additional
respect administrative scope boundaries. functions, however, are outside the scope of this document, because
(ii) As noted in [2], certain privileged UDP ports may be considered they are not specifically *firewall*-related. They are equally
dangerous, even with multicast. The multicast security policy should check applicable to an administrative domain that is not firewalled.
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).
8. Determining When to Relay Candidate Groups 6. Supporting a Multicast Security Policy
If a multicast group becomes a candidate to be relayed across the firewall, As noted above, a multicast security policy consists of specifying
the actual relaying should *not* be done continually, but instead should be the set of allowed multicast groups (& corresponding UDP ports) that
done only when there is actual interest in having this group relayed. The are candidates to be relayed across the firewall. There are three
reason for this is two-fold. First, relaying a multicast group requires basic ways in which a firewall can support such a policy:
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 1/ Static configuration. The firewall could be configured, in
relayed is for it to use actual multicast routing information, thereby advance, with the set of candidate groups/ports - for example,
acting much as if it were a real 'inter-domain' multicast router. If the in a configuration file.
intranet consists of a single subnet only, then the firewall could listen 2/ Explicit dynamic configuration. The set of candidate
to IGMP requests to learn when a candidate group has been joined by a node groups/ports could be set (and updated) dynamically, based upon
on this subnet. If, however, the intranet consists of more than one an explicit request from one or more trusted clients
subnet, then the firewall can learn about candidate group memberships by (presumably internal). For example, the firewall could contain
listening to "Domain Wide Multicast Group Membership Reports" [7]. a 'remote control' mechanism that allows these trusted clients
Unfortunately, this mechanism has only recently been defined, and is not - upon authentication - to update the set of candidate
yet used by most routers. 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.
Another, albeit less desirable, way for the firewall to learn when Notes:
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 (i) Certain ranges of multicast addresses are defined to be
notify the firewall whenever it joins, or leaves, a multicast group. This "administratively scoped" [6]. Even though the firewall
requires changes to the node's operating system or libraries, or does not act as a true multicast router, the multicast
cooperation from the application. Therefore this technique, like the security policy should set up and respect administrative
previous one, is applicable only within the intranet, not the external scope boundaries.
Internet. Note that if multicast applications are always launched from a (ii) As noted in [2], certain privileged UDP ports may be
special "session directory" or "channel guide" application, then this considered dangerous, even with multicast. The multicast
application may be the only one that need be aware of having to contact the security policy should check that such ports do not become
firewall. 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).
What makes the latter two approaches ("probing" and "explicit 7. Determining When to Relay Candidate Groups
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".
In some circumstances, however, the client cannot avoid contacting the If a multicast group becomes a candidate to be relayed across the
firewall prior to joining a multicast session. In this case, it may make firewall, the actual relaying should *not* be done continually, but
sense for this contact to also act as a 'notification' operation. instead should be done only when there is actual interest in having
Consider, for example, an RTSP [8] proxy associated with the firewall. this group relayed. The reason for this is two-fold. First,
When the proxy receives a request - from an internal user - to open a relaying a multicast group requires that one or both sides of the
remote RTSP session, the proxy might examine the response from the remote firewall join the group; this establishes multicast routing state
site, to check whether a multicast session is being launched, and if so, within the network. This is inefficient if there is no current
check whether the multicast group(s) are candidates to be relayed. 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.
9. Relaying Candidate Groups 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.
The actual mechanism that's used to relay multicast packets will depend Another, albeit less desirable, way for the firewall to learn when
upon the nature of the firewall. One common firewall configuration is to candidate multicast groups have been joined is for the firewall to
use two nodes: one part of the intranet; the other part of the external periodically 'probe' each of these groups. Such a probe can be
Internet. In this case, multicast packets would be relayed between these performed by sending an ICMP ECHO request packet to the group, and
two nodes (and then re-multicast on the other side) using a tunneling listening for a response (with some timeout interval). This probing
protocol. 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.
A tunneling protocol for multicast should *not* run on top of TCP, because Another possibility - less desirable still - is for each node to
the reliability and ordering guarantees that TCP provides are unnecessary explicitly notify the firewall whenever it joins, or leaves, a
for multicast communication (where any reliability is provided at a higher multicast group. This requires changes to the node's operating
level), yet would add latency. Instead, a UDP-based tunneling protocol is system or libraries, or cooperation from the application. Therefore
a better fit for relaying multicast packets. (If congestion avoidance is a this technique, like the previous one, is applicable only within the
concern, then the tunnel traffic could be rate-limited, perhaps on a intranet, not the external Internet. Note that if multicast
per-group basis.) 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.
One possible tunneling protocol is the "UDP Multicast Tunneling Protocol" What makes the latter two approaches ("probing" and "explicit
(UMTP) [9]. Although this protocol was originally designed as a mechanism notification") undesirable is that they duplicate some of the
for connecting individual client machines to the MBone, it is also a existing functionality of multicast routing, and in a way that scales
natural fit for for use across firewalls. UMTP uses only a single UDP poorly for large networks. Therefore, if possible, firewalls should
port, in each direction, for its tunneleling, so an existing firewall can attempt to make use of existing multicast routing information: either
easily be configured to support multicast relaying, by adding a UMTP IGMP (for a single-subnet intranet), or "Domain Wide Multicast Group
implementation at each end, and enabling the UDP port for tunneling. Membership Reports".
Notes: In some circumstances, however, the client cannot avoid contacting
(i) When multicast packets are relayed from the intranet onto the the firewall prior to joining a multicast session. In this case, it
external Internet, they should be given the same TTL that they had when may make sense for this contact to also act as a 'notification'
they arrived on the firewall's internal interface (except decremented by 1). operation. Consider, for example, an RTSP [8] proxy associated with
Therefore, the internal end of the multicast relay mechanism needs to be the firewall. When the proxy receives a request - from an internal
able to read the TTL of incoming packets. (This may require special user - to open a remote RTSP session, the proxy might examine the
privileges.) In contrast, the TTL of packets being relayed in the other response from the remote site, to check whether a multicast session
direction - from the external Internet onto the intranet - is usually less is being launched, and if so, check whether the multicast group(s)
important; some default value (sufficient to reach the whole intranet) will are candidates to be relayed.
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).
10. Networks With More Than One Firewall 8. Relaying Candidate Groups
So far we have assumed that there is only one firewall between the intranet The actual mechanism that's used to relay multicast packets will
and the external Internet. If, however, the intranet has more than one depend upon the nature of the firewall. One common firewall
firewall, then it's important that no single multicast group be relayed by configuration is to use two nodes: one part of the intranet; the
more than one firewall. Otherwise (because firewalls are assumed to be other part of the external Internet. In this case, multicast packets
application-level gateways - not proper multicast routers), packets sent to would be relayed between these two nodes (and then re-multicast on
any such group would become replicated on the other side of the firewalls. the other side) using a tunneling protocol.
The set of candidate groups must therefore be partitioned among the
firewalls (so that exactly one firewall has responsibility for relaying
each candidate group). Clearly, this will require coordination between the
administrators of the respective firewalls.
As a general rule, candidate groups should be assigned - if possible - to A tunneling protocol for multicast should *not* run on top of TCP,
the firewall that is topologically closest to most of the group members (on because the reliability and ordering guarantees that TCP provides are
both the intranet and the external Internet). For example, if a company's unnecessary for multicast communication (where any reliability is
intranet spans the Atlantic, with firewalls in New York and London, then provided at a higher level), yet would add latency. Instead, a UDP-
groups with mostly North American members should be assigned to the New based tunneling protocol is a better fit for relaying multicast
York firewall, and groups with mostly European members should be assigned packets. (If congestion avoidance is a concern, then the tunnel
to the London firewall. (Unfortunately, even if a group has many internal traffic could be rate-limited, perhaps on a per-group basis.)
and external members on both sides of the Atlantic, only one firewall will
be allowed to relay it. Some inefficiencies in the data delivery tree are
unavoidable in this case.)
11. Why SOCKS is Less Appropriate for Multicast One possible tunneling protocol is the "UDP Multicast Tunneling
Protocol" (UMTP) [9]. 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.
SOCKS [10] is a mechanism for transparently performing unicast communication Notes:
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 (i) When multicast packets are relayed from the intranet onto the
conversation between a pair of nodes, the SOCKS model is less appropriate. external Internet, they should be given the same TTL that
Although multicast communication across a firewall is implemented as two they had when they arrived on the firewall's internal
separate multicast communications (one inside the firewall; the other interface (except decremented by 1). Therefore, the internal
outside), the *same* multicast address(es) and port(s) are used on both end of the multicast relay mechanism needs to be able to read
sides of the firewall. Thus, multicast applications running inside the the TTL of incoming packets. (This may require special
firewall see the same environment as those running outside, so there is no privileges.) In contrast, the TTL of packets being relayed
need for them to use a special library. 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).
Nonetheless, there has been a proposal [11] to extend SOCKS V5 to support 9. Networks With More Than One Firewall
multicast.
This proposal includes two possible modes of communication:
(i) "MU-mode", uses only *unicast* communication within the
intranet (between the firewall and each internal group member), and
(ii) "MM-mode", which uses unicast for client-to-firewall relay
control, but uses *multicast* for other 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 So far we have assumed that there is only one firewall between the
environments where a firewall can learn about group membership only via intranet and the external Internet. If, however, the intranet has
"explicit notification". In this case each node might use SOCKS to notify more than one firewall, then it's important that no single multicast
the firewall whenever it joins and leaves a group. However, as we group be relayed by more than one firewall. Otherwise (because
explained above, this should only be considered as a last resort - a far firewalls are assumed to be application-level gateways - not proper
better solution is to leverage off the existing multicast routing mechanism. multicast routers), packets sent to any such group would become
replicated on the other side of the firewalls. The set of candidate
groups must therefore be partitioned among the firewalls (so that
exactly one firewall has responsibility for relaying each candidate
group). Clearly, this will require coordination between the
administrators of the respective firewalls.
It has been suggested [11] that a benefit of using multicast SOCKS (or an As a general rule, candidate groups should be assigned - if possible
"explicit notification" scheme in general) is that it allows the firewall - to the firewall that is topologically closest to most of the group
to authenticate a client's multicast "join" and "leave" operations. This, members (on both the intranet and the external Internet). For
however, does not provide any security, because it does not prevent other example, if a company's intranet spans the Atlantic, with firewalls
clients within the intranet from joining the multicast session (and in New York and London, then groups with mostly North American
receiving packets), nor from sending packets to the multicast session. As members should be assigned to the New York firewall, and groups with
we noted in section 4 above, authentication and privacy in multicast mostly European members should be assigned to the London firewall.
sessions is usually obtained by signing and encrypting the multicast data, (Unfortunately, even if a group has many internal and external
not by attempting to impose low-level restrictions on group membership. We members on both sides of the Atlantic, only one firewall will be
note also that even if group membership inside the intranet could be allowed to relay it. Some inefficiencies in the data delivery tree
restricted, it would not be possible, in general, to impose any such are unavoidable in this case.)
membership restrictions on the external Internet.
12. Security Considerations 10. Why SOCKS is Less Appropriate for Multicast
Once a security policy has been established, the techniques described in SOCKS [10] is a mechanism for transparently performing unicast
this document can be used to implement this policy. No security mechanism, communication across a firewall. A special client library -
however, can overcome a badly designed security policy. Specifically, simulating the regular 'sockets' library - sits between applications
network administrators must be confident that the multicast groups/ports and the transport level. A conversation between a pair of nodes is
that they designate as being 'safe' really are free from harmful data. implemented (transparently) as a pair of conversations: one between
In particular, administrators must be familiar with the applications that the first node and a firewall; the other between the firewall and the
will receive and process multicast data, and (as with unicast applications) second node.
be confident that they cannot cause harm (e.g., by executing unsafe code
received over the network).
Because it is possible for an adversary to initiate a "denial of service" In contrast, because multicast communication does not involve a
attack by flooding an otherwise-legitimate multicast group with garbage, conversation between a pair of nodes, the SOCKS model is less
administrators may also wish to guard against this by placing bandwidth appropriate. Although multicast communication across a firewall is
limits on cross-firewall relaying. 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.
13. Summary Nonetheless, there has been a proposal [11] to extend SOCKS V5 to
support multicast. This proposal includes two possible modes of
communication:
Bringing IP multicast across a firewall requires that the intranet first (i) "MU-mode", uses only *unicast* communication within the
establish a multicast security policy that defines which multicast groups intranet (between the firewall and each internal group
(& corresponding UDP ports) are candidates to be relayed across the member), and
firewall. The firewall implements this policy by dynamically determining (ii) "MM-mode", which uses unicast for client-to-firewall relay
when each candidate group/port needs to be relayed, and then by doing the control, but uses *multicast* for other communication within
actual relaying. This document has outlined how a firewall can perform the intranet.
these tasks.
14. References As noted in section 2 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.
[1] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, On the other hand, "MM-mode" (or some variant thereof) *might* be
August 1989. useful in environments where a firewall can learn about group
[2] Djahandari, K., Sterne, D. F., membership only via "explicit notification". In this case each node
"An MBone Proxy for an Application Gateway Firewall" might use SOCKS to notify the firewall whenever it joins and leaves a
IEEE Symposium on Security and Privacy, 1997. group. However, as we explained above, this should only be
[3] Freed, N., Carosso, K., considered as a last resort - a far better solution is to leverage
"An Internet Firewall Transparency Requirement", off the existing multicast routing mechanism.
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., Jacobson, V.,
"SDP: Session Description Protocol",
RFC 2327, April, 1998.
[6] Meyer, D.,
"Administratively Scoped IP Multicast",
RFC 2365 (BCP 23), July, 1998.
[7] Fenner, B.,
"Domain Wide Multicast Group Membership Reports",
Work-in-Progress,
Internet-Draft draft-ietf-idmr-membership-reports-01.txt, August, 1998.
[8] Schulzrinne, H., Rao, A., Lanphier, R.
"Real Time Streaming Protocol (RTSP)",
RFC 2326, April, 1998.
[9] Finlayson, R.,
"The UDP Multicast Tunneling Protocol",
Work-in-Progress, Internet-Draft "draft-finlayson-umtp-03.txt",
September, 1998.
[10] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Joned, L.,
"SOCKS Protocol Version 5",
RFC 1928, April, 1996.
[11] Chouinard, D.,
"SOCKS V5 UDP and Multicast Extensions",
Work-in-Progress,
Internet-Draft "draft-chouinard-aft-socksv5-mult-00.txt", July, 1997.
15. Author's Address It has been suggested [11] that a benefit of using multicast SOCKS
(or an "explicit notification" scheme in general) is that it allows
the firewall to authenticate a client's multicast "join" and "leave"
operations. This, however, does not provide any security, because it
does not prevent other clients within the intranet from joining the
multicast session (and receiving packets), nor from sending packets
to the multicast session. As we noted in section 3 above,
authentication and privacy in multicast sessions is usually obtained
by signing and encrypting the multicast data, not by attempting to
impose low-level restrictions on group membership. We note also that
even if group membership inside the intranet could be restricted, it
would not be possible, in general, to impose any such membership
restrictions on the external Internet.
Ross Finlayson, 11. Security Considerations
Live Networks, Inc. (LIVE.COM)
email: finlayson@live.com Once a security policy has been established, the techniques described
WWW: http://www.live.com/ in this document can be used to implement this policy. No security
mechanism, however, can overcome a badly designed security policy.
Specifically, network administrators must be confident that the
multicast groups/ports that they designate as being 'safe' really are
free from harmful data. In particular, administrators must be
familiar with the applications that will receive and process
multicast data, and (as with unicast applications) be confident that
they cannot cause harm (e.g., by executing unsafe code received over
the network).
Because it is possible for an adversary to initiate a "denial of
service" attack by flooding an otherwise-legitimate multicast group
with garbage, administrators may also wish to guard against this by
placing bandwidth limits on cross-firewall relaying.
12. 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.
13. References
[1] Deering, S., "Host Extensions for IP Multicasting", STD 5, 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. and K. Carosso, "An Internet Firewall Transparency
Requirement", Work in Progress.
[4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365 July 1998.
[7] Fenner, B., "Domain Wide Multicast Group Membership Reports",
Work in Progress.
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[9] Finlayson, R., "The UDP Multicast Tunneling Protocol", Work in
Progress.
[10] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L.
Joned, SOCKS Protocol Version 5", RFC 1928, April 1996.
[11] Chouinard, D., "SOCKS V5 UDP and Multicast Extensions", Work in
Progress.
14. Author's Address
Ross Finlayson,
Live Networks, Inc. (LIVE.COM)
EMail: finlayson@live.com
WWW: http://www.live.com/
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 61 change blocks. 
383 lines changed or deleted 353 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/