Subject: [MMUSIC] RTSP: Clarifying setup in Multicast

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Nov 2008 18:01:33 +0100

Hi,

This concerns the following issue:
https://sourceforge.net/support/tracker.php?aid=2105351

When sending SETUP request to a RTSP server it can either itself
indicate the multicast address to use or it can take a destination from
the client. The later has the normal DDOS security issues. However,
there need to be clarification on how one seperates the two.

I propose the following text to the Transport header section.

For Multicast there is several methods for specifying addresses but
they are different in how they work compared with unicast:

dest_addr with client picked address: The address and relevant
parameters like TTL (scope) for the actual multicast group to
deliver the media to. There are security implications
(Section 21) with this method that needs to be addressed if
using this method because a RTSP server can be used as a DoS
attacker on a existing multicast group.

dest_addr using Session Decription Information: The information
included in the transport header can all be comming from the
session description, e.g. the SDP c= and m= line. This
mitigates some of the security issues of the previous methods
as it is the session provider that picks the multicast group
and scope. The client SHALL include the information if it is
available in the session description.

No dest_addr: The lack of an explicit multicast group request the
server to decide the group address and its scope. For this to
work the server needs to have a context about what scope that
works. This method is currently under specified.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 4 Nov 2008 09:27:54 +0200

> works. This method is currently under specified.

I don't really understand the subtlety here. I mean, how would we end up in 
the no dest_addr case? Should the server not provide the infos in DESCRIBE in 
the first place?

Conversely, if the SDP is not obtained via RTSP (DESCRIBE), and does contain a 
multicast transport address, why would the client (need to) talk to the RTSP 
server at all? Supposedly this is a permanent multicast stream then 
(without "seeking" capabilities).

Perhaps we should remove the "No dest_addr" case.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "HAAS Christian" <[email-masked]>
Date: Tue, 4 Nov 2008 09:43:59 +0100

Hello!

From: Rémi Denis-Courmont 

> the no dest_addr case? Should the server not provide the infos in DESCRIBE
in 

Not if it is a dynamically created multicast presentation.
The server is configured to use a pool of x multicast streams, which is used
on demand by request of the client that doesn't know the destination address.
The server responds to a DESCRIBE with invalid c= info, and the client sends
a minimal Transport header. The server then allocates on of the multicast
streams and returns the actually used parameters.
At least this is the application I could think of.

> (without "seeking" capabilities).

Since the SDP does not state whether the stream is permanent or not (in the
sense of dynamically started/stopped depending on existing listeners) --
There was a related discussion on this list, though I hope not to mix up some
possibly separate topics.

> Perhaps we should remove the "No dest_addr" case.

I have to admit though, if it is not in the DESCRIBE, at least the client
should set something at least as a recommendation (how the client would guess
it to work) - and still, the server has the final word and may choose another
configuration.
Although, who is more knowledgeable about available multicast distributions -
the client or the server?

Regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]
 
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.