tinc and TLS

[Brian Candler]

On Sat, Dec 10, 2005 at 07:41:59PM +0100, Guus Sliepen wrote:
> > 5. TLS and OpenSSL have both been subjected to widespread scrutiny.
> 
> All true. Except that this does not work for UDP packets, unless DTLS
> becomes available or you do something like OpenVPN (reimplementing a
> kind of TCP on top of UDP just to support SSL/TLS).

Hmm, I've had a quit poke around OpenVPN too now. Yes, they run TLS over
their own pseudo-TCP over UDP. Ugly to implement, but nice for the
administrator as there's only one port to open for both key exchange and
traffic.

It's not clear to me whether OpenVPN uses actual IPSEC ESP packet format as
its encapsulation, or something else. Probably the best of all worlds would
be to use ESP for the traffic encapsulation and TLS for the session setup,
replacing the nastiness of IKE. I wasn't suggesting TLS for the actual
payload transport, just for the control channel. 

Where TINC seems to score well is:

1. A single daemon holding can manage connections to multiple peers (OpenVPN
can do this but only if you nominate one side as a multi-connection 'server'
and the others as single-connection 'clients')

2. The ability to distribute route information dynamically. Actually I'm not
sure whether OpenVPN can do that, but with a full IPSEC suite you can't.
With IPSEC you first setup the policy ("to reach subnet X.X.X.X go via peer
Y.Y.Y.Y"), and establish a connection to th e peer only on demand, when you
want to communicate with X.X.X.X. With TINC you setup the peers, connect
immediately, and let them describe the networks they can reach, minimising
the amount of pre-configured knowledge on each host. At least, that's how I
understand it from the docs.

Aside: I note that when using TLS, OpenVPN requires you to nominate one side
as 'server' and the other as 'client', just because TLS is asymmetric.
However it seems to me that this choice could be made automatically: e.g.
the peer with the higher IP address is the server, and the other is the
client.

> If you can code, I would welcome any contribution!

I guess I have to look at OpenVPN and TINC some more and see which is closer
to meeting my needs, before I start attempting to tinker.

One specific example of what I'd like to do: split a single subnet into
multiple bridged segments via a common untrusted network.

  "black"
  subnet X
  -------- BR ---+
                 |
  subnet X       | "red" untrusted network
  -------- BR ---+
                 |
  subnet X       |
  -------- BR ---+
              <-->
              encrypted

It looks like TINC and OpenVPN can both bridge traffic. The three (or more)
bridges need to set up tunnels to each other; with TINC I can preconfigure
them all as peers. With a bit of work I can imagine a 'beacon' mode where
all bridges can announce (e.g. via a multicast packet) that they are
available as peers for network <name>. Then the others can attempt to
establish a link to it when they see the broadcast.

I note that OpenBSD can do 'bump in the wire' IPSEC bridging:
http://www.thought.net/jason/bridgepaper/node9.html
which seems to be exactly what I want.

However I'm looking for something compact enough to run on OpenWRT hardware,
which forces me to go Linux.

Regards,

Brian.