draft-ietf-mboned-mcast-firewall-01.txt   draft-ietf-mboned-mcast-firewall-02.txt 
Network Working Group Ross Finlayson Network Working Group Ross Finlayson
Internet-Draft LIVE.COM Internet-Draft LIVE.COM
Expire in six months 1998.08.04 Expire in six months 1998.11.18
Category: Informational Category: Informational
IP Multicast and Firewalls IP Multicast and Firewalls
<draft-ietf-mboned-mcast-firewall-01.txt> <draft-ietf-mboned-mcast-firewall-02.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 46 skipping to change at line 46
some firewall mechanisms - such as SOCKS - that were designed specifically some firewall mechanisms - such as SOCKS - that were designed specifically
for unicast traffic, are less appropriate for multicast. for unicast traffic, are less appropriate for multicast.
3. Introduction 3. Introduction
A firewall is a security gateway that controls access between a private A firewall is a security gateway that controls access between a private
adminstrative domain (an 'intranet') and the public Internet. This adminstrative domain (an 'intranet') and the public Internet. This
document discusses how a firewall handles IP multicast [1] traffic. document discusses how a firewall handles IP multicast [1] traffic.
We assume that the external side of the firewall (on the Internet) has 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 access to IP multicast - i.e., is on the public "Multicast Internet"
other multicast network. (aka. "MBone"), or perhaps some other multicast network.
We also assume that the *internal* network (i.e., intranet) supports IP We also assume that the *internal* network (i.e., intranet) supports IP
multicast routing. This is practical, because intranets tend to be multicast routing. This is practical, because intranets tend to be
centrally administered. (Also, many corporate intranets already use centrally administered. (Also, many corporate intranets already use
multicast internally - for training, meetings, or corporate announcements.) multicast internally - for training, meetings, or corporate announcements.)
In contrast, some previously proposed firewall mechanisms for multicast In contrast, some previously proposed firewall mechanisms for multicast
(e.g., [2]) have worked by sending *unicast* packets within the intranet. (e.g., [2]) have worked by sending *unicast* packets within the intranet.
Such mechanisms are usually inappropriate, because they scale poorly and Such mechanisms are usually inappropriate, because they scale poorly and
can cause excessive network traffic within the intranet. Instead, it is can cause excessive network traffic within the intranet. Instead, it is
better to rely upon the existing IP multicast routing/delivery mechanism, better to rely upon the existing IP multicast routing/delivery mechanism,
skipping to change at line 379 skipping to change at line 379
however, does not provide any security, because it does not prevent other however, does not provide any security, because it does not prevent other
clients within the intranet from joining the multicast session (and clients within the intranet from joining the multicast session (and
receiving packets), nor from sending packets to the multicast session. As receiving packets), nor from sending packets to the multicast session. As
we noted in section 4 above, authentication and privacy in multicast we noted in section 4 above, authentication and privacy in multicast
sessions is usually obtained by signing and encrypting the multicast data, sessions is usually obtained by signing and encrypting the multicast data,
not by attempting to impose low-level restrictions on group membership. We not by attempting to impose low-level restrictions on group membership. We
note also that even if group membership inside the intranet could be note also that even if group membership inside the intranet could be
restricted, it would not be possible, in general, to impose any such restricted, it would not be possible, in general, to impose any such
membership restrictions on the external Internet. 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 Bringing IP multicast across a firewall requires that the intranet first
establish a multicast security policy that defines which multicast groups establish a multicast security policy that defines which multicast groups
(& corresponding UDP ports) are candidates to be relayed across the (& corresponding UDP ports) are candidates to be relayed across the
firewall. The firewall implements this policy by dynamically determining firewall. The firewall implements this policy by dynamically determining
when each candidate group/port needs to be relayed, and then by doing the 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 actual relaying. This document has outlined how a firewall can perform
these tasks. these tasks.
12. References 14. References
[1] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, [1] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989. August 1989.
[2] Djahandari, K., Sterne, D. F., [2] Djahandari, K., Sterne, D. F.,
"An MBone Proxy for an Application Gateway Firewall" "An MBone Proxy for an Application Gateway Firewall"
IEEE Symposium on Security and Privacy, 1997. IEEE Symposium on Security and Privacy, 1997.
[3] Freed, N., Carosso, K., [3] Freed, N., Carosso, K.,
"An Internet Firewall Transparency Requirement", "An Internet Firewall Transparency Requirement",
Work-in-Progress, Internet-Draft "draft-freed-firewall-req-02.txt", Work-in-Progress, Internet-Draft "draft-freed-firewall-req-02.txt",
December, 1997. December, 1997.
[4] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., [4] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V.,
"RTP: A Transport Protocol for Real-Time Applications", RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
January, 1996. January, 1996.
[5] Handley, M., [5] Handley, M., Jacobson, V.,
"Session Announcement Protocol", "SDP: Session Description Protocol",
Work-in-Progress, Internet-Draft "draft-ietf-mmusic-sap-00.txt,.ps" RFC 2327, April, 1998.
[6] Meyer, D., [6] Meyer, D.,
"Administratively Scoped IP Multicast", "Administratively Scoped IP Multicast",
Work-in-Progress, RFC 2365 (BCP 23), July, 1998.
Internet-Draft "draft-ietf-mboned-admin-ip-space-06.txt", June, 1998.
[7] Fenner, B., [7] Fenner, B.,
"Domain Wide Multicast Group Membership Reports", "Domain Wide Multicast Group Membership Reports",
Work-in-Progress, 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. [8] Schulzrinne, H., Rao, A., Lanphier, R.
"Real Time Streaming Protocol (RTSP)", "Real Time Streaming Protocol (RTSP)",
Work-in-Progress, RFC 2326, April, 1998.
Internet-Draft draft-ietf-mmusic-rtsp-09.{txt,ps}, February, 1998.
[9] Finlayson, R., [9] Finlayson, R.,
"The UDP Multicast Tunneling Protocol", "The UDP Multicast Tunneling Protocol",
Work-in-Progress, Internet-Draft "draft-finlayson-umtp-02.txt", Work-in-Progress, Internet-Draft "draft-finlayson-umtp-03.txt",
February, 1998. September, 1998.
[10] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Joned, L., [10] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Joned, L.,
"SOCKS Protocol Version 5", "SOCKS Protocol Version 5",
RFC 1928, April, 1996. RFC 1928, April, 1996.
[11] Chouinard, D., [11] Chouinard, D.,
"SOCKS V5 UDP and Multicast Extensions", "SOCKS V5 UDP and Multicast Extensions",
Work-in-Progress, Work-in-Progress,
Internet-Draft "draft-chouinard-aft-socksv5-mult-00.txt", July, 1997. Internet-Draft "draft-chouinard-aft-socksv5-mult-00.txt", July, 1997.
13. Author's Address 15. Author's Address
Ross Finlayson, Ross Finlayson,
Live Networks, Inc. (LIVE.COM) Live Networks, Inc. (LIVE.COM)
email: finlayson@live.com email: finlayson@live.com
WWW: http://www.live.com/ WWW: http://www.live.com/
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/