Wireguard is too simple. With IKEv2, you can push routes and DNS (configuration payload). I think IKEv2 displaced many proprietary VPN/OpenVPN setups because of this (IKEv1 was not able to do that).
It's not that WireGuard "can't" do that, it's that it pushes those features to another layer of the stack. There are WireGuard-backed VPN systems that have all those features and more.
IKEv2 does all those things without any further integration, and all major OSes support said features without further integration. It doesn't matter what Wireguard can do if you just bolt more things on top of it.
In Linux you mean, or as a protocol? As a protocol, sure, the complexity is far bigger but it also enables many enterprisy things (through authentication or payload configuration). I also wonder how Wireguard will implement post-quantum cryptography, while this is already available with IPsec.
Is plain IKE/IPsec that widely used for remote access/client VPNs? I've only seen it used as the transport layer for some proprietary vendor solution like AnyConnect/GlobalProtect/FortiVPN/etc.
For site to site tunnels it is the standard, but I'm surprised to hear about the importance of dynamic configuration, since those proprietary solutions bolt their own control plane on top anyway
With IKEv1, you had to rely on proprietary Cisco extensions, or using L2TP over IPsec, which was not a convenient setup. With IKEv2, it is easy to setup both on client side (Windows, Linux through Network Manager, macOS all support this out of the box) and server side (StrongSWAN on Linux). I think the proprietary vendor solutions stay popular because of inertia and I assume they bolt some additional unrelated features on top of that.
At work we run both IKEv1 and IKEv2 to interface with different enterprise VPNs of different companies. I'd say they're about the same level of hassle and definitely nowhere near as easy as Wireguard.
IKEv2 is perhaps simpler on the "happy path", but that barely ever happens and you'll still get stuck manually negotiating all of the billion connection parameters via e-mail.
Secureblue has been blacklisting problematic kernel modules for a while, I think they might be planning to move to an allowlist in the future? Brace (same dev as the defunct DivestOS) is also doing some interesting work in that area.
To pick the example of IPSEC, i wonder if it wouldn't be better to
have, e.g., a separate "linux-modules-ipsec" package that isn't
installed by default.
I have been thinking about this, too. The only distro I know which does this for their binary kernel packaging is OpenWRT (for size reasons), and it does seem like an easy way to shrink the kernel module attack surface down.
For existing distro kernels, I wonder if there's a tool similar to make localmodconfig that looks at the currently installed kernel modules and drops an entry into /etc/modprobe.d/ that blacklists everything but those kernel modules? (AFAICT there's no wildcard or whitelisting support in modprobe.d so you'd need to do this in a hook after every kernel update, but it seems like a viable thing to do...?)
a tool similar to make localmodconfig that looks at the currently installed kernel modules and drops an entry into /etc/modprobe.d/ that blacklists everything but those kernel modules?
Oh, the Brace module_restricter scripts linked from this comment look like they're intended to do something like this. Looks like started last week and actively being worked on. Nice!
There’s an experiment network my friend set up. We have a fairly large IPsec mesh with ~150 nodes. I told him about this vulnerability, and after some discussion, we decided that it doesn’t significantly impact us. While these LPEs are generic, if our single user machines are properly configured, attackers can't even gain access to perform LPE...
It isn't? Isn't it the basis for lots of corporate VPN software still?
I found IKEv2 to be a lot simpler to setup than older IPsec, but obviously Wireguard beats it in simplicity.
Wireguard is too simple. With IKEv2, you can push routes and DNS (configuration payload). I think IKEv2 displaced many proprietary VPN/OpenVPN setups because of this (IKEv1 was not able to do that).
It's not that WireGuard "can't" do that, it's that it pushes those features to another layer of the stack. There are WireGuard-backed VPN systems that have all those features and more.
IKEv2 does all those things without any further integration, and all major OSes support said features without further integration. It doesn't matter what Wireguard can do if you just bolt more things on top of it.
Right, the only problem with it is that it's a security train wreck.
In Linux you mean, or as a protocol? As a protocol, sure, the complexity is far bigger but it also enables many enterprisy things (through authentication or payload configuration). I also wonder how Wireguard will implement post-quantum cryptography, while this is already available with IPsec.
Is plain IKE/IPsec that widely used for remote access/client VPNs? I've only seen it used as the transport layer for some proprietary vendor solution like AnyConnect/GlobalProtect/FortiVPN/etc.
For site to site tunnels it is the standard, but I'm surprised to hear about the importance of dynamic configuration, since those proprietary solutions bolt their own control plane on top anyway
With IKEv1, you had to rely on proprietary Cisco extensions, or using L2TP over IPsec, which was not a convenient setup. With IKEv2, it is easy to setup both on client side (Windows, Linux through Network Manager, macOS all support this out of the box) and server side (StrongSWAN on Linux). I think the proprietary vendor solutions stay popular because of inertia and I assume they bolt some additional unrelated features on top of that.
IPSec is WIDELY used. So many S2S VPNs are relying on it.
Not many corporates run Linux desktops and on the server side it can always be enabled as part of the install configuration.
At work we run both IKEv1 and IKEv2 to interface with different enterprise VPNs of different companies. I'd say they're about the same level of hassle and definitely nowhere near as easy as Wireguard.
IKEv2 is perhaps simpler on the "happy path", but that barely ever happens and you'll still get stuck manually negotiating all of the billion connection parameters via e-mail.
Secureblue has been blacklisting problematic kernel modules for a while, I think they might be planning to move to an allowlist in the future? Brace (same dev as the defunct DivestOS) is also doing some interesting work in that area.
IPSec is the standard for inter-DC routing, used by AWS and OCI to name just two. So idk but it seems pretty important, certainly it is to me.
I can set up a managed and redundant IPsec tunnel pair at both AWS and OCI but AFAIK I cant do that using wireguard.
I have been thinking about this, too. The only distro I know which does this for their binary kernel packaging is OpenWRT (for size reasons), and it does seem like an easy way to shrink the kernel module attack surface down.
For existing distro kernels, I wonder if there's a tool similar to
make localmodconfigthat looks at the currently installed kernel modules and drops an entry into/etc/modprobe.d/that blacklists everything but those kernel modules? (AFAICT there's no wildcard or whitelisting support inmodprobe.dso you'd need to do this in a hook after every kernel update, but it seems like a viable thing to do...?)Oh, the Brace
module_restricterscripts linked from this comment look like they're intended to do something like this. Looks like started last week and actively being worked on. Nice!This is mostly like
kernel.modules_disabled=1after boot?On Debian, there is a linux-vulnerability-mitigation package that also blacklist problematic modules.
There’s an experiment network my friend set up. We have a fairly large IPsec mesh with ~150 nodes. I told him about this vulnerability, and after some discussion, we decided that it doesn’t significantly impact us. While these LPEs are generic, if our single user machines are properly configured, attackers can't even gain access to perform LPE...