Re: [Masque] Updated proposed charter text

I don't think the diversity of naming here is that useful as a guide to the
diversity of the use cases. For instance, 2817, which defines CONNECT uses
the term both "proxy" and "tunnel" in the same sentence.

"A CONNECT method requests that a proxy establish a tunnel connection on
its behalf."

And yet TURN, which provides a similar service, calls itself "Traversal
Using Relays around NAT".

As a practical matter, the TCP and UDP use cases focus on establishing an
association with the server in which packets are forwarded to and from a
given destination and the IP use case seems to focus on forwarding IP
datagrams from the client to and from arbitrary destinations (this last
might use some fleshing out, I suppose).

-Ekr

On Thu, Apr 2, 2020 at 7:03 AM Christopher Wood <caw@heapingbits.net> wrote:

> On Tue, Mar 31, 2020, at 4:34 PM, Spencer Dawkins at IETF wrote:
> > Hi, Christopher,
> >
> > Thanks for getting this update out so quickly.
> >
> > I have thoughts, but wanted to start with the first couple of
> paragraphs.
> >
> > On Tue, Mar 31, 2020 at 11:43 AM Christopher Wood <caw@heapingbits.net>
> wrote:
> > > Based on last week's meeting, it seems folks are generally
> enthusiastic about some form of MASQUE moving forward. To help scope that
> particular form, here's an update to the proposed charter.
> > >
> > >  ~~~
> > >  Many network topologies lead to situations where transport protocol
> proxying is beneficial. For example, proxying enables endpoints to
> communicate when end-to-end connectivity is not possible and can apply
> additional encryption where desirable (such as a VPN). Proxying can also
> improve client privacy, e.g., by hiding a client's IP address from a target
> server.
> > >
> > >  Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit
> with their own shortcomings. For example, SOCKS signalling is not encrypted
> and HTTP CONNECT is currently limited to TCP. In contrast, HTTP/3 is a
> viable candidate protocol for proxying arbitrary traffic, as it provides
> secure connectivity, multiplexed streams, and migration for a single
> connection while taking advantage of a unified congestion controller.
> HTTP/3 datagrams provide for unreliable data transmission, which enables
> transporting UDP and other unreliable flows via a proxy without introducing
> potentially redundant or unnecessary recovery mechanisms. Further, HTTP/3
> supports an established request/response semantic that can set up and
> configure flows for different services.
> >
> > If I remember correctly, somewhere between the audio conference and the
> > active jabber conversation, there were people who mentioned
> >  * proxies
> >  * relays
> >  * tunnels
> >  * VPNs
> >  * NATs, and
> >  * now that I look at the second paragraph, maybe even firewalls
> > Is it possible to agree on the functionalities that this community of
> > interest is thinking of, as part of the charter discussion?
> >
> > ISTM that if we're talking about "connect for IP", we're closer to a
> > tunnel than a proxy, and I don't think that's what most of the MASQUE
> > folk were thinking of.
> >
> > Perhaps this will fall out of the use cases people have been collecting?
>
> Yep, I expect that to be the case! While the use cases in the charter are
> not meant to be exhaustive, more specificity would probably help frame the
> rest of the content.
>
> Meta question: are you looking for a specific change in the text, and if
> so, what might that be?
>
> Best,
> Chris
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>