On Saturday 05 Jan 2013 19:38:07 Arne Babenhauserheide wrote: > Am Samstag, 5. Januar 2013, 17:24:03 schrieb Matthew Toseland: > > These are all fairly close together so I'll answer them together. > > That’s fitting, yes… I just wrote them after each other. > > > 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. > > Ah, OK. I’m also interested in the case where we have exactly *one* darknet > friend: The one who introduced us into freenet. If we now introduce someone > else, FOAF does not help, because we also only know one person. But we can > spread opennet noderefs.
Hmmm. True... If we are invited by somebody with darknet peers, we will have FOAFs. Is this a case we want to optimise? I suppose it's fairly important? A related question is is our whole "use opennet until you have 40 darknet peers/FOAFs" strategy acceptable, given you can get disconnected pockets? Should we keep the limits for darknet vs opennet completely separate and have some mechanism to detect when your darknet is "mature" enough to turn off opennet? IMHO while it's pockets we want the option to route only in the darknet before going to opennet ... and maybe even use it at the client layer, so we e.g. try to fetch a whole splitfile from the darknet before we request it on the opennet. Your argument is then that we need to be able to announce from any darknet peer? > > > 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*. > > As far as I understand it, the supernodes do not do much more than GWebCaches > in Gnutella: Spreading IPs. So instead of requiring full freenet nodes as > supernodes, we could use lightweight PHP scripts - which could be hosted by > many different people, but would get static IPs or DNS names by being hosted > on a regular hoster. No, we need to actually communicate with the downstream nodes: we exchange noderefs internally via an announcement. That means there needs to be two-way FNP traffic. It's necessary for UDP hole punching to work. Of course it doesn't always work... > > So even though the current implementation of Opennet is centralized, the > concept behind it is not. It’s just based around having some really long > lived > points of contact. Hmmm, maybe. I'm not sure I follow or agree. > > > 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. > > They might join after hearing a talk about Freenet. (I might be dreaming > here, > though :) ) Local publicity is *possible*. I don't think it would give an *instant* response. And like I said, there would be some darknet hopefully as a result. Also, an AS is a lot bigger than one university. There are only a few tens of thousands of them for the whole internet. Getting finer grained resolution may be difficult. > > If the CCC would ask people at the 30c3 next year to all run freenet, that > could be a significant boost, too. That would likely have the same effect as any other publicity: Lots of new nodes across lots of AS's. No? > > > 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. > > Sounds reasonable, yes. > > > > 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" ? > > The given location would for example be a range from 0.11 to 0.12, If that > gets significantly more new connections than before, the node would only > accept some of them. Maybe 50% more than the hour before. No, we can't do this. We want most of our connections to be close to our location. We do throttle new connections through various heuristics, but it's not really adequate protection, if creating a new node and announcing is free. If the attacker keeps on announcing with the same identity, he'll probably get through eventually. Which means trying to detect when he's using different identities on the same IP probably isn't useful. And it wouldn't help AFAICS: The attacker doing MAST only needs one peer. The attacker trying to surround a node just abuses path folding. We can make surrounding a little more expensive by checking the AS's of peers though; that doesn't need much central support. > > This could also slow down specialization of the network, though… > > > - 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. > > Ouch, yes. Please ignore I ever implied changing locations… > > So throttling must not stop regular nodes, because there is no fallback. There are two separate cases: Creating an identity: There is no fallback, except waiting - but the limits are probably strict enough that they may have to wait quite some time. Users are expecting an immediate response. However, we CAN tell them that there is a DoS attack going on on their ISP. Announcing: User may not be present or may be busy. We can simply retry. > > (reminds me of my old idea of having two locations, than any attack would > very > likely only affect one of your locations but not the other…) You'd need separate sets of peers. You'd be running two nodes. What's the benefit? > > > 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). > > Is that what pitch black does? > > How’s the status of our fix on that? Pitch Black is a DoS attack against swapping on darknet. There is a proposed fix. A student was supposed to be doing a project on it. He sent an update saying it worked but he wasn't ready to publish yet, some time last year. He hasn't contacted me since then. :( IMHO we could deploy the fix, or at least write our own simulator to test it ourselves. The main difficulty with that is I could never get my head around exactly what the Pitch Black attack was algorithmically. I'm sure I could deal with it now given enough time though...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
