Re: New draft: Reverse HTTP Transport

On Tue, Jul 11, 2023 at 10:43:45AM -0400, Benjamin Schwartz 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!
> --Ben Schwartz

That's an incredible coincidence as we haproxy developers have just
started a reflection on a similar feature for our future releases. The
idea is to initiate a connection from a server-side haproxy to a
client-side haproxy and then reverse it to transfer HTTP traffic, quite
similar to what is described in this RFC. It could definitely be
interesting if a standard would emerge for this so we will look
carefully for future development on this topic.

-- 
Amaury Denoyelle

Received on Thursday, 13 July 2023 14:48:50 UTC