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

[Kazuho Oku <[e-mail]>]

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.

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]>
Date: 2024年2月20日(火) 11:25
Subject: Confirm submission of I-D draft-kazuho-httpbis-reverse-tunnel
To: Kazuho Oku <[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/


Best regards,

        The IETF Secretariat
        through the Internet-Draft submission service





-- 
Kazuho Oku

---------- Forwarded message ---------
From: <[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]>


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
Status:
https://datatracker.ietf.org/doc/draft-kazuho-httpbis-reverse-tunnel/
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


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