rfc2588.txt

<VC++网络游戏建摸与实现>源代码


RFC 2588               IP Multicast and Firewalls               May 1999


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

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




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


9. Networks With More Than One Firewall

   So far we have assumed that there is only one firewall between the
   intranet and the external Internet.  If, however, the intranet has
   more than one firewall, then it's important that no single multicast
   group be relayed by more than one firewall.  Otherwise (because
   firewalls are assumed to be application-level gateways - not proper
   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.

   As a general rule, candidate groups should be assigned - if possible
   - to the firewall that is topologically closest to most of the group
   members (on both the intranet and the external Internet).  For
   example, if a company's intranet spans the Atlantic, with firewalls
   in New York and London, then groups with mostly North American
   members should be assigned to the New York firewall, and groups with
   mostly European members should be assigned to the London firewall.
   (Unfortunately, even if a group has many internal 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.)

10. Why SOCKS is Less Appropriate for Multicast

   SOCKS [10] 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.






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


   Nonetheless, there has been a proposal [11] to extend SOCKS V5 to
   support 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 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.

   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.

   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.

11. Security Considerations

   Once a security policy has been established, the techniques described
   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



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


   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.




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


   [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: [e-mail]
   WWW: http://www.live.com/



































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


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.



















Finlayson                    Informational                     [Page 12]