Local address announces

[Rob Townley]

Are the two nodes hooked with a cheap switch or a managed switch?
Cheap switches often deal with multicast better.  DD-WRT and many
other soho routers have an option to block multicast packets.

On 8/25/10, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 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>
>