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

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2014 06:34:36 +1100

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.

Cheers,

> On 30 Nov 2014, at 6:27 pm, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Hypertext Transfer Protocol Working Group of the IETF.
> 
>        Title           : Hypertext Transfer Protocol version 2
>        Authors         : Mike Belshe
>                          Roberto Peon
>                          Martin Thomson
> 	Filename        : draft-ietf-httpbis-http2-16.txt
> 	Pages           : 92
> 	Date            : 2014-11-29
> 
> Abstract:
>   This specification describes an optimized expression of the semantics
>   of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more
>   efficient use of network resources and a reduced perception of
>   latency by introducing header field compression and allowing multiple
>   concurrent messages on the same connection.  It also introduces
>   unsolicited push of representations from servers to clients.
> 
>   This specification is an alternative to, but does not obsolete, the
>   HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-16
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-http2-16
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 

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

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 1 Dec 2014 11:50:32 -0800

Minor (especially as this section will be removed prior to publication),
but the changelog in HPACK "D.1 Since
draft-ietf-httpbis-header-compression-09" sounds more drastic than it is:

"Updated integer representation."

That made me go look at the diffs, but it was just editorial.

On Mon, Dec 1, 2014 at 11:34 AM, Mark Nottingham <[email-masked]> wrote:

> 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.
>
> Cheers,
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 1 Dec 2014 23:55:38 +0100

Hi Mark,

On Tue, Dec 02, 2014 at 06:34:36AM +1100, Mark Nottingham wrote:
> Please have a look at the changes in this as well as HPACK-10, to verify that
> they incorporate the changes as discussed.  
> 

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2014 11:22:08 +1100

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 <[email-masked]> wrote:
> 
> Hi Mark,
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 15:29:58 -1000

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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2014 12:31:01 +1100

I believe the status code you're looking for is 429...

Cheers,

> On 2 Dec 2014, at 12:29 pm, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 15:34:07 -1000

> I believe the status code you're looking for is 429...

I was referring to the error code, probably in a GOAWAY frame.  Either works.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2014 12:37:47 +1100

This isn't going to be confusing at all...

> On 2 Dec 2014, at 12:34 pm, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 15:41:35 -1000

> This isn't going to be confusing at all...

Well, we don't use numbers in the hundreds for the error codes any
more... ENHANCE_YOUR_CALM is 0xb.  Jeff wanted 420, but he lost that
when we renumbered.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2014 12:42:21 +1100

> On 2 Dec 2014, at 12:41 pm, Martin Thomson <[email-masked]> wrote:
> 

And yet you still called it 420 ;)

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 2 Dec 2014 07:44:51 +0100

> likely SETTINGS_MAX_CONCURRENT_STREAMS).

The issue is that a regular implementation doesn't really know. In
fact when it knows, it's too late :-/

> for exploitation on servers.  That said, adding DoS considerations

Yes I think that the best solution here is to just add some text so that
implementers can think about it when doing the code, and possibly plan
for system-dependant variants.

Best regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 2 Dec 2014 07:47:03 +0100

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

No, I don't mind. I just wanted to report this part to ensure it doesn't
get lost before we get an RFC.

Thanks,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Dec 2014 21:22:32 -1000

> get lost before we get an RFC.

I'm not against opening issues here:
https://github.com/http2/http2-spec/issues/662

I've marked it editorial, but the bar at this stage of the process is
quite high.  Expect a PR and some time to review.  Also expect some
level of coordination with the IESG, who will be reviewing the
document at the same time.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 2 Dec 2014 08:33:13 +0100

> document at the same time.

Sure. Thanks Martin!
Willy

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 11 Dec 2014 07:16:54 +0000

Hi Mark,

> Our issues list is empty, and I believe we have consensus to publish these

We agree.
 
> submit them all for publication in a couple of days.

Both HTTP/2 and HPACK are ready for advancement to IESG in our opinion. Is there any reason to wait even more days?

---

From: "DRUTA, DAN" <[email-masked]>
Date: Sat, 13 Dec 2014 19:43:53 +0000

I also think we should get the documents submitted for IESG review sooner rather than waiting a few extra days.
Holiday season is around the corner and any delay will push the review  window further out.

Regards,
Dan

-----Original Message-----
From: Gabriel Montenegro [mailto:[email-masked]] 
Sent: Wednesday, December 10, 2014 11:17 PM
To: Mark Nottingham; HTTP Working Group
Subject: RE: I-D Action: draft-ietf-httpbis-http2-16.txt

Hi Mark,

We agree.

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 13 Dec 2014 19:57:51 +0000

+1
I do think both HTTP/2 and HPACK documents are ready for advancement
and they should get submitted to IESG asap
so that the IETF last call and the IESG review can start before the vacation period

br
Salvatore

---

From: Biren Roy <[email-masked]>
Date: Mon, 15 Dec 2014 11:55:49 -0500

My colleagues and I would be interested in seeing the spec proceed to IESG
as well.

Thanks,
Biren

On Sat, Dec 13, 2014 at 2:57 PM, Salvatore Loreto <
[email-masked]> wrote:
> > I also think we should get the documents submitted for IESG review
> sooner rather than waiting a few extra days.
> >> Our issues list is empty, and I believe we have consensus to publish
> these
> >> documents.
> >
> > We agree.
> >
> > Both HTTP/2 and HPACK are ready for advancement to IESG in our opinion.
> Is there any reason to wait even more days?
> >
> >
>
>

---

From: Bence Béky <[email-masked]>
Date: Mon, 15 Dec 2014 14:37:31 -0500

Hi Mark et al.,

+1.  FWIW, I also feel that the two drafts are ready, and would love
to see them go to the next stage before the holidays.

Thanks,

Bence