Dan Stromberg wrote:
> So DJB's program basically has a large listen queue, and goes
> into queue-only mode after 40 concurrent connections?
tcpserver -c n ...
where n is the number of simultaneous connections. Defaults to 40.
> If that's the case, then there's still a DOS
> - just fill the listen queue with so much stuff
> that connections aren't serviced for a long time.
IMHO we do want a limit on simultaneous connections and a queue after the limit's reached:
No limit => Attacker may make one service eat all resources on your system.
No queue => Your system will be intolerant of sudden bursts: When the limit's reached new connections will be dropped even when there's no real DoS.
If your limit is not based on maximum simultaneous connections, but on eg. maximum resource concumption, the queue argument still holds.
> So DJB's program basically has a large listen queue, and goes
> into queue-only mode after 40 concurrent connections?
tcpserver -c n ...
where n is the number of simultaneous connections. Defaults to 40.
> If that's the case, then there's still a DOS
> - just fill the listen queue with so much stuff
> that connections aren't serviced for a long time.
IMHO we do want a limit on simultaneous connections and a queue after the limit's reached:
No limit => Attacker may make one service eat all resources on your system.
No queue => Your system will be intolerant of sudden bursts: When the limit's reached new connections will be dropped even when there's no real DoS.
If your limit is not based on maximum simultaneous connections, but on eg. maximum resource concumption, the queue argument still holds.
:) Bjørnar
[ reply ]