You can build a custom L7 on top of anything, really. I think my favorite was tcp/ip over printers and webcams.
The question is what does QUIC get you that UDP alone does not? I don't know the answer to that. Is it because firewalls understand it better than native wireguard over UDP packets?
> WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however.
This comment https://news.ycombinator.com/item?id=45562302 goes into a practical example of QUIC being that "layer above WireGuard" which gets plugged in. Once you have that, one may naturally wonder "why not also have an alternative tunnelling protocol with <the additional things built into QUIC originally listed> without the need to also layer Wireguard under it?".
Many design decisions are in direct opposition to Wireguard's design. E.g. Wireguard (intentionally) has no AES and no user selectable ciphers (both intentionally), QUIC does. Wireguard has no obfuscation built in, QUIC does (+ the happy fact when you obfuscate traffic by using it then it looks like standard web traffic). Wireguard doesn't support custom authentication schemes, QUIC does. Both are a reasonable tunneling protocol design, just with different goals.
The hope with QUIC is encrypted tunnels that look and smell like standard web traffic are probably first in the list of any allowed traffic tunneling methods. It works (surprisingly) a lot more often than hoping an adversarial network/security admin doesn't block known VPN protocols (even when they are put on 443). It also doesn't hurt that "normal" users (unknowingly) try to generate this traffic, so opening a QUIC connection on 443 and getting a failure makes you look like "every other user with a browser" instead of "an interesting note in the log".
I.e. the advantage here is any% + QUIC%, where QUIC% is the additional chances of getting through by looking and smelling like actual web traffic, not a promise of 100%.
QUIC could be allowed, but only if it can be decrypted by the adversarial admin.
If the data can't be decrypted (or doesn't look like plain text web traffic) by the adversarial network admin, the QUIC connection can just be blocked.
Work laptops typically have a root cert installed allowing the company to snoop on traffic. It's not unfeasible for a nation state to require one for all devices either.
Are you arguing "QUIC has no more of a chance of getting through than Wireguard" or "QUIC doesn't stop all forms of blocking from working"? Nobody will disagree with the latter, regardless of protocol, but I'm not sure I follow on what these points have to do with the former.
If you work in a highly monitored environment, all HTTPS transactions are decoded -- because typically there's a root cert installed. That is one form of an adversarial admin, say. You can limit HTTPS traffic to port 443, and only allow it if the firewall can see the full TLS handshake. You can maybe see China doing this, e.g.
The next step is to block all connections that can't be decoded by the root cert. That's not really that far off when you think about it. If it's not typical HTTPS/HTML traffic, the adversarial network admin can simply drop packets and connections.
A similar thing is happening today in Spain when a soccer game is on. If anything looks suspicious they pretty much block the subnet, because it's easier to block entire subnets than to figure out how to block the protocols that transmit the pirate stream. This is acceptable in Spain, I guess. I'm not sure why.
I'm arguing if an adversarial network admin decides to nix QUIC on the network because they can't detect a VPN, don't be surprised when it suddenly happens worldwide until QUIC helps them (or Broadcom, e.g.) figure out which streams are VPNs and which aren't.
You really don't want reliable transport as a feature of the tunnel unless you are _intimately_ familiar with what all of the tunneled traffic is already doing for reliable transport.
The net result of two reliable transports which are unaware of each other is awful.
The question is what does QUIC get you that UDP alone does not? I don't know the answer to that. Is it because firewalls understand it better than native wireguard over UDP packets?