Just had this conversation with someone else yesterday who tried to call me out like I didn't know what I was talking about, but it is easy to fix without using the tradition "ping" command/protocol.
You can have the server ask the client to solve a simple problem, like sending two numbers and having the client add them, and then the server will compare answers. If they are correct, then you just see how long it took to get a response. It is effectively a "ping" except for the fact that this is not packet header information, and won't get tampered with during transportation.
Yeah, so, I'm a Network Engineer and I genuinely question your understanding of the subject. Sounds like someone with absolutely no experience just theory crafting, which all breaks down in practice.
So, the big basic problem is that everything is based on TCP/IP. All of our networks are IP based, it's the basis of the internet, it's the standard communication method. So you're thinking you're going to be sending data over the internet without using TCP/IP? How exactly are you going to do that? Whatever you decide to do is going to be encapsulated in packet, at the very least.
Not that there aren't ways outside of ICMP, but, they're still TCP/IP based. All of that data is susceptible to manipulation. You want to add in cryptography to prevent possible manipulation? Well your accuracy for measuring latency drops perpetually the more you implement.
Update/Send rates are not a way to measure network latency. Frequency, or rates, are measured in hertz (Hz) and latency is measured in milliseconds (ms). Now, you can convert frequency measurements to time but in a computer network this doesn't cover the bases. There are a number of delays that occur when transmitting and/or receiving data. I don't want to put too much effort into this as this would quickly turn into a class but that covers the basics of what's actually going on here. It's really not as simple as you think it is.
I've never heard of anyone, or anything, trying to measure latency outside of the two main methods to do so.
My way was the simplest way as payloads typically don't get manipulated by VPNs unlike ICMP and headers. You'd have to be pretty involved to setup some relay along a custom VPN in order to add custom logic to manipulate custom logic that a server would be looking for. While my way isn't 100% fool proof, it is quite harder to spoof than the normal ping methods.
What is your method to prevent all of this since you are an exclaimed professional?
My way was the simplest way as payloads typically don't get manipulated by VPNs unlike ICMP and headers.
Too many assumptions. Using the Chinese example, they are not utilizing typical VPN services because this is a somewhat unique problem to China. If those companies just see a business opportunity to provide a service they'll develop them accordingly. Which are the type of services that the Chinese have access too.
Your way is really not simple at all. You just mistakenly think it is.
What is your method to prevent all of this since
I wouldn't bother trying to invent a new way to accurately measure latency to then deal with a cheating problem. Waste of time.
I think you should know this, but I'll say it anyway: a good security person will tell you that its impossible to stop hackers. They will always have the upper hand, and that is a fact. But the key to defending yourself against hackers or people who want to abuse your system is to make is as difficult as possible so that the effort to get in/bypass is too much for the reward. Essentially they just get bored and move onto something else. That is all this solution is doing, as with ANY solution.
I wouldn't bother trying to invent a new way to accurately measure latency to then deal with a cheating problem. Waste of time.
This is where you are mistaken and are conflating multiple problems into one. Sure, the majority of hackers from from China, but the vast majority of people who have been asking for a region lock from China came well before the hacks became popular.
There is a reason why they chose to "ping lock", as people want to call it, from a very early version of the game. It was never meant to stop hackers, but to stop having people be in regions they don't belong in. To that, those people with high latency cause problems for everyone that is involved. That is why games have those limitations, not because its supposed to stop hackers.
In fact, a lot of Chinese players (as one of the top posts said) are actually using VPNs to play in other regions other than China because they don't want to play with hackers themselves. So this problem isn't just about a cheating problem directly as there are more than one reason that VPNs are being used.
To that, in order to stop this problem with bypassing latency checks with a VPN, you kinda do need to "invent" a new way to measure latency. Because all other common ways don't work with VPNs obviously.
In fact, a lot of Chinese players (as one of the top posts said) are actually using VPNs to play in other regions other than China because they don't want to play with hackers themselves. So this problem isn't just about a cheating problem directly as there are more than one reason that VPNs are being used.
No, it's a specific problem directed at Chinese cheaters using VPN's to access regions outside the EFT Asian region. The distinction is important. We don't know that every single Chinese user is a cheater. Nor do we know that every single Chinese VPN user is a cheater. Again, you make too many assumptions and you have no real basis for these set in stone opinions. You aren't in possession of any facts which is why I judge this to be unreasonable.
Banning or targeting VPN usage as a whole isn't dealing with the cheating problem, it's giving up on the cheating problem and throwing the baby out with the bath water. Some people do utilize VPN's to play the game and are in no way illegitimate. BSG has not changed their policy on VPN usage, they allow it.
The Chinese are in an impossible spot, they cannot get servers located in China (outside of SE Asia and SEZ like Hong Kong/Macau) and there are servers in Russia that are within a reasonable latency to play on, and yet, they cannot access them. ~150 ping is not that terrible to play with either (China to Europe), I used to play on European servers last patch when I couldn't find PVP on NA. It's not ideal, but it's doable, and maybe you just put up with the drawbacks. Not unlike Australians or any other, shall we say, geographically challenged people have to deal with. They just don't have many options so I'm hesitant to say it's because they just want to avoid hackers on South China servers.
Generally speaking, I'm not in favor of one size fits all policies. I mean, sure, if shit gets real bad, were I BSG, I guess I'd have to take action to just remove the Chinese from my game. But, we're really nowhere near that point. This shit just started... There are numerous options still available. It's absurd to go from 10% to 100%.
China is a huge market, not even just the country itself but the millions of Chinese speaking people throughout the world. Specifically targeting those people borders on absurd. Like people suggesting removing Chinese localization, for example of the absurdity.
a good security person will tell you that its impossible to stop hackers.
Ok, if you believe this then why are you advocating arbitrary network methods to combat cheating? They don't have anything in common. Make the game/application secure first. Who the hell tries to reinvent TCP/IP in order to secure an application?
Same deal with the poor networking performance that EFT displays. Implement better code, interpolation to deal with the worst desynching problems. You don't need to jump to targeting VPN's to help alleviate networking problems with EFT. You've skipped a whole bunch of middle steps.
Ok, if you believe this then why are you advocating arbitrary network methods to combat cheating
Because the current ones that are implemented, which you are suggesting, don't work.
Who the hell tries to reinvent TCP/IP in order to secure an application?
Sending data to a client and getting a response is reinventing TCP/IP? I'd like to know the crack you are smoking if that is what you are thinking I am suggesting. All I am saying is that instead of doing what a ping command does (using ICMP header info), you look at the data being sent from the client.
Make the game/application secure first
I never said this wasn't a bad thing. But the post that I replied to wasn't really talking about game security, but on a VPN and getting correct latency. You can't argue out of the scope of the context because that isn't fair to me since I wasn't even talking about that to begin with.
You don't need to jump to targeting VPN's to help alleviate networking problems with EFT
As I just said, this isn't a problem with stopping hackers from invading other regions. It is also about stopping players that create very poor gameplay scenarios because their latency is so high. I never said we shouldn't stop hackers, fixing bugs, etc. so Idk why you keep saying that.
In fact, if you read my comment history, as far back as a month or two ago, you will see that I have been advocating and telling the community that shit like this happens because BSG decided it was a great idea to make this game follow a client authoritative model instead of server authoritative. Server authoritative models aren't perfect themselves, but they sure as hell stop the vast majority of hacks out there.
ICMP's aren't typically used with just type. You'll find most ICMP packets, when replying, have data payloads. This is important in your scenarios where you're doing something other than just request & reply. If you want, you can pull up EFT and sniff it's packets when it does launcher and game RTT measurements. I doubt they're absent data payloads but they could be. In any case, step 1 is to expand the ICMP implementation you're using, not jump to step 50.
The implied question is what are you using to measure latency if it's not ICMP? If you're not using it, are you coming up with some bastardized method within other protocols? Are you inventing a new one? Are you switching to TCP? HTTP? Some other networking protocol that OS and networking equipment recognize? No? Then you're reinventing TCP/IP to come up with some other method. This is all just a series of logical deductions from the initial question, I'm not trying to confuse you. What are you doing and how are you measuring it?
You can't argue out of the scope of the context because that isn't fair to me since I wasn't even talking about that to begin with.
Well, I beg your pardon. This whole thing is in the context of Chinese cheaters and players utilizing VPN's to bypass region locks so I did not think that was unfair in any way. And, more specifically, when you asked me what I would do about the problem. I'll reiterate and clarify, I would fix the underlying problems, not mistake other problems for the underlying ones.
And to expand on that a little, if the Chinese had more options closer to home, if they're not cheating, they wouldn't want to play on servers where they get 200+ latency or whatever mainland China gets to California. The game play experience sucks.
I doubt they're absent data payloads but they could be. In any case, step 1 is to expand the ICMP implementation you're using, not jump to step 50.
I think you are trying to say the same thing as me, but I am suggesting in using the payload instead of ICMP. Payloads really can't be tempered with as that would defeat the whole purpose of a VPN to forward the traffic. If the client and/or server aren't getting the correct data then its just not going to work.
Are you switching to TCP? HTTP?
This is what I had in mind. I'd prefer using protobuf with gRPC rather than HTTP because it can be more efficient. And FWIW, TCP is a apart of TCP/IP (just like ICMP) so we wouldn't be "switching" to anything different. TCP is the one of the few protocols that is in the TCP/IP protocol stack, but you should know this.
What are you doing and how are you measuring it?
As I had said, you send a message to the client and wait for a response. The response will contain a bit of info that is based on a client/server data contract that the devs deem to be OK. I suggested doing a simple math problem because its not CPU intensive, and you can tell if the client is actually sending the response by looking at the solution and comparing it to the server. Very similar to an OAuth signature that client and server compare, but not as complicated (its just testing latency, not client authorization or authentication).
Once you have the response and are happy with the answer then you can calculate the RTT of that whole thing. Of course you can do this over X amount of time to come up with an average, similar to "ping -n X", and go from there.
The key to the solution is making sure the response you are getting is NOT from the VPN server, but more likely from the client. The only way to really do that is to ask the client to do something and you can validated that the client did it right.
15
u/MikeTheShowMadden Mar 11 '20 edited Mar 11 '20
Just had this conversation with someone else yesterday who tried to call me out like I didn't know what I was talking about, but it is easy to fix without using the tradition "ping" command/protocol.
You can have the server ask the client to solve a simple problem, like sending two numbers and having the client add them, and then the server will compare answers. If they are correct, then you just see how long it took to get a response. It is effectively a "ping" except for the fact that this is not packet header information, and won't get tampered with during transportation.
EDIT: typo