Re: [MMUSIC] RTSP & NAT: Symmetric RTP

[Magnus Westerlund <magnus.westerlund@era.ericsson.se>]

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