Subject: Re: Submission of RTSP V1.0 (Real Time Streaming Protocol) for MMUSIC Working Group of IETF

From: Mark Baugher <[email-masked]>
Date: Mon, 21 Oct 1996 13:40:51 -0700

Christian,

At 01:39 PM 10/21/96 -0400, Christian Huitema wrote:

>The firewall argument is very bogus. A firewall that does not let UDP
>through would not only block multi-media signalling. It would block the
>multi-media data as well...

yes, both are blocked today and we have a problem.  Unicast UDP
streams are thought to be a real threat, probably rightly so.  I 
imagine that one design point would be to allow access for UDP data 
that is associated with a TCP control channel - the TCP connection 
providing the state needed by the firewall to validate the particular 
UDP flow.

Mark

>-- 
>Christian Huitema

---

From: [email-masked] (Christian Huitema)
Date: Mon, 21 Oct 1996 16:57:35 -0400

Mark,

There are a few steps that a firewall can do besides "barring UDP" or
"associating UDP and TCP flows (how?)". One of the obvious possibilities
is to let the firewall act as an application relay -- RTP is specifically
designed to allow that. Another possibility is to let the firewall act as
a signalling relay, listening to the call set-up or synchronization
traffic, and have it then selectively open the gates for one or another
RTP stream. Note that such application relays are actually easier to
implement with UDP than TCP...

-- 
Christian Huitema

---

From: Mark Handley <[email-masked]>
Date: Mon, 21 Oct 1996 21:59:36 +0100

>providing the state needed by the firewall to validate the particular 

Actually what you're talking about here sounds more like a
"conference" or at least "conference control protocol" aware firewall.
If you have firewall awareness at this level, it makes little
difference what protocol the control channel is conveyed over.

I expect in the not too distant future that real-time traffic will be
a very significant proportion of network traffic.  Thus it does make
lots of sense to have firewall awareness of real-time control
protocols.  But it only makes sense if we can rationalise the problem
down to one (or very close to one) control protocol.  This is why it's
so important we do get this right, why we must listen to many
different viewpoints, and why we have to be a little careful not to be
too over-influenced by what todays firewalls can do.

But we shouldn't completely ignore the issues of deployability too...

Mark

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 22 Oct 1996 09:06:32 +0100

>providing the state needed by the firewall to validate the particular 
 
right - the existence of secure state creation in firewalls for TCP
and use to validate UDP is used as the baseline argument for re-use of
TCP

but if we define any kind of workable remote control protocol mapping
on to UDP, it is creating state at the server and shoudl do so in some
sort of relaible way - getting the ISN selection type trust that you get 
in TCP into such a protocol would not be hard....and then we could use it for
firewalls too....

or we could mandate for a proper secure design in the first plaec and
avoid the requirement (i.e. make the actual application level
control protocol trustworthy enough that people always let it through
their firewalls anyhow......though i guess this is hard since if it is
UDP based, it can always be used as a denial of service attack on
someones NFS server......maybe we could use this to pursuadew people
to run secure TCP based NFS and do the same with other sensitive
UDP based apps...:-)

 jon