Preventing artificial latency or "Lag Hacking" in multiplayer games
I see two conceptual paths for dealing with lag attacks:
Punish lags. When an "artificial" lag is detected, evict the offender and enforce a ban period. This is hard to do in practice because there is a delicate balance to be found between people who cheat through lagging, and people who simply suffer from an occasional hiccup in their Internet connection. It is bad business practice to smite your own customers. Such kinds of solutions will necessarily end up with a threshold to distinguish between bad people and unlucky people. Cheaters will stick close to the threshold and this will probably be sufficient to gain some strategic advantage.
One promising approach along the punishment line is to apply small but cumulative penalties for each lag: whenever a packet is lost or shows up late, remove one hit point, make the player flash, whatever... this can even be integrated in the game universe (for instance, for a FPS convert the detected lag into a rifle jam). This implies that people with reliable Internet connections and big computers will be at an advantage -- and I believe that players are ready to accept that, on the basis that similar things happen in a lot of other leisure-competition situations (e.g. if your hobby is skateboarding, you know that a better skateboard will not replace talent, but will help nonetheless, and skateboarder accept that as a fact of life). Ultimately, this might incite ISP to work a bit on their latency, which would be good for everybody, not just gamers.
Don't trust clients. Massively online games are distributed computing. Most of their security issues are due to the fact that many game rules, i.e. the properties of the world in which the players act, are maintained by the client systems. The players themselves, and in particular the potential cheaters, have extensive control of their machines. Existing countermeasures tend to have limited effectiveness for the same reasons that software DRM and antivirus may fail: this is an arms race in which attackers and defenders are locked into a fast-paced battle of patches and counterpatches which is tiresome and requires expensive, continued maintenance.
The generic architectural response is to maintain the game rules server-side only; clients become "thin" and are just display interfaces. This is unfortunately hard to implement, because display performance (hence game experience) becomes very sensitive to latency, artificial and natural alike; and ADSL links will have a minimal latency close to 50 ms, which is high with regards to average gamer reflexes. Also, this means that the game servers need more CPU muscle. But the security advantage is huge: when a player induces lagging, he inherently punishes himself and none other.
Maintaining all game state and rules on the servers is not completely science-fiction either. Back in the late 1980s, one of the very first MMO games was "CarCrash", an offspring of the defunct French magazine Jeux et Stratégie; it was played over the Minitel, another old French technology where users simply had text terminals (with limited graphics) with no local computing abilities; the central server(s) maintained the game rules and computed the screen updates for everybody, and it worked. Computers at that time had far less CPU muscle than today; a 20 MHz CPU was enough to be deemed a "supercomputer". A 35$ home router of 2013 is more than ten times as powerful as a big server of that era. And yet it worked.
Maintaining game rules on the server implies departing from the way games are usually architectured. Historically, most games were local and became multiplayer by connecting clients with each other, with possibly a central server which only served as rendez-vous point. To take a political metaphor, games became multiplayer by forming confederations, but security against cheaters requires a federation.
Mixed strategies are possible, of course. The core idea is the same: give as few sensitive data as possible to client systems; and when you must trust them for something, use a big stick or a big carrot to maintain them in line.
(If you understand that players should be handled like cattle herds, well,... there is truth in that, indeed. You don't want your cows to be unhappy, but you will not let them choose their walking direction and pace either.)
Edit: just got an insight while waiting for my tea to cool a bit. A game architecture could include several (possibly dozens) of cooperating "trusted" servers spread worldwide, which "play the game" like game clients do today. Each gamer would connect to one server which is "close by" (in a network sense) so as to have a low latency, allowing for the display-only strategy outlined above. If ISP themselves can be involved in the deal (each ISP would host a few servers in its own infrastructure) then this could make sense in a business way.
With tongue only partly in cheek, I'm going to suggest that Xbox Live already has controls to limit the damage caused by lag switches. I'm going to channel my inner Schneier and say that where technical controls may be problematic to implement, reactive and societal controls are perfectly valid options:
- Mark the player to "Avoid" - makes it unlikely you'll get matched up with them again
- File a complaint for "System Tampering" - makes it possible their account will be revoked
This has proven to be an effective set of controls against the "mod" hackers in the game I play regularly, "Call of Duty: World at War". The one difficulty I see is that lag switching is difficult to prove; unlike someone flying through the air with noclip, it's not unusual to see innocent players with laggy connections that seem to help them sometimes.