Re: [MMUSIC] RTSP and NATs

[Tom Marshall <[e-mail]>]

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?

There is no need to deliberately limit functionality in this way.  Perhaps
SDP is committed to its course, although it appears to still be in draft
stage.  We don't have to do the same with RTSP.

> >I have just started looking at STUN but I have some questions:
> >
> >1. Given a NAT that supports RTSP (eg. Linux 2.2 masquerading with an RTSP
> >   module loaded), will the client "detect" that it is behind a NAT? 
> 
> Yes.
> 
> >   If so,
> >   how does this affect the Transport: header as it passes through?  It
> >   seems to me that the RTSP enabled NAT will break the STUN-enabled
> >   Transport: header.  If this is the case, I think that STUN should be
> >   reconsidered (at least for RTSP) as would break an otherwise functional
> >   NAT setup.
> 
> 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.

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

Unfortunately, the overlap of people who would check for the destination=
parameter and the people who know how to code ALGs is very very small. 
Perhaps this argues for simpler protocol specs?

> and Linksys and Netgear to not hire such people - its not their business.

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.

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 will have to do some checking,
> >   but IIRC the Linux 'ipchains' NAT code does mappings with a '5-tuple':
> >   client ip, client port, nat port, server ip, server port.  If the latter
> >   case is assumed (no relay), I don't think that the STUN mappings would
> >   behave as described in the draft.  Packets sent to and from the 
> >   appserver
> >   will have a different 5-tuple, and thus a different nat port, rendering
> >   STUN ineffective.  Has this case been considered?
> 
> 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?

> >>>If the vendors won't support it, then adding more Transport attributes
> >>>creates more implementation headaches for ourselves with little or no
> >>>benefit.  I think the best solution is to find out how to persuade the
> >>>vendors to properly support RTSP.  It is really not much more difficult
> >>>to support than, say, FTP.
> >>
> >>I sinceerely doubt that.
> >
> >
> >Which do you doubt?  The implementation headaches or that RTSP support is
> >not difficult in NAT?
> 
> That RTSP ALGs are likely to be supported widely in the vast array of 
> $100 NAT boxes on the market. FTP *is* widely supported, but RTSP is a 
> domain-specific protocol, and I suspect not on their radar screens.

Unfortunately, I doubt any protocols requiring special handling besides FTP
are on their radar screens.  But UPnP compliance is, and together with the
ALGs in Linux and FreeBSD and Symmetric RTP, I suspect that a vast majority
of the home NATs are covered without STUN.

> >>OPTION 1: Symmtric RTP. See 
> >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-04.txt. 
> >
> >This is similar to a technique that we (RealNetworks) use for our internal
> >transport.  It is quite effective (but not 100% of course). 
> 
> I am curious about what problems you have encountered.

I was not personally involved in the testing but I can probably find someone
who was.

-- 
Happiness isn't something you experience; it's something you remember.
        -- Oscar Levant