[tahoe-dev] Can Tahoe works well in this scenario?

Brian Warner warner at lothar.com
Mon Dec 6 02:33:41 UTC 2010


On 12/5/10 7:21 PM, Greg Troxel wrote:
> 
> Brian Warner <warner at lothar.com> writes:
> 
>> Oh, using socks as a *listening* proxy, instead of a connecting proxy?
>> Interesting, I'd completely forgotten about that feature.
> 
> My hidden agenda is tor hidden service support :-)


That's an awesome agenda. With 'tsocks' it probably works already: we've
resolved a couple of tickets for that purpose already. As far as Tahoe
is concerned, it's listening on a localhost-only socket, but advertising
the .onion address in tahoe.cfg:[node]tub.location . Tor is configured
to publish a hidden service and knows about the local listening port.

Jake Applebaum was working on some patches to make a simple "be private"
flag in tahoe.cfg, which would check the rest of your config for any
options that might expose your IP address. He's very keen on Tahoe+Tor
too.

> Until now I had been blissfully unaware of UPnP, but having read the
> wikipedia article, it seems promising -- if a tahoe node can find the
> public IP and make a port mapping, it can register correctly and
> function, which would be a big win.

UPnP is a curious beast. I usually dismiss it as one of those
Microsoft-developed specs that only survived the first brush with real
engineers because it has all of Microsoft behind it. As protocols go,
it's horrible: HTTP, XML, JSON, and three other protocols all smushed
together in one underspecified nightmare. 5 years ago, the paper that I
read said that lots of home routers claimed to support it, but only a
small fraction had usable implementations (the others would simply fail
to establish a connection). I'm hoping things are better these days, but
I haven't looked into it personally at all.

But given how common it is in home routers, a successful implementation
in Tahoe will probably get us more NATted servers than any of the other
options. There are a few additional pieces we'd probably need: UPnP will
set up a forwarding from an external IP address to our internal server,
but we also need to learn what our external IP address *is*, so we can
advertise the right one. We also need to learn when it changes, and we
must be able to update the advertisements in a timely manner.

Re IPv6: yeah, I really want Tahoe-over-v6 too (it's blocked on Twisted,
followed by a blocker on Foolscap). I don't think it's going to help
NATted servers much, though. Yes, if you're one of the three people on
earth who've successfully configured a v6 tunnel, then it effectively
gives your internal machines a public IP(v6) address. But the number of
people whose NAT problems will be solved by v6 support is tiny.

cheers,
 -Brian



More information about the tahoe-dev mailing list