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