--- /dev/null
+## 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`.
projects / wiki / blobdiff