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 _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE