On Thursday 04 November 2010 21:12:33 Robert Hailey wrote: > > On 2010/11/04 (Nov), at 3:06 PM, Ian Clarke wrote: > > > On Thu, Nov 4, 2010 at 2:09 PM, Robert Hailey <rob...@freenetproject.org > > > wrote: > > As best I can see, then, there may be major problems with the > > current announcement and path folding implementations: > > (1) announcements gather at non-destination points (in fact, shallow > > first), > > (2) the RequestSender logic will always eat an incoming path folding > > request if we want a peer (often for very short paths), > > (3) the RequestHandler logic will probabilistically drop an incoming > > path folding request (about once every HTL) > > (4) if path folding request is dropped (or not wanted), an > > intermediate node might forward it's reference instead > > > > I think the behavior of 2, 3, & 4 are more likely to be making the > > peer-clumps, which (as you said) might not be a horrible thing. But > > I think all of these points go against the original intent of > > destination sampling. > > > > I think the behavior of 1 (this patch) is forming a specialized > > "backbone" of routability around the seed nodes. > > > > This looks interesting, is there a way we can test your hypotheses > > in a controlled way? > > > > Ian. > > That is a great question. > > We can test the low-level operability of the announcement change (to > make sure the patch doesn't break anything). We might also be able to > drum-up a histogram stat for announcement replies (if toad is > concerned for long links).
That would be interesting yes. If there are way too few far off locations due to the nodes near the seednodes being overloaded that could be a problem, although I'd expect it to be corrected eventually, and IMHO it is far more important that we get the many short links than the few long links... > I already suggested comparing routing stats > from seed & common nodes. One important difference is most seednodes do very few local requests and so have a very low payload percentage. At least that's been my experience. :| > > As for the rest, we can make a test-fix that causes behaviors 2 & 4 to > occur only 1/3rd the time and see if network health improves :) #2: The originator may not even want the peer. Cutting this off will reduce path folding dramatically. It will also reduce anonymity. #4: Replacing the empty ref 1/3rd of the time means it will be replaced after one or two hops. This will make the problem even worse, because the connection will be even shorter. > > The trouble is... I think that announcement & path folding tend to > effect each other, so if we axe #4 (possibly the easiest and most > maleffective feature to disable) I would expect far fewer path folding > connections (i.e. proportionally more announcement connections) and > exacerbate #1. Right, but we could probably compensate for a reduction in path folding by accepting it more often. See below. Plus, while we might accept more announcements, we would not necessarily *create* more announcements, because we only announce when we have min(6, peer limit / 2) peers. > > But in short, I wouldn't change anything till #1 is taken care of, it > is also the most benign-looking fix. See my other email. > > It should also be known that most of these have been put in place to > actually avoid "destination sampling", because then you know who sent > you the data (and you could freely connect to them) Or worse you could eliminate them as a censorship attack. But fortunately all the nodes along the path have already cached the data, so that's not as powerful as it seems. > or know who > requested the data from you. Right, which is much worse. Unfortunately this is another of Freenet's dirty little secrets: Even now, you can exploit this to find who is requesting relatively unpopular content. You need enough nodes to correlate the requests, of course. In practice, mobile attacker source tracing is cheaper (although if people insert as SSK and never reinsert it is limited to chat data and a few samples from correlatable files), and connecting to everyone and doing correlation attacks is more reliable. However, you probably only need hundreds of nodes (perhaps less) to break a very large opennet, provided the files are unpopular i.e. not widely cached. Eliminating all path folding other than literal destination sampling - connecting the originator to the data source - is not justified by theory, since IIRC it was Oskar and Ian who originally proposed the random resets! And it would be really bad for security. There is an argument that if we can improve opennet's performance by moving from being hideously insecure to being hopelessly insecure we should do it to get more users who will eventually build a darknet - but IMHO it is wrong, users come to Freenet because they think it is secure. > There might be some onion routing magic > that could save this, but I doubt it; Full onion routing is not likely to be feasible on Freenet. We could build something like I2P with a DHT so you can select random nodes, but it wouldn't work on darknet, so it's doubtful whether it's worth the effort; and it would of course introduce lots of new vulnerabilities based on peer selection, and we'd have to open connections just for tunnels; it would be very messy and probably not as effective as we might hope. Random rendezvous tunnels are however a reasonable approximation, giving an anonymity set close to the entire network for reasonable cost, and working even on darknet. Unfortunately, it will cost us quite a few hops - likely more than Tor's 3 for a vaguely comparable level of security, probably in the region of 5 - although it could be tunable. My inclination is to enable tunnels on NORMAL and MAXIMUM i.e. if you don't care about security (LOW), turn them off, but also if you are on darknet but aren't excessively paranoid (HIGH). We could also use them only for insert of keys we expect to be linkable, although that doesn't protect on opennet against an attacker connecting to every node, and doesn't protect requests at all. > if you use opennet, you might > just have to rely on the fact that there are very few path-folding > requests (compared to requests at-large) [security through obscurity/ > rareness]. There is an opportunity for path folding after each successful CHK request. We deliberately throttle them by various alchemy in OpennetManager - we don't want to accept requests too often etc. So the argument that path folding is rare is dubious. > > I don't have much time to presently offer, though :(
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
