Re: [MMUSIC] RTSP & NAT: Symmetric RTP

[David Yon <yon.ietf@rfdsoftware.com>]

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
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic