Design goals

This is a list of the design goals for tinc, sorted on importance. Although we already achieved a lot of what is below, not all goals are covered yet.

Be as secure as possible

This should of course be the primary goal of any VPN implementation. Security is not only achieved by applying strong cryptography, we are also trying to make tinc free of buffer overflows and other design faults that could allow root exploits, trying to prevent private data from lying around (in memory, swap or regular files), trying to prevent errors from human carelessness (wrong permissions on files containing the configuration and private keys), trying to avoid security problems arising from the interaction between different (security) mechanisms. We also hope we can get a lot of people and possibly security experts to audit our code.

Allow for scalability

After our first real stable implementation of tinc (around version 0.2.19), we noticed that setting up a large VPN with many sites required a lot of tunnels. Even worse, because we used a star network, the node in the middle was passing through a lot of network traffic for other nodes. From then on we tried to make the tinc daemon accept more than one connection, and let the tinc daemons contact each other directly in the most direct way, without requiring the VPN sites to configure all those direct routes themselves. We hope to let tinc scale to VPNs with over 1000 sites.

Stability and reliability

We are trying to make sure the tinc daemons stay up and running no matter what happens. Network errors should not be a reason for requiring an administrator to restart the daemons. We try to make sure tinc runs as long as your UPS does.

Easy configuration

The configuration of tinc should be as easy as possible. Any error made in the configuration files can be a compromise to security. However, we do require the administrator to have a good knowledge of network administration.

Flexibility

Of course, we want tinc to be able to run in any kind of setup or environment. We try to make tinc run on as many operating systems and architectures as possible, and make it provide a solution for any network topology.

Plans for tinc 1.0.x

The stable branch of tinc, with version numbers 1.0.x, will not see any significant development. Only bugs will be fixed, and perhaps non-invasive features that do not conflict with existing features and do not depend on new libraries might be added.

Plans for tinc 1.1

The 1.1 branch of tinc has been created as a stepping stone towards 2.0. Only gradual changes to the source code are allowed, ensuring that the code is always in a mostly usable state. The protocol will stay compatible with that of the 1.0 branch. The following features are planned or are already implemented in this branch:

Replaceble cryptography backend

The 1.0 branch uses OpenSSL exclusively. Although this library is well known and widely available, it has two drawbacks: it is quite large and its license is not completely compatible with the GPL. In 1.1 there will be an abstraction layer that allows tinc to be linked with different cryptography libraries. At least OpenSSL and libgcrypt will be supported.

Control socket

The 1.0 branch has limitted support to control a running tinc daemon. In 1.1 the tinc daemon will have a control socket that allows a tinc control program to connect to it and issue commands to or retrieve information from the running daemon. This will also allow for a GUI or dock applet to control tinc or show its status.

Automatic connection management

The 1.0 branch can exchange packets directly with other peers via UDP, creating a full mesh. However, the TCP control connections are only made according to the manually specified ConnectTo statements in the tinc.conf files. It is desirable to have tinc manage the creation of control connections as well, so that the administrator does not have to do this manually anymore.

Automate setting up nodes

The tincctl utility should have a wizard-like interface that asks a few necessary questions and then creates all the configuration files. Another useful feature would be to allow it to export a GPG signed email to selected recipients, which would be able to import them with a simple command. Another option would be to allow a user to connect via SSH to a remote node (if he has an account there), and do a two-way exchange of configuration files.

Plans for tinc 2.0

The 2.0 branch will be a complete rewrite of tinc. Expectations have changed in the past 10 years. Applications should just work, and should do as much as possible automatically. For example, setting up a VPN with 1.0 requires the administrator to create a number of configuration files (tinc.conf, tinc-up, a host config file), generate keys, and exchange host config files with peers somehow. This should be reduced to a simple tinc setup command, which asks the user a few relevant details (name, subnet), and perhaps asks if the credentials (the host config file in 1.0) should be sent to another person, via email or other means. The recipient of these credentials should just pipe them through tinc import which would show a fingerprint and ask the user if he was sure, and would then automatically update the running tinc daemon’s configuration with the new information. Of course, there should also be a GUI to manage one’s setup, preferably well integrated into the OS and desktop environment of the user’s choice. Features from the 1.0 and 1.1 branches will be included in the 2.0 branch if possible. Other features planned for 2.0 are:

Certificate based authorisation

In tinc 1.x authentication and authorisation is based on exchange of public RSA keys and full trust principles. For finer control over the VPN, and to limit the damage a rogue peer can do, a web of trust should be formed using certificates. This can be in the style of X.509, i.e. with a single authority who can sign certificates for peers and the subnets they are allocated, or in the style of PGP, where peers can sign each other, and if there are enough signatures, they can allow communication. Trust management should be simple, for example using a command like

tinc trust foo

which should let the local tinc daemon trust information from the peer named foo. To authorise the use of addresses on the VPN, a command like the following could be used:

tinc allow bar 192.168.3.0/24

This should generate a small certificate that proves that the node that issued this command trusts node bar with the 192.168.3.0/24 range of addresses. This certificate should then be added to the local tinc daemon’s configuration, but also spread immediately amongst the other peers in the VPN. It is also important to allow trust and authorisation to be revoked in the same way:

tinc distrust foo

This should make the local tinc daemon stop trusting any information from foo.

tinc deny bar

This should generate a certificate (with a newer timestamp than the previous one) denying bar any access, and spread this amongst the other peers as well. The other peers should replace the previous certificates for bar from this peer with the new one, and recalculate their trust of bar based on other certificates they might have.

Replacable tunnel backend

Tinc 1.x uses its own protocols to set up tunnels to other tinc daemons. Once a tunnel has been set up, it synchronises the other end with the rest of the VPN. Whereas most other VPN daemons concentrate on the workings of a single tunnel, this is of less importance to tinc, which is more about managing lots of tunnels between peers to create a seamless network. It also is better to use a well-established protocol such as SSH or TLS instead of our own. Also, it is not necessary at all to use the same protocol for all the connections in a single VPN. Tinc should therefore allow tunnel backends as plugins, and allow other peers to be reached via URLs such as ssh://some.server.org or https://another.server.net:4443.