rfc2588.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页

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]

RFC 2588               IP Multicast and Firewalls               May 1999


   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.

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




Finlayson                    Informational                      [Page 3]

RFC 2588               IP Multicast and Firewalls               May 1999


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

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



Finlayson                    Informational                      [Page 4]

RFC 2588               IP Multicast and Firewalls               May 1999


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

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



Finlayson                    Informational                      [Page 5]

RFC 2588               IP Multicast and Firewalls               May 1999


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

   In some circumstances, however, the client cannot avoid contacting
   the firewall prior to joining a multicast session.  In this case, it
   may make sense for this contact to also act as a 'notification'
   operation.  Consider, for example, an RTSP [8] proxy associated with
   the firewall.  When the proxy receives a request - from an internal
   user - to open a remote RTSP session, the proxy might examine the
   response from the remote site, to check whether a multicast session
   is being launched, and if so, check whether the multicast group(s)
   are candidates to be relayed.










Finlayson                    Informational                      [Page 6]