Re: Interest in a UDP equivalent to the CONNECT method

On Sat, Feb 03, 2018 at 02:27:35PM +0000, Lucas Pardue wrote:
> 
> 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):

Why you are assuming the data has anything to do with TLS? What would
be the other endpoint of the TLS link? If it is the proxy, that seems
overly complicated, as things can be keyed easier. If remote server,
I do not think there are any programmatically understandable ways of
using TLS in this scenario. And then there are protocols that use
DTLS or something else to secure themselves.
 
> 
>   *   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.

There are UDP protocols that absolutely rely on segmentation, so the
segmentation needs to be preserved. I think DTLS 1.3 (as currently
drafted) is actually one of those protocols.

1:1 frame translation would be possible in HTTP/2 and QUIC (obviously
not in HTTP/1.1). However, it would change semantics of the DATA
frames from just being fragments of stream to meaningful units in
themselves.

Also, it seems to me that using any reliable streaming protocol
would run contrary to reasons applications are using UDP. TCP is so
much easier than UDP! Granted, the unpredictable delays would be much
smaller. I am not quite sure if QUIC plans to have unreliable streams
for the first version or not.
 
> The handling of UDP "closure" is a problem area that needs more
> thought.

I thought UDP has no "closure". You mean client or proxy shutting down
the listener (so to free the proxy resources)?


-Ilari

Received on Saturday, 3 February 2018 15:43:19 UTC