Feature Request: Implement RUDP Version Matching to Open Connection

[alec1o]

Description

I would like to propose the implementation of a version matching feature for RUDP connections, where a secure version string is used during the connection process. This feature ensures that only clients using the correct version of the application can establish a connection, enhancing security by preventing outdated or unauthorized clients from connecting.

Rationale

When updating an application, it’s crucial to ensure that clients using outdated versions are no longer able to connect. This prevents issues related to compatibility and security vulnerabilities. The version string should serve as a security key, making it difficult for hackers or cheaters to predict or spoof the correct version. By using a secure version string during the connection handshake, we can:

• Prevent clients with older versions from connecting to the server.
• Increase security by using a complex, unpredictable version identifier, making it harder for attackers to guess the valid version.
• Ensure that only authorized clients with the correct application version can establish a connection.

Proposed Solution

1. Secure Version String: Implement a version string that acts as a security key. This string can be in any format (e.g., vX.x.x, a GUID, or any arbitrary string). The key point is that the version string must match exactly between the client and server, and it should be complex enough that it cannot be easily guessed or spoofed.

2. Handshake Modification: During the handshake process, both the client and server will exchange and verify their version strings. If the versions do not match, the server will silently reject the connection, making it appear as though the server is not listening.

3. Security Considerations:

   • The version string should be complex and unpredictable, such as a GUID, to prevent attackers from guessing the next valid version.
   • Ensure that the version string is securely stored and transmitted to avoid leaks or tampering.
   • The use of a non-sequential version identifier increases the difficulty for hackers or cheaters to predict the version, thereby preventing unauthorized access using outdated or modified versions of the application.

4. Version Mismatch Handling:

   • If a version mismatch is detected, the server will silently reject the connection without providing any feedback to the client, making it appear as though the server is not responding to unauthorized or outdated clients.

Benefits

• Enhanced Security: By using a complex and unpredictable version string as a security key, the connection process becomes significantly more secure, reducing the risk of unauthorized access.
• Improved Compatibility Management: Ensures that only clients with the correct and up-to-date version of the application can connect, reducing the risk of bugs or security issues due to outdated software.
• Stealth Rejection: Silently rejecting connections from mismatched versions provides an additional layer of security by not revealing any information to unauthorized clients.

Implementation Considerations

• Decide on the best format for the version string, ensuring it is unpredictable (e.g., GUID) to prevent attackers from guessing the correct version.
• Ensure that the version string is securely integrated into the RUDP handshake process.
• Update relevant documentation to reflect this feature.
• Plan for backward compatibility or phased rollouts where necessary.

Additional Context

If there are any specific scenarios or examples where version-based connection filtering has been successfully implemented in other RUDP protocols like KCP, please provide them here. This will help in designing a robust and secure version matching feature.