Hey everyone,

I'm using Electron, and since I have access to their net package (nodejs), I've been doing some P2P testing lately. I have an authorization server that handles all game logic. But, I wanted to switch to a P2P approach for only movement outside of PvP for testing. I know it's not ideal, but I'm just playing around with it for now.

Anyways, with that said:

Someone could easily get the IP of someone their connected to. Thus, let's say Player A is connected to Player B and are in a game together moving around, communicating fine.

Then, Player B logs off. Player A gets notified by this, by the authoritarian server.

But, there is one catch. Lets Player B sniffed Player A's IP address and then connected to them and just starting to send movement signals all over the place. (Without even being in a game).

Or dos/ddosing that user.

This basically opens up a huge can worms, right? Am I getting all of this right, or is there something I'm missing? :P Maybe create a UUID that expires, that is needed for two clients to connect? But then again, unless their firewall is modified they can still cause massive harm to that player? (Even with a firewall, UDP/etc can still do decent dmg)

Sorry I'm kind of all over the place here, I'm just curious do I have the right train of thought? (P2P = Hacking/Cheating/abuse is inevitable), 100%?

Thanks ~

>> (P2P = Hacking/Cheating/abuse is inevitable), 100%?

ANY networked software - not just games - is vulnerable to abuse.

in network computing overall, a client-server model probably is easier to secure than a peer-peer model - as you can usually at least secure the server side pretty well.

false transmissions, data sniffing, and data destruction are things all networked systems which someone might potentially abuse must deal with.

> dos/ddosing that user.

Yes, it is possible. A centralized star architecture where players only know the address of the server does not necessarily expose the addresses of other players.

Attacks are possible from anyone on the public Internet, so that is nothing new. Anybody can attempt a denial of service attack on any IP address.

> Player B sniffed Player A's IP address and then connected to them and just starting to send movement signals all over the place. (Without even being in a game).

Not likely. Each connection is a 4-tuple of {source IP, source port, dest IP, dest port}. For connection-based systems when the game ends the connection will end too. Establishing a new connection will require a new handshake which you don't have. Your own game is going to have its own protocol and rules to follow, so being outside the game and influencing the game is not something they can do unless you build that in to your protocol.

It is possible for someone to introduce their own proxy and play the game through the proxy, then maliciously introduce additional commands while they are in the game. That is a standard attack vector. The solution there is to never trust anything coming over the wire, always validate all input, no exceptions.

> (P2P = Hacking/Cheating/abuse is inevitable), 100%?

There are attack vectors in all networked software. When the software is popular enough someone will want to attack it.

Defending against all possible attacks is not really possible. Figure out what the most realistic attacks are against your system. Then either design your system so the attacks do nothing, or write code that defends against those attacks. Don't worry about the rest.

Someone could easily get the IP of someone their connected to.

This is a real risk of peer-to-peer games (or any other system) on the current Internet. Rage booting services are cheap, and people with an inflated sense of entitlement and common.

The game rule bits are relatively easy to solve. The authorization server could issue a token to each player; each player when connecting to another player would provide a signature of some challenge, and that other player would then verify the signature with the auth server. This avoids the "you're not supposed to be here" problem.
However, rules enforcement, and outside-the-game shenanigans like DoS-ing, aren't under your control anymore. If you use a fully lock-step system with no late joiners, like most RTS-es, then you can detect that <i>someone</i> in the game cheated, if there is a rule-breaking move, but you'll never be certain of who it was (voting rings are a thing.) And information leak cheats wouldn't even be visible on the network -- if I had a side screen that showed me all your units in an RTS at all times, I'd have a significant advantage!
If your game has any kind of persistent value (level progress, monster loot, mining resources, ...) then trying to keep that cheat-proof in a peer-to-peer system is a losing battle.

If you plan to make a real business out of your game, carefully consider these challenges! Servers are cheap, relatively speaking.

Thanks Frob, hplus, and Norman. I upvoted your posts, but will respond just once to everything :P

However, rules enforcement, and outside-the-game shenanigans like DoS-ing, aren't under your control anymore

This really put the nail in the coffin for me.

I am definitely going to incorporate the token/key to each player before connecting. As hplus said, I guess anything further than that, is beyond the scope of what I can do. Which makes me feel sad because obviously I cannot do anything else, but happy because now I don't have to think about it anymore :)

Thanks guys so much, your information here is really invaluable. I cannot see me asking these types of questions on StackOverflow or whatnot without getting shot down so I appreciate it!

You just need better authentication / encryption.

Basically, never work with raw sockets and IP addresses directly, if you can avoid. Negotiate P2P secure connections, preferably via a secure server, which can also help with the NAT punch-through and packet reflection.

Even then, don't trust the data send by clients. But it's more about game hacks and exploits, and how your game handles cheating, rather than a straight-up security issue.

Roughly how it looks in APIs such as XBox Live, PSN ...

1) player A creates a game session. That game session then resides on a secure server.

2) player A registers himself with the game session (probably part of the game session creation process anyway).

3) all communications between game server and player A are uniquely encrypted and secure.

4) player B searches for the game session.

5) player B finds the game session, then registers himself with the game session.

6) all communications between game server and player B are uniquely encrypted and secure.

7) player A gets notified by the game server that player B is registered with the game session. Received security information on how to connect to player B.

8) player B gets notified by the game server that player A is registered with the game session. Received security information on how to connect to player A.

9) Player A, or player B, or both then attempt to connect to each other. Their communications will be encrypted, and only decipherable by them (ideally).

and so on...

The game layer sees secure addresses being established under the hood, with payloads coming in. The game code doesn't really deal with raw IP's any more (on steam, it's just player Steam Ids). Which makes it a little bit tricky as far as debugging is concerned, but hey.

Encryption typically protects two people behaving well from having a bad actor inject stuff or usefully eavesdrop.

Encryption doesn't help if the person on either end is a bad actor. They can encrypt stuff that violates your protocol all they want and send it over the secure connection.

Think of encryption as an armored car service. If both sides of the transaction are behaving all is well. It doesn't matter how good the service is if the person sending the packet is the criminal sending a bomb or shorting you money; the service will securely transport the bomb or the insufficient funds. If either side is a bad actor then encryption doesn't help much.

So yes, encrypt your data for the good guys, so they can have secure transport and be secure from some attacks. But no, don't assume all data over an encrypted line is valid. Attackers can use encrypted connections, too. You still need to validate every byte that comes across the wire.

The reason Xbox Live and PSN can use peer-to-peer networking is that the hardware is locked down against players injecting their own code.
This is also one reason why they ban all consoles that seem like they're hacked/cheating/rooted.
On PC, you don't have that luxury. The rules are completely different!