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

Hey Willy,

Would you mind if we handled that as part of IETF Last Call? I don't think it'd be controversial.

Cheers,


> On 2 Dec 2014, at 9:55 am, 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
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 2 December 2014 00:22:33 UTC