Subject: A rough analysis of the impact of headers on DoS

From: Roberto Peon <[email-masked]>
Date: Fri, 11 Jul 2014 09:21:16 -0700

I've seen folks stating that HPACK/or its reference set are related to DoS
or HoL blocking, but wanted to point out that these are orthogonal.

There are three modes of DoS attack using headers:
1) Stalling a connection by never finishing the sending of a full set of
headers.
2) Resource exhaustion of CPU.
3) Resource exhaustion of memory.

I don't find #1 interesting, since the attacker is mostly just attacking
themselves

I don't find #2 very interesting, since there are other (and far more
effective) ways of attacking including sending a SETTINGS frame between
every other DATA frame, sending 1-byte DATA frames, or by creating and
tearing down the connection repeatedly, etc.

I think #3 is the interesting attack vector.
The current design handles this fairly well, at most one set of headers can
be incomplete at any point in time (sending a large number of incomplete
headers and keeping most of them incomplete most of the time is an
excellent attack vector, which the design currently precludes).

Sending headers via a large buffer or via fragments changes nothing about
this particular attack vector-- the important part is to keep the max
number of incomplete headers down to as small as possible (e.g. 1).

In terms of memory exhaustion, knowing the size of the set of headers which
is being received is marginally helpful and can be detrimental in terms of
DoS.
On the helpful side, if one realizes that the headers are going to be
larger than one wishes to handle, knowing the length means knowing that the
data should be processed and thrown out.
On the less-than-helpful side, knowing the size encourages allocating that
much buffer, which an attacker can then exploit by not finishing the
connection, and thus increasing the amount of memory which must sit idle.

In other words, it is likely that the most robust solution is to allocate
memory on demand.

There is another interesting memory resource attack, which is the
memory-expansion of compressed headers into uncompresed (i.e. zip-bomb)
attack. This is orthogonal to other considerations and can be done so long
as any compression at all is used, and so probably shouldn't factor into
any decisions about framing.

I will point out, however, that the reference set actually reduces the risk
there by a factor of 2 (not enough to really care about either way, imho).

That brings us to HPACK.
Its only interesting DoS impact is that it enables expansion attacks, as
would *any* compressor, stateful or stateless.

Eliminating the reference set changes nothing about the DoS impact.

Switching to stateless changes nothing but effectiveness of the compressor
(and thus the expansion/compaction ratio),.

-=R

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 12 Jul 2014 14:49:47 +1200

> or HoL blocking, but wanted to point out that these are orthogonal.

Pardon?

HOL blocking a connection while one client incrementally HPACKs streamed
headers is orthoginal to HOL blocking how?

> tearing down the connection repeatedly, etc.

Okay. So its fine to stall your connections with a DDoS. What software
did you write h2 into BTW?

> be incomplete at any point in time

The current design (I assume you mean status quo / h2-13 ?) encourages
fragmentation and up to 400% bandwidth overheads on each fragment.

> (sending a large number of incomplete

This is only possible using the interleaved CONTINUATION proposal. And a
very good reason from removing CONTINUATION.

The large frames "Greg et al" proposal is not vulnerable to this.

> number of incomplete headers down to as small as possible (e.g. 1).

It changes the statefulness of the protocol. A pretty fundamental
property in HTTP.

Atomic frames are inherently stateless. Fragments are stateful by
definition.

The driver for large frames to to retain atomic and stateless frames.
CONTINUATION in all its forms is fragmented and stateful.

> is being received is marginally helpful and can be detrimental in terms of

Not knowing the size is even more detrimental in terms of DoS *and* HOL
blocking.

> data should be processed and thrown out.

A key property for preventing the DoS.

> connection, and thus increasing the amount of memory which must sit idle.

Not knowing the size encourages buffer over-allocation to even greater
sizes - which the attacker can take advantage of.

In Squid I occasionaly see admin configuring multi-MB buffer limits in
order to receive Gbps traffic while also being able to cope with the
unknown message sizes. So long as CONTINUATION exists that is not able
to change.

> In other words, it is likely that the most robust solution is to allocate

Indeed. Which large frames encourages: advertise in advance what your
limit is, allocate buffer as small as the frame which is already
arriving, and PROTOCOL_ERROR anything above that.

Simple and efficient. Memory re-allocation on each TCP packet is
simpler, but far far less efficient.

> any decisions about framing.

Indeed this has nothing to do with the frame proposals. HPACK draft
should cater for that type of attack protection.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 19:59:43 -0700

> headers is orthoginal to HOL blocking how?

Don't do that.  I think that's been said plenty of times.  If you
intermediate and multiplex messages from multiple peers onto the same
connection, you can't safely stream headers.  You need to have an
entire block before you commit, otherwise you have this problem.  But
that's *your* fault as the intermediary, not the fault of your clients
or the protocol.

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 12 Jul 2014 17:04:14 +1200

On 12/07/2014 2:59 p.m., Martin Thomson wrote:
> On 11 July 2014 19:49, Amos Jeffries wrote:
>>
> connection, you can't safely stream headers.

We must be reading different WG lists. Because the rationale I've been
seeing most strongly behind removing reference set was to increase
streaming of HEADERS+CONTINUATION from A to B without having to worry
about size or buffering. Mostly server peoples arguments, with a case
for not wanting to buffer child application output.
 If one elimitates buffering of headers before send then the HOL is
directly incurred. Nothing orthogonal about that.

>  You need to have an

I do agree completely. Which is why I am neither supporting nor
objecting to the HPACK proposals at this point.

Amos