No description
Find a file
Etienne Dechamps 24d28adf64 Use a smarter algorithm for choosing MTU discovery probe sizes.
Currently, tinc uses a naive algorithm for choosing MTU discovery probe
sizes, picking a size at random between minmtu and maxmtu.

This is of course suboptimal - since the behavior of probes is
deterministic (assuming no packet loss), it seems likely that using a
non-deterministic discovery algorithm will not yield the best results.
Furthermore, the randomness introduces a lot of variation in convergence
times.

The random solution also suffers from pathological cases - since it's
using a uniform distribution, it doesn't take into account the fact that
it's often more interesting to send small probes rather than large ones,
because getting replies is the only way we can make progress (assuming
the worst case scenario in which the OS doesn't know anything, therefore
keeping maxmtu constant). This can lead to absurd situations where the
discovery algorithm is close to the real MTU, but can't get to it
because the random number generator keeps generating numbers that are
past it.

The algorithm implemented in this patch aims to improve on the naive
random algorithm. It is organized around "cycles" of 8 probes; the sizes
of the probes decrease as we go through the cycle, thus making sure the
algorithm can cover lots of ground quickly (in case we're far from
actual MTU), but also examining the local area (in case we're close to
actual MTU). Using cycles ensures that the algorithm will "go back" to
large probes to better cover the new interval and to protect against
packet loss.

For the probe size itself, various mathematical models were simulated in
an attempt to find the one that converges the fastest; it has been
determined that using an exponential based on the size of the remaining
interval was the most effective option. The exponential is adjusted with
a magic multiplier fine-tuned to make tinc jump to the "most
interesting" (i.e. 1400+) section as soon as discovery starts.

Simulations indicate that assuming no packet loss and no help from the
OS (i.e. maxmtu stays constant), this algorithm will typically converge
to the *exact* MTU value in less than 10 probes, and will get within 8
bytes in less than 5 probes, for actual MTUs between 1417 and ~1450
(which is the range the algorithm is fine-tuned for). In contrast, the
previous algorithm gives results all over the place, sometimes taking
30+ probes to get in the ballpark. Because of the issues with the
distribution, the previous algorithm sometimes never gets to the precise
MTU value within any reasonable amount of time - in contrast, the new
algorithm will always get to the precise value in less than 30 probes,
even if the actual MTU is completely outside the optimized range.
2015-01-02 09:55:52 +00:00
bash_completion.d Add UDP discovery mechanism. 2015-01-01 17:40:15 +00:00
doc Move responsibility for local discovery to UDP discovery. 2015-01-01 17:40:15 +00:00
gui tinc-gui: Don't assign broadcast subnets to any node, fix parsing of Edges, fix diplay of Subnet.weight. 2014-10-14 22:18:56 +02:00
m4 We don't depend on ECDH functions from OpenSSL anymore. 2014-12-26 17:54:29 +01:00
src Use a smarter algorithm for choosing MTU discovery probe sizes. 2015-01-02 09:55:52 +00:00
test commandline.test: Adding test that fetching non-existing config setting really fails. 2014-08-07 23:02:12 +02:00
.gitignore Don't ignore Makefile.am. 2012-09-24 14:56:00 +02:00
AUTHORS Remove Google from the list of copyright owners. 2014-08-30 10:57:57 +01:00
configure.ac Allow tinc to be compiled without OpenSSL. 2014-12-29 22:57:18 +01:00
COPYING Update copyright notices. 2014-02-07 20:38:48 +01:00
COPYING.README Releasing 1.0.12. 2010-02-03 22:49:48 +01:00
Makefile.am Start of a test suite. 2013-09-01 12:48:31 +02:00
NEWS Releasing 1.1pre11. 2014-12-27 09:22:31 +01:00
README Releasing 1.1pre11. 2014-12-27 09:22:31 +01:00
README.android Android cross-compilation instructions. 2012-09-24 13:55:38 +02:00
README.git Document clearly that tinc depends on curses and readline libraries. 2014-01-20 20:16:58 +01:00
THANKS Update THANKS file. 2014-12-26 14:59:15 +01:00

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.