tinc-vpn.org Git - wiki/blob - goals.mdwn

   1 ## Design goals
   2
   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
   5 are covered yet.
   6
   7 **Be as secure as possible**
   8
   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
  19 our code.
  20
  21 **Allow for scalability**
  22
  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
  32 sites.
  33
  34 **Stability and reliability**
  35
  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.
  40
  41 **Easy configuration**
  42
  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.
  47
  48 **Flexibility**
  49
  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
  53 any network topology.
  54
  55 ## Plans for tinc 1.0.x
  56
  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.
  61
  62 ## Plans for tinc 1.1
  63
  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 in this branch:
  69
  70 **Replaceble cryptography backend**
  71
  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.
  78
  79 **Control socket**
  80
  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.
  86
  87 **Automatic connection management**
  88
  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.
  95
  96 **Deal with NAT**
  97
  98 The 1.0 branch by default tries to exchange packets via UDP.
  99 However, if one or more peers are behind a NAT, and source ports
 100 might be changed or packets may not arrive at all, the
 101 administrator had to manually enable the TCPOnly option or use
 102 another workaround to get tinc to work. Tinc should be able to cope
 103 with altered source ports, and should detect whether or not packet
 104 exchange via UDP works at all, and if not fall back to TCP.
 105
 106 **Automate setting up nodes**
 107
 108 The tincctl utility should have a wizard-like interface that asks a few
 109 necessary questions and then creates all the configuration files.  Another
 110 useful feature would be to allow it to export a GPG signed email to selected
 111 recipients, which would be able to import them with a simple command.  Another
 112 option would be to allow a user to connect via SSH to a remote node (if he has
 113 an account there), and do a two-way exchange of configuration files.
 114
 115 ## Plans for tinc 2.0
 116
 117 The 2.0 branch will be a complete rewrite of tinc. Expectations
 118 have changed in the past 10 years. Applications should just work,
 119 and should do as much as possible automatically. For example,
 120 setting up a VPN with 1.0 requires the administrator to create a
 121 number of configuration files (tinc.conf, tinc-up, a host config
 122 file), generate keys, and exchange host config files with peers
 123 somehow. This should be reduced to a simple `tinc setup`
 124 command, which asks the user a few relevant details (name, subnet),
 125 and perhaps asks if the credentials (the host config file in 1.0)
 126 should be sent to another person, via email or other means. The
 127 recipient of these credentials should just pipe them through
 128 `tinc import` which would show a fingerprint and ask the
 129 user if he was sure, and would then automatically update the
 130 running tinc daemon's configuration with the new information. Of
 131 course, there should also be a GUI to manage one's setup,
 132 preferably well integrated into the OS and desktop environment of
 133 the user's choice. Features from the 1.0 and 1.1 branches will be
 134 included in the 2.0 branch if possible. Other features planned for
 135 2.0 are:
 136
 137 **Certificate based authorisation**
 138
 139 In tinc 1.x authentication and authorisation is based on exchange
 140 of public RSA keys and full trust principles. For finer control
 141 over the VPN, and to limit the damage a rogue peer can do, a web of
 142 trust should be formed using certificates. This can be in the style
 143 of X.509, i.e. with a single authority who can sign certificates
 144 for peers and the subnets they are allocated, or in the style of
 145 PGP, where peers can sign each other, and if there are enough
 146 signatures, they can allow communication. Trust management should
 147 be simple, for example using a command like
 148
 149     tinc trust foo
 150
 151 which should let the local tinc
 152 daemon trust information from the peer named *foo*. To authorise
 153 the use of addresses on the VPN, a command like the following could
 154 be used:
 155
 156     tinc allow bar 192.168.3.0/24
 157
 158 This should generate a small certificate that proves that the node that
 159 issued this command trusts node *bar* with the 192.168.3.0/24 range
 160 of addresses. This certificate should then be added to the local
 161 tinc daemon's configuration, but also spread immediately amongst
 162 the other peers in the VPN. It is also important to allow trust and
 163 authorisation to be revoked in the same way:
 164
 165     tinc distrust foo
 166
 167 This should make the local tinc daemon stop trusting any information from *foo*.
 168
 169     tinc deny bar
 170
 171 This should generate a certificate (with a newer timestamp than the previous one) denying
 172 *bar* any access, and spread this amongst the other peers as well.
 173 The other peers should replace the previous certificates for *bar*
 174 from this peer with the new one, and recalculate their trust of
 175 *bar* based on other certificates they might have.
 176
 177 **Replacable tunnel backend**
 178
 179 Tinc 1.x uses its own protocols to set up tunnels to other tinc
 180 daemons. Once a tunnel has been set up, it synchronises the other
 181 end with the rest of the VPN. Whereas most other VPN daemons
 182 concentrate on the workings of a single tunnel, this is of less
 183 importance to tinc, which is more about managing lots of tunnels
 184 between peers to create a seamless network. It also is better to
 185 use a well-established protocol such as SSH or TLS instead of our
 186 own. Also, it is not necessary at all to use the same protocol for
 187 all the connections in a single VPN. Tinc should therefore allow
 188 tunnel backends as plugins, and allow other peers to be reached via
 189 URLs such as `ssh://some.server.org` or
 190 `https://another.server.net:4443`.