Re: Striving for Compromise (Consensus?)

On 12/07/2014 7:06 a.m., Johnny Graettinger wrote:
>>
>>>> Ok in that case, Roberto’s analysis does not prove what you say it does.
>>>
>>> I'm pretty sure that it does.
>>>
>>> This point:
>>>> 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).
>>
>> This is the flaw:
>>
>> "1) Stalling a connection by never finishing the sending of a full set of
>> headers.
>>
>> I don't find #1 interesting, since the attacker is mostly just attacking
>> themselves"
>>
>> If you coalesce connections there are N users per connection. Thats a real
>> problem you can’t just wave away.
> 
> 
> 
> Without interleaving, such a proxy coalescing un-trusted users must buffer
> at most *one* set of incomplete request headers per-user before forwarding.
> As you note, it can't forward fragments. This prevents an attacker from
> impacting other coalesced clients.

This is an incorrect conclusion IMO. By requiring that the proxy buffer
without providing a total input size in advance the proxy is forced to
commit unlimited resources to *each* client. And the one which consumes
too many resources on the proxy causes stalling down each of the other
clients connections.
 Like Martin said in his priority matrix earlier; stalling is more
important than HOL.

The effect is identical to piping 9 straws and a fire hose into a sealed
container with 10 straws leaving it. The 9 input straws are going to get
backed up while the firehose content is dealt with regardess of whether
any of the firehose input gets sent on the outbound.

This is what CONTINUATION means in h2. It's bad, really bad.

> 
> But with interleaving, such a proxy must buffer M different sets of
> incomplete request headers for each of N different users. Requiring that
> :headers appear in the first frame increases the likelihood that the proxy
> is able to incrementally forward, but it doesn't eliminate it (again,
> consider a reverse proxy routing on a session cookie). The only bound on M
> right now is the stream concurrency limit, which is large.
> 

Agreed. Interleaving on a stateful connection (HPACK state) makes the
effects worse. When the effect without interleaving is enough to cause a
DoS there is no sane reason to believe amplifying it will help.

Amos

Received on Saturday, 12 July 2014 04:04:29 UTC