Re: I-D Action: draft-ietf-httpbis-http2-16.txt

420 Enhance Your Calm.  The problem here is that there is a resource
that is committed (the socket that sites in TIME_WAIT) and no
accounting for it under the current set of resource limits (most
likely SETTINGS_MAX_CONCURRENT_STREAMS).

This isn't really special in that regard; I'm sure that the greater
ease with which clients can initiate requests will open other avenues
for exploitation on servers.  That said, adding DoS considerations
text is easy.

On 1 December 2014 at 12:55, Willy Tarreau <w@1wt.eu> wrote:
> Hi Mark,
>
> On Tue, Dec 02, 2014 at 06:34:36AM +1100, Mark Nottingham wrote:
>> Everyone,
>>
>> Our issues list is empty, and I believe we have consensus to publish these
>> documents.
>>
>> Please have a look at the changes in this as well as HPACK-10, to verify that
>> they incorporate the changes as discussed.
>>
>> I'm going to prepare the shepherd writeups and -- barring any surprises --
>> submit them all for publication in a couple of days.
>
> While comparing to a previous paper copy I had, I just found a note I had
> written on the paper which is still problematic as there's a moderate risk
> of DoS with CONNECT :-(
>
>    8.3. The CONNECT Method
>    ...
>    The END_STREAM flag
>    on a DATA frame is treated as being equivalent to the TCP FIN bit.  A
>    client is expected to send a DATA frame with the END_STREAM flag set
>    after receiving a frame bearing the END_STREAM flag.  A proxy that
>    receives a DATA frame with the END_STREAM flag set sends the attached
>    data with the FIN bit set on the last TCP segment.
>
> This point means that a client can very easily exhaust a proxy's source
> ports for several minutes by sending DATA+END_STREAM on many successive
> CONNECT requests. Indeed, if the proxy closes with a FIN bit, it ends up
> with a TIME_WAIT socket on the outgoing side preventing it from reusing
> the same local port for the whole duration of the TIME_WAIT state. While
> some recent OSes can reuse a source port to connect to a different target,
> it's far from being the case everywhere and even blacklisting a single
> target is a problem (think about the effect of blacklisting an internal
> server or a well-known a search engine from a corporate proxy for example).
>
> In HTTP/1 this problem was not very important because in order to do so,
> the client had to put itself in this situation of sending a FIN. Also it
> was limited by the connection rate making things very visible on the
> network or firewalls. But with H/2 it just has to open many streams and
> send CONNECT then close them. This can be very quick and maybe even
> discrete if internal policies prevent from logging CONNECT to whitelisted
> sites.
>
> Most of the time proxies will have to workaround this by closing with a
> TCP RST instead, causing the loss of any possibly unread data on the peer.
> But anyway protocols where the client closes first are broken with TCP.
>
> I think we could slightly relax the rule by adding a sentence at the end
> of the paragraph after this :
>
>    ...A proxy that
>    receives a TCP segment with the FIN bit set sends a DATA frame with
>    the END_STREAM flag set.  Note that the final TCP segment or DATA
>    frame could be empty.
>
>    => Implementations MAY chose to close with a TCP segment with the RST
>       bit set when there is a risk of local port starvation related when
>       using the FIN bit.
>
> It doesn't enter into implementation detail and implementors can chose
> based on their platforms and the level of control they have over the
> local TCP stack.
>
> Note that it is not critical and can even wait for an errata if this is
> expected to be the last version. But proxy implementors definitely need
> to take this into consideration.
>
> Best regards,
> Willy
>
>

Received on Tuesday, 2 December 2014 01:30:26 UTC