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

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

Received on Friday, 6 March 2015 13:35:47 UTC