> Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way.
Or they are centrally/corporate-controlled and do not allow hole punching.
Wait? How does that work? QUIC REQUIRES CA TLS for all endpoints. So you can do the discovery/router workarounds but then the person trying to connect to you with QUIC won't be able to unless you have a signed corporate CA TLS cert. I guess you could integrate some Lets Encrypt ACME2 periodic updater scheme into your P2P program but that's getting pretty complex and fragile. And it also provides a centralized way for anyone who doesn't like your P2P tool to legally/socially pressure it to shut it down.
A good time to mention that the P2P Yggdrasil network uses QUIC/TLS selfsigned certs but then runs its own encryption over that. You can add as many peers as desired, and the network will automatically choose the best path (latency). So no multi-pathing but gets around the issue of changing IP addresses/network locations. Plus, it's able to do multicast to find peers in your LAN without having a centralized control server. I'm actually getting better speeds than WireGuard over my LAN - but this is a stable link. Once you start sending the yggdrasil packets over long unstable links you may start to get into funky issues like TCP in TCP head of line blocking, but they try to mitigate this by having huge MTU sizes and packet dropping algorithms. (https://yggdrasil-network.github.io/2018/08/19/congestion-co...)
Ok so you need to trust each other's certs. What's the big deal? Presumably you already have some other channel to share addresses so you can also share temporary self signed certs for this purpose.
I'm working with QUIC in a personal project, while you can roll your own QUIC library the spec is large enough that it's quite a bit of work to implement it yourself. Most libraries allow you to pass in your own certificates. Realistically you could just bake in certs to your program and call it a day. Otherwise yes, you can implement your own cert logic that completely ignores certs altogether. s2n-quic for example specifically allows for both, though the former is much easier to do.
I guess most if not all QUIC endpoints you come across the internet will have encryption, as the specification requires as such. But if you control both ends, say you're building a P2P application that happens to use QUIC, I don't think there is anything stopping you from using an implementation of QUIC that doesn't require that, or use something else than TLS, even if the specification would require you to have it.
Just as long as you statically build and ship your application. Because I guarantee the QUIC libs in $distro are not going to be compiled with the experimental flags to make this possible. You're going to be fighting QUIC all the way to get this to work. It's the wrong choice for the job. Google did not design QUIC for human use cases and the protocol design reflects this.
Judging (guessing) by the author's GitHub profile (https://github.com/marten-seemann), seems they've built their own "pure Go" QUIC implementation, maybe precisely for those purposes :)
Maybe success rates are higher with UDP – I don’t know. But it certainly works to hole punch with TCP as well. If you’re lucky you can even run into a rare condition called ”TCP simultaneous open”, where both sides believe they are the dialer.
First time I've heard about this, and went looking for more. Came across https://news.ycombinator.com/item?id=5969030 (95 points - July 1, 2013 - 49 comments) that had bunch of background info + useful discussions.
It can be done, but it's less reliable and also requires the ability to forge packets that is not allowed on all platforms. So it's hard to use in any production application if you want it to run in user space, on Windows, or on mobile.
It seemed like there was such a good exciting start, but the spec has been dormant for years. https://github.com/w3c/p2p-webtransport
Or they are centrally/corporate-controlled and do not allow hole punching.
https://yggdrasil-network.github.io/documentation.html
I'm currently working on creating a managed Yggdrasil relay node service. A feature I hope they implement is QUIC multistream support.
For TCP based protocols it's very hard since there is no reliable way to hole punch NATs and stateful firewalls with TCP.
First time I've heard about this, and went looking for more. Came across https://news.ycombinator.com/item?id=5969030 (95 points - July 1, 2013 - 49 comments) that had bunch of background info + useful discussions.