3 ms·

What's also bad about IPsec is that most of its features are useless in the vast majority of use cases. Some are probably even actively harmful to try to use. F

What's also bad about IPsec is that most of its features are useless in the vast majority of use cases. Some are probably even actively harmful to try to use. For example, it's possible to use static encryption keys for a security association. That's not a good feature to have. If you just want to set up a secure tunnel connecting two networks over an untrusted network, probably 95% of what IPsec can do won't be of any help to you at all, and will actively hinder you because you have to find the exact combination of settings that works for whatever two endpoints you want to join together.

starfallg 5y ago
>For example, it's possible to use static encryption keys for a security association. That's not a feature per se, it's just a side effect of having pluggable mechanisms at each part of the protocol. They allow IPSEC to be extensible - for example to support group SAs for GETVPN (Group VPN), used in a lot of encrypted networks in higher security environments. This is usually done on the CPE router. On very high security networks, a separate hardware encryption device is needed. To implement something similar to GETVPN in wireguard would require an agent to constantly change the private and public key pairs for every peer relationship in the group.
- 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 ago
    That'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.

starfallg 5y ago

>For example, it's possible to use static encryption keys for a security association. That's not a feature per se, it's just a side effect of having pluggable mechanisms at each part of the protocol. They allow IPSEC to be extensible - for example to support group SAs for GETVPN (Group VPN), used in a lot of encrypted networks in higher security environments. This is usually done on the CPE router. On very high security networks, a separate hardware encryption device is needed. To implement something similar to GETVPN in wireguard would require an agent to constantly change the private and public key pairs for every peer relationship in the group.

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 ago
  That'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.