Local address announces

[Guus Sliepen]

Hello Daniel,

Sorry for the long delay, but I now have set up a test environment for your
multicast patch.

> I've attached something like a commit message (I think).
> Sorry, but I am not familiar with git and currently familiarizing with it.

Great!

> In the meantime, I fixed some code and introduced a compatibility wrapper to
> allow porting tinc to "Fritz!Box" (using Freetz http://trac.freetz.org/).
> The file is called ifaddr-compat.h/c and wraps the function "getifaddrs".

That's also very nice. I have a Fritz!Box so I can try Freetz out as well.

> > Why the need for a response message?
> Because a simple "announce/broadcast" can't be authenticated, thus, an
> adversary could announce that he's a legitimate endpoint.

It can be authenticated, just like you do with the multicast response. Of
course, you need to know which key to use to create the signature. At the
moment you are broadcasting at a fixed interval (every 10 seconds). Instead,
you could send a signed announce when you are sending PMTU discover packets to
another node.

> Although this would not allow the adversary to decrypt packets,
> communication between nodes could be interrupted.
> By requesting the nodes to answer by encrypting the challenge, a safe
> authentication can be achieved.
> Since the challenge is random, no replay attacks can be performed.

Well, there is a replay attack where an adversary that has access to both LANs
bridges only the multicast packets, tricking the nodes to think they are all on
the same LAN. But you cannot really stop that.

Ok, on to the testing. First of all, the compiler failed when I applied the
patch to my git tree, because you removed the contradicting edge detection
code, but not completely. It would be very helpful if you could keep a tree
where the only changes you make are those related to the local announcement
feature. But perhaps this was caused by copying some files from the pre-git
work to your git checkout?

Second, tinc immediately segfaulted on my systems. The cause was
src/multicast.c line 141, where ifa->ifa_addr was dereferenced, but
ifa->ifa_addr was NULL. I added a check for this, skipping such struct ifaddrs.

After that, I had two nodes behind a symmetric NAT, connecting to a third one
without a NAT. As expected, the third node forwarded information about the
externally visible IP addresses and port numbers the first two nodes had
(namely that of the NAT device), and they could not contact each other
directly. I also saw multicast UDP packets being sent to the LAN from both
nodes, and they were received by each other's network interface. However, the
multicast packets were not seen by tincd. Not even select() was triggered.  I
cannot see anything wrong in the code, and also not with the configuration of
the nodes. Do you have any ideas?

-- 
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/20100825/e73e071a/attachment.pgp>