Re: [Masque] Updated proposed charter text

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?

Best,

Spencer

> The primary goal of this working group is to develop mechanisms that allow
> configuring and concurrently running multiple proxied stream- and
> datagram-based flows inside a HTTP/3 connection. The group will specify an
> HTTP-based signaling protocol for creating and configuring each service
> flow. The group will first focus on a limited set of client-initiated
> services such as IP, UDP, and TCP proxying. Specifying proxy server
> discovery mechanisms is out of scope for the group. However, the group may
> specify techniques for identifying proxy servers to aid future discovery
> mechanisms.
>
> The group will coordinate closely with other working groups responsible
> for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS.
> ~~~
>
> This should address most of the issues raised during the meeting [1]. We'd
> like to hear what people think about this as a viable path forward.
>
> Thanks,
> Chris, on behalf of the chairs
>
> [1] These issues include, though are not limited to:
>
> 1. Whether or not this is a new protocol or an extension of an existing
> protocol must be clear before moving forward.
> 2. Motivation for proxy technologies requires improvement. In particular,
> there’s no mention of privacy objectives.
> 3. The proxy threat model is unclear or underspecified. Does it model
> Tor’s threat model, or is it something simpler? (Meta question: should this
> be part of an existing document?)
> 4. Why are services beyond simple “CONNECT for UDP or IP” in scope? Should
> we focus on the simple datagram proxy case first and carve out room for
> extensibility?
> 5. To what extent is discovery out of scope?
> 6. Framework is perhaps not the best word to describe MASQUE.
>
> Any errors or omissions from this list are entirely my fault!
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>