Question about Glacier2.Client.SleepTime

[rc_hz]

"Glacier2.Client.SleepTime = num" is used to protecting router and back-end servers against denial-of-service attacks from malicious clients.

As Ice manual says:

If num is set to a value larger than zero, the Glacier2 router sleeps for the specified number of milliseconds after forwarding all queued requests from a client. This prevents the client from flooding the router with requests. This property is only relevant when Glacier2.Client.Buffered=1. ...

That is, the router just buffers the requests from malicious clients instead of discarding them. So can it really protecting back-end servers against denial-of-service attacks ?
For example, we set Glacier2.Client.SleepTime=500 (0.5 second), then just several malicious clients can flood the back-end server by denial-of-service attacks.

Maybe in my view, it would be better that another config item such as Glacier2.Client.NumOfBufferedRequests can be added. That is, during the Glacier2 router's sleeping time, only Glacier2.Client.NumOfBufferedRequests requests can be buffered, other requests would be discarded.

[rc_hz]

Are there any comments ? Thx!

[beagles]

Sorry, the documentation is a little misleading. Glacier2.Client.SleepTime is not intended as a security feature. The 'sleep' in request processing is to provide opportunity for batching and overrides (see the Glacier2 section of the Ice documents for further details).

A anti-flooding security feature would probably do something like throttling the rate at which Glacier2 reads requests from the network. If the server is being "flooded", the network buffers would eventually fill up and TCP/IP flow control would slow down the incoming traffic.

We'll fix the Glacier2.Client.SleepTime documentation for the next release. Thanks for pointing this out!

[rc_hz]

Thanks, beagles. Do you mean that currently there is no way for Glaicer2 to protect against flooding attack ?

As you say:

A anti-flooding security feature would probably do something like throttling the rate at which Glacier2 reads requests from the network. If the server is being "flooded", the network buffers would eventually fill up and TCP/IP flow control would slow down the incoming traffic.

If we can control the number of buffered request(<=Glacier2.Client.NumOfBufferedRequests) and do not read any more the network (suppose this control is per client based), maybe this problem can be solved. Do you think so ?

[rc_hz]

I have read again newsletter: Advanced Use of Glacier2
( http://www.zeroc.com/newsletter/issue2.pdf )

Page 9 - "Denial of Service" has talked about this issue. However, it seems that it is not corrent.

[beagles]

My colleagues will correct me if I am wrong, but Glacier2 currently doesn't provide a mechanism that specifically controls the number of requests that are queued or processed in a given period.

Adding anti-flooding security is on our TODO list.

[rc_hz]

If we can control the number of buffered request(<=Glacier2.Client.NumOfBufferedRequests) and do not read any more the network (suppose this control is per client based), maybe this problem can be solved.

After a sleep, I think that this solution can not work if the client provides a callback object(that is, the connection between client and glacier2 is bidirectional).