Re: Proposal for Creating Reverse Tunnels, for HTTP and TCP (Fwd: New Version Notification for draft-kazuho-httpbis-reverse-tunnel-00.txt)

[Ben Schwartz <[e-mail]>]

Hi HTTP,

Kazuho and I had a longer discussion about this proposal.  I think it's interesting, but I'm not convinced it's a good basis for standardization:

1. In the "reverse TCP server" use case, this design requires the backend to open up and maintain a huge backlog of hanging GET requests to accommodate any spikes in connection attempts.  This seems extremely wasteful.
2. For "Reverse HTTP", this design doesn't extend to HTTP/3 in an obvious way.  I would like to see a unified design for Reverse HTTP that spans HTTP/2 and HTTP/3 (and preserves the performance and functionality of HTTP/3).

There are a lot of possible ways to solve these reverse-connection problems, and I'm glad that we now have a few ideas about how it might be done.  Hopefully as we explore these possibilities the right answer will become clearer.

--Ben


________________________________
From: Kazuho Oku <[e-mail]>
Sent: Monday, February 19, 2024 9:40 PM
To: HTTP Working Group <[e-mail]>
Subject: Proposal for Creating Reverse Tunnels, for HTTP and TCP (Fwd: New Version Notification for draft-kazuho-httpbis-reverse-tunnel-00.txt)

Hello folks, At the previous IETF meeting, Ben presented the “Reverse HTTP” proposal, which can be found at: https: //github. com/httpwg/wg-materials/blob/gh-pages/ietf118/reverse-http. pdf. When we discussed the proposal, it seemed that there
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Hello folks,

At the previous IETF meeting, Ben presented the “Reverse HTTP” proposal, which can be found at: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf118/reverse-http.pdf.

When we discussed the proposal, it seemed that there is interest in:
* using extended CONNECT, and
* supporting reverse tunneling for TCP, in addition to HTTP.

As stated during the meeting, we are interested in implementing this feature in h2o and have therefore submitted the draft, available at: https://www.ietf.org/archive/id/draft-kazuho-httpbis-reverse-tunnel-00.html<https://www.ietf.org/archive/id/draft-kazuho-httpbis-reverse-tunnel-00.html>.

Please let us know what you think.

For the primary use case of setting up HTTP connections in the reverse direction, the draft employs the extended CONNECT method (or the upgrade mechanism in HTTP/1.1). Once the tunnel is set up, HTTP/1.1 or HTTP/2 can be used as-is.

The design utilizes URIs to identify the reverse service, offering flexibility to operators, including the large-scale reverse proxy operators who automate configuration changes. Operators can provide unique URIs to each backend that connects in the reverse direction, and authenticate the backends using HTTP authentication (or other HTTP-based authentication schemes).

Additionally, this feature can be seamlessly integrated into existing reverse proxies with minimal effort and virtually zero overhead. A reverse proxy can accept the reverse tunnel using HTTP/1.1, and upon establishment, just “add” the tunnel’s TCP / TLS connection to the already-existing connection pool. This is because the protocol being used atop the tunnel is HTTP/1.1 or HTTP/2 unmodified. Of course, the draft does not forbid endpoints from using HTTP/2 to establish reverse tunnels. It will be at the discretion of the endpoints to decide which HTTP version to use.

Considering that tunnels will be typically established using HTTPS, additional encryption atop the tunnel is often unnecessary. In light of this, the draft defines a method to negotiate the application protocol by reusing the ‘ALPN’ header field, streamlining communication within the encrypted tunnel.

For the other use case of setting up a TCP relay, the draft utilizes the ‘Forwarded’ header field to convey the 4-tuple of the TCP connection being relayed. The header field is sent as part of a successful response indicating the establishment of the relay. Until a relay is established, 100 (Continue) responses are used to indicate that the relay is waiting for a connection to be matched.

Regarding the TCP relay use case, it might be worthwhile to mention an alternative approach not included in the current draft submission. This strategy entails establishing an HTTP reverse tunnel as previously described, followed by utilizing this channel to transmit 'CONNECT' requests that relay TCP connections. This approach might be slightly more complex than the design specified in the draft, but it builds on top of the HTTP feature that already exists for relaying bi-directional byte streams.

---------- Forwarded message ---------
From: IETF I-D Submission Tool <[e-mail]<mailto:[e-mail]>>
Date: 2024年2月20日(火) 11:25
Subject: Confirm submission of I-D draft-kazuho-httpbis-reverse-tunnel
To: Kazuho Oku <[e-mail]<mailto:[e-mail]>>



Hi,

The IETF datatracker Internet-Draft submission service has received your Internet-Draft
draft-kazuho-httpbis-reverse-tunnel-00, and requires a
confirmation step in order to be able to complete the posting of
the Internet-Draft.
Please follow this link to the page where you can confirm the posting:

https://datatracker.ietf.org/submit/status/140209/confirm/da185e3e7d346ab40f2a320bf26a2917/<https://datatracker.ietf.org/submit/status/140209/confirm/da185e3e7d346ab40f2a320bf26a2917/>


Best regards,

        The IETF Secretariat
        through the Internet-Draft submission service





--
Kazuho Oku

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: 2024年2月20日(火) 11:35
Subject: New Version Notification for draft-kazuho-httpbis-reverse-tunnel-00.txt
To: Kazuho Oku <[e-mail]<mailto:[e-mail]>>


A new version of Internet-Draft draft-kazuho-httpbis-reverse-tunnel-00.txt has
been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:     draft-kazuho-httpbis-reverse-tunnel
Revision: 00
Title:    Reverse Tunnel over HTTP
Date:     2024-02-20
Group:    Individual Submission
Pages:    12
URL:      https://www.ietf.org/archive/id/draft-kazuho-httpbis-reverse-tunnel-00.txt<https://www.ietf.org/archive/id/draft-kazuho-httpbis-reverse-tunnel-00.txt>
Status:   https://datatracker.ietf.org/doc/draft-kazuho-httpbis-reverse-tunnel/<https://datatracker.ietf.org/doc/draft-kazuho-httpbis-reverse-tunnel/>
HTML:     https://www.ietf.org/archive/id/draft-kazuho-httpbis-reverse-tunnel-00.html<https://www.ietf.org/archive/id/draft-kazuho-httpbis-reverse-tunnel-00.html>
HTMLized: https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-reverse-tunnel<https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-reverse-tunnel>


Abstract:

   This document specifies an HTTP extension to establish bi-directional
   byte streams in the direction from servers to their clients,
   utilizing HTTP as a tunneling mechanism.  This approach not only
   facilitates communication between servers located behind firewalls
   and their known clients but also introduces the potential for these
   known clients to serve as relays.  In such configurations, clients
   can forward application protocol messages or relay TCP connections,
   allowing servers to interact with any client on the Internet without
   direct exposure.



The IETF Secretariat




--
Kazuho Oku