Re: Interest in a UDP equivalent to the CONNECT method

[Martin Thomson <[e-mail]>]

I'm surprised that no one has mentioned TURN yet.  So let me be the first.

On Sun, Feb 4, 2018 at 1:27 AM, Lucas Pardue <[e-mail]> wrote:
> 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.  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]) 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.
>
>
> 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
>
>