[tahoe-dev] switching from introducers to gossip?

[Nathan]

On Tue, Jul 3, 2012 at 8:17 AM, Zooko O'Whielacronx <zookog at gmail.com> wrote:
> On Sun, Jul 1, 2012 at 9:51 PM, Brian <warner at lothar.com> wrote:
>>
>
> ... snipping out a lot of useful, clearly written details about the
> new introduction and accounting mechanisms ...
>

[... snipping even more useful discussion to focus on firewall traversal tech.]


> • How to handle NAT/firewall/inconveniently-behaving-router? Nodes
> utilize the latest and greatest Romulan packet technology, such as
> UPnP (#49), "NAT hole punching" techniques (#169) or even µTP (#1179)
> or relay service (#445) to breeze through such impediments as though
> they weren't even there.

Missing from the list of firewall hopping technologies: tor hidden services.

I advocate a name change to this technology to emphasize it's feature
list.  Tor hidden services are:

* A firewall traversal mechanism.
* A highly-available addressing mechanism.
* A self-authenticating address.
* Possibly (see below) a connection-capability.
* "hidden"

It seems people are only aware of the last feature because of the
poorly chosen name.  IMO, the "hidden" aspect is one of the less
interesting features.  I've heard a rumor that there's a proposal to
make a version of this feature which provides the other features
without the hidden part for the benefit of lower latency.

I'm going to start calling them "tor firewall-traversing, highly
available, self-authenticating, potentially
connection-capability-offering addresses for services that also happen
to hide your IP address."  ;-)

As for connection capability: onion addresses are an 80 bit substring
of a public key hash, so that's 80 bits of unguessable [1].  The
design doc [2] does not mention a goal such as "undiscoverability"
which would be necessary for capabilities (ie: You can only learn an
onion by generating one or being told one out of band, but not by
sniffing tor introducer or directory service traffic).  However, from
chatting with tor devs I believe this may be an implemented feature.
I'm still browsing source code and specs to see if that's true.

The address-to-connection resolution mechanism should be highly
available because it's based on a decentralized table, and there are
many nodes already running this dht.  On top of this, the devs and
operators highly prioritize censorship resistance.  (For other
newfangled firewall hopping technologies, how many users are there? Do
they care about resisting censorship attacks?)

The trade-off for these features is latency, the overhead of running
tor, and the packaging/runtime dependencies.  I believe tor has low
overhead in CPU/RAM, but don't bet your system's robustness on this
belief.

I'm not familiar with i2p which may have something similar.  (Could
the i2p people here share any overlapping features so that we can
determine what, if any, changes to tahoe could improve integration
with both technologies?)


[snip...]

> If you want "sysadmin-friendly software" then you probably want the
> opposite of all these features!

For using hidden services as a firewall hopping feature, one approach
is to bundle tor as a dependency (when this feature is required), and
to launch tor and automatically generate hidden services with it (if
the config file says to do so, and other nodes support this approach).

In that deployment, the user configuration management is minimized.
Instead of spitting out vanilla furls, there are onion-furls.  The
user experience could ideally be quite similar to the case without
this feature.

[snip stuff about which tahoe services to run and sysadmin control
over ports and connectivity...]

> Don't get me wrong -- I think the p2p style, which foolscap already
> implements part of -- is sweet. I'd like to improve it, in the
> interests of making Tahoe-LAFS deployment more automatic for
> end-users. However, we should probably pay attention to the fact that
> many of our current users do not use those features, and some of them
> are actively requesting the ability to turn off those features.

Which features do they want to turn off?

>
> Maybe some kind of friendly fork or more targeted packaging would help
> us manage these diverging deployment scenarios?
>
> Regards,
>
> Zooko
>


Nejucomo

References:
[1] Hidden service rendezvous spec:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt
[2] Tor design of hidden services:
https://svn.torproject.org/svn/projects/design-paper/tor-design.html#sec:rendezvous