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

From: Thomas Zeng <[email-masked]>
Date: Fri, 28 Feb 2003 16:14:05 -0800

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.

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). 

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.

Hence I prefer the inclusion of SessionID.

- thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 25, 2003 3:46 AM
Cc: [email-masked]
Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiparty Multimedia Session Control
Working Group of the IETF.

	Title		: How to make Real-Time Streaming Protocol (RTSP) 
                          traverse Network Address Translators (NAT) and 
                          interact with Firewalls
	Author(s)	: M. Westerlund
	Filename	: draft-ietf-mmusic-rtsp-nat-00.txt
	Pages		: 18
	Date		: 2003-2-24
	
This document describes four different types of NAT traversal
techniques that can be used by RTSP. For each technique a description
on how it shall be used, what security implications it has and other
deployment considerations that exist is given. Further a description
on how RTSP relates to firewalls are also given.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-rtsp-nat-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic