Yet a different perspective on NAT

There has been some discussion on the list on the question if 
there are workarounds how 2 peers behind a NAT can communicate.

I did some research / have been told by better informed people
that this is often possible for UDP with todays NAT routers.
But it can be made impossible and the ISP/telco/record industry and 
surveillance agencies complex has a vital interest to make it as 
impossible as they can. So in the end John Walkers analysis remains valid.
On the other hand are even RFC's defining NAT traversal protocols
for IPSec.

It is nice if some of you can overcome this problems with NAT routers
they have control over. But this is not the issue here.

In the following I try to put the facts together in a short summary.

1. Firewall priming is possibe.
   Let us assume both sides sit behind a NAT router which can 
   handle UDP "connections", i.e. if i send UDP to 
   IP Adress a.com, Port 123, then UDP Packets from a.com, Port 123
   will be forwarded back to my machine to the port i send the first
   UDP packet from. This allows us to "prime" the firewall to set
   up a temporal port forwardings. If we send UDP to several IP
   Adresses/ports, we should be able to set up a lot of such 
   port forwardings.  This was the good news. The bad news is: 
   it will not be enough if both peers prime their firewalls.

2. Peer A sends UDP to the exterior NAT adress of peer B. He needs
   magic advice to guess which external destination port number to 
   use for peer B.

3. Peer B will not get this package, but A's firewall sets up a port
   forwarding rule. Now B needs to get magic advice to know what the
   external source port number of Peer A was. If he has, Peer B can
   send UDP to this Port in Peer A's NAT, and the connection is done.

4. Note, that we need magic help 2 times. In fact we can use network
   probes (UDP traceroute) to figure out the NAT port/adress our
   outgoing pakets get. BUT note, peer A even has to guess, which
   port/adress peer B WILL get, when sending UDP to the port/adress
   pair, A's packet WILL have after NAT. In General this task is
   impossible. 
   If we know a pattern of port/adress allocation, (i.e. just
   incrementing port numbers), then we will be able to guess correctly.
   We can try to pre-prime a range of port adresses in our NAT router by
   sending UDP to a whole port/adress range on the peers side. This
   would allow peer B to send UDP to us from all the port/adress
   combinations we have sent UDP to.  This may make guessing possible,
   but it will raise Intrusion detection alarms in the NAT router.
   
5. Bottom line
   If one or both sides have special knowledge of a regular port/adress
   allocation pattern of their NAT router AND have a connection
   via a third party, they have a fair chance to get UDP peer to
   peer communication. If both NAT routers have a big enough port/adress
   range and randomize port/adress allocation the chance is zero
   whithout agressive search strategies that could be detected by
   IDS systems.

   There is no simple and robust NAT traversal strategy that would help
   the big majority of users.



                      * * *

To unsubscribe from this mailing list, send E-mail containing
the word "unsubscribe" in the message body (*not* as the
Subject) to [email protected]