4 ms·
It is a real shame that they couldn't have made this work with/for wireguard.
by SEJeff 4y ago
It is a real shame that they couldn't have made this work with/for wireguard.
- ikiris 4y agoI think what you meant is that its a real shame that wireguard completely refuses to use any common standards, or actual proper networking.
- aaaaaaaaata 4y agoYeah. Why can't they be just like OpenVPN? Who needs reduced attack surface?
- remus 4y agoIt sounds like they were working on this before wireguard would have been a viable option.
- hujun 4y agoaccording to the blog, one key driver for inventing a new protocol is Google wants to do per-connection encryption, (e.g. using different keys for each TCP/UDP connection), I don't think wireguard (which is interface based model) could be easily modified to support that.
- aaaaaaaaata 4y agoThat's...exactly how I'd describe Wireguard's paradigm to someone!
- harshreality 4y agoWireguard has different keys for different tunnels/routes (which might be considered virtualized layer 2 interfaces), not per connection (which would be layer 4- or 5-ish).
- aaaaaaaaata 4y agoI'm gonna say if it's a different keypair, and a different origin/endpoint, it's a different connection. Sharing a config file doesn't make it the same connection — in fact, the whole security model is that it's an easily grouped, but cryptographically ensured separate connection — no?
- cmeacham98 4y agoI don't see why it couldn't, both sides just need some way to get the key to use for each connection (which is a problem their current solution already has to solve somehow).
- mjevans 4y agoFrom the description summary you provided alone, it seems likely that each Connection could get it's own virtual Interface, which would be dynamically created and destroyed and the Session keys exchanged initially with the primary Interface key.