Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Mar 2003 10:13:52 +0100

Hi Thomas,

Comments below:

Thomas Zeng wrote:

>Magnus:
>
>I have a comment on 3.2 Symetric RTP.
>
>As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server
>normally uses a single RTP port (let's call it X) to send RTP packets to
>many (potentially hundreds) of clients. Now Symetric RTP asks these clients
>to send an RTP packet with their individual client SSRC in the payload to
>this port X on the server host. Since each client randomly generates client
>SSRC, there is some chance (as high as 10^-4 according to RFC1889, section
>8.1) that two clients may end up with same SSRC, in which case the server
>may send RTP packets to wrong clients. I did study the SSRC collision
>detection scheme in RFC1889 and found it irrelevant because it only applies
>to multicast RTP sessions. I don't think destination IP can help here since
>prior to the establishment of binding  our server doesn't know clients
>public IPs. Besides, the two collided clients may well be behind the same
>NAT and hence probably share public IP.
>  
>

My first comment is that the easiest way of solving this problem, is for 
the server to send from different ports for each client. That way you 
reduce the probability of collisions and ensures maximum security in 
respect to hijacking.

>I hereby suggest that the binding RTPs to add, in a fashion defined below,
>client's RTSP sessionID in addition to client's SSRC in those binding RTP
>packets. Notice RTSP sessionIDs are generated by the server and hence can be
>made unique amongst all clients of that server.
>
>The session ID happens to provide other niceties:
>
>1. One client only has to make sure that its client SSRCs are unique amongst
>the RTP tracks it has in the session (if it happens to have more than one
>track)
>2. Since RTSP session ID can be 64 bytes or longer, it offers added
>protection against stream hijacking or brute force attacks (since now the
>hijacker/attacker must guess not only SSRC, but also SessionID).
>
>Careful thinking revealed to me that the fundamental problem here is that
>prior to the establishment of port mapping, there is no way for the server
>to determine RTP session using the traditional source and destination (IP,
>port-pair) as defined in RFC1889 section 3. Unfortunately, it means that
>what I said about RTP port mapping is also true to RTCP port mapping.
>
>Assuming you readers are with me so far, I then propose that the binding RTP
>packets include SessionID in the following fashion:
>
>1. Do NOT use PT=0, instead, use a dedicated PT for binding purposes (we
>probably need to reserve one).
>2. The only payload in this RTP is the session ID.
>3. This payload type shall be used for the binding packets the client send
>to sender's RTCP send port as well (in lieu of the normal RTCP packets in
>Magnus draft, section 3.2.3, page 8). 
>  
>

I can agree that a new payload for RTP would allow a server to save it 
from the need to perform real port multiplexing between its clients. 
However I don't see a need for solution only to this problem. If we 
would be design a new RTP payload format then we should make this for 
the general security problems related to RTSP.

1. Provide improved security for symmetric RTP by allowing for longer 
random tags.
2. Allow for a RTP/RTCP based challenge mechanism that can be used to 
ensure that a receiver accepts the data traffic, i.e. solve the 
destination security problem.

Such a solution should consider the following problems:
- Be usable for both RTP and RTCP.
- Allow for dynamic tag length.
- Be possible to authenticate in respect to both sender and receiver.
- Have room for response codes.

>
>Interestingly, there is another way to deal with client SSRC collision:
>rejecting the SETUP request containing a client SSRC already registered.
>But that breaks backwards compatibility in that current clients don't know
>to change SSRC and resend SETUP request. Besides, the nice security feature
>of sessionID is gone.
>  
>

This seem to be a bad idea. It creates backwards compatibility issues 
where other solutions exist.

>Hence I prefer the inclusion of SessionID.
>  
>

I prefer the solution that the servers take responsibility and actually 
use multiple ports. In the long run we could define a general challenge 
mechanism. This mechanism can then in the future be used to ensure 
better security in several ways.

Best Regards

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: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Tom Marshall <[email-masked]>
Date: Mon, 3 Mar 2003 09:52:04 -0800

> reduce the probability of collisions and ensures maximum security in 

This is a big resource drain on the server.  It effectively *triples* the
number of sockets you need to pass into select() or poll().  That is, for N
clients, the server must poll on 3*N sockets (one RTSP, RTP, and RTCP socket
per client) instead of 1*N+2 (one RTSP socket per client plus a fixed RTP
and RTP socket).

I can see an example server doing this, but I have doubts that commercial
code would be willing to take the hit.

-- 
"When competing for a section of road or a parking space, remember that the
vehicle in need of the most body work has the right-of-way."
        -- Massachusetts Driver Education Manual