Re: New draft: Reverse HTTP Transport

Hey Ben,

On Thu, Jul 13, 2023 at 9:14 PM Ben Schwartz <bemasc@meta.com> wrote:

> Hi Lucas,
>
> I am under the impression that the QUIC stream types are fully symmetrical
> (https://datatracker.ietf.org/doc/html/rfc9000#table-1).  In Reverse
> HTTP/3, these restrictions would presumably apply as usual but to the
> opposite stream types.  Does this make sense?  How could we make the text
> clearer?
>

Oh I think it's totally feasible for this to work but I would paint it out
more clearly exactly how you'd do that.  I don't think that would take too
much text / effort. For example, in RFC 9114 Section 6.1 [1] the text says

> All client-initiated bidirectional streams are used for HTTP requests and
responses. A bidirectional stream ensures that the response can be readily
correlated with the request. These streams are referred to as request
streams.This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on streams 4, 8, and so on. In order to permit
these streams to open, an HTTP/3 server SHOULD configure non-zero minimum
values for the number of permitted streams and the initial stream
flow-control window. So as to not unnecessarily limit parallelism, at least
100 request streams SHOULD be permitted at a time.

> HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams. Clients MUST treat receipt
of a server-initiated bidirectional stream as a connection error
<https://www.rfc-editor.org/rfc/rfc9114.html#errors> of type
H3_STREAM_CREATION_ERROR
<https://www.rfc-editor.org/rfc/rfc9114.html#H3_STREAM_CREATION_ERROR>
unless such an extension has been negotiated.

Your proxy is a QUIC server but an HTTP/3 client. It can't open a
client-initiated stream. So the text in reverse HTTP/3 could say something
like below (I'm adding reverse qualifiers here to help avoid confusion,
spec text could omit them).

"All server-initiated bidirectional streams are used for HTTP requests and
responses. These streams are referred to as reverse request streams. This
means the reverse HTTP/3 client's first request occurs on QUIC stream 2,
with subsequent requests on streams 6, 10 and so on. In order to permit
these streams to happen, the reverse HTTP/3 server (i.e. QUIC client)
SHOULD configure non-zero minimum values ....

Reverse HTTP/3 does not use client-initiated bidirectional streams, though
an extension could define a use for these streams. Reverse HTTP/3 clients
MUST treat receipt of a client-initiated bidirectional stream as a
connection error of type H3_STREAM_CREATION_ERROR
<https://www.rfc-editor.org/rfc/rfc9114.html#H3_STREAM_CREATION_ERROR>
unless such an extension has been negotiated."

This highlights some issues with extensions. One solution is that
extensions that change rules for stream behaviour (e.g. WebTransport) might
need a small document that defines how they could be mapped to reverse
HTTP/3. Another solution might be to provide general reverse HTTP/3
guidance to accommodate reversal of extensions.

Cheers,
Lucas
[1] - https://www.rfc-editor.org/rfc/rfc9114.html#section-6.1



> --Ben
>
> ------------------------------
> *From:* Lucas Pardue <lucaspardue.24.7@gmail.com>
> *Sent:* Thursday, July 13, 2023 11:03 AM
> *To:* Benjamin Schwartz <ietf@bemasc.net>
> *Cc:* ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> *Subject:* Re: New draft: Reverse HTTP Transport
>
> Hiya, On Tue, Jul 11, 2023 at 3: 47 PM Benjamin Schwartz <ietf@ bemasc.
> net> wrote: Hi HTTPBIS, TIru Reddy and I have a fun new -00 today for your
> amusement: Reverse HTTP Transport (https: //www. ietf.
> org/archive/id/draft-bt-httpbis-reverse-http-00. html).
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
>
> ZjQcmQRYFpfptBannerEnd
> Hiya,
>
> On Tue, Jul 11, 2023 at 3:47 PM Benjamin Schwartz <ietf@bemasc.net> wrote:
>
> Hi HTTPBIS,
>
> TIru Reddy and I have a fun new -00 today for your amusement: Reverse HTTP
> Transport (
> https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-00.html).
>
> Abstract:
>    This document defines a secure transport for HTTP in which the client
>    and server roles are reversed.  This arrangement improves the origin
>    server's protection from Layer 3 and Layer 4 DDoS attacks when an
>    intermediary is in use.  It allows origin server's to be hosted
>    without being publicly accessible but allows the clients to access
>    these servers via an intermediary.
>
> Although the mechanism described here is generic, the main expected use
> case is related to MASQUE, OHAI, and Oblivious DoH.  The essence of the
> proposal is straightforward, but there are definitely some things for us to
> talk about in the details:
>
> * Transport proxies like CONNECT-UDP are handled by having the origin run
> its own proxy endpoint for access to itself.
>   - "CONNECT-TCP" is not used (even though I think it's great), because
> the target is only identified by an Origin, not a URI Template.
> * The TLS server (i.e. HTTP client) speaks first, at 1.5 RTT on the
> half-open TLS connection.
> * Ownership of transport endpoints and IP addresses is inferred from
> ownership of matching HTTP origins.
> * There are some real open questions about what to do about DNS
> verification and stolen key attacks.
>
> Please send us your thoughts!
>
>
> This is generally interesting so thanks for sharing. There are a lot of
> open questions, aside from the ones you others highlighted, the big one for
> me is that more definition is required to make the Reverse HTTP/3 design
> actually realizable. The doc states "operating with the roles reversed but
> otherwise unmodified" but I don't think this actually works that way. QUIC
> places more restrictions on what client or server roles can and can't do.
> For example, a QUIC server can open server streams. HTTP/3 doesn't allow
> request message sequences to be sent on QUIC bidirectional server streams,
> so an HTTP/3 implementation would need to support a different mapping
> definition to make this work in practice.
>
> Cheers,
> Lucas
>