HTTP/2 open issues <draft-ietf-httpbis-http2-17>

[Bob Briscoe <[e-mail]>]

HTTP/2 editor & co-authors,

As I read through the draft, I attempted to list all the areas where 
an open issue has been left dangling. I checked the issues list, and 
none of these were there. I expect you might want to (or ought to) 
move some of these onto an issues list (for a future version of HTTP, 
if not the current version).

That being said, in nearly all the cases below, if I had been the 
protocol designer, given the importance and prevalence of HTTP, I 
would have felt obliged to redesign the protocol to make it 
inherently robust against these issues. There should at least be some 
assurance that a major extension has safety valves or fall-backs that 
can be deployed if faced with an abuse of any of the weaknesses below.

[BTW, I have quoted the text as written - I will list nits in a later posting.]


<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-3.2>3.2. 
Starting HTTP/2 for "http" URIs
"  Requests that contain an payload body MUST be sent in their entirety
    before the client can send HTTP/2 frames.  This means that a large
    request entity can block the use of the connection until it is
    completely sent.
"
So...

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.2.2>5.2.2. 
Appropriate Use of Flow Control
"  Deployments with constrained resources (for example, memory) can
    employ flow control to limit the amount of memory a peer can consume.
    Note, however, that this can lead to suboptimal use of available
    network resources if flow control is enabled without knowledge of the
    bandwidth-delay product (see [RFC7323]).
"
So... (see previous posting on flow control)

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.2.2>5.2.2. 
Appropriate Use of Flow Control
"  When using flow
    control, the receiver MUST read from the TCP receive buffer in a
    timely fashion.  Failure to do so could lead to a deadlock when
    critical frames, such as WINDOW_UPDATE, are not read and acted upon.
"
So... (see previous posting on flow control)

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.4>6.4. 
RST_STREAM
"  However, after sending the
    RST_STREAM, the sending endpoint MUST be prepared to receive and
    process additional frames sent on the stream that might have been
    sent by the peer prior to the arrival of the RST_STREAM.
"
So... [I notice numerous IESG reviews picked up on this, but the 
sentence has been left unchanged]. When can it eventually relax this 
requirement (to release stream state), and what are the consequences 
if it relaxes too early?

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-8.2>8.2. 
Server Push

"    Note this could result in
    the promised stream being reset if the client does not recognize a
    newly defined method as being safe.
"
So...
[Won't this risk breaking a perfectly good (but unrecognised) 
application? Wouldn't the behaviour a couple of paras later be more 
appropriate "...made available to the application separately"? Or is 
the idea that if the promised stream is reset, the client then 
naturally requests the stream?]

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-10.5>10.5. 
Denial of Service Considerations

"  The SETTINGS frame can be abused to cause a peer to expend additional
    processing time.  This might be done by pointlessly changing SETTINGS
    parameters, setting multiple undefined parameters, or changing the
    same setting multiple times in the same frame.  WINDOW_UPDATE or
    PRIORITY frames can be abused to cause an unnecessary waste of
    resources.
"
So...

"  Large numbers of small or empty frames can be abused to cause a peer
    to expend time processing frame headers.  Note however that some uses
    are entirely legitimate, such as the sending of an empty DATA or
    CONTINUATION frame at the end of a stream.
"
So...

"  Header compression also offers some opportunities to waste processing
    resources; see Section 7 of [COMPRESSION] for more details on
    potential abuses.
"
So...

"  Limits in SETTINGS parameters cannot be reduced instantaneously,
    which leaves an endpoint exposed to behavior from a peer that could
    exceed the new limits.  In particular, immediately after establishing
    a connection, limits set by a server are not known to clients and
    could be exceeded without being an obvious protocol violation.
"
So...

"  All these features - i.e., SETTINGS changes, small frames, header
    compression - have legitimate uses.  These features become a burden
    only when they are used unnecessarily or to excess.
"
So...

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-10.5.2>10.5.2. 
CONNECT Issues
"  The CONNECT method can be used to create disproportionate load on an
    proxy, [...]  A proxy therefore
    cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the
    resources consumed by CONNECT requests.
"
So...

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-10.8>10.8. 
Privacy Considerations

"  Because the PING and SETTINGS frames solicit immediate responses,
    they can be used by an endpoint to measure latency to their peer.
    This might have privacy implications in certain scenarios.
"
So...



Bob



________________________________________________________________
Bob Briscoe,                                                  BT