Interest in a UDP equivalent to the CONNECT method

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Sat, 03 February 2018 14:31 UTC

Resent-Date: Sat, 03 Feb 2018 14:28:11 +0000
Resent-Message-Id: <E1ehynb-0004qW-Ic@frink.w3.org>
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: "bemasc@google.com" <bemasc@google.com>
Thread-Topic: Interest in a UDP equivalent to the CONNECT method
Thread-Index: AdOc9p/RJM+VVNUGQX2RQg/+Gk9/9Q==
Date: Sat, 03 Feb 2018 14:27:35 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BACADD6@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-GB
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BACADD6bgb01xud1012_"
MIME-Version: 1.0
Subject: Interest in a UDP equivalent to the CONNECT method
Archived-At: <https://www.w3.org/mid/7CF7F94CB496BF4FAB1676F375F9666A3BACADD6@bgb01xud1012>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hi,

I'm wondering if there is interest from the WG in the following space before investing any more technical effort.

It recently struck me that there might be a use in iterating upon the CONNECT method, in order to support a world of UDP servers that support HTTP/QUIC. That spec neatly summarises the current state of play:

In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a
tunnel to a remote host. In HTTP/2, the CONNECT method is used to
establish a tunnel over a single HTTP/2 stream to a remote host for
similar purposes.

A CONNECT request in HTTP/QUIC functions in the same manner as in
HTTP/2. The request MUST be formatted as described in [RFC7540],
Section 8.3<https://tools.ietf.org/html/rfc7540#section-8.3>. A CONNECT request that does not conform to these
restrictions is malformed. The request stream MUST NOT be half-
closed at the end of the request.

A proxy that supports CONNECT establishes a TCP connection
([RFC0793<https://tools.ietf.org/html/rfc0793>]) to the server identified in the ":authority" pseudo-
header field. Once this connection is successfully established, the
proxy sends a HEADERS frame containing a 2xx series status code to
the client, as defined in [RFC7231], Section 4.3.6<https://tools.ietf.org/html/rfc7231#section-4.3.6>.

The sad part here is that an HTTP/QUIC client that uses an HTTP/QUIC proxy in this mode needs to support TCP for secure connection to the remote host. This presents some resistance to moving away from TCP in the future.

I wondered if something better could exist, and Ben Schwartz and I batted some ideas around. The strongest one was the idea of a new method (e.g. UDPBIND) that would allow a client to indicate to the proxy that it wished to communicate with the remote host using UDP. Depending on the protocol being used for client-to-proxy communication some options present themselves (NB: the data exchanged is the serialization of TLS handshake and protected packet format):

* HTTP/QUIC
* DATA frames sent by client (UDP) are transmitted by the proxy to the remote host UDP port (UDP).
* data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (UDP).
* HTTP/2
* DATA frames sent by client (TCP) are transmitted by the proxy to the remote host UDP port (UDP).
* data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (TCP).
* HTTP/1.1 ?
* data sent by the client (TCP) is transmitted by the proxy to the remote host UDP port (UDP).
* data received by the proxy (UDP) is transmitted to the client (TCP).

The conversion between TCP and UDP should be treated carefully, payloads may be segmented unexpectedly.

The handling of UDP "closure" is a problem area that needs more thought.

Kind regards
Lucas

Interest in a UDP equivalent to the CONNECT method Lucas Pardue
Re: Interest in a UDP equivalent to the CONNECT m… Ilari Liusvaara
Re: Interest in a UDP equivalent to the CONNECT m… Göran Eriksson AP
RE: Interest in a UDP equivalent to the CONNECT m… Lucas Pardue
RE: Interest in a UDP equivalent to the CONNECT m… Lucas Pardue
Re: Interest in a UDP equivalent to the CONNECT m… Ben Schwartz
Re: Interest in a UDP equivalent to the CONNECT m… Ian Swett
Re: Interest in a UDP equivalent to the CONNECT m… Ben Schwartz
Re: Interest in a UDP equivalent to the CONNECT m… Albert Lunde
Re: Interest in a UDP equivalent to the CONNECT m… Fossati, Thomas (Nokia - GB/Cambridge)
RE: Interest in a UDP equivalent to the CONNECT m… Lucas Pardue
Re: Interest in a UDP equivalent to the CONNECT m… Göran Eriksson AP
RE: Interest in a UDP equivalent to the CONNECT m… Mike Bishop
Re: Interest in a UDP equivalent to the CONNECT m… Martin Thomson
RE: Interest in a UDP equivalent to the CONNECT m… Lucas Pardue
Re: Interest in a UDP equivalent to the CONNECT m… Martin Thomson
Re: Interest in a UDP equivalent to the CONNECT m… Göran Eriksson AP
Re: Interest in a UDP equivalent to the CONNECT m… Ben Schwartz
RE: Interest in a UDP equivalent to the CONNECT m… Lucas Pardue
Re: Interest in a UDP equivalent to the CONNECT m… Göran Eriksson AP
Re: Interest in a UDP equivalent to the CONNECT m… Göran Eriksson AP
Re: Interest in a UDP equivalent to the CONNECT m… Amos Jeffries
Re: Interest in a UDP equivalent to the CONNECT m… Göran Eriksson AP