X-Git-Url: https://www.tinc-vpn.org/git/browse?a=blobdiff_plain;f=goals.mdwn;fp=goals.mdwn;h=41a5a10b272dadd2ada0467523166b2ff2dfc45d;hb=7c74a57cd95cfc0358fdd5980d9170ea16751dfb;hp=0000000000000000000000000000000000000000;hpb=f980b3945271b51a8a200c44b8d3e7d61d086bab;p=wiki diff --git a/goals.mdwn b/goals.mdwn new file mode 100644 index 0000000..41a5a10 --- /dev/null +++ b/goals.mdwn @@ -0,0 +1,181 @@ +## 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 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. + +**Deal with NAT** + +The 1.0 branch by default tries to exchange packets via UDP. +However, if one or more peers are behind a NAT, and source ports +might be changed or packets may not arrive at all, the +administrator had to manually enable the TCPOnly option or use +another workaround to get tinc to work. Tinc should be able to cope +with altered source ports, and should detect whether or not packet +exchange via UDP works at all, and if not fall back to TCP. + +## 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`.