[tahoe-dev] Building a more resistant introducer

[Brian Warner]

>> Incidentally, we should only run one introducer at a time. Clients
>> will attempt to connect to all of the FURL's "connection hints"
>> simultaneously, and the first correct response will win.
> 
> Oh, interesting, I was sure this process was sequential. That's even
> better because it makes the attack of creating a rogue introducer by
> someone having access to one of the DNS zone present in the furl much
> more difficult. This rogue introducer needs to have lower latency than
> the regular introducer to be able to attract a majority of the nodes.

The "tubid" portion of the FURL (the first long crypto string, before
the @ sign) prevents completely "rogue" introducers: clients will only
accept a connection with a server that proves ownership of the
corresponding private key. Foolscap is designed to provide full
end-to-end security, regardless of attacks at the DNS or IP level. The
worst that a network-side attacker can do is to prevent you from
connecting to the right server; they can't trick you into connecting to
the wrong one.

The connections are done in parallel both to speed things up and to get
a slight form of path optimization: since the first correct response
wins, it favors shorter paths. If you have multiple location hints, and
one of them goes through a proxy or something (or the server lives on
the same network as you do and one hint is for a local address and the
other is for a global one that goes through a NAT port forwarding or
something slow), then the faster hint ought to win, resulting in a
slightly faster connection for the real data that follows.

> I'd prefer if you call it 'volunteergrid.lothar.com' so we won't
> confuse the VolunteerGrid with the TestGrid which runs only on
> allmydata.com servers.

Sure thing.. I wasn't sure which grid this was for.

It might be appropriate to *not* set up DNS pointers for the other
connection hints. If the primary introducer location (let's call it
server[0]) is on francois' machine, and the hint[0] name gets resolved
by a DNS service on the same machine (as would be the case for my
volunteergrid.lothar.com server), then they share fate: if hint[0] can't
be resolved, then server[0] won't be reachable anyways, so you don't win
anything by making hint[1] point to server[0]. If/when server[0] goes
down, the hint[1]-or-hint[2] name and server[1]-or-server[2] machine can
be brought up. This would also reduce the delay incurred by a cached
hint[1]->server[0] mapping sticking around for a while, so we could use
a kinder 24hour DNS TTL.

It'd also be ok to always map the hint[1]/hint[2] to real IP addresses
and real ports (for server[1]/server[2]), which just don't happen to be
running yet (and wouldn't be started until server[0] goes down). The
Foolscap connection mechanism will handle that fine: it'll get
Connection Refused from those hints and ignore them.

If we wanted to crazy, we could create a meta-introducer: run all three
servers at once, let clients connect to one at random, use the
meta-introducer to introducer the regular introducers to each other, and
flood announcements through all of the introducers. But we might as well
do it right and implemented the distributed introducer properly.

cheers,
 -Brian