3 This is a list of the design goals for tinc, sorted on importance.
4 Although we already achieved a lot of what is below, not all goals
7 **Be as secure as possible**
9 This should of course be the primary goal of any VPN
10 implementation. Security is not only achieved by applying strong
11 cryptography, we are also trying to make tinc free of buffer
12 overflows and other design faults that could allow root exploits,
13 trying to prevent private data from lying around (in memory, swap
14 or regular files), trying to prevent errors from human carelessness
15 (wrong permissions on files containing the configuration and
16 private keys), trying to avoid security problems arising from the
17 interaction between different (security) mechanisms. We also hope
18 we can get a lot of people and possibly security experts to audit
21 **Allow for scalability**
23 After our first real stable implementation of tinc (around version
24 0.2.19), we noticed that setting up a large VPN with many sites
25 required a lot of tunnels. Even worse, because we used a star
26 network, the node in the middle was passing through a lot of
27 network traffic for other nodes. From then on we tried to make the
28 tinc daemon accept more than one connection, and let the tinc
29 daemons contact each other directly in the most direct way, without
30 requiring the VPN sites to configure all those direct routes
31 themselves. We hope to let tinc scale to VPNs with over 1000
34 **Stability and reliability**
36 We are trying to make sure the tinc daemons stay up and running no
37 matter what happens. Network errors should not be a reason for
38 requiring an administrator to restart the daemons. We try to make
39 sure tinc runs as long as your UPS does.
41 **Easy configuration**
43 The configuration of tinc should be as easy as possible. Any error
44 made in the configuration files can be a compromise to security.
45 However, we do require the administrator to have a good knowledge
46 of network administration.
50 Of course, we want tinc to be able to run in any kind of setup or
51 environment. We try to make tinc run on as many operating systems
52 and architectures as possible, and make it provide a solution for
55 ## Plans for tinc 1.0.x
57 The stable branch of tinc, with version numbers 1.0.x, will not see
58 any significant development. Only bugs will be fixed, and perhaps
59 non-invasive features that do not conflict with existing features
60 and do not depend on new libraries might be added.
64 The 1.1 branch of tinc has been created as a stepping stone towards
65 2.0. Only gradual changes to the source code are allowed, ensuring
66 that the code is always in a mostly usable state. The protocol will
67 stay compatible with that of the 1.0 branch. The following features
68 are planned or are already implemented in this branch:
70 **Replaceble cryptography backend**
72 The 1.0 branch uses OpenSSL exclusively. Although this library is
73 well known and widely available, it has two drawbacks: it is quite
74 large and its license is not completely compatible with the GPL. In
75 1.1 there will be an abstraction layer that allows tinc to be
76 linked with different cryptography libraries. At least OpenSSL and
77 libgcrypt will be supported.
81 The 1.0 branch has limitted support to control a running tinc
82 daemon. In 1.1 the tinc daemon will have a control socket that
83 allows a tinc control program to connect to it and issue commands
84 to or retrieve information from the running daemon. This will also
85 allow for a GUI or dock applet to control tinc or show its status.
87 **Automatic connection management**
89 The 1.0 branch can exchange packets directly with other peers via
90 UDP, creating a full mesh. However, the TCP control connections are
91 only made according to the manually specified ConnectTo statements
92 in the tinc.conf files. It is desirable to have tinc manage the
93 creation of control connections as well, so that the administrator
94 does not have to do this manually anymore.
96 **Automate setting up nodes**
98 The tincctl utility should have a wizard-like interface that asks a few
99 necessary questions and then creates all the configuration files. Another
100 useful feature would be to allow it to export a GPG signed email to selected
101 recipients, which would be able to import them with a simple command. Another
102 option would be to allow a user to connect via SSH to a remote node (if he has
103 an account there), and do a two-way exchange of configuration files.
105 ## Plans for tinc 2.0
107 The 2.0 branch will be a complete rewrite of tinc. Expectations
108 have changed in the past 10 years. Applications should just work,
109 and should do as much as possible automatically. For example,
110 setting up a VPN with 1.0 requires the administrator to create a
111 number of configuration files (tinc.conf, tinc-up, a host config
112 file), generate keys, and exchange host config files with peers
113 somehow. This should be reduced to a simple `tinc setup`
114 command, which asks the user a few relevant details (name, subnet),
115 and perhaps asks if the credentials (the host config file in 1.0)
116 should be sent to another person, via email or other means. The
117 recipient of these credentials should just pipe them through
118 `tinc import` which would show a fingerprint and ask the
119 user if he was sure, and would then automatically update the
120 running tinc daemon's configuration with the new information. Of
121 course, there should also be a GUI to manage one's setup,
122 preferably well integrated into the OS and desktop environment of
123 the user's choice. Features from the 1.0 and 1.1 branches will be
124 included in the 2.0 branch if possible. Other features planned for
127 **Certificate based authorisation**
129 In tinc 1.x authentication and authorisation is based on exchange
130 of public RSA keys and full trust principles. For finer control
131 over the VPN, and to limit the damage a rogue peer can do, a web of
132 trust should be formed using certificates. This can be in the style
133 of X.509, i.e. with a single authority who can sign certificates
134 for peers and the subnets they are allocated, or in the style of
135 PGP, where peers can sign each other, and if there are enough
136 signatures, they can allow communication. Trust management should
137 be simple, for example using a command like
141 which should let the local tinc
142 daemon trust information from the peer named *foo*. To authorise
143 the use of addresses on the VPN, a command like the following could
146 tinc allow bar 192.168.3.0/24
148 This should generate a small certificate that proves that the node that
149 issued this command trusts node *bar* with the 192.168.3.0/24 range
150 of addresses. This certificate should then be added to the local
151 tinc daemon's configuration, but also spread immediately amongst
152 the other peers in the VPN. It is also important to allow trust and
153 authorisation to be revoked in the same way:
157 This should make the local tinc daemon stop trusting any information from *foo*.
161 This should generate a certificate (with a newer timestamp than the previous one) denying
162 *bar* any access, and spread this amongst the other peers as well.
163 The other peers should replace the previous certificates for *bar*
164 from this peer with the new one, and recalculate their trust of
165 *bar* based on other certificates they might have.
167 **Replacable tunnel backend**
169 Tinc 1.x uses its own protocols to set up tunnels to other tinc
170 daemons. Once a tunnel has been set up, it synchronises the other
171 end with the rest of the VPN. Whereas most other VPN daemons
172 concentrate on the workings of a single tunnel, this is of less
173 importance to tinc, which is more about managing lots of tunnels
174 between peers to create a seamless network. It also is better to
175 use a well-established protocol such as SSH or TLS instead of our
176 own. Also, it is not necessary at all to use the same protocol for
177 all the connections in a single VPN. Tinc should therefore allow
178 tunnel backends as plugins, and allow other peers to be reached via
179 URLs such as `ssh://some.server.org` or
180 `https://another.server.net:4443`.