Re: Interest in a UDP equivalent to the CONNECT method

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