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

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 Monday, 1 December 2014 22:56:02 UTC