Re: [Masque] Proposed draft charter

[Eric Kinnear <[e-mail]>]

Awesome, thanks all for the feedback! 

Updating with the changes proposed by Ekr and Lucas, thanks for the great suggestions.

===============

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).

QUIC is a good candidate protocol for tunneling these types of traffic, as QUIC
provides secure connectivity, multiplexed streams, and connection migration.
Further, HTTP/3 supports an established request/response semantic that can be
used to set up and configure services.

Using QUIC as a tunneling technology allows for proxying of both reliable stream
(TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams
provide reliable in-order delivery across the client-proxy link. QUIC datagrams
provide for unreliable data transmission, which allows for transporting UDP and
other unreliable flows via a proxy without introducing potentially redundant or
unnecessary recovery mechanisms. In addition, QUIC can carry both types of flows
over the same connection while taking advantage of a unified congestion
controller.

This working group will work on MASQUE (Multiplexed Application Substrate over
QUIC Encryption), a framework that allows concurrently running multiple proxied
flows inside a QUIC connection. The MASQUE framework will specify a signaling
protocol that is used between the endpoint(s) and the MASQUE server to negotiate
proxy services that establish tunneled connectivity. The initial functionality
will be limited to client-initiated proxy tunnels. The WG may subsequently
recharter to consider other applications.

Proxy services that extend the signaling of the base MASQUE protocol can be
adopted by the group by creating a new milestone with AD review.
 
If MASQUE requires any extensions to existing protocols, the group will
coordinate closely with the respective group responsible for maintaining that
protocol, such as the HTTPBIS, QUIC, or TLS working groups.

===============


Thanks,
Eric



> On Feb 4, 2020, at 5:23 PM, Mirja Kuehlewind <mirja.kuehlewind=[e-mail]> wrote:
> 
> Hi Eric,
>  
> thanks for narrowing this down. The proposed text below looks like a good starting point for a working group!
>  
> Mirja
>  
>  
> From: Masque <[e-mail]> on behalf of Eric Kinnear <ekinnear=[e-mail]>
> Date: Tuesday, 4. February 2020 at 16:30
> To: "[e-mail]" <[e-mail]>
> Subject: Re: [Masque] Proposed draft charter
>  
> Hi all,  
>  
> There’s been some good discussion on this thread, which has led to some potential improvements in the draft charter. 
>  
> Here’s some proposed text which tightens things up quite a bit and tries to clarify many of the parts that caused concern. Thoughts and feedback welcome!
>  
> Thanks,
> Eric
> 
> 
> 
> ==================
> 
> 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).
> 
> QUIC is a good candidate protocol for tunneling these types of traffic, as QUIC
> provides secure connection establishment, multiplexed streams, and connection
> migration. Further, HTTP/3 provides an existing request/response syntax that can
> be used to set up and configure services.
> 
> Using QUIC as a tunneling technology allows for proxying of both reliable stream
> (TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams
> provide reliable in-order delivery across the client-proxy link. QUIC datagrams
> provide for unreliable data transmission, which allows for transporting UDP and
> other unreliable flows via a proxy without introducing potentially redundant or
> unnecessary recovery mechanisms. In addition, QUIC can carry both types of
> streams over the same connection while taking advantage of a unified congestion
> controller.
> 
> This working group will work on MASQUE (Multiplexed Application Substrate over
> QUIC Encryption), a framework that allows concurrently running multiple proxied
> flows inside a QUIC connection. The MASQUE framework will specify a signaling
> protocol that is used between the endpoint(s) and the MASQUE server to negotiate
> proxy services that establish tunneled connectivity. The initial functionality
> will be limited to client-initiated proxy tunnels. The WG may subsequently
> recharter to consider other applications.
> 
> Proxy services that extend the signaling of the base MASQUE protocol can be
> adopted by the group by creating a new milestone with AD review.
> 
> If MASQUE requires any extensions to existing protocols, the group will
> coordinate closely with the respective group responsible for maintaining that
> protocol, such as the HTTPBIS, QUIC, or TLS working groups.
> 
> ==================