(no title)
tbocek | 3 months ago
https://github.com/tbocek/qotp and https://github.com/qh-project/qh
The main idea is to have a simple encryption (ed25519/chacha20+poly1305) for encryption in the transport layer, on top of that then qh, where certs are use for signing content.
With out of band key exchange, you can establish a connection after you successfully punched a hole.
However, its not QUIC compatible in any way (https://xkcd.com/927)
throw0101d|3 months ago
"Cannot" is a strong word:
> UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint.
* https://en.wikipedia.org/wiki/UDP_hole_punching#Overview
I've also heard lots of people complain about how they're stuck behind CG-NAT and various P2P things do not work.
octoberfranklin|3 months ago
This link is 404.
QOTP looks really cool. Like what QUIC would be if DJB were in charge of it.
tbocek|3 months ago
Imustaskforhelp|3 months ago
jcelerier|3 months ago
... how does that work when the network disallows UDP altogether?
octoberfranklin|3 months ago
If you're really really desperate you can send UDP packets with fake TCP headers (i.e. you aren't actually doing any congestion control or retransmission) but you have to control both ends of the connection for that.
And there's ICMP.