Subject: New Version Notification for draft-bishop-http2-extension-frames-00.txt

From: Mike Bishop <[email-masked]>
Date: Fri, 8 Nov 2013 19:21:35 +0000

Since I was volunteered at the working group meeting to share this, here's the current version of my draft.  I will re-emphasize that this is strictly a strawman, and any suggestions on how to improve this are more than welcome.

Sent from Windows Mail

From: [email-masked]<mailto:[email-masked]>
Sent: ?Friday?, ?November? ?8?, ?2013 ?11?:?16? ?AM
To: Mike Bishop<mailto:[email-masked]>

A new version of I-D, draft-bishop-http2-extension-frames-00.txt
has been successfully submitted by Mike Bishop and posted to the
IETF repository.

Filename:  draft-bishop-http2-extension-frames
Revision:  00
Title:   Extension Frames in HTTP/2.0
Creation date:  2013-11-08
Group:   Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-frames-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bishop-http2-extension-frames
Htmlized:        http://tools.ietf.org/html/draft-bishop-http2-extension-frames-00

Abstract:
   This document describes a proposed modification to the HTTP/2.0
   specification to better support the creation of extensions without
   the need to version the core protocol or invoke additional protocol
   identifiers.

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.

The IETF Secretariat

---

From: James M Snell <[email-masked]>
Date: Fri, 8 Nov 2013 12:06:28 -0800

It's great to see work being done on the extension model but I'm not
convinced that the approach you suggest in this draft is the best way
forward.

The approach that I would like to see is this:

For Frames:

1. Clearly define the notion that some frames are *always* end-to-end,
while others are *always* hop-by-hop
2. Clearly differentiate these types using the MSB of the frame type.
If the MSB is set, the frame is end-to-end
3. Specify that end-to-end frames are *always* subject to flow control
4. Change the type of the DATA frame to 0x80
5. Dedicate 10 frame types at the top of each range (0xF5-FF and
0x75-7F) as "private use" frame types that cannot be assigned by IANA.
6. Require that end-to-end frames are only sent on open streams
(basically, whenever a DATA frame can be sent)

For Settings:

Dedicate some portion of the possible range of settings as "private
use" that cannot be assigned by IANA

- James

On Fri, Nov 8, 2013 at 11:21 AM, Mike Bishop
<[email-masked]> wrote:
> Since I was volunteered at the working group meeting to share this, here’s
> the current version of my draft.  I will re-emphasize that this is strictly
> a strawman, and any suggestions on how to improve this are more than
> welcome.
>
> Sent from Windows Mail
>
> From: [email-masked]
> Sent: ‎Friday‎, ‎November‎ ‎8‎, ‎2013 ‎11‎:‎16‎ ‎AM
> To: Mike Bishop
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-frames-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bishop-http2-extension-frames
> Htmlized:
> http://tools.ietf.org/html/draft-bishop-http2-extension-frames-00
>
>
> Abstract:

---

From: James M Snell <[email-masked]>
Date: Fri, 8 Nov 2013 12:13:22 -0800

> (basically, whenever a DATA frame can be sent)

Missed one:

  7. Require that implementations ignore-but-forward unknown
end-to-end frames; while allowing them to ignore-and-drop unknown
hop-by-hop frames... with the option of signaling an error if they so
choose.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 8 Nov 2013 12:39:49 -0800

As far as I can tell you have included everything discussed, including
hop-by-hop vs end-to-end distinctions, a workable extension id space, as
well as an example.
Coolness!

-=R
On Nov 8, 2013 11:25 AM, "Mike Bishop" <[email-masked]> wrote:

>  Since I was volunteered at the working group meeting to share this,
> here’s the current version of my draft.  I will re-emphasize that this is
> strictly a strawman, and any suggestions on how to improve this are more
> than welcome.
>
>  Sent from Windows Mail
>
>   *From:* [email-masked]
> *Sent:* Friday, November 8, 2013 11:16 AM
> *To:* Mike Bishop <[email-masked]>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Sat, 9 Nov 2013 00:04:31 +0000

We discussed some of this at the Bellevue interim….

With regard to HbH vs. E2E:

·         End-to-end on stream zero isn’t possible, since there’s nowhere to forward them

·         On-stream frames mix hop-by-hop and end-to-end

In order to simplify the model, there was general consensus that we could simplify this considerably by reducing it to two states:

·         Stream zero is hop-by-hop, and ignored if not understood

·         On-stream is end-to-end and may be dropped or forwarded

While I’m not inherently opposed to also allowing on-stream hop-by-hop frames since the protocol has them, it does increase the handling complexity some.

With regard to your space partitioning idea, it doesn’t solve type exhaustion.  In fact, it exacerbates it since one type can be exhausted while types still remain in the other half of the space.  If we allow a mix of E2E and HbH frames on-stream, I’d prefer a flag to the MSB approach.

The idea of having a private-use range for use during development followed by registration and a shift to IANA-assigned values is an option, but given that some of our numbers tend to broadly deploy things that are still under active development, that complicates both the transition from the unassigned to assigned versions and the ability of extensions to coexist.

-----Original Message-----
From: James M Snell [mailto:[email-masked]]
Sent: Friday, November 8, 2013 12:13 PM
To: Mike Bishop
Cc: HTTP Working Group
Subject: Re: New Version Notification for draft-bishop-http2-extension-frames-00.txt

> while others are *always* hop-by-hop 2. Clearly differentiate these

> types using the MSB of the frame type.

> If the MSB is set, the frame is end-to-end 3. Specify that end-to-end

> frames are *always* subject to flow control 4. Change the type of the

> DATA frame to 0x80 5. Dedicate 10 frame types at the top of each range

> (0xF5-FF and

Missed one:

  7. Require that implementations ignore-but-forward unknown end-to-end frames; while allowing them to ignore-and-drop unknown hop-by-hop frames... with the option of signaling an error if they so choose.

> <[email-masked]<mailto:[email-masked]>> wrote:

>> here’s the current version of my draft.  I will re-emphasize that

>> this is strictly a strawman, and any suggestions on how to improve

>> this are more than welcome.

>> has been successfully submitted by Mike Bishop and posted to the IETF

>> repository.

>> http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-fram

>> es-00.txt

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

---

From: James M Snell <[email-masked]>
Date: Sun, 10 Nov 2013 10:11:45 -0800

On Fri, Nov 8, 2013 at 4:04 PM, Mike Bishop
<[email-masked]> wrote:
> In order to simplify the model, there was general consensus that we could
> simplify this considerably by reducing it to two states:
>

-1 on the "may be dropped". As I've mentioned before, silently
dropping end-to-end frames could significantly impact the semantics of
the stream data and could have very bad unintended side effects. The
result is that end-to-end extension frames become impossible to rely
upon. The better (and more reliable) option is to require that
end-to-end frames are either passed through untouched or the stream is
closed with an RST_STREAM if the endpoint does not intend to pass them
along.

> While I’m not inherently opposed to also allowing on-stream hop-by-hop
> frames since the protocol has them, it does increase the handling complexity
> some.
>

If the handling requirements are clearly articulated, there is no harm
in allowing them. It would be clear: an unknown hop-by-hop frame on a
stream could be dropped safely without changing the semantics of the
end-to-end message.

>
>
> With regard to your space partitioning idea, it doesn’t solve type
> exhaustion.  In fact, it exacerbates it since one type can be exhausted
> while types still remain in the other half of the space.  If we allow a mix
> of E2E and HbH frames on-stream, I’d prefer a flag to the MSB approach.
>

I don't want to "solve" the type exhaustion because I'm not convinced
that it's a problem in the long run. Keeping the extension space
limited ought to discourage bad behavior. Using a flag is problematic
for two reasons: (1) the flag value space is far more limited than the
available type identifier space and (2) it would mean that a single
frame type could be sent end-to-end OR hop-by-hop, potentially
muddying the semantics significantly (an extension frame would need to
clearly indicate what behavior is appropriate in either case).

>
>
> The idea of having a private-use range for use during development followed
> by registration and a shift to IANA-assigned values is an option, but given
> that some of our numbers tend to broadly deploy things that are still under
> active development, that complicates both the transition from the unassigned
> to assigned versions and the ability of extensions to coexist.
>

Again, the limited value space ought to discourage bad behavior.

- James

> Subject: Re: New Version Notification for
> draft-bishop-http2-extension-frames-00.txt
>
>
>
>   7. Require that implementations ignore-but-forward unknown end-to-end
> frames; while allowing them to ignore-and-drop unknown hop-by-hop frames...
> with the option of signaling an error if they so choose.
>
>
>
>
>
>>
>
>> For Settings:
>
>>
>

---

From: James M Snell <[email-masked]>
Date: Sun, 10 Nov 2013 11:19:48 -0800

A few additional specific comments:

1. re: BASE_SPECIFICATION_ONLY ... this is currently underspecified in
the draft. Let's suppose my client establishes a stream that "travels"
through two intermediate hops on it's way to the server. The path
determined dynamically by the intermediaries. The first intermediary
allows end-to-end extension frames to pass through, but the second
intermediary does not and sends BASE_SPECIFICATION_ONLY. What should
the first intermediary do if it receives extension frames from the
client? Obviously, it cannot send those but there is nothing in the
draft that describes exactly how the intermediary ought to handle it.

 a. Should it just silently drop any extension frames it receives from
the client without notification. The problem being, of course, that
the client would have no idea that it's complete message is not
getting through
 b. Should it update it's settings with the client and say
BASE_SPECIFICATION_ONLY, while silently dropping any extension frames
it may have already received? The problem with this, of course, is
that it terminates that clients ability to send extension frames
through that first intermediary to any other endpoint that might not
have the BASE_SPECIFICATION_ONLY requirement.
 c. Should it RST_STREAM the stream with the client letting it know
that the extension frames could be passed on?

 (IMHO, (c) is obviously the best choice)

2. re: Flow control ... are end-to-end extension frames subject to
flow control, and if not, why not?

3. Strongly feel that the use of Private enterprise numbers as a
namespacing mechanism for extensions is going to encourage abuse and
non-standardization of protocol extensions. Specifically, it allows
specific vendors the ability to define, deploy and maintain their own
proprietary protocol extensions without any pressure whatsoever to
take things through standardization. IMHO, that's fairly dangerous.
Having a limited extension space with very clear processing
requirements is a significantly better option.

4. A compromise approach here would be to utilize both of the
approaches suggested by myself and Mike's draft. Specifically:

  a. Segment the existing frame type space into end-to-end and
hop-by-hop as I have suggested,
  b. Define that hop-by-hop frames MUST either be passed through
untouched or RST_STREAM returned,
  c. Define that *all* hop-by-hop frames are subject to flow-control,
  d. Define that extension end-to-end frames MUST NOT change session
state and can be silently dropped.
  e. Define a new INFO frame type that can always be silently dropped.
The structure of the INFO frame would essentially be the same as Mike
suggests in his draft. The INFO frame would be hop-by-hop, with the
intermediary having the ability to decide whether or not to forward
those on (like we currently do with PUSH_PROMISE).

This would be a much more robust and reliable approach.

- James

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Nov 2013 02:22:51 +0000

If the intermediary is forwarding a stream onto a connection with BASE_SPECIFICATION_ONLY set, it has to drop any extension frames.  This is why streams are allowed to have different treatment -- because the intermediary may have to accommodate different preferences on the back-end.  You’re correct that a client can’t know for sure whether an end-to-end extension is supported on each new stream; I hesitate to solve that by terminating the stream and eating an RTT, though.

Your concern over fragmentation is one that I’ve struggled with, too.  RFC 6709 is definitely something we should all read in depth several times as we have this discussion.  A couple elements I find relevant there:

  *
Avoiding “local/private use” ranges, because of the possibility of collisions and incompatibility between different local/private implementations
  *
Delineating in the base spec how extensions interact with unextended peers to ensure the failure modes are graceful
  *
“Protocol variations -- specifications that look very similar to the original but don’t interoperate with each other or with the original -- are even more harmful to interoperability than extensions.  In general, such variations should be avoided.”  My concern is that if we limit extensibility too sharply, this would be the outcome instead.
  *
In particular, section 4.4 suggests that a small parameter space (8 bits or less) combined with FCFS allocation is a recipe for trouble.  Vendor extensions (my draft) or stricter allocation requirements (your draft) are two solutions they note, with the respective problems of fragmentation and unregistered usage.  (Reference Dave Thaler & Mark’s recent discussions around URI schemes for an unregistered usage example.)

I think this is an area for working group discussion -- is our goal to have a more universal extension space with constrained capabilities (HTTP headers), a tightly-constrained one (WebSockets extensions), or somewhere in the middle?  That goal will inform how these drafts evolve, and it’s something neither James nor I can decide on our own.

Sent from Windows Mail

From: James M Snell<mailto:[email-masked]>
Sent: ‎Sunday‎, ‎November‎ ‎10‎, ‎2013 ‎11‎:‎20‎ ‎AM
To: Mike Bishop<mailto:[email-masked]>
Cc: HTTP Working Group<mailto:[email-masked]>

- James

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 12 Nov 2013 11:25:39 +0100

> closed with an RST_STREAM if the endpoint does not intend to pass them

And the better option will live only as long as no one figures how to push
objectionable optional content such as ads, trackers or cookies with it,
then you'll see those frames dropped regardless of what the spec says.

It's an unfortunate reality today that the people who control web sites
have not always the best interests of the people who consult them in mind,
and silently dropping parts of the stream at the browser or at any
intermediary level is here to stay. You can not specify morals in the spec
and giving an all-or-nothing power to one of the nodes involved in the
http/2 dialog is not going to work.

Regards,

-- 
Nicolas Mailhot

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Nov 2013 08:43:44 -0800

Content filtering is a different matter entirely, and usually happens
in a way that is content-sensitive. The kind of "silent dropping"
that's being discussed here is indiscriminate, with no consideration
being given to the frame content. The fact of the matter is that
silently dropping end-to-end frames without understanding why they've
been transmitted is extremely dangerous.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 12:38:30 +0100

Le Mar 12 novembre 2013 17:43, James M Snell a écrit :
> in a way that is content-sensitive.

I like "usually". The truth is that outside advertisers, the NSA and
Hollywood movies the amount of content analysis done out there is very
minimal. There is known safe stuff, known unsafe stuff, a lot of probably
safe stuff, and
weird-stuff-we-dont-have-time-to-analyse-that-we-will-drop-for-now

What I'm use is any part of the spec with "use this if you want to avoid
filtering" is certain to be abused sooner than later. Just like port 443
and https encapsulation have been abused widely as soon as it become clear
it avoided lots of controls.

> The kind of "silent dropping"

So is "blindly accept what you don't know". No security professional will
sign on such a proposal, since he has to justify why he let dangerous
traffic pass in case of incident.

-- 
Nicolas Mailhot