Re: Making Implicit C-E work.

inflate size-computation is: (1 << windowBits) + 1440*2*sizeof(int)
windowBits can be as large as 15, thus at least 44k

So, we have each stream potentially allocating and keeping around 44k, and
an unbounded or large number of streams.

The client can largely decide how many streams to create and it can
(guaranteed) leave them idle for as long as it wants (until the proxy
finally closes the stream).
Yes, the server can reduce the max parallelism, but then the protocol is
not doing what it was intended to do.

With 100 streams, we're talking about 4.22 megabytes of uncontrolled buffer.
That is *WAY* more than the typical static-cost for a connection, which the
server can otherwise control to a few bytes, and perhaps two orders of
magnitude larger than typical/desired in-use costs for a connection.

Even better, the proxy may be forced into this scenario because of flow
control, when it is unable to forward bytes onward to the destination.
-=R


On Wed, May 14, 2014 at 2:18 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> Maybe someone needs to use small words or something, but to me, this DoS
> claim is this far poorly supported in fact from my reading.
>
> Assuming that you employ flow control, the only commitment an intermediary
> makes when decompressing is the decompression context for each stream. That
> is bounded in size too. That might be larger than people might like, but
> I'm not all that excited about a new protocol that is more expensive to
> operate than an old one in some corner case.
> On May 14, 2014 1:37 PM, <K.Morgan@iaea.org> wrote:
>
>> On 14 May 2014 17:52, jgraettinger@google.com wrote:
>> > On 14 May 2014, Keith Morgan wrote:
>> >> Nearly all of the problems brought up w.r.t. t-e gzip are also true
>> for C-E
>> >> gzip. This one is no exception.
>> >> Implicit C-E gzip adds a large DoS attack surface to intermediaries.
>> >> An attacker simply sends requests without ‘accept-encoding: gzip’ from
>> a HTTP/1.1.
>> >> origin through a 1.1<->2 gateway for a resource it knows the server
>> will
>> >> implicitly C-E gzip. Then (using your own words Johnny) “the gateway
>> is required
>> >> to decompress before handing off to the origin … and face the ensuing
>> DoS attack
>> >> surface.”
>> >
>> >
>> > This is a problem which already exists today. As Roberto noted,
>> existing h1
>> > intermediaries add a-e: identity on behalf of clients who didn't ask
>> for it, and
>> > existing servers send c-e: gzip anyway, because the observed impact of
>> not
>> > compressing is higher than the interop issues it introduces.
>> >
>> >
>> > The DOS mitigation which is available today, and continues to be
>> available for
>> > h2/h1 gateways under implicit c-e: gzip, is to pass through what the
>> server sent
>> > without decompression. There's a high likelihood the h1 client will be
>> able to
>> > handle c-e: gzip  (and even prefers it), which is definitely not true
>> if t-e: gzip
>> > were used instead.
>>
>>
>> The current -12 spec says "Intermediaries that perform translation from
>> HTTP/2 to
>> HTTP/1.1 MUST decompress payloads unless the request includes an
>> Accept-Encoding
>> value that includes 'gzip'." [1].
>>
>> So implicit gzip either introduces a legitimate DoS at the HTTP/2 to
>> HTTP/1.1 gateway
>> or you want gateways to ignore this requirement and introduce interop
>> issues. Which
>> is it?
>>
>> If it's the latter (forward compressed regardless of the A-E header),
>> then what's the
>> point of Roberto's "uncompressed-*" headers for the gateways if you don't
>> really want
>> the gateways to deccompress? And what's the point of this "MUST
>> decompress payloads"
>> requirement?
>>
>> If it's the former (decompress at the gateway), and you want to live with
>> the DoS
>> attack surface, I have to ask again, what's the point of all this - just
>> to have
>> compression on one or two h2 hops and then force gateways to dynamically
>> decompress??
>>
>>
>> [1] http://http2.github.io/http2-spec/#Compression
>> This email message is intended only for the use of the named recipient.
>> Information contained in this email message and its attachments may be
>> privileged, confidential and protected from disclosure. If you are not the
>> intended recipient, please do not read, copy, use or disclose this
>> communication to others. Also please notify the sender by replying to this
>> message and then delete it from your system.
>>
>>