--- 1/draft-ietf-mboned-mcast-firewall-01.txt 2006-02-05 00:20:11.000000000 +0100 +++ 2/draft-ietf-mboned-mcast-firewall-02.txt 2006-02-05 00:20:11.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group Ross Finlayson Internet-Draft LIVE.COM -Expire in six months 1998.08.04 +Expire in six months 1998.11.18 Category: Informational IP Multicast and Firewalls - + 1. 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 @@ -36,22 +36,22 @@ 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. 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. +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 upon the existing IP multicast routing/delivery mechanism, @@ -369,67 +369,82 @@ 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 4 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. Summary +12. 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 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. + +13. 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. -12. References +14. References [1] 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" +[5] Handley, M., Jacobson, V., + "SDP: Session Description Protocol", + RFC 2327, April, 1998. [6] Meyer, D., "Administratively Scoped IP Multicast", - Work-in-Progress, - Internet-Draft "draft-ietf-mboned-admin-ip-space-06.txt", June, 1998. + 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-00.txt, November, 1997. + Internet-Draft draft-ietf-idmr-membership-reports-01.txt, August, 1998. [8] Schulzrinne, H., Rao, A., Lanphier, R. "Real Time Streaming Protocol (RTSP)", - Work-in-Progress, - Internet-Draft draft-ietf-mmusic-rtsp-09.{txt,ps}, February, 1998. + RFC 2326, April, 1998. [9] Finlayson, R., "The UDP Multicast Tunneling Protocol", - Work-in-Progress, Internet-Draft "draft-finlayson-umtp-02.txt", - February, 1998. + 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. -13. Author's Address +15. Author's Address Ross Finlayson, Live Networks, Inc. (LIVE.COM) email: finlayson@live.com WWW: http://www.live.com/