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:11:17 -0700

I believe that this provision, suggested at the latest IETF, is
representative of undesirable "scope creep".

I fully Sampo's, Henning's, and Rob's comments in this regards (i.e., it
leaves us open to some nasty denial of service attacks and is otherwise
unacceptable from a security perspective).

Like the majority attending the IETF session in which this was proposed,
I do believe that the idea is a very good one. However, the idea is
improperly targeted: it addresses a conferencing need, not a streaming
need. RTSP is an inappropriate place whereby this idea should be
enacted. Rather, I believe that this idea belongs with H.323 and MBONE
*conferencing*.

I suggest rather that we ensure that RTSP has the necesary "hooks" to
stream data into H.323 conferences and into MBONE conferences.

> -----Original Message-----
> From:	Sampo Syreeni [SMTP:[email-masked]]
> Sent:	Friday, April 18, 1997 6:36 AM
> To:	Henning Schulzrinne
> Cc:	Rob Lanphier; [email-masked]
> Subject:	Re: RTSP: 6. Destination for data that is not the source
> of   control messages
> 
> 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: Mark Handley <[email-masked]>
Date: Fri, 18 Apr 1997 12:42:15 -0400

>enacted. Rather, I believe that this idea belongs with H.323 and MBONE

The provision to send to a multicast address has been in there since
last summer.  It's not scope creep at all, and the need to be able to
play into a multicast session is one of the main reasons why this is
being discussed in MMUSIC at all.  Remove this ability from the RTSP
spec, and a new parallel standards track spec addressing this issue
will simply emerge to satisfy this need, and none of us desire that to
happen.

The question of sending to a third-party unicast address is what is
being discussed here.  This requires no additional mechanism to
implement once you can send to a multicast address, but does raise
serious security issues.  The question on the table is at what level
to address those security issues.  

Mark