Subject: Re: [MMUSIC] RE: Symmetric NAT traversal is a key feature. (was: draft-ietf-mmusic-rtsp-nat-00.txt)

From: [email-masked]
Date: Thu, 27 Feb 2003 13:00:30 +0100

Tom you write:

> We know that STUN does not work for symmetric NATs.

STUN works for symetric NAT if you run the STUN server co-located with the RTSP server,
and that is the key thing: a solution that works for *all* NATs.

As Jonathan coined it very nicely in draft-rosenberg-sipping-ice-00.txt:

"The need to run STUN on the same transport address as the media
   stream represents the "ugliest" piece of ICE. However, it is an
   essential part of the story. By sending STUN requests to the very
   same place media is sent, any bindings learned through STUN will be
   useful even when communicating through symmetric NATs. This results
   in a substantial increase in the scope of applicability of STUN, in
   terms of cases where it can provide connectivity. In that sense, the
   usage of STUN here is radically different than the usage models
   outlined in [13], where STUN is generally useless for dealing with
   symmetric NAT."

>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).
>
....
>But it is not our intent to deliberately undermine administrative
>control.

ha no! not that!
you cannot 3093'ze me on this because
3093 does not apply a single bit here.
(I feel in the position to debate about 3093 since the London meeting!-)

the plan is not  to undermine "administrative control",
because and *that* is the point: you *cannot* "undermine" it!
 when the adminitrator wants to block RTP traffic  he will,
because he can and it is *very* easy!!!!!!

my original point was that:

(A)in order of priority for operators "NAT comes first" and then
"someone wants to fix the RTP problem" specifically we are told:
"ok, there is this NAT, and we want to deploy
VOD using RTSP, what do you propose ? "

(B)Telling them to start a procedure (internal or external or both!)
that would lead to transforming that NAT is not a good idea,
*especially* since you cannot guarantee it will work  in all cases!

But we will have to influence "them" in at least one respect,
it must be documented somewhere that:

"Symmetric NATs SHOULD be configured so that a given RTP
client is attributed the same public IP address as the corresponding
RTSP client"

(if there are NAT implementors online can they please comment on that?
it does not look like a very difficult thing to implement ?)

Because otherwise whenever the symmetric NAT will allocate different IP addresses
the RTSP server will *have to* deny the service for DDOS prevention.

>NAT traversal is intended to work around the limitations in common NAT
>implementations.

not enough for me,
I want a solution for all NATs, forever.

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 21:07                                                                                                        

On Wed, Feb 26, 2003 at 07:26:15PM +0100, [email-masked] wrote:
> 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 ?

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.

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

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

> 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 ?-]

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.

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

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

---

From: Tom Marshall <[email-masked]>
Date: Thu, 27 Feb 2003 09:26:50 -0800

> because he can and it is *very* easy!!!!!!

Am I the only one here that reads the same argument for 3093?

  the plan is not  to undermine "administrative control",
  because and *that* is the point: you *cannot* "undermine" it!
   when the adminitrator wants to block 3093 traffic  he will,  
  because he can and it is *very* easy!!!!!! it's a simple matter
  of blocking the "TCP_*", "IP_*", "IP4_*", and "IP6_*" headers!!!

> client is attributed the same public IP address as the corresponding

I have yet to see an example where a client was assigned different public IP
addresses for RTSP and RTP connections to the same server.  Rumors keep
flying that they exist so I'll assume they do.

I like this recommendation -- it should always be the case anyway.  If it's
not, the NAT is being unreasonable.

> it does not look like a very difficult thing to implement ?)

Yes, please.  Does someone run a NAT where a given (client_ip, server_ip)
can be mapped to more than one nat_ip?

> the RTSP server will *have to* deny the service for DDOS prevention.

I am wondering if you are equating "symmetric NAT" with a NAT that maps
clients to multiple public addresses.

My understanding is that symmetric NAT is a more strict case of general NAT. 
The difference is that a general NAT maps a given NAT port based on the pair
(client_ip,client_port) and a symmetric NAT maps a given NAT port based on
the 4-tuple (client_ip,client_port,server_ip,server_port).  Am I mistaken?

> I want a solution for all NATs, forever.

I want world peace, too.  And no more spam.  And ...

Seriously, there is no all-encompassing solution.  Why not?  Because NAT is
the general name for a family of hacks with no formal specification or
interoperability requirements.  As soon as you design a solution that you
think covers all NATs, someone will build a different NAT that breaks your
solution.

Symmetric RTP and multiplexed STUN/RTP are functionally equivalent for NAT
traversal and they are the best solution you will find in the forseeable
future.

-- 
Any sufficiently advanced technology is indistinguishable from a rigged
demo.
        -- Andy Finkel