Re: [MMUSIC] RTSP and NATs

[Jonathan Rosenberg <[e-mail]>]

inline.

Tom Marshall wrote:
> On Mon, Feb 03, 2003 at 06:45:54PM -0500, Jonathan Rosenberg wrote:
> 
>>
>>Tom Marshall wrote:
>>
>>
>>>>STUN does not allocate the addresses. It merely tells the client what a 
>>>>regular, off the shelf NAT has allocated to a user. Since regular, 
>>>>off-the-shelf NATs do not know anything about RTP port pairings, two 
>>>>separate STUN requests will result in a nat allocating two bindings 
>>>>which are most likely not consecutive (or follow the odd/even rule). 
>>>>THis is dealt with through an SDP extension that allows a client to 
>>>>provide a specific address and port for SDP 
>>>>(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt).
>>>
>>>
>>>This draft again assumes that RTP is the only transport choice:
>>>
>>> rtcp-attribute =  "a=rtcp:" port
>>>
>>>What if there were some other UDP based transport that required two UDP
>>>ports (perhaps even "RTPng")?  You would need yet another draft to address
>>>it.  Why not make the solution generic instead?
>>
>>Well, if thats so, I would have rather had such a debate in the context 
>>of the above draft. Anyway, I know of no other media stream that uses 
>>UDP that uses multiple ports AND that has an algorithmic relationship 
>>between those ports (i.e., has no way to express in the SDP which ports 
>>are needed). Seems like a non-problem.
> 
> 
> Prior to IPv6 there was no known way to express a numeric IP address such
> that it would not fit into a 32-bit integer.  Now there is, and it is one
> source of poring issues.  Of course this is not a problem now.  Can you say
> with certainty that it will never be a problem?

Seems like a bit of an over-exaggerated analogy. As I said, for any new 
protocol that needs multiple ports, it should simply make sure that its 
SDP parameter definitions include them. In such a case you will never 
have a problem.

Anyway, the point is moot, since, based on my limited RTSP knowledge, 
SDP is not used in the client addresses anyway. Thus, you can't use the 
SDP draft above.



>>A smart ALG won't. It should know not to muck with IP addresses inside 
>>of the RTSP message if they are not private addresses (if stun is used, 
>>those addresses will have already been changed to public ones by the 
>>RTSP client). Indeed, one can imagine usign RTSP to setup a streaming 
>>media session to some third party device outside of the nat, in which 
>>case the ALG has to know not to change the IP. I wonder if the linux 
>>code you cite supports that.
> 
> 
> All of the four or so RTSP modules that I am familiar with simply look at
> client_port= and perform a mapping.  In order to detect that a transport
> spec is using STUN, the module would also need to check for a destination=
> attribute.

Right. Although, I must admit confusion. If the client doesnt provide a 
destination attribute, to what IP address is the media sent? It seems to 
me that the destination parameter would normally be there. Or perhaps 
you are saying it is there, but its not looked at by the ALG?


> 
> 
>>Which, of course, brings me to my beef with ALG - the wrong people write 
>>them in general. Only an RTSP expert would probably know to look for 
>>such nuances (even then...), 
> 
> 
> Indeed.  I have written one of the modules referenced above and I did not
> consider it.  On the other hand, the destination= parameter has always been
> a security risk at the server side and I am reluctant to advocate using it. 

I guess I don't understand how media is delivered to the client then.


> It certainly is their business if they make the equipment.  It's enough of
> their business that they provide an ALG for FTP.  But I think it should also
> be (or should have been) the business of the IETF to design a NAT traversal
> protocol which allows the client to directly request mapped ports from the
> NAT device.  Such a protocol would reduce or eliminate the need for STUN and
> friends, and it would provide a single protocol for the vendors to implement
> instead of a running treadmill of RFCs.

Oh yes, no doubts there. midcom has been trying for years, and still no 
success. Even then, once its done, it doesn't work for many topoligies. 
The ultimate right answer is nsis, which would allow the client to 
directly ask for bindings through all nats that it will need to talk to. 
But, we are years and years away from such a thing seeing deployment.

> 
> But the vendors have already been given a single protocol to implement:
> UPnP.  It was created from the desire for NAT control at the client and
> appears to have a lot of support from NAT vendors already.  And this makes
> me wonder why we are continuing to propose more NAT traversal solutions. 
> Why not either recommend UPnP or design an equivalent?

I indicated in another mail several problems with upnp. Another 
practical one is that its not that widely deployed yet. So, when an 
media company wants to deploy, do they wait and hope that people go off 
and buy upgrades to their nat, or hope all the nat vendors fall in line? 
No way. They want to be able to deploy the service now, without being 
dependent on features placed into home routers.

Anyway, ietf is working on their version of upnp, which is the midcom 
protocol.

>>Certainly. This is called "symmetric NAT". Its common but to date the 
>>full-cone variety, which maps bindings by private IP/port alone, is 
>>quite prevalent amongst the home NATs.
> 
> 
> Interesting.  Where can I find out more about how many home networks use
> which types of NAT?

I've heard reports of studies done on the subject, but have not seen 
concrete or quotable reports. I think such an analysis, especially 
tracking it over time, would be a great masters project for some student 
somewhere.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com

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