Subject: [MMUSIC] RTSP 2.0: Removing queuing of server to client requests

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Jun 2013 13:39:59 +0200

WG,

Robert raised an issue regarding some text in 10.2:

A server that attempts to send a
   request to a client that has no connection currently to the server
   SHOULD discard the request directly, but it MAY queue it for later
   delivery.  However, if the server queues the request it SHOULD when
   adding additional requests to the queue ensure to remove older
   requests that are now redundant.

>>
>> The text talks about the option to queue S->C requests if there isn't a
>> connection to the client available. Ostensibly, this means the request
>> can go down some future connection. It's not clear how the server can
>> tell the right client connected. In particular, when using rtsps, how do
>> you prevent a malicious client from getting such a queued message that
>> wasn't meant for him?
> 
> 
> Okay, this security issue I have totally missed but it is clearly
> serious. I don't see any easy way of fixing this. Thus I would suggest
> that we simply make it clear that a server MUST NOT queue the S->C RTSP
> message, independent if they are requests PLAY_NOTIFY and TEARDOWN or
> responses to client requests.
> 
> 
>>
>> Given that the text talks about queuing S-C requests, it should
>> explicitly call out whether a server can queue a response if the
>> connection the associated request arrived on is no longer available. I
>> think what you want to say is that such a response must not be queued,
>> and must be dropped.
> 
> Agreed, lets mandate that they are dropped.
> 
> 

I propose that this change is done and implemented like this text
replacing the above one.

 A server that attempts to send a request to a client that has no
connection currently to the server SHALL discard the request directly.

I also propose that we add a indented reasons paragraph:

Queuing of server to client requests has been considered. However a
security issue exist in how one authorizes a client establishing a new
connection as being a legit receiver of request related to a particular
RTSP session without the client first issuing requests related to the
request. Thus, likely making any such requests even more delayed and
less useful.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------