Subject: RE: RTSP: 6. Destination for data that is not the source of con trol messages

From: Eric Fleischman <[email-masked]>
Date: Fri, 18 Apr 1997 09:51:55 -0700

RTCP use is great. However, one of the underlying concepts of RTSP was
that it was to be "neutral" about the data delivery protocol. RTCP just
doesn't care whether the data -- and RTSP "control messages" themselves
-- is carried by UDP, TCP, UPD/RTP, TCP/RTP or Joe's recent transport
invention. Thus, binding RTSP to RTP represents a change in thinking as
to what RTSP actually is.

There is power in limiting RTSP to its original constraints and relying
on other protocols, in partnership with RTSP, to fill in those holes
which are purposefully "out of scope" to RTSP itself.

> -----Original Message-----
> From:	David Oran [SMTP:[email-masked]]
> Sent:	Friday, April 18, 1997 8:11 AM
> To:	Sampo Syreeni; Henning Schulzrinne
> Cc:	Rob Lanphier; [email-masked]
> Subject:	Re: RTSP: 6. Destination for data that is not the source
> of   control messages
> 
> >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?
> >
> 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: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 18 Apr 1997 21:00:15 -0400

A few quick remarks:

1) In many cases, RTSP will want to do authentication. Indeed, it
already offers reasonably secure facilities (digest) and barely secure
(basic) facilities to do that, in either UDP or TCP. Authentication will
be needed, in particular, for pay-per-view or limited distribution
services. In those cases, the redirect poses a limited risk (assuming
the server has a suitable contract with the authenticated party and has
some hope of legal or contractual recourse).

2) Just adding another UDP protocol asking "do you really want this
stream" won't work. The perp just directs the stream to a non-existent
address on an existing subnet and fakes the 'yes, please, send' messages
or RTCP messages. This could be prevented by a challenge-response
protocol, but then we are basically back to case 1, which is already
supported as is.

Thus, given that we really can't prevent people from allowing a single
unicast address (instead of multicast) as a destination, that not
allowing third-party addresses will still be possible without the
feature (simply by faking UDP RTSP commands to come from the targeted
site) and that it does not increase protocol complexity, my suggestion
would be to leave the feature in, but strongly suggest that servers
require authentication for any UDP command (at least), regardless of
whether it asks for redirect or not.

Henning