Name: Protocol for Transposed Transactions over HTTP (PTTH)

Description

The HTTP protocol family provides a rich request-response facility between HTTP clients (which emit requests) and HTTP servers (which return responses). Each version of HTTP relies on a transport protocol to provide the connection – typically TCP, TLS, or QUIC. The transport also identifies a client (which initiates the connection) and a server (which accepts the connection).

In every standard version of HTTP, the transport client is also the HTTP client. This is sensible in ordinary HTTP use cases, in which the client knows how to reach the desired server, but the server does not know how or when to reach all potential clients. However, there are some specialized service architectures in which the situation is reversed:
- The server is only intended to be accessed directly by a small number of clients.
- The server knows how to reach these approved clients.
- The server is not widely accessible by arbitrary clients due to security or routing constraints.

This arrangement most commonly occurs for servers that are subject to a strict transport firewall or have no fixed location. Examples include:
- Servers that are only publicly reachable via a CDN or DDoS defense service, to avoid unauthorized access and DDoS attacks on the backend server.
- Servers whose IP address changes frequently, and rely on an HTTP gateway to provide a stable destination for clients.
- “Hidden services” whose server location is a secret, concealed by an anonymizing transport proxy service.
- On-premise corporate servers, answering queries from an approved externally hosted service.
- Untrusted clients that need access to specific resources but are not permitted to initiate outgoing connections.

An additional area of emerging use cases is fueled by advances in MASQUE that enable tunneling of arbitrary UDP and TCP flows over HTTP. Proprietary solutions such as Zero Trust Network Access services commonly reverse initiator and responder transport roles for encapsulated network flows to provide security benefits and deployment flexibility.

Currently, there are multiple proprietary or vendor-specific deployed solutions for each of these use cases. In the absence of a standard, they are served by custom protocols and software. This impedes migration between service providers and cross-vendor integration.

Required Details

• Status: not WG Forming
• Responsible AD: Mike Bishop
• BOF proponents: Yaroslav Rosomakho <yaroslavros@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, Marius Kleidl <marius@transloadit.com>, Ben Schwartz <bemasc@meta.com>, Lucas Pardue <lucas@lucaspardue.com>
• BOF chairs: David Schinazi <dschinazi.ietf@gmail.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
• Number of people expected to attend: 100+
• Length of session (1 or 2 hours): 2 hours
• Conflicts (whole Areas and/or WGs)
• Chair Conflicts: webtrans, oauth, httpbis, tls, masque
• Technology Overlap: httpbis, masque
• Key Participant Conflict: wimse, webtrans, avtcore, ppm, privacypass, hpke, quic

Information for IAB/IESG

The PTTH BoF will discuss various use cases requiring reversing of HTTP roles and their implications. While presenters may mention specific solutions or design proposals, the focus of the meeting will be on defining the problem space and clarifying use cases. The outcome of the BoF will define further direction of this initiative: spawn a new working group, add this initiative into a charter of an existing working group such as httpbis or choose not to pursue this problem space at this time.

In addition to multiple proprietary solutions in this space, there been a number of relevant proposals over the years:
-https://datatracker.ietf.org/doc/html/draft-bt-httpbis-reverse-http
-https://datatracker.ietf.org/doc/html/draft-benfield-http2-p2p
-https://datatracker.ietf.org/doc/html/draft-lentczner-rhttp
-https://datatracker.ietf.org/doc/html/draft-rosomakho-masque-reverse-connect

Agenda

• Presentations of use cases by proponents
• Open discussion on the path forwards