RE: HTTP/2 extensibility <draft-ietf-httpbis-http2-17>

Hi, Bob -

Let me try to address a few of your points.  The logic behind "discard unknown" is precisely so that new frame types can be added.  If you receive a frame type that you know and can validate the length, then you're able to reject it as an improper length -- but if it's a frame type you don't recognize, the length allows you to skip past it.  So, just as you suggest, the worst case is to inject something that gets ignored.  There were concerns raised with forwarding frame types you don't understand, particularly when you consider a connection to an intermediary where different streams may be going to different servers on the back-end.  If the frames on different streams were related in some way, but you could only untangle the relation if you understood the frames, the eventual recipients would get fragmentary conversations.  (Think of a shared compression context across streams, for example.)

For this reason, it was decided that extension frames should be hop-by-hop, but could be defined such that a recipient who understands the frame would relay it onto subsequent connections.  New extensions can define additional frames, and can define the processing of them.  That processing may include whether/how to forward them to the next hop, if you're an intermediary.  I would consider it good practice for any extension which defines frames to also define intermediary behavior, but the WG opted not to make that good practice a normative requirement.

It was also an explicit choice not to allow an endpoint to *unilaterally* change the definition of existing frames, because that leads to unknown behavior when you receive a known frame type of an unexpected length.  You don't know where the changes are, and whether fields still mean what you think they do.  However, the flexibility to modify rules by mutual agreement is the obvious way around that.  Define, as part of your extension, a setting that indicates your willingness to accept, say, an "opinion" string embedded in each SETTINGS ACK.  Upon receipt of that setting, someone who doesn't speak your extension ignores it and sends normal ACKs.  Someone who does speak your extension knows they can send you non-standard ACKs and you'll handle them appropriately without generating a FRAME_SIZE_ERROR.

-----Original Message-----
From: Bob Briscoe [mailto:bob.briscoe@bt.com] 
Sent: Thursday, March 5, 2015 4:55 AM
To: mbelshe@chromium.org; fenix@google.com; martin.thomson@gmail.com
Cc: ietf-http-wg@w3.org
Subject: HTTP/2 extensibility <draft-ietf-httpbis-http2-17>

HTTP/2 folks,

I've reviewed the whole draft. I know the draft has just successfully passed IESG review, but I hope this posting is still useful.

My credentials for this: first role in the IETF in 1995 was to ensure
HTTP/1.1 generalised from Web pages to objects, but for the last 15 years my focus has shifted down the layers into transport.
Non-credentials: I've been paying insufficient attention to HTTP/2 until now, but I have tried to research back over the ML for the rationale behind design decisions.

So consider this as a late review from a clueful but fresh pair of eyes.

My main concerns are
* extensibility
* flow control
* numerous open issues left dangling
I'll cover extensibility here, and my other concerns (as well as
nits) in subsequent posting.


Achieving this milestone on time has been impressive. I understand 
the reasons for having to get something standardised. However, I see 
potential problems. And that would be fine, but only if there were a 
more granular mechanism to extend the protocol to fix it in future.

For instance, a number of potential issues around DoS are left open. 
If the protocol has to be hardened against new attacks, I believe the 
recommended extensibility path is to design and implement a 
completely new protocol release, then upgraded endpoints negotiate it 
during the initial handshake. The timescale for such a process is 
measured in years, during which the vulnerability has to be lived 
with. Surely we need more granular extensibility; to introduce new 
frame types and structures, and/or to deprecate outdated/vulnerable ones.

Rather than a blanket statement saying that an endpoint discards and 
ignores a frame type that it does not recognise, we should include a 
field in the generic frame header to specify this behaviour. In this 
way, the currently defined extensibility behaviour could be required 
or relaxed depending on what the future brings - instead of having to 
decide the extensibility model now.

This would be safe, because the worst an attacker can do is inject a 
new unrecognised header and get it forwarded, but not acted on. 
Unless it is a type known to at least one implementation, it will 
never be acted on.

The same point applies to extending known frame types. There is no 
point having a length field on frames if any length other than that 
specified produces a FRAME_SIZE_ERROR. For extensibility, a frame 
with an unexpected length should at least be ignored, rather than 
leading to a stream error. Ideally, similar to above, there should be 
a field that specifies what action to take (forward or not) if the 
structure of the frame type is unrecognised.

One of the greatest strengths of HTTP/1.x was the general rule about 
unrecognised headers, which enabled 'a thousand flowers to bloom'. 
The few most beautiful ones survived. If evolution can only proceed 
in giant steps, the natural selection process will be glacially slow.

HTTP is important to us all. It has now become the only way to extend 
transport capabilities. The last thing we should do is build over the 
only pathway we have left with an evolutionary cul-de-sac.



Bob


________________________________________________________________
Bob Briscoe,                                                  BT

Received on Thursday, 5 March 2015 18:22:37 UTC