- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 2 Dec 2014 12:31:01 +1100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
I believe the status code you're looking for is 429... Cheers, > On 2 Dec 2014, at 12:29 pm, Martin Thomson <martin.thomson@gmail.com> wrote: > > 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 >> >> -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 2 December 2014 01:31:29 UTC