Thoughts on future upnp/nat-pmp support in Tor

[Jacob Appelbaum]

Hi,

During our developer meeting at the 26c3, we had a brief discussion
about extending Tor to work better behind NAT devices. Specifically,
we'd like to have the ability to configure port forwards for a bridge or
a relay behind a UPnP/NAT-PMP enabled device. Vidalia already does some
legwork to configure port forwarding on devices that support UPnP;
However, some systems do not have the ability to run Vidalia.

Here are two helpful pages to define the terms used above:
http://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol
http://en.wikipedia.org/wiki/Universal_Plug_and_Play

It seems like we have at least two paths forward:

 * Make a port forwarding stand alone program
 * Include port forwarding support in Tor itself

We had discussed possibly building an external helper tool but Peter
pointed out that this won't work well for running a chrooted Tor. If we
want to chroot by default in the future, we're probably not going to be
able to rely on external binaries. This may not be the best way forward.

Roger thinks that it's probably best to fork a (UPnP/NAT-PMP) project,
include it the Tor source and include it in the main Tor binary. If a
user has the local library (and it's newer than the included code),
we'll use their local library. This is similar to what Vidalia is doing
for UPnP support. However, Vidalia is lacking NAT-PMP support and of
course Vidalia is obviously external to the Tor binary itself. I think
adding UPnP/NAT-PMP to Tor may be the best way forward with some caveats.

Adding UPnP/NAT-PMP support to Tor has some possible pitfalls and some
clear benefits.

From a security standpoint, I'm sure that whatever library we use will
introduce code that we will need to audit. If we include it in the
source to Tor, I'm hopeful that someone will audit it. I'm not sure
who's going to step up and I'm certain that it's a lot of work. I wonder
if whatever we choose will even build with our debugging flags? I guess
probably not?

From a usability standpoint, adding this functionality seems like a
fantastic opportunity. The UPnP/NAT-PMP support will hopefully make it
effortless to setup a relay or to setup a bridge.

There are a few different software packages that we can choose from.
Currently, Vidalia uses the miniupnp client library. It seems that the
miniupnp client libraries are a good choice for UPnP/NAT-PMP support:
http://miniupnp.free.fr/
http://miniupnp.free.fr/files/download.php?file=miniupnpc-1.4.tar.gz
http://miniupnp.free.fr/files/download.php?file=libnatpmp-20091219.tar.gz

Both libraries are written in ANSI C and under a BSD license. The code
offered by the miniupnp project supports both UPnP and NAT-PMP. The UPnP
client appears to have a stable release, the NAT-PMP client code doesn't
appear to have had a real release yet. It may be best to introduce two
configuration options as we add support for each protocol:

	AttemptUPnP yes|no|auto
	AttemptNAT-PMP yes|no|auto

I've created a git branch on freehaven called 'attempt-upnp-natpmp'
where I will import the above listed tar.gz files.

I think that it's probably the case that we'll need a proposal for how
Tor's behavior will change. Does anyone want to take a stab at this with
me? I'll take a first pass at this and include it in my branch tonight.

All the best from the CCCB in Berlin,
Jake

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100102/53e40938/attachment.pgp>