On 22 November 2015 at 23:06, Guus Sliepen <[email protected]> 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. _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
