Open markmandel opened 4 years ago
Go seems to have a DTLS implementation: https://github.com/pion/dtls In addition to that, I've had some interesting findings internally where a Go port of a Rust piece of networking code was MUCH faster in Go, I suspect this is because of the ease of parallelizing work in Go which is less there in Rust.
This might be the type of thing that warrants looking at Go again ?
https://github.com/sfackler/rust-native-tls/issues/136 - if we wanted to extend Rust libraries to support DTLS, this might be a good place to start.
Pure Rust implementation would be ideal though.
Although from all reports https://github.com/ctz/rustls is meant to be way more performant than OpenSSL. Shame the PR for DTLS never got finished.
One other thought I had. Maybe we shouldn't be doing encryption? Or maybe not as high a priority at least?
Godot has DTLS in it's stack, Unreal has a DTLS component, each type of UDP protocol, such as netcode.io or KCP includes encryption in their stack (often without the ability to turn it off).
Maybe we make encryption a much lower priority (likely focus then on routing and redundancy), since it seems like where the current state of affairs is at, people expect it to be part of their Game Server tech stack -- not pulled out of it (yet).
Thoughts?
Hmmm, that's an excellent point. In a perfect world, I'd like our routing token and anything we need to add to the packets for our filters to also be encrypted, but if games can deal with it on their own then that's much more of a "nice to have" than it would be if they did not ... It seems reasonable to downprio this in that case.
100% agree that our token routing needs to be secure - but it seems like we might have to handle that separately.
The only downside is, if we aren't decrypting content as it comes in, it's much harder to determine if it's an malicious packet at the proxy level. I wonder if we could use something like https://crates.io/crates/tls-parser as a filter to reject anything that isn't valid dtls.
Good point there, hmm ... We can't practically do much with our filters unless we deal with encryption and decryption ourselves in general, beyond declining syntaxically invalid packets, details depending on the crypto method, I suppose. 'This is perhaps a strong argument we should deal with crypto ourselves.
I think ultimately, we really need to do both. Because users will want both.
If we meet developers where they are now - we likely don't have to lead with encryption. If we want to lead them where we would like them to go, we eventually need to do encryption.
That would be my thought.
Here's an ongoing DTLS rust implementation for the rust webrtc project, it looks promising :heart_eyes: https://github.com/webrtc-rs/webrtc/tree/master/dtls
DTLS implementation is now here: https://github.com/webrtc-rs/dtls
Wasn't quite clear on how it could be used though. Will require some research I think.
Just noting that the dtls webrtc github repo now has an example for a dtls client and server: https://github.com/webrtc-rs/dtls/tree/main/examples
...and I just realised that this corresponds with a recent release: https://crates.io/crates/webrtc-dtls/versions
This looks like it's ready for use 🤔 😄
Just noticed that godot implemented DTLS into their UDP stack: https://godotengine.org/article/dtls-report-1 https://godotengine.org/article/enet-dtls-encryption
From initial review, DTLS gives us encryption, without the overarching of UDP reliability layer that Quic has.
That being said, I the best dtls libraries I've found are tied to openssl (I can't seem to find a pure rust implementation), which has portability concerns. But that was only a initial review of the ecosystem.
Resources:
https://users.rust-lang.org/t/announcing-udp-stream/35011 (tokio udp-stream lib with little documentation, but a dtls example which is pretty simple!) https://github.com/simmons/tokio-dtls-example https://github.com/ctz/rustls (dtls wip) https://crates.io/search?q=dtls