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

Martin, (and Ben who reinforced Martin's points),

So extensibility experience from the app-layer is being applied to a 
transport layer protocol (an unfortunate consequence of giving a name 
to a new transport protocol that makes it look like a major revision 
of an app-layer protocol).

In the IETF TCP maintenance WG, the bar to changes is very high, 
given insufficiently analysed and tested changes could be devastating 
to the Internet. When doing 'mundane' lower layer stuff like framing 
and multiplexing, it is much less likely that you will get an 
explosion of different ways of doing it. In TCPM, explosion of 
feature interactions is only a minor concern, because the number of 
revisions has remained small.

In the transport layer 'culture' changes take longer to introduce. 
But that's because the cost of failure is higher, and it's much 
harder to fix errors once they have been deployed.

inline...

At 17:57 05/03/2015, Martin Thomson wrote:
>You might like to think of this from another perspective: Postel's
>famous statement[1] is not a principle that guides protocol design, it
>is in fact a fatalistic observation about the effect of entropic decay
>of a protocol.

I assume you're referring to
" In general, an implementation must be conservative
   in its sending behavior, and liberal in its receiving behavior." [RFC791]

This /is/ a principle that guides protocol design, but perhaps 
HTTP/1.x experience shows that it is less appropriate at higher 
layers. At lower layers, it has stood the test of time, and you don't 
hear anyone questioning it.


>Finally, designing good extensibility is really, really hard.  It
>takes time.  And as the saying goes, shipping is a feature.

Oh dear. I think we are witnessing a layering violation of cultures.


> > For instance, a number of potential issues around DoS are left open.

Ben, I'm referring to the large number of DoS concerns listed in the 
HTTP/2 spec in open-ended sentences that just state the concern. Each 
one made me think "So, why haven't you redesigned the protocol then?" 
If I had designed a protocol with those concerns, I wouldn't have 
even brought it to standardisation until I had at least some idea of 
a direction to address them. Again, this seems to be a culture 
difference between app-layer and lower layers.

>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.
>
>I don't know what others think, but I would expect that a small,
>necessary change to the protocol could be deployed by those affected
>in much the same timescale as an extension might be.  I do appreciate
>the fact that calling something HTTP/3 to fix a small DoS bug might
>*seem* drastic, but the only risk is in avoiding people with an axe to
>grind trying to get in other changes when you do that.

Has the WG really thought through whether this extensibility approach 
is going to work? For instance, has a revision naming scheme been 
designed that can describe forks?

Also, it's not just about how a revision is /named/. It's about a 
completely different /process/...

HTTP/3 (or even HTTP/2.0.0.1) would need to be agreed by a whole 
standards committee process, no matter how minor the change. Whereas 
a new unilateral frame type could be experimented with locally, or 
used locally to patch a vulnerability.


>(I'll also note that your concerns are largely only relevant in the
>presence of intermediaries, for what that is worth.)

Correct, revisions (whether unliateral or standardised) are v hard to 
deploy if intermediate nodes must 'discard if unknown' (see the 
thread with Mike Bishop, that I have forked).


Bob




________________________________________________________________
Bob Briscoe,                                                  BT

Received on Friday, 6 March 2015 14:34:02 UTC