On Tuesday 08 Jan 2013 10:09:57 Arne Babenhauserheide wrote: > 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.
Yes, I thought it was more like 30 days. We do have plans to investigate this... We don't do LRU, we do random replacement, but still, "every download resets the clock" is probably approximately true thanks to healing. > > 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. Exactly. IMHO there is an argument, for anti-censorship purposes, for a minimum store size measured in gigabytes. I'm not sure what it should be however. > > > > 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. Provided it's in the caches near to the target location. > > But I think I forgot, that it is not reinserted, when the request succeeds > from cache… Successful requests are reinserted randomly. Reinserting every time we have a hit from cache would be rather costly - the point of the cache is to limit the impact of popular content etc. > > For multi-chunk files that would work, though: Once one chunk isn’t in the > cache anymore, it will be healed on download. Right. Although healing is usually not comprehensive. > > > > 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. We will usually continue to route it anyway. But we won't store it, meaning it has less redundancy. > > 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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
