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/