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

Mike,

I omitted to comment on the rather unconventional structure of 
SETTINGS frames too, which makes SETTINGS both hard to extend and inefficient.

"A SETTINGS frame with a length other than a multiple of 6 octets 
MUST be treated as a connection error"
The SETTINGS frame structure seems not to use the extensible 
type-length-value (TLV) design, that has been tried and tested for 
binary protocols over decades.

The 16b SETTINGS type is currently used for 6 values (1-6). 
Extensibility to allow the other 65,530 values will be fairly 
pointless if each of their values has to fit within 32b.

A [T:L:V] of [8:8:variable] octets would probably have been 
sufficient, more efficient and far more flexible.



Bob

[Side-stepping Poul-Henning's comments that are probably true, but 
perhaps not phrased in a way that will persuade you to reconsider.]


At 13:35 06/03/2015, Bob Briscoe wrote:
>Mike,
>
>At 18:22 05/03/2015, Mike Bishop wrote:
>>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.
>
>That's only an argument for having a length field. It doesn't 
>justify 'discard unknown' any more than it justifies 'ignore 
>unknown'. And it doesn't justify hard-coding the predetermined valid 
>length into the implementation.
>
>>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.)
>
>OK, that /is/ a valid argument for 'discard unknown' rather than 
>'forward unknown'.
>
>But I suggested a solution to that; if it's unknown, there could be 
>a field in the frame that says whether to forward or discard it 
>(aka. late binding, like in IPv6 extension headers). Then:
>* if a new frame type would be susceptible to inconsistency over 
>different paths, it can be flagged as 'discard unknown'.
>* Otherwise it would be flagged as 'forward unknown'.
>* And if we're not sure, we can play safe and flag it as 'discard 
>unknown' anyway.
>
>Then you could keep the tightly consistent design you want today (by 
>setting discard unknown on all frame types), but you haven't 
>foreclosed on a 'forward unknown' frame type if you really need it in future.
>
>During the design discussions, did anyone suggest this 'late binding' idea?
>
>>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.
>
>There seems to be an assumption that implementers will add new 
>features even though they won't work e2e until everyone else has 
>implemented and deployed the same feature. That seems to overlook 
>the last two depressing decades of experience (at the transport 
>layer) of chicken-and-egg deployment incentives.
>
>>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.
>
>Yes. So again, my concern is that the spec requires frames to be 
>discarded if they are of known type but unknown length; rather than 
>using the 'late-binding' idea, to be able to 'ignore but forward unknown'.
>
>
>Bob
>
>
>>-----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
>
>________________________________________________________________
>Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT

Received on Friday, 6 March 2015 17:10:22 UTC