RE: Interest in a UDP equivalent to the CONNECT method

Hi Ilari,

Thanks for the comments. To be clear, the intent is to emulate the use of CONNECT as far as possible. The details of how CONNECT is used across HTTP/1.1, HTTP/2 and HTTP/QUIC varies a little but the main gist is similar.

Ilari Liusvaara wrote:

> 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.

My main experience is with HTTP/QUIC so I gave that as an example. In simple terms, the client using the proxy begins a TLS 1.3 negotiation over UDP with the remote host, once keys are exchanged protected QUIC packets are used.

> 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.

I think this is already true of HTTP/2 and CONNECT. RFC 7540 section 8.3 states that on the stream that initiated the CONNECT request, DATA frames have a new meaning, they correspond to data sent on the (remote) TCP connection.

For HTTP/QUIC, I would imagine that a client packages QUIC packets targeting the remote host within DATA frames. The proxy unframes these and forwards them on, and vice-versa.

> 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.

Ben made the same point so perhaps I'm not understanding the issue. As I understand it, if you are using a protocol on top of UDP that requires reliability, then you need to provide that. E.g in the HTTP/QUIC use case  QUIC provides the reliability assurances.

> > 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)?

I'm open to input here.

Kind regards


This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to

Received on Sunday, 4 February 2018 14:54:42 UTC