On 2014/04/09 (Apr), at 5:24 PM, Matthew Toseland wrote: > On 09/04/14 23:09, Matthew Toseland wrote: >> On 01/04/14 20:10, Matthew Toseland wrote: >>> 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. >> One serious problem with this: If you get a HTL 18 request from a node >> that is not likely to be a core opennet node, what do you conclude? :(
Well... if being a "core node" was both global segregation and remotely decernable, then I would conclude that it either came from the node that handed it to you, or one not very far down the "non core" chain. On did I miss something, that you also assume every non-core node has at least one connection to the core, and will with 100% certainty route a request thereto? Contrawise, I envisioned the core-node test being a bit more relative. e.g. if you could measure all the goodness that *is* a core node using a function (e.g. observed uptime, percentage success, pReject... whatever)... then the core nodes "to us" would be (for example) the top-half of our peers when sorted with that function; and if that function is applied to our own node, then we are a core node if we have at least the value of the least core node. >> >> So maybe we need to wait until we have tunnels ... on the other hand if >> you're directly connected to the target, you can usually identify what >> it's doing anyway ... ??? > In particular, consider the connect-to-everyone attack: > If Mallory connects to every node (he needs ~ 1% of the network, all of > which need to be core nodes), and the target happens to be non-core, > then he can *IMMEDIATELY* identify the target, Bob, when Bob sends an > identifiable, high HTL insert to him - because he doesn't route high HTL > requests for other nodes! Really? Hmm... I suppose that if you replace the relativism with constants (making it a global decision), and if one could trust whatever stats our peers hand us (e.g. number of requests handled, remotely-measured uptime, etc) rather than what we observe to determine if a remote node considers itself to be "in the core"... then yes, I suppose you have exposed what counter-intuitively is a very sensitive boolean asto how a node handles inserts... ...but still, what is the likelihood that Bob would be connected to Mallory? Isn't that already considered a "you lose" situation? ...and also, aren't you saying that Bob would REJECT a high htl request from any of his peers, or only that all of his peers would never give bob a high htl request because he is not a core node? > Whereas in any other case he'd need to do statistical analysis and/or > add more connections to promising nodes. Which is still terrible. So > it's a bit faster once he's got his core nodes. On the other hand he has > to pay time and resources to get core nodes, so it will cost him more to > get the same number of connections. Add to that, I would presume that it would be much harder and slower to "move through the core", or more precisely... to convince a core node that you are also core, than to convince a leaf or non-core node that you are core. In any event, this does not sound much different from the current situation... if you get a non-local (address-wise) GET request, it likely came from the peer that handed it to you. -- Robert Hailey _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
