Re: Yet a different perspective on NAT

On Wed, 6 Aug 2003, Johannes Poehlmann wrote:

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

There is an article about the surveillance agencies targetting VoIP:
http://rss.com.com/2102-1028_3-5056424.html?tag=ni_print
Its release date corresponds closely with SF EOL announcement.

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

We can cheat by two ways.

The easiest way is to specify the sender port for the UDP packets, to bind
the socket to a predefined port instead of asking the OS for getting
assigned a free one. The disadvantage is that we probably have only one
connection possible then. (Maybe not, I didn't play with such specific
socket binding yet.) This way we could have both source and target ports
set to 2074, and packet would look as from a.b.c.d:2074 to e.f.g.h:2074.

The other way is to use a server somewhere outside. This is breaking the
strict peer-to-peer architecture, but allows a side-channel to exchange
the "magic". It can also work as the who-is-listening server. Unlike the
"packet forwarding" solution for the voice channel, the bandwidth
requirements are next to zero.

This server also can act for diagnostic purposes (eg, the user behind NAT
runs a program that connects by TCP to a script on the server, which then
instructs the program what UDP packets it shall send to the server, and
listens for them, then sends back other UDP packets and lets the program
announce over the TCP connection what packets arrived there. Something
like an automated firewall/NAT test. Exactly the same thing people do with
tcpdump when debugging, just tailored for this one application.


Some firewalls can also be controlled by UPnP from the inside. Typical app
using this approach is MSN Messenger.


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

There is always hope. :)



                      * * *

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