friend of a friend type darknets

[Guus Sliepen]

On Sat, Sep 18, 2010 at 12:25:29AM +0200, Alex wrote:

> here a little patch for darknet functionality, i hope it does what its
> intended for sufficiently ... but it seems to work :).
> 
> what should it do?
> 
> imagine your friend-network. A trusts B and C. B trusts D and E, D trust
> F, C trusts G. All trust relationships are mutal
> 
>  A <---> C <---> G
>  ^
>  \
>   \-----> B <---> D <---> F
>           ^
>           \
>            \---> E

You have drawn an acyclic graph, but tinc can work with any kind of topology,
including cycles (in fact, that makes it more robust in case some connection
fails).

> now they want to share some files, but they do not want that untrusted
> users know who shares the files.
> 
> The idea: just route over friend-routes. solution: use IndirectData
> connections of tinc, and connect only to trusted persons.

I don't really see why you want to avoid nodes from connecting to each other
directly. If you use IndirectData, it just decreases the efficiency of the
network. All the nodes can still send data to each other via the VPN.

You could combine this with the DirectOnly option, but that means
friends-of-friends cannot talk to each other at all.

> what was missing from tinc: anonymity. do a killall -USR2 tincd and you
> can see the ips of everybody in your syslog.
> 
> what the patch adds: if FriendOfAFriend is set, then your node does not
> distribute information about the IP and port of other known nodes. so A
> can reach G only indirect, because C does not disclose the real IP of G
> to A.
> A can reach F only over B and D, and because A and B, B and D and D and
> F are friends, the data can still be routed indirectly.

Personally, I do not see any point in hiding a node's public IP and port, while
still allowing traffic to their VPN interface. I would assume that if they are
using a VPN, then their public IP is behind some firewall at least, so I do not
see a security advantage.

The patch itself looks nice. However, you only hide the public IP and port in
send_add_edge(). But you could receive those ADD_EDGE messages back (it is
possible even when you have an acyclic graph), so you need to deal with it in
add_edge_h() and del_edge_h() as well. It is less simple there. Also, when you
have a graph with cycles (for example, G connects to F as well), and not
everyone is using the FriendOfAFriend option, then you will get conflicting
ADD_EDGE messages, which will trigger a never-ending flood of correcting
DEL_EDGE and ADD_EDGE messages.

I do not really see this working for tinc 1.x. The TunnelServer option is
something related to this, but I'm also not so happy with it, although some
people are using it. These options that hide information are just very tricky
to implement correctly.

What exactly do you want to achieve? Anonymity of nodes? What attacks are you
trying to defend from?

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20100919/ee4f4e12/attachment.pgp>