Authenticating VPN addresses: a proposal

[Etienne Dechamps]

On 22 November 2015 at 23:06, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 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.

Yes, I agree that this would be ideal. But that's a lot of work; hence
my suggestion for some interim solution, which is indeed not perfect
but IHMO significantly better than what's already there.

> What you propose is some kind of Balkanization, by selectively blocking
> Subnets from other nodes.

Indeed.

> 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.

Yes. It only makes sense if the topology of the metagraph somewhat
resembles administrative boundaries. I can definitely understand that
this is problematic in terms of tinc's philosophy, but it's only a
"side feature" - I'm not saying this should be a definitive solution.

> 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.

Yes. That's the point: the "other side" is responsible for managing
their own security with their own ACLs for their own subnets. I won't
have to deal with it. The only thing I care about is that their side
cannot impersonate one of *my* nodes when talking to my side.

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

Yep.

> 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 :)

Yes. I am well aware of the philosophical problems, but it's not like
this is a fundamental redesign or anything of the sort: it's basically
just a filter on subnet messages, which is trivial to implement and
doesn't really affect future evolution.