Local address announces

[Daniel Schall]

Hi Guus,


> 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.

Unfortunately, I did not know, which key to use.
Also, I rather wanted to send a "generic" announce that can be answered
by every node on the same LAN, not just one.

> 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.

That would be possible, although I prefer announcing regularly, since
LAN topologies might change (switches can come up down, nodes can
connect/disconnect from a LAN).
If we only announce while doing PMTU, we might miss some opportunities
to connect directly.


> > 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.

The adversary has to bridge the multicast announce, but also the unicast
response to trick the nodes.
I agree, that this is theoretically possible, but do you think this is a
practical attack scenario?

> 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?

Sorry for that, I ran into the same problem yesterday. Seems like I
checked out an older version from git, implemented multicast and copied
all changed files over a newer version of tinc.

Please find attached an archive, which contains my latest version, as
well as a diff patch.

> 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.

Same problem here, I guess the pointer ifa, which gets passed as an
argument to the func getifaddrs(..) has to be NULLed (or a valid pointer
to an ifaddrs struct). The ifaddrs struct is a linked list, and the
pointer you pass in gets appended at the end of the list.
Therefore, it must be initialized to NULL, prior to calling the
function.
I fixed that in the version I attached.

> 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?
> 

Did you set the configuration to "LocalAnnounce = AnnounceAndReceive"?
Maybe it works if you re-compile the version I attached, some bugs
mentioned earlier might prevent tinc from working properly.
Right now, I do not have a clue.


By the way, I tried to commit my changes by issuing "git push", but I
get the error: "fatal: The remote end hung up unexpectedly" :-/
Same if I type "git push git://tinc-vpn.org/tinc"..


Best,

Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commit.patch
Type: text/x-patch
Size: 43612 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20100826/789f7651/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tinc.tar.gz
Type: application/x-compressed-tar
Size: 408566 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20100826/789f7651/attachment-0003.bin>