Re: Interest in a UDP equivalent to the CONNECT method

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> 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.
> -----------------------------
>