On 10/04/14 02:03, Robert Hailey wrote: > 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. Global segregation definitely makes it more powerful. We can e.g. limit the number of core nodes on a given IP range. Of course we need per-node performance monitoring as well - once a node has managed to stay in the routing table for some set time period, if it has the global flag, then we move it to our core nodes table, so it can't be dropped because of a newbie, only by another core node newly promoted (this is because we are routing a different set of requests to it now). > 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? The proposal was that we only route high HTL requests to core nodes. So if we don't have peers which are core peers ... do we route to non-core peers? Maybe. Or maybe we don't route at all, and ensure that bootstrapping gets us some core peers? > 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)... "It has stayed connected for X period" is a good summary of all that IMHO, though we may have some arbitrary requirements e.g. for bandwidth usage.
> 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. As I've explained, it needs to be a persistent flag even on the peer level, because it will change the peer's behaviour somewhat. >>> 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... Even if it is on a peer level, it should be possible to observe a peer and conclude that it's unlikely that it has any peers that consider it to be a core node. Or if it does that they are newbies and probably don't go for many hops? > ...but still, what is the likelihood that Bob would be connected to Mallory? > Isn't that already considered a "you lose" situation? True. This makes a terrible attack (connect to everyone and correlate) even worse (in the sense of being significantly faster). > ...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? The latter. >> 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. Yeah ... there's a 50% chance of decrementing the HTL at 18, so you can already identify requests with an interesting level of confidence, and be sure if you can correlate them. If you're already connected to the node you can identify requests fairly easily. Tunnels will greatly improve this. Route high HTL to core nodes would help to prevent easier attacks... For connect-to-everyone in particular, it would be more expensive as you need to setup core nodes, but it would be faster once implemented ... this is true of a lot of countermeasures, e.g. routing requests in bundles (pseudo-tunneling) makes it easier to connect them if you do see the bundle, but much less likely to pick it up in the first place... Thoughts? Is it still worthwhile to do only-route-high-HTL-to-core-nodes first or do we need to go straight to tunnels? And if we have tunnels, do we still need only-route-high-HTL-to-core-nodes or would it be better to rely solely on tunnels?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
