Strawman for DoS considerations

I think that we need something along these lines.  I'm inclined to
just add this and then deal with change request, but let's discuss
this briefly first.
--
Denial of Service Considerations

An HTTP/2.0 connection can demand a greater commitment of resources to
operate than a HTTP/1.1 connection.  The use of header compression and
flow control require that an implementation commit resources for
storing a greater amount of state.  Settings for these features ensure
that memory commitments for these features are strictly bounded.
Processing capacity cannot be guarded in the
same fashion.

The <x:ref>SETTINGS</x:ref> frame can be abused to cause a peer to
expend additional processing time.  This might be done by pointlessly
changing settings, setting multiple undefined settings, or changing
the same setting multiple times in the same frame.  Similarly, trivial
<x:ref>WINDOW_UPDATE</x:ref> or <x:ref>PRIORITY</x:ref> frames
unnecessarily waste resources.

Large numbers of small or empty frames can be abused to cause a peer
to expend time processing frame headers.  Note however that some uses
are entirely legitimate, such as the sending of an empty
<x:ref>DATA</x:ref> frame to end a stream.

Header compression also offers some opportunities to waste processing
resources, see <xref target="COMPRESSION"/> for more details on
potential abuses.

In all these cases, there are legitimate reasons to use these protocol
mechanisms.  These features become a burden only when they are used
unnecessarily or to excess.

An endpoint that doesn't monitor this behavior exposes itself to a
risk of denial of service attack.  Implementations SHOULD track the
use of these types of frames and set limits on their use.  An endpoint
MAY treat activity that is suspicious as a <xref
target="ConnectionErrorHandler">connection error</xref> of type
<x:ref>ENHANCE_YOUR_CALM</x:ref>.

Received on Friday, 11 October 2013 15:23:26 UTC