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

From: [email-masked]
Date: Wed, 26 Feb 2003 19:26:15 +0100

Tom you wrote:

>Firstly, I assume that the case where a server is behind a NAT is rare.
>NATs are primarily for clients.

I dont see how the "localization" of the NAT
makes any difference from the end-to-end point of view
of having RTSP clients and servers ?

[BTWwhat I am seeing (now and not improoving in any future)
is a lot of NATs everywhere !
i.e. several NATs between a server and a client !
actually it was told that IPV6 deployement,
which should solve the addressing issue(!?)
can only happen progressively and that
 IPV6/IPV4 realms will be effectively linked using ...NATs !
arg! getting pessimistic ?-]

> [My personal opinion: if an administrator is too afraid
> to handle those nasty unclean UDP packets,
> they shouldn't be running a server.

yes ... I used to think that too...
but I discovered that often the guy who wants to deploy the RTSP service
only vaguely knows how to possibly get in contact with the guys running the (first) NAT :-!
these are different jobs, typically different corporations and
unfortunately they usually  have so different priorities/agendas
that they have trouble speaking together...

regards,

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

                                                                                                                                       
                                                   To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                   cc:   [email-masked]                                             
                                                    [email-masked]                                                                    
                                                   Subject:    Re: [MMUSIC] RE: draft-ietf-mmusic-rtsp-nat-00.txt                      
               Tom Marshall                                                                                                            
               <[email-masked]>                Classification:                                                                     
                                                                                                                                       
               26/02/2003 18:52                                                                                                        

On Wed, Feb 26, 2003 at 11:40:04AM +0100, [email-masked] wrote:
>
> 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!...)

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?

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

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.

> 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_ !

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.

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

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
(See attached file: att5k12c.dat)

---

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

> of having RTSP clients and servers ?

It makes little difference in the specification, but it a huge difference in
the implementation.  If it's possible for the server to be behind a NAT that
doesn't forward UDP packets, it would need to use NAT traversal to inform
the client of its RTP ports.

We know that STUN does not work for symmetric NATs.  We know that NATs as
implemented in most common Unix routers are symmetric.  Therefore, I am
guessing that most NATted servers will be behind symmetric NATs and
server-to-client STUN will not work anyway.

This is not to say that we should discourage its use, of course.  I am only
saying that NAT should be viewed primarily as a client-side phenomenon. 
Implementors are free to implement STUN and/or Symmetric RTP on both client
and server and have a product that works when both are behind NAT.  With
careful implementation, a product could even work when both ends are behind
symmetric NATs.  See http://www.peercast.org/ for one possible application
of server side NAT traversal.

> i.e. several NATs between a server and a client !

Absolutely.  There are two between my home machines and the net.

> arg! getting pessimistic ?-]

IPv6 is amazingly adept at traversing IPv4 NAT.  I am running an IPv6 tunnel
to my home machines.  You can contact them via IPv6 anywhere in the world
even though they are behind two levels of IPv4 NAT.

> that they have trouble speaking together...

The sysadmin vs. netadmin argument holds no water.  We should NOT be
providing a means to deliberately break administrative control.  (It's
redundant anyway, see RFC 3093).

NAT traversal is intended to work around the limitations in common NAT
implementations.  If it happens to work for the server-to-client direction,
well, that's a coincidence.  It might even be seen as a consequence of good
design.  But it is not our intent to deliberately undermine administrative
control.

-- 
A revised schedule is to business what a new season is to an athlete or a
new canvas to an artist.
        -- Norman Augustine