[ENet-discuss] DOS problem with connections?

[Lee Salzman]

Well, there are probably a bunch more DoSes hiding in ENet. I never
really went through hardening the protocol against such stuff just
because it was not an issue for what I was using it for on the time. But
if someone *cough* would like to audit it for this sort of thing and
submit sane bug-fixes, that's A-OK with me. :)

Lee

On Wed, May 12, 2004 at 03:05:24PM -0700, Kevin Deus wrote:
>    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.