On 31/03/14 19:50, Arne Babenhauserheide wrote: > Am Sonntag, 30. März 2014, 20:41:41 schrieb Matthew Toseland: >> If we ensure that only nodes >> with a proven track record of performance (or at least bandwidth) route >> high HTL requests or participate in tunnels, we can slow down MAST >> significantly. (Inspired by the "don't route high HTL requests to >> newbies" anti-fast-MAST proposal). > If that’s the only requirement, then the fix is trivial: Each node records > for its connections, whether they fulfill the requirements for high-HTL > opennet nodes. > > For example it could route high-HTL requests only to nodes which have at > least 1/4th of its uptime*average bandwidth or are among the 1/4th of the > nodes with the highest uptime*average bandwidth (choose the best match from > that subset of the nodes). > > As bandwidth, ideally only count successfully returned data (so a node cannot > appear to be high bandwidth by just doing many requests or returning garbage). > > The big advantage of this is that it requires no global state at all. > > That would also have a few beneficial side-effects: > > - High uptime nodes are likely to be well-connected. So requests should be > less likely to be stuck in badly connected clusters. > - For new nodes this is essentially random-routing the first steps. > - The effects of churn on the network are reduced, because the requests > quickly get into the well-connected cluster. > > The bad side-effect would be that attacks using long-lived, high-bandwidth > nodes would become easier. For those attacks, the network would effectively > be half as large. But those attacks are expensive, and someone who wants to > do do those attacks effectively has to provide a backbone for freenet which > increases privacy for anything which is not being attacked right now. IMHO the routing effects are fairly serious, but solvable:
When we add a peer we send it low HTL, specialised requests; after a few hours we start sending it high HTL requests which are much further away from our location. This may cause the peer's success rate to drop and it to get dropped in favour of a newbie. Then it comes back ... we get "flapping". But there is a simple solution (albeit one with a certain amount of alchemy): Have two routing tables. That is: - An "established" peer can receive high HTL requests. (And eventually participate in tunnels) - An "established" peer cannot be kicked out by an "ordinary" peer, only by a newly promoted established peer, and only after a grace period. How much benefit it has for security is another question ... There are four classes of attacks: - Fast MAST (bored student class): E.g. predictable splitfile inserts. User is vulnerable because not following the rules! Lots of blocks, only need a few connections to intercept a few, once there Mallory can rapidly approach the target location provided he can change locations. - Comprehensive surveillance (connect to everyone). (Need ~ 1% of the network, can only see big stuff, works against random routing) - Slow MAST: E.g. target is making forum posts. Hours or days between inserts, so the attacker needs a lot more connections. Then he reallocates them once he starts seeing hits. - Statistical attack against random routing: Very similar to slow MAST. Only routing high HTL requests to nodes that have been connected for at least few hours makes the first attack much slower (but still feasible). It makes very little difference to the other three. On the other hand, it may be possible to improve opennet's stability, and to persist our list of "established" peers across restarts of both sides within reason. If we can get it to the point where good nodes require their peers to have been connected almost continually for a week plus, then this would help significantly, and it could have interesting performance properties too, e.g. it might allow us to use Bloom filter sharing on opennet. Note also that *we need this sort of structure for tunnels anyway*: For both security and performance we need nodes that participate in tunnels to be reasonably fast and reliable.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
