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

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

Why would you define a feature and then strongly recommend that it not
be deployed?

Wouldn't it be much more reasonable to either not define the feature at
all or else ensure that hooks exist to work with another protocol in
which the feature actually belongs?

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

>which the feature actually belongs?

The question is one of where the relevant authorisation mechanism
should be.  Looking at the RTSP architecture, it doesn't feel like
this is the right place for such an authorisation mechanism, partly
because it adds a lot of extra complexity, and partly because it seems
to be a more generic function that may well benefit other
applications.

If this is indeed the case, then the correct course of action is to
provide the request mechanism in the RTSP *protocol*, but dictate that
it not be used unless an appropriate authorisation mechanism is
available.

The thing here is to distinguish policy and mechanism.  If it's an
appropriate mechanism to send to a specified multicast address it
should probably be an appropriate mechanism to send to a specified
unicast address.  The difference between the two is policy, and policy
not be designed into a protocol *at this level*.

Mark