&gt; Shouldn&#x27;t you be verifying a MAC before decrypting anyways? Relying on decrypting scrambled data, especially for a bitflip, seems like a bad idea.<p>Oh, we&#x27;re going into the realm of MAC-then-encrypt vs Encrypt-then-MAC, which is waaaay out of scope of this book. As it&#x27;s mentioned in some footnote, under &quot;encryption&quot; I&#x27;ve meant &quot;the whole package, including encryption, integrity authentication, etc.&quot; (which is currently routinely done by some kind of AEAD for wired data). I certainly don&#x27;t want to go into a deep crypto-level discussion of AEAD etc. in a book for app-level developers; what I&#x27;m aiming for here, is a simple recipe of &quot;just do it this way, it will work&quot;.<p>&gt; 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&#x27;re &quot;under attack&quot; and rate limit by IP address, just like any anti-DDoS does.<p>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).