Security Condideration of initial SETTINGS_MAX_CONCURRENT_STREAMS

Hi,

In the current spec, an initial value of SETTINGS_MAX_CONCURRENT_STREAMS
is no limit and many of endpoints set it at the first SETTINGS.

A malicious client can send massive HEADERS without replying SETTINGS-ACK
in order to overflow server's stream sessions until SETTINGS_TIMEOUT
error or up to max stream-id.

This might be a case of ENHANCE_YOUR_CALM error as in "10.5 Denial of
Service Considerations" but some implementers would miss its protection
against DoS streams at the initial startup because they expect to receive
SETTINGS-ACK promptly and do not care that the max concurrent stream is
 unlimited.

One idea is to define an initial SETTINGS_MAX_CONCURRENT_STREAMS such as 100
which is recommended as minimum in the current spec.
Is there any reason not to define it?

If limiting of the inital value is a bad idea, it is better to write a
description in the security section to care against the DoS at the connection
startup.

Regards,

Received on Wednesday, 15 January 2014 01:55:32 UTC