On 01/04/14 19:12, Matthew Toseland wrote: > 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, Sorry, to clarify: "Good nodes" (high uptime nodes) ideally would require their "established" peers to have been connected for a week plus to maintain their "established" status. They can of course have peers which are not "established"; those peers don't receive high HTL requests. > 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. So, priorities for security: 1. Force opennet nodes to not change location. - Opennet nodes don't change location at present; a hybrid node doesn't swap. - Drop opennet peers with prejudice if they change their location. 2. Identify "established" opennet peers and only route high HTL requests to them (and darknet peers). - This makes "fast MAST" much harder, paves the way for tunnels and some interesting performance optimisations. - (Possibly longer term) Try to persist "established" status across restarts on both sides, within limits. 3. Make darknet easy and fast. - This is essential. 4. Implement signed publication/agreement of peers list. - Needed for tunnels. - May be verified by tunnel setup (PISCES) or countersigned by shadow nodes (ShadowWalker), or both. -- If we use shadow nodes, we may need to implement centralised identity creation at this point. -- Is it possible for the node not to know its shadow's IP address? E.g. use tunnels or routed protocol to coordinate? - Include locations so we can check FOAF locations. - Enforce peers limit per node (we need some way to deal with the possibility of excess darknet peers). - Note that this stage may slow down connection churn significantly simply because of the costs and time involved. 5. Implement tunnels on both opennet and darknet. - Greatly improves security; attacker needs 20%+ of the network to compromise most routes.
After that: What can we do to stabilise opennet connections? - What do the stats look like now for established nodes? Can we raise the thresholds? - Is it a good idea? - Workarounds during crises e.g. slashdottings. -- Reduce need during update deployment by staggering updates. Do we want seednodes to assign random locations? - Is there any point? Seednodes have limited capacity; flooding is detectable; limits per IP per time possible ... So maybe ... Can we / do we want to ensure that one IP address can only be used by one node at a time? - Would need involvement of seednodes. - More fuzzy limits (subnets, ASNs) may be acceptable if they only affect "established" status ... but tricky, manual intervention, unreliable? Can we / do we want to track performance of nodes on an inter-node level? - Shadow nodes could probe for node reachability on IP level, or via a routed protocol. - Bandwidth usage could be recorded as part of counter-signing agreement for peers list. - Use it or lose it? Once it's created, if it goes down for more than some period it can't be "established" - attacker can't save up locations for later use. -- Is it possible to probe actual performance? Maybe, but only if connected to non-attacker nodes... Can we increase the cost of creating a node? - Probably not with BTC. Not acceptable to users, and may be << cost of running nodes? - Is there anything else we can do? -- CAPTCHAs are accepted by users but so cheap as to be pointless...? Can we increase the cost of running a node? - Specific performance requirements? - CBR? I.e. minimum transfer per peer regardless of traffic to stay "established" ? Also think about performance enhancements enabled by the above - Bloom filter sharing with established peers. - Local (slow, non-waiting-except-last-node) broadcast of keys to peers in low HTL.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
