On Fri, Jul 18, 2008 at 10:42 PM, Florent Daigni?re <nextgens at freenetproject.org> wrote: > Yesterday I have implemented and committed the naive > implementation of foaf into the trunk... (foaf routing : > http://archives.freenetproject.org/message/20080707.111733.13824377.en.h > tml) > > I am reluctant to enable it by default as they are some major security > implications. As far as I understand, the logic was: "the swapping > algorithm can already be subverted by an attacker to extract our peers' > location... hence implementing foaf won't harm much: it will just > provide more accurate data to a potential attacker". > > Foaf-routing is about two things: > 1) publish our peers' location > 2) use the intelligence our peers provide us to route more > effectively > > While the old logic covers point 1 it doesn't cover point 2 and we have > to ask ourselves how point 2 can be used by a bad guy... > > The obvious attack scenario is: > The attacker has a direct link to my node. For his attack to > succeed he would like to capture all my outgoing traffic (in > which case it's obvious I don't have any anonymity). It is > trivial to do on a foaf-enabled node; The routing algorithm > always route to "the closest location it can find"; The bad guy > can advertise several locations for his node (pretending he is > peered to some nodes who have the locations he wants them to > have). The bad guy also have an accurate view of my peers' > location as I have cleverly sent them to him... > > If he advertises two peers for each of my peers with a location ^^^^^^^^^^^^^^^^^^^^^^^^^
not "two peers for each of my peers", but "two peers for each of my peers' peers". i.e. 20 * 20 * 2 = 800 For he does not know my peers' peers, this is not that easy. (although this is still possible, when combine with the information from location swapping) Do you feel better with this? > slightly closer and slightly further on the keyspace (say +/- > 0.000000001), my node *will* send every requests to his node! > > It's obviously a problem we will want to address somehow... > > One option is to limit the amount of locations he can advertise. It is > an inefficient mitigation measure as he doesn't need many of them: the > average node has 20 links... so he would only need to advertise 2*20=40 > locations to cover all the keyspace. > > An other solution would be to compute the proportion of the keyspace > each node controls... That would be an efficient mitigation measure... > Moreover we could use that metric to determine whether a clustering > attack is going on or not... and decide whether we should randomize our > location or not. Of course it means introducing some more alchemy into > the algorithm and the code... but I don't regard the current solution as > acceptable. > > Can anyone think about some other mitigation measure we could use? > Is anyone willing to run some simulations and find out the magic-values > we are going to use in the mitigation algorithm? > > NextGen$ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIgKvgU/Z/dHFfxtcRAqYxAKDFNoTSn7vWVqadEWYlx4SwMB64DACgqPxS > v+fnY1n9ziLzcS5QRahHKow= > =L2XY > -----END PGP SIGNATURE----- > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
