These are all fairly close together so I'll answer them together. On Saturday 05 Jan 2013 09:39:45 Arne Babenhauserheide wrote: > Am Donnerstag, 3. Januar 2013, 17:31:12 schrieb Matthew Toseland: > …seednodes… > > This is fairly complex and will eventually run into scalability problems. > > That’s exactly what I thought. Also it sounds too complex for a decentral > system. Interaction between many nodes is already complex enough with simple > systems… > > Also central points of failure and control are bad™. > > Isn’t there a simplest possible way of achieving the same? > > Best wishes, > Arne
Some principles before I get into detail: 1. I'm not talking about darknet here AT ALL. I'm only interested in opennet: The case where we have no Friends, we just want Freenet to work out of the box. Ideally we would like it to provide a reasonable level of security in this case. Maybe we can make darknet so easy, and freenet so popular, that opennet is unnecessary; certainly we should try that first before spending a lot of effort securing opennet. But that's not what I'm interested in here. 2. Opennet is ALREADY a supernode-based semi-centralised network. The supernodes are pretty dumb and are only involved in bootstrapping. But in order to get online for an opennet newbie node, or for an established opennet node after significant downtime, *you need to talk to the seednodes*. 3. I agree my proposals are complex. However fully decentralised solutions are generally even more complex, and often less reliable. And see #2: Opennet is already centralised, we cannot make it FULLY decentralised. I explain below why it is tempting to make it a little more centralised. If Freenet is illegal, there will be only darknet; opennet can be blocked simply by blocking the seednodes' IP addresses. And keeping secret the full list of seednodes isn't a good solution either, if we give them out then they can be found. 4. Nothing proposed here or below impacts on requests. We are still talking about bootstrapping, announcement, and long-term maintenance here. Freenet will *never* involve centralised lookups of actual keys. Fundamentally, the classic peer-to-peer strategy is "safety in numbers". Unfortunately this is nonsense. It is just way too cheap to run large numbers of nodes: A small network can be overwhelmed cheaply, and the costs of overwhelming a large network are not that much bigger because of economies of scale - and the rewards are greater. On Saturday 05 Jan 2013 09:07:14 Arne Babenhauserheide wrote: > Am Donnerstag, 3. Januar 2013, 17:31:12 schrieb Matthew Toseland: > > - Create lots of (malicious) > > nodes cheaply/quickly. That probably means a single datacentre/host, i.e. > > on the same AS. > > Am I right in thinking that this is likely hard to distinguish from 1.000 > students in a single university suddenly starting to use freenet? No. 1000 students don't suddenly join Freenet: They would likely do so over a period of time. And if they did join quickly, in some sort of orchestrated campaign, they'd probably use darknet. On the other hand, the cheapest, least visible model for an attacker is to create a large number of nodes very quickly, probably using a single ISP/datacentre/Autonomous System Number, hunt down the target, and then take the nodes (and the target!) offline. Our minimal objective would be, in the ideal world, to detect this, and thus force them to run a number of nodes over a longer period, preferably across multiple AS's, thus increasing costs considerably. In principle we can detect this, but only as a spike in identity creations or announcements on a single AS. The problem is: - Some AS's are, with manual inspection, much more likely to host such attacker clusters than others. E.g. cloud providers. - AS's vary in size. We can deal with this by establishing a baseline. - Press coverage can create spikes over a subset of AS's. In some languages press coverage might only affect a handful of AS's, so is hard to distinguish from an attacker. But if we get press coverage we want Freenet to work for the people seeing it! Hence, even if we know both how many announcements and identity creations are happening and approximate uptimes of the resulting nodes, it is probably not realistic to detect or deter these sorts of attacks purely automatically, let alone in a fully decentralised fashion. So some degree of central control (as well as central monitoring) is tempting. How the policy/governance works is an important question, but it's not worth asking until we know what the tools are. On Saturday 05 Jan 2013 10:00:19 Arne Babenhauserheide wrote: > Am Donnerstag, 3. Januar 2013, 17:31:12 schrieb Matthew Toseland: > > MAJOR ATTACKS FOR OPENNET (stuff we could maybe limit by tinkering with > > announcement etc) > > > - Announce to chosen location. Component of many easy > > attacks, e.g. MAST, some published stuff. > > Can’t this be mitigated decentrally if nodes only accept a limited number of > new connections from a given location per hour No. What is "the given location" ? It will be different every time: The attacker chooses a location based on either a) wanting to censor a key (announcement allows him to get close to a location without having to fetch and propagate it), or b) trying to trace an inserter (MAST). PS announcements are already throttled. > - and if opennet nodes which > don’t manage to get accepted just change their location? No. Changing location is a really big deal, because it effectively invalidates our datastore. We don't want to do it often. We can maybe make it a bit more efficient, but it's a hard problem. We will eventually need to make some progress on it on darknet, but mostly even darknet nodes don't change locations that often. We have to announce when we reconnect after downtime. We have to announce to our old location (corresponding to our datastore), even if our IP address has changed. So we can't e.g. use location = hash(IP address). > > > - Dominate the keyspace/topology and thus control a large proportion of > > tunnels etc. Controlling the keyspace, or topology, allows lots of attacks against both content and inserters, and even against proposed architectures (e.g. tunnels would likely involve choosing a random node; an attacker that controls the topology or keyspace can ensure that there's a good chance his nodes are selected).
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
