Integrating libnatpnp and miniupnpc into Tor

[Steven J. Murdoch]

Currently Vidalia is using miniupnpc [1] to automatically configure
port forwarding on UPnP compatible routers, but this means that people
running a headless Tor instance are out of luck. This is particularly
bad because it is likely that the most reliable potential Tor
bridges/relays are headless.

So as to help support the draft proposal on automatic bridge promotion
[2] Jake and I've been working on adding UPnP and NAT-PMP support to
Tor, so as to allow Tor bridge and relay operators to automatically
configure their NAT router to port-forward. For NAT-PMP we are using
libnatpmp [2], which supports Apple hardware, and miniupnpc which
supports most of the rest.

The branch where this is work is happening is being maintained by
Jake:

 https://gitweb.torproject.org/ioerror/tor.git/shortlog/refs/heads/natpmp

Currently it is only a stand-alone utility, but eventually the plan is
to integrate it into Tor. Before we do so there are a few design
options that we should consider.

The first is how the library will be called by Tor. One option is to
call it from the Tor main thread. This is simple, but has the
disadvantage that a bug in the library could cause Tor to crash. This
would annoy the user, but on the other hand a Tor bridge without port
forwarding being set up isn't much use.

Another option is to fork() off a new process. This would insulate Tor
from crash bugs, but isn't as robust security-wise because the
subprocess would have read-only access to Tor's memory (unless we
fiddle with page table permissions).

Yet another option would be to fork() and exec(). This might be tricky
to get right because Tor would need to find where the helper program
lives. It would give some security isolation, but not much because the
subprocess would still be running under the same user ID.

Another choice we have is how to manage the build process. Neither
miniupnpc or libnatpmp come with binary packages for major Linux
distributions. Asking people to build these before building Tor might
be too much to ask (especially given that they don't use autoconf).
Also we might want to keep the version we use under our own control
because in the past the library has broken API compatibility and their
build scripts currently don't work on all platforms (notably the BSD
family).

For these reasons both Vidalia and the Transmission BitTorrent client
keep versions of the libraries in their own source tree, and update
from the upstream periodically. At least for Vidalia, the build of the
libraries is done using the same build tool (Cmake) as the rest of the
code and we could do the same with autoconf. Having to track an
external library isn't great, but it might be the best of the
available options.

Any comments?

Steven.

[1] http://miniupnp.free.fr/
[2] http://miniupnp.free.fr/libnatpmp.html
[3] https://gitweb.torproject.org/sjm217/tor.git/blob/xxx-automatic-node-promotion:/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt

-- 
http://www.cl.cam.ac.uk/users/sjm217/