Subject: RTSP: 6. Destination for data that is not the source of control messages

From: Rob Lanphier <[email-masked]>
Date: Thu, 17 Apr 1997 15:09:30 -0700

At Memphis, the general consensus was that there
should be a mechanism to allow a client to direct the
data stream to a unicast or multicast address other
than the current one.

The problem one can imagine is denial of service,
where one could flood any arbitrary machine on the
Internet with unrequested RTSP streams. While there
are certainly other ways of doing this today, the
idea that one could cause the streams to come from a
variety of locations from which one has no special
privledges is particularly troublesome.

Security problems with this approach must be resolved
before widespread implementation of this feature
could be expected. Nonetheless, the general feeling
that policy decisions should not be made in the
protocol requirements.

The issue of of having multiple destinations for a
stream in a single session was also discussed. This
would enable a conference participant to request that
a stream be delivered to all the other unicast
participants in the conference.

David Oran from Cisco pointed out that if the
sessions aren't tightly synchronized, then having
multiple unicast addresses isn't a very big win. The
same result could also be achieved by simply creating
multiple RTSP sessions each controlling a single
destination, rather than a single RTSP session
controlling multiple destinations. Having only to
worry about single destinations simplifies the
protocol in a number of ways.

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Apr 1997 20:15:15 -0400

> privledges is particularly troublesome.

Also, a single user with a lowly 14.4 kb/s modem could direct a whole
T3's worth of data to one or more targets simply by setting up a number
of high-rate streams. This 'force multiplier' is novel, I think.

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 18 Apr 1997 16:36:09 +0300 (EET DST)

>of high-rate streams. This 'force multiplier' is novel, I think.

Hmm. I think direct instantiation of high-speed links to (possibly)
unknown (unknowing) participants isn't very neat. If a mechanism of this
kind is needed, it shouldn't initiate the data transfer but, rather, an
off-band  negotiation cycle (on RTSP?). Of course, this is a no-no for
multicast addresses... Comments?

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>

---

From: Mark Handley <[email-masked]>
Date: Fri, 18 Apr 1997 10:33:44 -0400

>of high-rate streams. This 'force multiplier' is novel, I think.

I agree this is an issue that must be dealt with.  However, I tend to
believe that this is really a session control/authentication issue
rather than a stream control issue.  So I see no reason why the RTSP
*protocol* shouldn't allow this, although I would strongly advise
server designers to disable to feature by default in the absense of
sufficient (probably out-of-band) authentication.  If you allow the
feature in the protocol, I'd advise a comment along these lines in the
spec.

Mark

---

From: David Oran <[email-masked]>
Date: Fri, 18 Apr 1997 11:10:34 -0400

>multicast addresses... Comments?
Well, there's no other way to specify a multicast address than for either
the client or the server to pick it.

Actually, multicast addresses are safer than unicast addresses since
receivers have to join the multicast group before the data flows. 

In thinking about this thread, if a client wants data sent to some random
IP address, the server shouldn't do it unless something at that IP address
says it's OK. Maybe we have to invent a simple UDP-based protocol from the
destination address to the server to actually turn on transmission, or
possibly add an RTCP message that comes from a unicast destination back to
the server before data will flow.

The more I think about it, the more I think the RTCP idea may be worth
pursuing since it would work on any RTP stream coming from a cooperating
source (which the RTSP server is likely to be) but wouldn't be dependent on
RTSP - other protocols might run into similar 3rd party spoofing problems.

-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: [email-masked]

---

From: Jeff Smith <[email-masked]>
Date: Fri, 18 Apr 1997 08:43:05 -0700

This is beginning to sound more and more like a task to be performed
by an invitation protocol (SIP) and not a channel control protocol.

Also reminds me of Scott Petrack's examples of call forwarding.  (I
wasn't able to attend the IETF so it is entirely possible that this is
indeed born of Scott's suggestion :)

js

|On Thu, 17 Apr 1997, Henning Schulzrinne wrote:
|
|>> At Memphis, the general consensus was that there
|>> should be a mechanism to allow a client to direct the
|>> data stream to a unicast or multicast address other
|>> than the current one.
|>> 
|>> The problem one can imagine is denial of service,
|>> where one could flood any arbitrary machine on the
|>> Internet with unrequested RTSP streams. While there
|>> are certainly other ways of doing this today, the
|>> idea that one could cause the streams to come from a
|>> variety of locations from which one has no special
|>> privledges is particularly troublesome.
|>
|>Also, a single user with a lowly 14.4 kb/s modem could direct a whole
|>T3's worth of data to one or more targets simply by setting up a number
|>of high-rate streams. This 'force multiplier' is novel, I think.
|
|Hmm. I think direct instantiation of high-speed links to (possibly)
|unknown (unknowing) participants isn't very neat. If a mechanism of this
|kind is needed, it shouldn't initiate the data transfer but, rather, an
|off-band  negotiation cycle (on RTSP?). Of course, this is a no-no for
|multicast addresses... Comments?
|
|Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>
|
|

---

From: Sampo Syreeni <[email-masked]>
Date: Sat, 19 Apr 1997 19:47:09 +0300 (EET DST)

>by an invitation protocol (SIP) and not a channel control protocol.

Indeed. However, there may be some problems in that approach as well.
Especially in the case where the desired destination address is multicast.

's no other way to specify a multicast address than for either
>receivers have to join the multicast group before the data flows. 

Agreed. Multicasting is built from the ground up to have dynamic group
membership, something unicast protocols do not ordinarily have. So that
makes things a lot easier.

>says it's OK.

Precisely my point.

>Maybe we have to invent a simple UDP-based protocol from the

Indeed. RTSP should be reserved for stream control, not for managing
multicast group memberships or anything like that.

>RTSP - other protocols might run into similar 3rd party spoofing problems.

Yep. The idea is well in line with the idea of keeping things simple and
modular.

---

From: Jeff Smith <[email-masked]>
Date: Sat, 19 Apr 1997 09:50:00 -0700

Why would a multicast destination be problematic?  Seems to me that
SIP was designed largely for the multicast case.

|On Fri, 18 Apr 1997, Jeff Smith wrote:
|
|>This is beginning to sound more and more like a task to be performed
|>by an invitation protocol (SIP) and not a channel control protocol.
|
|Indeed. However, there may be some problems in that approach as well.
|Especially in the case where the desired destination address is multicast.
|
|Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>
|
|

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 23 Apr 1997 15:43:33 +0300 (EET DST)

>SIP was designed largely for the multicast case.

Sorry. I seem to have been a little mixed up the day I wrote that. I was
thinking about the direction SIP works in completely assbackwards....

--------

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 23 Apr 1997 15:43:33 +0300 (EET DST)

--------