If you encode each packet in a QUIC stream with it's own stream ID, and close QUIC streams after a timeout, you can use QUIC for unreliable unordered transports as well.
UDP for games – encryption and DDoS protection
21–30 of 47 posts
Re: UDP for games – encryption and DDoS protection
#22>As a side bonus, with proper encryption you can be sure that network errors which corrupt your packets are not going undetected Shouldn't you be verifying a MAC before decrypting anyways? Relying on decrypting scrambled data, especially for a bitflip, seems like a bad idea. >Potential attack here is about attacker modifying the (unencrypted/unsigned) data coming to the victim’s Client, So establish a session key, an…
> Shouldn't you be verifying a MAC before decrypting anyways? Relying on decrypting scrambled data, especially for a bitflip, seems like a bad idea.
Oh, we're going into the realm of MAC-then-encrypt vs Encrypt-then-MAC, which is waaaay out of scope of this book. As it's mentioned in some footnote, under "encryption" I've meant "the whole package, including encryption, integrity authentication, etc." (which is currently routinely done by some kind of AEAD for wired data). I certainly don't want to go into a deep crypto-level discussion of AEAD etc. in a book for app-level developers; what I'm aiming for here, is a simple recipe of "just do it this way, it will work".
> Why not just use TCP for sign-in and key establishment, and get 3-way handshake for free. That eliminates spoofing IPs. From there, just have monitors that determine when you're "under attack" and rate limit by IP address, just like any anti-DDoS does.
But then, for UDP (and you DO need UDP for fast-paced games) you will need your own protected protocol (probably using keys exchanged over TLS-over-TCP). There are many ways to do your own protocol wrong, and only a few to do it right; and if an average app-level developer will try doing it - it is much more often a disaster than not :-(. As a result, I am arguing for using standard security protocols wherever possible (and the anti-DDoS hack described there keeps DTLS security intact, this IS important).
Re: UDP for games – encryption and DDoS protection
#23> Both known-to-me implementations of CurveCP (NaCl and libchlorium) seem to be pretty much abandoned as of beginning of 2016, libsodium (the continuation of NaCl) is actively maintained.
Last thing I've heard was that specifically CurveCP was separated from libsodium into libchlorium, and it is not maintained now.
Re: UDP for games – encryption and DDoS protection
#24> DTLS and QUIC And, of course, the mother of all datagram encryption protocols - the IPsec suite (ESP, IKE 2). It works with IP packets, but it can be very easily repurposed for UDP.
You're right, I forgot about it. But is there a ready-to-use library doing it?
Re: UDP for games – encryption and DDoS protection
#25> ...if some artifact within your game costs $20K+ of real-world dollars – you should start thinking about [encryption] seriously. In these cases, game account becomes as important as (and for quite a few people out there – much more important than) a bank account. Which carries all the security implications of the bank, including (but not limited to) encryption. Sorry to nitpick but UDP seems like the wrong protocol…
> Sorry to nitpick but UDP seems like the wrong protocol for authentication.
While authentication over UDP is indeed a bit more difficult if implementing it yourself, fortunately there is DTLS which is a very official and well-recognised way to implement authentication over UDP (very briefly - DTLS does make a handshake, and it does have a session, but this session operates in a packet-oriented mode which supports reordering and packet loss).
Re: UDP for games – encryption and DDoS protection
#26Earlier quoted context omitted.
This is some old code, based off of the hashcash algorithm, that prototypes protecting DNS servers using a proof of work (also UDP). https://github.com/jevinskie/SlothNS/blob/master/pow/pow.c#L...
Maybe I'm misunderstanding things - is this a particular algorithm (that I could look up in a textbook for example?)
After looking into it more, I think the implementation is more Coelho et al than hashcash. Sorry, this was long ago for me.
Re: UDP for games – encryption and DDoS protection
#27Doing a lot of crypto at work so this article was super interesting. My god though, those illustrations are gorgeous.
Re: UDP for games – encryption and DDoS protection
#28>As a side bonus, with proper encryption you can be sure that network errors which corrupt your packets are not going undetected Shouldn't you be verifying a MAC before decrypting anyways? Relying on decrypting scrambled data, especially for a bitflip, seems like a bad idea. >Potential attack here is about attacker modifying the (unencrypted/unsigned) data coming to the victim’s Client, So establish a session key, an…
BTW, when I've wrote about those "undetected network errors", I've meant those-network-errors-which-arise-in-UNENCRYPTED-packets (as 16-bit UDP checksum is certainly not enough for this purpose). And DTLS etc. take care of packet corruption themselves (actually, they consider it an attack).
Re: UDP for games – encryption and DDoS protection
#29> ...if some artifact within your game costs $20K+ of real-world dollars – you should start thinking about [encryption] seriously. In these cases, game account becomes as important as (and for quite a few people out there – much more important than) a bank account. Which carries all the security implications of the bank, including (but not limited to) encryption. Sorry to nitpick but UDP seems like the wrong protocol…
TCP and UDP occurring over the same route on a WAN can wreak havoc with UDP packet loss.[1] Using both is only a good idea up until you dig deep into socket performance. A network is not a piece of software where you can isolate things and expect them to behave in an isolated way, everything you push over it interacts with everything else that you are pushing over it. This "use UDP and TCP" is a dangerous anti-pattern because it seems to be an obvious solution from a software perspective, but is in reality a problem from the electron perspective. To paraphrase a famous quote:
> Some game developers, when confronted with a TCP problem, think "I know, I'll add UDP." Now they have two problems.
Games that implement their own protocol over UDP typically have packet modes (frequently a "channel" akin to WebSocket channels): reliable, ordered delivery or neither or either. There is almost always the notion of a connection, where appropriate. This is the correct way to do things, and with Raknet now being free you really have no excuse to do it any other way.
For authentication you could just use the reliable/ordered channel and carry on as though you were using TCP - which somewhat defeats the purpose of this article.
Re: UDP for games – encryption and DDoS protection
#30Can someone please explain me as if I was 5 years old how the proof of work is performed ?
Like Bitcoin, you can ask clients to find a hash of a string (in the format of, say, 'server_key' + 'random_number' + 'client_adjusted_nonce') with the value of the last four bytes being higher than say 50,000. You can increase the value until 0xFFFFFFFE, where only 1 in 4294967296 hashes would 'pass' the test. Your client will basically be working on passing the test for a predictable amount of time, dependent on th…
[deleted]