2 ms·
I suppose I should have phrased my point differently. I think having that kind of a feature as a side-effect of how the whole thing works isn't particularly goo
by chousuke 5y ago
I suppose I should have phrased my point differently. I think having that kind of a feature as a side-effect of how the whole thing works isn't particularly good for security and usability, though I understand why you might need the flexibility in some scenarios.
IPsec can certainly do fancy things when you really get serious about encrypting and authenticating everything and wireguard is not nearly ready tooling-wise to replace all of that, but the configurability also makes IPsec pretty unfriendly for solving simpler cases like just connecting two or more separate networks together or road-warrior client setups. I suspect people are excited about Wireguard largely because these cases are common enough that whatever actual reason IPsec has to be as flexible as it is is dwarfed by the pain it causes in simple cases.
As for group VPNs, maybe I'm misunderstanding something, but why would you need to be constantly changing Wireguard keys on nodes in the network, when you only need to distribute the public keys for all nodes that need to communicate? You only really need one keypair per node that's participating, and it's not really a problem for the public keys to be long-lived.
- starfallg 5y agoThat's because unless you work with the secure plumbing of bits at scale and in complex environments, you don't run into the use cases where the flexibility of IPSEC makes sense. However a lot of network and security engineers do. Regarding your last point, the whole idea of GETVPN is membership in a encryption group. This include joining the group and leaving the group (and what this entails), as well as distributing group keys. Witeguard just itself designed for this and it can't even be hacked on. Whereas extending IPSEC to support group semantics was relatively seamless.