Re: [Masque] Updated proposed charter text

[Marcus Ihlar <[e-mail]>]

Hi,
The previous charter proposal, shown in the BoF slides, refers to using QUIC as a candidate protocol for proxying traffic.
In the text you propose below, all mentions of QUIC are replaced with HTTP/3.
I'm afraid that specifying that HTTP/3 should serve as the substrate for the proxied traffic at this point will limit the possible solutions the working group can consider. Using the word QUIC instead of HTTP/3 in the charter text would allow the wg to consider a broader solution space, including something based on HTTP/3.

Marcus

-----Original Message-----
From: Masque <[e-mail]> On Behalf Of Christopher Wood
Sent: den 31 mars 2020 18:43
To: [e-mail]
Subject: [Masque] Updated proposed charter text

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.

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
[e-mail]
https://www.ietf.org/mailman/listinfo/masque