Re: [Masque] Updated proposed charter text

[Christopher Wood <[e-mail]>]

Hi Marcus,

For what it's worth, this change reflects the mechanism currently proposed in [1]. This seemed to have some measure of rough consensus based on comments we (chairs) heard before, during, and after the meeting. There are of course pros and cons with this change, e.g., it can re-use existing machinery (pro!), but that machinery might not always exist or can be too complex (con!).

Best,
Chris

[1] https://tools.ietf.org/html/draft-schinazi-masque-protocol-01

On Fri, Apr 3, 2020, at 6:06 AM, Marcus Ihlar wrote:
> 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
> -- 
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>