RE: Header compression: buffer management

For HeaderDiff, the encoder can transmit two buffer management commands:

-          Add a new header

-          Replace a previous header with a new one
A malicious encoder could try to make the buffer grow indefinitely. To prevent this, the decoder must check for each addition and replacement that the buffer size is kept below a predefined limit (either negotiated, or advertised).

Some other checks are needed (but this is true for any compression mechanism), for example limiting the length of a header name or of a header value, limiting the total size of a header set…

Keeping the buffer management as simpler as possible on the decoder side helps understanding its behavior and preventing attacks from malicious clients.

Hervé.

From: James M Snell [mailto:jasnell@gmail.com]
Sent: jeudi 21 mars 2013 20:45
To: Poul-Henning Kamp
Cc: RUELLAN Herve; ietf-http-wg@w3.org
Subject: Re: Header compression: buffer management


I've briefly looked at this and it definitely is a challenge.  With delta,  we at least have the benefit of allowing the decompressor to set an upper bound on stored state size,  but even that can be problematic under heavy load and does not completely resolve the issue.  For instance,  a malicious client could potentially send hundreds of junk headers frames intentionally designed to make the decompressor do significant extra work managing it's internal buffers.  If the intermediary blindly passes such requests through,  it will likely end up double buffering the junk data causing even more issues.  It is obvious that fairly aggressive defensive techniques are going to be required to watch for bad behavior and compensate. On the plus side,  a delta decompressor could simply choose to throw up its hands and give up doing any buffer management, simply passing values through...  Which,  of course just passes the problem on to someone else.
On Mar 21, 2013 9:51 AM, "Poul-Henning Kamp" <phk@phk.freebsd.dk<mailto:phk@phk.freebsd.dk>> wrote:
In message <6C71876BDCCD01488E70A2399529D5E5163F39C4@ADELE.crf.canon.fr<mailto:6C71876BDCCD01488E70A2399529D5E5163F39C4@ADELE.crf.canon.fr>>, RUELL
AN Herve writes:

>In HeaderDiff we chose to let the encoder decide how the buffer is managed
>(regarding additions and removals). These decisions are encoded on the wire
> and applied by the decoder on its own buffer. We think this choice has
> several advantages.

Has this been analysed from a denial-of-service perspective ?

Anything in the protocol where the client can cause memory allocation
on the server/proxy/whatever, should be scrutinized in a DoS perspective.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG<mailto:phk@FreeBSD.ORG>         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.