Please sign in to comment.
Add tokens to the protocol
Tokens are added to the protocol in order to prevent IP spoofing attacks from being successful. A new flag has been added to the packet header, in previously unused space that has incorrectly been interpreted as part of the `ack` field (which needs to be 10 bits wide but 12 bits were used). The flags are now, in the first byte, from highest to lowest: - Compression - Resend requested - Connectionless - Control - Token If the token flag is present, the previously 3 bytes header is extended by 4 bytes that contain the token. This token was added in order to prevent IP spoofing to be successful. The connection setup now works as follows: The client (connection initiator) sends a `NET_CTRLMSG_CONNECT` message with a payload of at least 512 bytes, without the token flag. Bytes 5 to 8 of the payload contain the token that the server needs to play back to the client. The token flag isn't sent in order to maintain compatibility with servers that do not support the flag, they would interpret it as part of the `ack` field and drop the packet otherwise. The size requirement is in place to make the `NET_CTRLMSG_CONNECT` message useless for reflection attacks. The server (connection acceptor) sends a `NET_CTRLMSG_CONNECTACCEPT` message with the token field set to the client's token, and the first four payload bytes being the token for the established connection. The server does not save any data about this connection request, instead, it combines the client's IP together with a frequently rotated secret in order to obtain the connection token. This prevents the denial of service attack of sending a lot of `NET_CTRLMSG_CONNECT` packets to the server. The client now sends its first protocol message in a packet containing a token, if the server receives such a message, it allocates a client slot for the new connection, or sends a close message to inform the client that no slot is available for it. For backward compatibility, if `sv_allow_old_clients` is set to 1, the client continues to accept `NET_CTRLMSG_CONNECTACCEPT` messages without the token flag. This removes the `NET_CONNSTATE_PENDING` connection state (as that's only implicitly tracked now) and the `NET_CTRLMSG_ACCEPT` (as that message is unused on the other side and is unreliable anyway).
- Loading branch information...
Showing with 336 additions and 116 deletions.
Oops, something went wrong.