Authenticating VPN addresses: a proposal

[Guus Sliepen]

There are many ways to set up and manage a VPN. Tinc's roots are a
"friend network", where there is a group of nodes that all trust each
other, and there is no central authority. It also works well in
situations where all nodes are controlled by the same authority, for
example when a sysadmin configures several nodes, like within a company
that wants to link together several networks.

It also works in a situation where a group of people trust a central
authority which provides them with the configuration for their tinc
nodes, if StrictSubnets is used. The drawback is that an external tool
needs to be used (ChaosVPN is one such example, but there are others)
and it is not very flexible, but I would disagree that it is
unmanageable.

For tinc 2.0, the idea is to have light-weight certificates for Subnets
(and perhaps other information), which can be signed by one or more
nodes, and each node can choose whether to trust certain signatures or
not. It could allow a central authority, or a PGP-style web of trust.
The big advantage is that it decouples authorization from the actual
network topology.

What you propose is some kind of Balkanization, by selectively blocking
Subnets from other nodes. Although it is not my preferred direction for
tinc, I do think it might actually be a workable method of limiting
trust in a network where you might not trust all nodes equally. But:

> /etc/tinc/my_network/hosts/client_node:
> ConnectionSubnetACL = +10.42.42.42 # this client's assigned subnet
> ConnectionSubnetACL = -ALL # deny everything else
> 
> /etc/tinc/my_network/hosts/other_central_node:
> ConnectionSubnetACL = +ALL # trust everything from that node (could be
> the default)
> 
> /etc/tinc/my_network/hosts/central_node_from_other_side:
> ConnectionSubnetACL = +10.13.37.0/24 # the other side's subnet space
> ConnectionSubnetACL = -ALL # deny everything else

The ACLs will be simple if there are distinct subnet ranges on each
"side". But if Subnets are scattered around or if there are many
connections per node, it might become an administration problem on its
own. It also does not prevent all cases of bad nodes injecting
unauthorized Subnets. For example, a bad node on the "other side" in
your example might announce Subnet=10.13.37.0/32#0 through
Subnet=10.13.37.255/32#0, and capture all traffic sent to the "other
side". It requires the central node from the other side to have ACLs of
its own to prevent this.

It probably also won't work well with AutoConnect, but you'd turn that
off when using connection ACLs.

I'd not spend time myself on implementing this feature, but it looks
like it can implemented relatively cleanly, and doesn't require any
protocol changes, so if there is interest in it, go ahead :)

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20151123/69355b1e/attachment.sig>