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
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$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080718/1c630c2c/attachment.pgp>
