Re: Striving for Compromise (Consensus?)

On Jul 11, 2014, at 2:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 11 July 2014 11:45, Jason Greene <jason.greene@redhat.com> wrote:
>> 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.
> 
> No, that is still right.  You are mounting the DoS on yourself.  Your
> N users can blame you, not the protocol.
> 
> If it were possible to stream small bits of messages (as we can do for
> DATA) and the real subject of Roberto's analysis weren't a problem (it
> is), then you might be able to stream onto a shared resource and get
> away with it.  As a practical matter, I don't believe that streaming
> into a shared connection is advisable.
> 
> Still, the real issue is the one I quoted: forcing an implementation
> to hold multiple partially complete header sets open is a superb DoS
> vector.  Better than the HOL blocking we've been talking about, which
> can be easily contained.
> 

You can do that the same (and prevent it the same) either way. I can create N connections with incomplete headers just as easily as I can create N streams. The server can prevent N streams just as easily as it can prevent N connections.

Roberto’s analysis is really just an argument that streaming is problematic for receivers, and to that I agree. If it’s benefits are to be limited to 1:1 connection proxies then I don’t think the benefits of the feature justify its complexity.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Friday, 11 July 2014 19:42:11 UTC