[JDEV] NAT Issues

[Charles Forsythe]

Bernd Eckenfels wrote:
> 
> On Sun, Dec 17, 2000 at 02:59:13PM -0600, Charles Forsythe wrote:
> > Why would you not know which port to send to?  The NAT does not change
> > the port number, only the IP address.
> 
> Of course it does.

You're right, it *can*, but it isn't required.  The whitepaper
specifically mentions that the UDP hack only works if the UDP port is
not translated.  I was confused and thought that was in RFC 2663; my
mistake.

> Ever wondered what the number in brackets in the output of netstat -M for
> Linux is?

My NAT is on a Cisco PIX.  netstat -M doesn't output anything on my
Linux system, Mr. Smart Guy.  Anyway, if you'd bother to read the
whitepaper carefully, you'll notice that the author tested the UDP hack
using Linux IP Masquerading.

> Dynamic NAT needs to use unique local ports, it chooses them from
> the range of the local masq ports, usually above 60000.

Dynamic port translation doesn't break TCP services but it does break
some UDP services.  Even without NAT, TCP is already designed to
negotiated connections in which a dynamic port number is assigned.  

UDP is connectionless and this allows a UDP service to asynchronously
receive data from any number of senders.  A two-party UDP protocol, such
as TFTP can negotiate dynamic "session" ports, but a multi-party
protocol, such as the game listed in the whitepaper, must establish a
known listening port as the destination for all packets.  Because UDP is
unreliable, most two-party protocols use TCP connections.  This means
that applications for which UDP's connectionless behavior is most
important will be broken by a NAT that translates UDP ports.  Hence it
is a better design tradeoff *not* to translate UDP ports in a NAT.

The UDP hack is only one of several options to deal with two peers
behind two NATs.  Although it has been shown to work in many real-world
situations, it may fail for several reasons.  One reason is that as a
security "best practice" many enterprises block *all* incoming UDP
traffic.  Another reason might be that a particular NAT does, in fact,
translate UDP ports.  Finally, if multiple peer-to-peer sessions need to
be formed between communities that are both behind two particular NATs,
then it is unclear how the NAT will route the UDP packets.  The external
negotiating server will need to detect multiple peers behind a NAT and
implement a mechanism to assign them each a unique UDP port.

-- Charles