No description
eeebff55c0
This commit replaces the node UDP address hash table "cache" with a full-blown splay tree, aligning it with node_tree (name-indexed) and node_id_tree (ID-indexed). I'm doing this for two reasons. The first reason is to make sure we don't suddenly degrade to O(n) performance when two "hot" nodes end up in the same hash table bucket (collision). The second, and most important, reason, has to do with the fact that the hash table that was being used overrides elements that collide. Indeed, it turns out that there is one scenario in which the contents of node_udp_cache has *correctness* implications, not just performance implications. This has to do with the way handle_incoming_vpn_data() is implemented. Assume the following topology: A <-> B <-> C Now let's consider the perspective of tincd running on B, and let's assume the following is true: - All nodes are using the 1.1 protocol with node IDs and relaying support. - Nodes A and C have UDP addresses that hash to the same value. - Node C "wins" in the node_udp_cache (i.e. it overwrites A in the cache). - Node A has a "dynamic" UDP address (i.e. an UDP address that has been detected dynamically and cannot be deduced from edge addresses). Then, before this commit, A would be unable to relay packets through B. This is because handle_incoming_vpn_data() will fall back to try_harder(), which won't be able to match any edge addresses, doesn't check the dynamic UDP addresses, and won't be able to match any keys because this is a relayed packet which is encrypted with C's key, not B's. As a result, tinc will fail to match the source of the packet and will drop the packet with a "Received UDP packet from unknown source" message. I have seen this happen in the wild; it is actually quite likely to occur when there are more than a handful of nodes because node_udp_cache only has 256 buckets, making collisions quite likely. This problem is quite severe because it can completely prevent all packet communication between nodes - indeed, if node A tries to initiate some communication with C, it will use relaying at first, until C responds and helps A establish direct communication with it (e.g. hole punching). If relaying is broken, C will not help establish direct communication, and as a result no packets can make it through at all. The bug can be reproduced fairly easily by reproducing the topology above while changing the (hardcoded) node_udp_cache size to 1 to force a collision. One will quickly observe various issues when trying to make A talk to C. Setting IndirectData on B will make the issue even more severe and prevent all communication. Arguably, another way to fix this problem is to make try_harder() compare the packet's source address to each node's dynamic UDP addresses. However, I do not like this solution because if two "hot" nodes are contending on the same hash bucket, try_harder() will be called very often and packet routing performance will degrade closer to O(N) (where N is the total number of nodes in the graph). Using a more appropriate data structure fixes the bug without introducing this performance problem. |
||
|---|---|---|
| bash_completion.d | ||
| doc | ||
| gui | ||
| m4 | ||
| src | ||
| systemd | ||
| test | ||
| .gitignore | ||
| AUTHORS | ||
| configure.ac | ||
| COPYING | ||
| COPYING.README | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| README.android | ||
| README.git | ||
| THANKS | ||
This is the README file for tinc version 1.1pre11. Installation instructions may be found in the INSTALL file. tinc is Copyright (C) 1998-2014 by: Ivo Timmermans, Guus Sliepen <guus@tinc-vpn.org>, and others. For a complete list of authors see the AUTHORS file. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. See the file COPYING for more details. This is a pre-release --------------------- Please note that this is NOT a stable release. Until version 1.1.0 is released, please use one of the 1.0.x versions if you need a stable version of tinc. Although tinc 1.1 will be protocol compatible with tinc 1.0.x, the functionality of the tinc program may still change, and the control socket protocol is not fixed yet. Security statement ------------------ This version uses an experimental and unfinished cryptographic protocol. Use it at your own risk. Compatibility ------------- Version 1.1pre11 is compatible with 1.0pre8, 1.0 and later, but not with older versions of tinc. When the ExperimentalProtocol option is used, tinc is still compatible with 1.0.X and 1.1pre11 itself, but not with any other 1.1preX version. Requirements ------------ In order to compile tinc, you will need a GNU C compiler environment. Please ensure you have the latest stable versions of all the required libraries: - OpenSSL (http://www.openssl.org/) version 1.0.0 or later, with support for elliptic curve cryptography (ECC) and Galois counter mode (GCM) enabled. The following libraries are used by default, but can be disabled if necessary: - zlib (http://www.gzip.org/zlib/) - lzo (http://www.oberhumer.com/opensource/lzo/) - ncurses (http://invisible-island.net/ncurses/) - readline (ftp://ftp.gnu.org/pub/gnu/readline/) Features -------- Tinc is a peer-to-peer VPN daemon that supports VPNs with an arbitrary number of nodes. Instead of configuring tunnels, you give tinc the location and public key of a few nodes in the VPN. After making the initial connections to those nodes, tinc will learn about all other nodes on the VPN, and will make connections automatically. When direct connections are not possible, data will be forwarded by intermediate nodes. By default, nodes authenticate each other using 2048 bit RSA (or 521 bit ECDSA*) keys. Traffic is encrypted using Blowfish in CBC mode (or AES-256 in GCM mode*), authenticated using HMAC-SHA1 (or GCM*), and is protected against replay attacks. *) When using the ExperimentalProtocol option. Tinc fully supports IPv6. Tinc can operate in several routing modes. In the default mode, "router", every node is associated with one or more IPv4 and/or IPv6 Subnets. The other two modes, "switch" and "hub", let the tinc daemons work together to form a virtual Ethernet network switch or hub. Normally, when started tinc will detach and run in the background. In a native Windows environment this means tinc will intall itself as a service, which will restart after reboots. To prevent tinc from detaching or running as a service, use the -D option. The status of the VPN can be queried using the "tinc" command, which connects to a running tinc daemon via a control connection. The same tool also makes it easy to start and stop tinc, and to change its configuration.