Subject: New Internet-Draft: "IP Multicast and Firewalls"

From: Ross Finlayson <[email-masked]>
Date: Thu, 05 Mar 1998 02:19:57

In recent months there have been several enquiries (& also a little
confusion) about how to relay (& control the relaying of) IP multicast
across firewalls.

I have recently written a new informational Internet-Draft that will, I
hope, shed some light on this topic.  The draft should be announced within
a few days, but for now it can also be accessed on the Web at:
	<http://www.lvn.com/mcastfw.txt>
I'd be interested in any comments that people may have.

As "IP multicast across firewalls" falls into the general area of "MBone
deployment", I'd like to get some feedback - on this mailing list and/or
the MBONED session at the upcoming Los Angeles IETF - as to what, if
anything, should be done with this draft.  In particular, do we want to
make this a product of this WG (as was the "Introduction to IP Multicast
Routing" I-D?  Also, should this eventually become an informational RFC or
a BCP?

---------------------------------------

                       IP Multicast and Firewalls

                   <draft-finlayson-mcast-firewall-00.txt>
...
2. 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.

-----------------------------

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 06 Mar 1998 15:05:05 +0000

In message <[email-masked]>, Ross Finlayso

 >>confusion) about how to relay (& control the relaying of) IP multicast
 
nice doc

a comment - basically its on the principle of principals:-)

the idea you've expressed could also be said that the principal who is
authed to one side of a multicast firewall should be a Session, not a user

so we have 

internal net	firewall	external net
useri		mapper		usere
sessioni			sessione

and users inside subscribe to sessions iside which are mapped to
sessions outside

that way we get the key scaling stuff (asymetric keyts) as well as
other scaling properties....and can even manage multiple firewalls on
the edge of an org......

at least thats what i think you meant:-)

thanks for this - i've bee nfrustrated at the socks V and other stuff
for a while!

cheers

 >>for unicast traffic, are less appropriate for multicast.

 cheers

   jon

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 06 Mar 1998 20:10:31

>authed to one side of a multicast firewall should be a Session, not a user

That's right.  The multicast communication model ("arbitrarily many
receivers, who are anonymous") means that there's no point in trying to
authorize every internal join of a session.  Instead, you authorize merely
the ability to relay the session, regardless of who may participate in it.
(Then, if you want to restrict participation, you do so using digital
signatures & encryption.)

>thanks for this - i've bee nfrustrated at the socks V and other stuff

Unfortunately, many security administrators are likely to want to
micro-manage the use of multicast inside their administrative domain -
e.g., by trying to authenticate and audit every join.  To some, SOCKS may
appear attractive for this purpose.  ("When your only tool's a hammer, ..."
:-)  My basic approach here is to try to push this issue to the side, by
noting that most of these extra management functions aren't really
firewall-related.  These management functions would be equally
(in-)appropriate, even if the domain weren't firewalled at all.

	Ross.