[tahoe-dev] keeping private grids private

[Brian Warner]

On 3/9/12 7:39 PM, Vladimir Arseniev wrote:

> Let's say that we have a private grid, with both local and hosted
> servers. But our introducer.furl falls into the wrong hands, and
> uninvited nodes start appearing. Maybe they're just leeching storage.
> Maybe they're disrupting the grid through flapping, running deep-check
> all the time, or whatever. Maybe they're actively attacking the grid.
> 
> How do we exclude them? Can introducers be configured to accept only
> known nodes? Could we create a new introducer, and circulate its furl
> to authorized nodes? Or would that just create a new grid?

Like Markus said, we're getting closer, but we aren't quite there yet.
The most important fix is to make the introducer.furl actually secret
(currently it's guessable by anyone who knows the tubid): ticket #860 is
related (but I can't find the actual ticket). Once fixed, then keeping
the introducer.furl from falling into those wrong hands will work. It
gives you a sort of secret-frat-party security system: anyone who's in
the club can invite anyone they like, and there's no way to kick someone
out (knowledge of the introducer.furl is irrevocable).

We don't want to add new security measures to the Introducer itself
(like giving it a list of "good" clients so it can ignore the rest),
because we want to get rid of the Introducer entirely. We want to
replace it with a distributed gossip-based system (#68), and you can't
rely on a bunch of gossiping nodes to enforce access-control policies.
So we're looking in different directions to provide the sort of control
you're looking for.

The next step is the explicit-server-selection work: #467. When that's
done, each client will be able to indicate which servers they want to
use, ignoring rogue servers. That will fix the availability problems
(servers connecting, accepting shares, then disappearing). The
configuration of this is still a matter of debate: one approach is to
list the pubkey of the servers you want to use, but that can be
labor-intensive for larger grids, and makes it hard to share files if
the uploader uses a different list than the downloader. Another approach
is to delegate membership to a "grid manager" of some sort: more moving
pieces but probably easier to use.

The step after that is part of Accounting (#666), in which servers
reject operations by unauthorized clients. This would include both
storage (leeching) and network bandwidth (downloading shares, running
deep-check, etc, but not basic DoS).

But for now, yeah, IP-address filtering is a good quick answer.

cheers,
 -Brian