Hi David,
For RTSP and RTP usage it seems possible to make the whole process work
using the RTP SSRC. In RTP flows that is present in the RTP header making
it simple to handle. For RTCP it becomes even more important that it can
be sent in the context of RTCP. RTCP traffic will flow through out the
whole session. Therefore a special demultiplexing between RTCP and binding
messages will be difficult.
Using SSRC requires a simple parameter addition to the transport header.
The client simple tells the server what to use. However the big question
is if a 32 bit SSRC value is unique enough to function well. A RTSP server
at least has the advantage that it can use multiple sending ports. If a
client SSRC proposal already is in use on some port this can simple be
sent to a different sender port.
Using other methods of transporting this ID on top of UDP or other
transport protocols create problems. Defining a general format that is
simple used creates multiplexing problems for all use cases. For RTP it
could be possible to define both a RTP payload format and a RTCP packet
type that can be sent containing a general type of ID.
Best Regards
Magnus
David Yon wrote:
As Jonathan points out in his reply, a similar attack is being discussed
in the context of comedia/comedia-fix. The proposed solution in
comedia-fix is to window the protocol by always starting the stream with
a unique ID prior to sending packets using the protocol that has been
signalled in the SDP. My discontent with this mechanism is well
documented in that email thread.
If there is to be some sort of session correlation embedded in the media,
I would greatly prefer the approach you are suggesting. I.e., make the
endpoint ID be something derived from the protocol proper, rather than
inserting the ID out-of-band in relation to the signalled protocol.
As evidenced by this RTSP discussion, this need exists outside the scope
of connection-based media, so perhaps comedia isn't the place to document
a generic media/session correlation mechanism.
If one accepts the notion that connectionless media has this need for
session correlation, then it becomes clear that the comedia-fix proposal
is not equipped to address the problem in this larger scope.
What immediately comes to my mind is how to window the protocol when the
media is carried over unreliable transport (i.e., UDP). Since there is
no guarantee of ordering or delivery, the sender cannot simply just send
the first packet with the endpoint ID. The packet may never arrive at
the receiver, or it may arrive after other media packets. So the
receiver has no reliable way of parcelling out the endpoint ID from the
in-band media, unless of course the endpoint ID is encoded within the
framework of the media itself.
This is sounding more and more to me like endpoint ID is a standalone
topic. Perhaps a short I-D that documents the need and the SDP syntax,
plus globbing together a few of the more obvious protocol extensions
(i.e., the RTP suggestion discussed below).
At 07:50 AM 2/10/2003, Magnus Westerlund wrote:
Security risks: Hi-jacking of media streams. The basic problem is that
any RTP/RTCP traffic arriving to the sender port prior to the clients
message will result in redirection of the media stream to the sent
packets address and port. This allows an attacker to spoof the sender
IP/port number to that of a target of an Distributed DOS attack. This
can basically be done without being on the path between client and
server by simple guessing port numbers.
Good Solution: Create a RTP payload format that carries session
identifier and a sufficient large random tag that prevents guessing.
However due to NATs and the setup this can never be ensured against
attackers located on the path between client and server.
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
--
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic