Am Montag, 7. Januar 2013, 18:11:14 schrieb Matthew Toseland: > > wouldn’t the pre-insert keys never be requested, so they would drop out > > anyway after 14 days on average? (following digger3’s stats)
> Yes. I didn't think it was that bad though. :| I don’t think it’s really bad. It is an essential property that stuff which noone wants is forgotten. I would prefer to have the 50% limit at 30 days, but even the current state is quite good: Stuff inserted a week ago can be accessed. And every download resets the clock. So something has to be uninteresting to people for more than a week to drop out. And thanks to our new messaging tools (Sone, FMS, fli(rc)p), that does not happen that often anymore. > Right. So we can simply impose a minimum store size of say 5GB, and this > attack gets pretty hard. With that minimum size I could not run my current node… (I have everything on a ram disk, and I only have 8GiB of memory). So I obviously don’t think that this would be a good solution :) But even 1GiB is pretty much to displace - and if you do not know the store size, you have to displace 90% of the mean store size to have any measure of reliability in your attack. > > And as soon as the upload has been downloaded, it is in the cache and the > > attack is useless, because downloaders can heal the inserted key. > I'm not sure I follow your scenario here. It takes longer to displace a key > than to reinsert it to a different key? No: Even if they displace the key, it’s still in caches, so people can still get the data. But I think I forgot, that it is not reinserted, when the request succeeds from cache… For multi-chunk files that would work, though: Once one chunk isn’t in the cache anymore, it will be healed on download. > > The attack tries to make all nodes around you send you inserts all of a > > sudden, so the write rate has a massive spike. Smooth that spike and the > > attack is mostly useless. > So if our store rate suddenly spikes, we route the inserts anyway, but > randomly refuse to store? We can't selectively reject inserts because > backoff doesn't care whether it's an insert or a request... I'm not sure > whether exploiting such a countermeasure would be a cheap way to DoS > requests by causing us to backoff? I assume we cannot just tell another node to handle the insert (I am not the location you seek :) )… because that node would just return the insert to us. Essentially a fan-out: If the shit hits the fan… (couldn’t resist that :) ) That would mean that an attack would lead to worse locations for inserts. --- snip --- I only partially understood the rest. Especially I did not understand the advantage of #3 over #4. For example I don’t see the problem with the UI in #4: “veiled upload in progress” … “lifting the veil”. Or easier: “hidden upload in progress”…“revealing”. That would turn our current 2 stages into 3 stages: - compressing/splitting/encoding - uploading - revealing That would even make it easier to explain, why you only get the keys when the insert has finished :) I cannot really solve priorizing (not sufficient knowledge), but at least I can ask questions: - What’s the attack we want to stop right now? - What’s the easiest way to fix it (in terms of necessary development time) which does not lead us into a dead end? Best wishes, Arne -- Ich hab' nichts zu verbergen – hab ich gedacht: - http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
