Share via

5.1 Security Considerations for Implementers

  • Article

The following security considerations pertain to the DirectPlay 4 Protocol:

  • The DirectPlay 4 Protocol was not designed to be a secure protocol. Any application that requires end-to-end security would need to implement secure identity, and possibly encryption and/or packet signing. This is no different than the case where applications are built on sockets.<23>

  • The only exploits that are prevented in DirectPlay 4 are problems where the formatting of a message could lead to a buffer overrun or cause a computer to crash. Since DirectPlay 4 was a sufficiently complex and proprietary protocol, used primarily in the domain of game applications, it was not anticipated that there would be much point in attacking the link. If an application required to secure a link, it could use the secure modes and packet signing that would prevent such exploits as mentioned above.

  • The DirectPlay 4 Protocol does not perform validation on the sender of a message. An implementation might choose to validate the sender of a message, but it is not a requirement for compatibility with DirectPlay.

  • Player IDs are assigned by the game session host and as a result, a new player has no way to "force" itself to become the new host. For more information, see section 3.1.7.1.

  • Although player IDs are allocated sequentially (starting from a random value), the random value is XOR'd with a secret value to generate the player ID. As a result, there is no guarantee that the distributed player ID values will be sequential. From a security perspective, this manner of allocation is helpful because it generates values that cannot be easily guessed. If an implementation were to attempt to spoof a game and join the game session by accurately guessing a player ID value, the implementation would also have to recognize the secret value in order to be able to guess the next player ID.