[ENet-discuss] DOS problem with connections?

[Kevin Deus]

   Maybe I'm missing something, but it looks like there's a possible
denial-of-service issue with ENet's connection scheme.  From the looks of it
(and from a previous post), the connection follows this sequence:

   Computer 'A' is the client, attempting to connect.
   Computer 'B' is the server, accepting connections.

1) A sends CONNECT to B
2) B receives CONNECT ->
    B reserves a Peer slot for this client, setting its
      state to ENET_PEER_STATE_ACKNOWLEDGING_CONNECT
    B sends ACK:CONNECT to A
    B sends VERIFY_CONNECT to A
3) A receives VERIFY_CONNECT ->
    A delivers CONNECT event
    A sends ACK:VERIFY_CONNECT to B
4) B receives ACK:VERIFY_CONNECT ->
    B delivers CONNECT event

   However, what happens if A isn't really a valid client, and all it's
trying to do is use up slots on the server so that nobody else can connect?
The sequence will stop after step #2, since the client will never respond.
And the server has already reserved a peer slot for that client.  The server
will keep that slot in use until enet_protocol_check_timeouts() times out on
the VERIFY_CONNECT packet.  ...which looks like it'd be about 16 seconds,
since the default round-trip time is set to half a second, and the packet
won't time out until 32* that amount.
   All that a malicious user would have to do to prevent the server from
establishing any new connections is repeatedly send CONNECT packets to the
server (either from one host or from a distributed collection of computers
using forged IP headers).  The server will use up all its peer slots and
valid clients won't be able to connect (except on the rare occasion where
the server has just timed out one of the invalid clients and it hasn't
received the next invalid CONNECT packet yet).

   If I'm missing something and this wouldn't be a problem, please let me
know..  ...otherwise I may poke through the code and look into a fix.