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

From: [email-masked]
Date: Wed, 26 Feb 2003 11:40:04 +0100

Magnus,

First bravo for this draft, it is a very useful document.

I have a few comments, mostly about STUN
(you know I am a STUN fan!)

I note that in the STUN section you write:

" To be able to use STUN to traverse symmetric NATs the STUN server
   needs to be co-located with the streaming server media distribution
   ports."

This is true and it is a very interresting feature indeed,
but then when you had the reader say "ahah!" and
start to get really interrested you cold shower it with:

"This creates an unclear demultiplexing point within the
   server. As this will create implementations difficulties and possibly
   security problems this SHOULD NOT be done."

I think that a "should not" is really too strong here if it is
an implementation issue, co-locating is not in itself
a big issue for exemple a lot of RTSP servers
are also HTTP servers right?
(the "possible security problems" would have to be compared
with the alternative solutions!...)

**************

BTW in the Symetric RTP section you write:

"It has the advantage of working for all types of NATs. However it requires server modifications."

Therefore I conclude that there is no difference
in terms of implementation between STUN and symetric RTP
since in both case you need to change the RTSP server,
and in a similar fashion!

Also you write in the same section:

"   1. The client knows or has determined by the use of STUN that it is
       located behind a NAT. It may also determined the type of NAT it
       is behind."

So If one wants to use Symetric RTP one will have to implement STUN _anyway_ !

For implementers the advantages of symetric RTP are therefore difficult to see ?

and then the reason why, by comparison, would co-located-STUN get a "SHOULD NOT" gets
really difficult to understand!

****************

Anyway I would propose to reword the section  3.1.3. as:

"There are 2 ways to use STUN dependign if the STUN server
is co-located with the streaming server media distribution ports or not.

3.1.3.1. STUN server outside

 Advantages:

   - Does not require RTSP server modifications, totally client
      implemented tool.

   Disadvantages:

   - Requires a STUN server deployed in the public address space.
   - Does only work well behind Cone NATs. Does not work with
      Symmetric NATs.

3.1.3.2. STUN server inside (co-located at the server media distribution
   ports)

 Advantages:

   - Works with all NATs including Symmetric NATs (however see the security section about sending RTP
data at a different public IP address than the one of the RTSP client).

   Disadvantages:

   - Requires a modified RTSP server with co-located STUN server.

**************************************

Last  open issue about STUN:

you describe a number of RTSP modifications for symetric RTP
and none for STUN while there could be one very useful thing:

In the response to DESCRIBE the server should indicate
the UDP ports it is planning to use so that the client can immediately
STUN toward these ports, and then the STUN server reply can
be used for SETUP (saves a lot of round trips).

The question is how can a server indicate its
RTP _AND_ RTCP port numbers ?

For example you can do that with a header in the RTSP response:

   C->S: DESCRIBE rtsp://foo/twister RTSP/1.0
           CSeq: 1

   S->C: RTSP/1.0 200 OK
           CSeq: 1
           Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057
           Content-Type: application/sdp
           Content-Length: xxx

           v=0
           o=- 2890844256 2890842807 IN IP4 172.16.2.93
           s=RTSP Session
           etc...

Also you can include this informationin SDP,
which may be better since the client may get the SDP
by some other means, right?

Regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Feb 2003 11:16:44 -0500

I have yet to read through the doc, but I wanted to let folks know that 
I have released an I-D which is very relevant to this problem:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-00.txt

it should appear in the archives shortly. Although its a sipping draft, 
its applicable to anything that follows an offer/answer style of 
negotiation. One of the things in there is the usage of STUN over media 
ports (called STUN derived transport addresses). It talks about this 
demux issue, and describes how it can be done for RTP and more generally 
for any UDP protocol. As your note below indicates, sending STUN to the 
media port will obviate the need for symmetric RTP, and it works for 
non-RTP transports too. It is my preference to do that in order to have 
a single solution.

The benefit of ICE is that it always ends up selecting the "best" 
connectivity between entities. In the case of the typical RTSP 
deployment, it would end up using connectivity learned by STUNning to 
the media ports on the server. However, ICE would allow for other 
connectivity models, such as cases where a user is in an enterprise that 
wishes to have a media relay on-path for all media (a turn server, for 
example).

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Tom Marshall <[email-masked]>
Date: Wed, 26 Feb 2003 09:52:37 -0800

> with the alternative solutions!...)

It seems to me that an RTSP server which also does STUN is functionally
equivalent to Symmetric RTP.  So why bother to implement STUN in this case?

> and in a similar fashion!

I see two big differences:

1. Timing.  In STUN, the client presumedly contacts the STUN server and
receives the answer for its client_port mapping before sending the SETUP
request (most likely introducing an extra round-trip latency).

2. Protocol.  In STUN, a separate non-RTP protocol is used.  The server must
"demultiplex" the packets by using heuristics to determine if the incoming
packet is STUN or RTP.  While this may be possible due to the specific
differences between STUN and RTP, it is not a good idea in general.

> So If one wants to use Symetric RTP one will have to implement STUN _anyway_ !

I think the wording is incorrect here.  The client does not need to know
that it is behind a nat to use Symmetric RTP.  It simply uses it and the
server determines whether it needs to adjust its destination.

>            o=- 2890844256 2890842807 IN IP4 172.16.2.93

Firstly, I assume that the case where a server is behind a NAT is rare. 
NATs are primarily for clients.  If someone sets up an RTSP server behind a
NAT and forwards port 554 to it, they should also forward UDP traffic to it. 

[My personal opinion: if an administrator is too afraid to handle those
nasty unclean UDP packets, they shouldn't be running a server.  Relying on
the connection oriented nature of TCP for security is surely folly.  But
passing the buck by requiring someone else "take the security hit" is simply
not acceptable and we should not be supporting this scenario at all.]

Secondly, you are correct that there is no way to specify non-contiguous
transport ports in 2326.  The current agreement for 2326bis is to use the
existing transport tokens with the syntax m/n to indicate an arbitrary list
of ports.

-- 
Coding is easy; All you do is sit staring at a terminal until the drops of
blood form on your forehead.
        -- Anonymous

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Feb 2003 11:28:25 +0100

Hi, Philippe,

My comments below:

>with the alternative solutions!...)

I think this is something we need to discuss further. My current view is 
that due to the lack of a well defined demultiplexing structure between 
media protocol and STUN on the servers ports makes STUN solutions for 
symmetric NATs a bad choice. As pointed out you need to compare the 
media protocols bit structure with STUN request. This is not safe 
operation. I do agree that RTP and RTCP seems to be reasonable safe to 
demultiplex, however it is impossible to know that all protocols media 
protocols will work.

I also find your example with HTTP and RTSP a bad example. HTTP and RTSP 
are distinguished using the nice demultiplexing mechanism of ports. 
Normally HTTP request goes to port 80 while RTSP goes to port number 
540. This is a well defined demultiplexing.

Yes, unless you can use STUN to find two port numbers that match the RTP 
rule of consecutive even and odd ports. Both solutions requires updates. 
However STUNs are less from a RTSP protocol perspective.

>So If one wants to use Symetric RTP one will have to implement STUN _anyway_ !
I need to clarify that this is OPTIONAL behavior that MAY improve the 
performance of the solution.

>really difficult to understand!
As explained before this is not a clean solution.

In the second case you forgot the disadvantage of not being guaranteed 
to be able to correctly distinguish media packets and STUN request.

Another thing that it seems that I forgot being a disadvantage of STUN 
is that it does not work if the media mappings would get different IP 
addresses, either between each UDP stream or with the TCP connection. 
The reason is the restriction that RTSP must use to prevent DOS attacks.

Actually you can include this information in the SDP without any extra 
extensions is just the matter of defining the usage. The RTP port number 
can be located in its normal place on the m= line. The RTCP port can be 
set by the attribute defined by
draft-ietf-mmusic-sdp4nat-03.txt. To make this in a good fashion the 
server should define a RTSP feature tag that indicates this 
functionality and that the server should provide the information when 
sending the DESCRIBE response.

I think we need to further discuss the RTSP NAT traversal solutions and 
possible optimization. My draft was intended to be a common ground to 
discuss around.

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]