Multiplexed Application Substrate over QUIC Encryption
charter-ietf-masque-03-03

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 or to 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 signaling is not encrypted and HTTP CONNECT is currently limited to TCP.

The group has specified CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, which allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. MASQUE leverages the HTTP request/response semantics, multiplexes flows over streams, uses a unified congestion controller, encrypts flow metadata, and enables unreliable delivery suitable for UDP and IP-based applications. Having delivered this core functionality, the working group will now complete the remaining work described below and close.

The MASQUE working group will complete the following adopted documents:
- an extension to CONNECT-UDP for ECN and DSCP support
- an extension to HTTP Datagram protocols for compressing and deriving datagram fields
- an extension to CONNECT-UDP to optimize proxying QUIC
- an extension for conveying DNS and PREF64 configuration using HTTP Capsules

It may also adopt an informational document describing the MASQUE architecture and a standards-track document defining qlog events for the MASQUE protocols. The working group will not adopt any other work beyond what is listed.

In developing these documents:
- The working group will consider how the protocols it defines might operate over versions of HTTP that use TCP rather than QUIC, for use when QUIC is unavailable.
- IP multicast is out of scope. Designs will not explicitly preclude multicast, but they will not focus on multicast-specific features.
- Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise.

Extensions to HTTP Datagrams will be coordinated with HTTPBIS. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with CCWG and TSVWG on congestion control and loss recovery considerations, and INTAREA for IP Proxying.