The network is virtual, your privacy is not...

Design goals

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

Planned features

• Certificate based authorisation
  Currently tinc's authentication and authorisation is based on exchange of public keys and full trust principles, without the need for a central authority. This works well when different nodes on the VPN are peers, but sometimes a client/server approach is better suited, for example for "tunnel server" setups where a central server at a company allows home workers to connect to the VPN. In that situation authentication and authorisation based on certificates signed by a central authority (the company) is more appropriate.
• External credential repository
  Currently public keys are stored in tinc's own configuration directory. It should be possible to store public keys or certificates in external repositories, for example DNS or LDAP.
• Public key propagation
  Currently administrators need to exchange public keys for every meta connection they want. It should be possible however to let public keys distribute themselves automatically once a single meta connection has been established.
• Graphical interface
  To aid in configuration and to give an overview of the status of a running VPN, a graphical user interface called pokey is being developed.
• Threaded design
  Currently tinc has a single select() loop that handles all in- and outgoing traffic and events. While this works perfectly most of the time, it lets tinc stall during authentication due to RSA encryption/decryption. Also, if hardware cryptography accelerators are used, tinc is feeding relatively small chunks of data to the crypto accelerator and waiting for it to complete. Using a multi-threaded design with dedicated threads for RSA key handling (as implemented by OpenVPN and packet encryption/decryption (as discussed at Hardware Acceleration in FreeS/WAN) would decrease latency and possibly increase bandwidth.
• Replacable tunnel backend
  Currently tinc 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 other VPN daemons concentrate on the workings of a single tunnel, this is of less importance to tinc. It should be possible to replace tinc's tunnel backend. See also Building a VPN Using Yavipin.