Is it safe not to encrypt ping packets?

Question

I am running encrypted communication with ping tacked on after decryption and deserialization is complete.

I.e.

incoming data -> split into packets -> decrypt -> deserializer -> actual message or ping

outgoing message or ping -> serializer -> encrypt -> send

I would prefer ping be handled before any decryption happens and make it part of the lowest socket layer instead.

What I wonder is if I introduce any weakness this way. (The actual crypto layer may be TLS or similar.)

I don't see how manipulating the unencrypted ping would enable much, given that I only use it to test the liveness of the connection and get a RTT.

Am I overlooking something?

EDIT:

Just so this is clear - it relates to a custom server-client protocol for a game. The "ping" here is simply a special packet periodically sent from server to client and then back again.

This helps both client and server ensure that communication is open: one can implement the check "if ping isn't seen within x seconds, assume that the connection is broken".

Answer 1

Your question is quite unclear on the particulars, so I assume that you mean the following:

• You have some sort of VPN going on between machine A and machine B, and the VPN encapsulates all IP packets from A to B and from B to A within an encrypted tunnel which probably uses SSL/TLS for the encryption part.

• The VPN picks up all packets, whether they relate to TCP, UDP or ICMP.

• You are wondering whether making the ICMP Echo packets (aka "ping") travel outside of the VPN, unprotected, would open vulnerabilities.

Under these conditions, the answer seems to be "no, it does not open any vulnerability", under the following argument: VPN protection is about protecting some specific traffic, between A and B, against interference from outsiders. As long as your "important traffic", the one you wish to protect, still goes through the VPN, then that traffic will keep on being protected. Note, though, the following points:

• It may be hard to configure a VPN software to exclude, explicitly, ICMP Echo requests and replys, but still include TCP and, crucially, other ICMP message types. While the "ping" protocol is pretty benign, some other ICMP messages can be important for proper network traffic propagation. Also, since a "ping" consists in a request and then a reply, both ends of the tunnel (machines A and B) should be configured to not-protect the ICMP packet.

• You do a "ping" for a reason. If the "ping" is unprotected, then it can be altered by attackers, which may impact the reason why you do the ping. Attackers could block either the request or the reply, simulating a "down" machine (arguably, if they can do that, they can also block all the VPN traffic as well, so that point could be quite moot).

• A "ping" going outside of the VPN tests whether the machine on the other side is up and running, but, by definition, it will not test whether the VPN link is also up and running. The other machine could be up but the VPN service down, and then the "ping" will not tell it to you. Thus, handling the "ping" outside of the VPN does not offer the same functionality as an in-VPN "ping".

• Similarly, in many VPN setups, one of the machines actually is a complete local network containing many machines with private IP addresses. A "ping" request going through the VPN can be directed to any of these machines with private IP. A "ping" outside of the VPN can reach only machines with a non-private, Internet-reachable IP address, i.e. the VPN gateway. There again, functionality is different.

This also begs the question: why would you want an "unprotected" ping ? The only reason I see is when the VPN appears to be down or unresponsive, and you want to know whether the culprit is the VPN software on the other side, or the network in-between.