Re: Interest in a UDP equivalent to the CONNECT method

I see two: HTTP/QUIC and WebRTC.  In both cases, connecting through an HTTP
proxy currently prevents UDP communication with the destination, impairing
performance and compatibility.

On Sun, Feb 4, 2018 at 12:02 PM, Ian Swett <ianswett@google.com> wrote:

> This seems generally useful, but are there enough motivating use cases?
>
> On Sun, Feb 4, 2018 at 11:19 AM, Ben Schwartz <bemasc@google.com> wrote:
>
>> In my view, a UDP counterpart to CONNECT ought to work not only for
>> HTTP/QUIC but also for WebRTC.  That means that it should have the ability
>> to receive packets from unexpected sources, as the remote party's effective
>> address may not be known in advance.  I don't know how to map that semantic
>> into HTTP/2 frames.
>>
>> On Sun, Feb 4, 2018 at 9:54 AM, Lucas Pardue <Lucas.Pardue@bbc.co.uk>
>> wrote:
>>
>>> 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.
>>>
>>> Noted.
>>>
>>> > 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
>>> Lucas
>>>
>>>
>>> -----------------------------
>>> http://www.bbc.co.uk
>>> 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
>>> immediately.
>>> Please note that the BBC monitors e-mails
>>> sent or received.
>>> Further communication will signify your consent to
>>> this.
>>> -----------------------------
>>>
>>
>>
>