Skip to main content

Multiplexed Application Substrate over QUIC Encryption (masque)

WG Name Multiplexed Application Substrate over QUIC Encryption
Acronym masque
Area Web and Internet Transport (wit)
State Active
Charter charter-ietf-masque-03 Approved
Document dependencies
Additional resources Github
Issue tracker
Wiki
Zulip stream
Personnel Chairs Dennis Jackson, Eric Kinnear
Area Director Zaheduzzaman Sarker
Mailing list Address masque@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/masque
Archive https://mailarchive.ietf.org/arch/browse/masque/
Chat Room address https://zulip.ietf.org/#narrow/stream/masque

Charter for Working Group

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

The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. The group has specified CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this functionality. 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.

The MASQUE working group will now develop HTTP extensions, which might be specific to the HTTP version, to the core client-initiated CONNECT-UDP and CONNECT-IP functionality. Services that a proxy initiates without any prompt from a client are out of scope.

Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps to make it easier to support new use cases or accommodate changes in the environment in which these protocols are deployed. The initial set of extensions will be in support of UDP listening, CONNECT-UDP proxying optimizations when the UDP traffic is QUIC, and tunneling of Ethernet packets. Additional extensions that provide missing functionality, improve performance, or otherwise ease deployability for use cases may be adopted where there are multiple implementation and/or deployment proponents. The intended status is Standards Track, but the WG may downgrade if it believes that is appropriate for the ultimate document maturity level.

Extensions to HTTP Datagrams will be coordinated with HTTPBIS. Extensions that solely relate to generic proxying functionality, and are not specific to the core MASQUE documents, are out of scope.

Specifying proxy server discovery mechanisms is out of scope. New congestion control and loss recovery algorithms are also out of scope. However, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE proxies, and may issue recommendations accordingly.

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. This might include defining alternative extensions specifically for use in these HTTP versions.

IP multicast is out of scope. Designs need 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.

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 ICCRG and CCWG on congestion control and loss recovery considerations, and intarea for IP Proxying and Ethernet tunneling. Finally, it will coordinate with IEEE 802.3 to make sure Ethernet concepts are correctly represented.

MASQUE is not intended to be a long-lived working group.

Milestones

Order Milestone Associated documents
Last Submit an extension for Ethernet over MASQUE
Submit an extension for QUIC-aware proxying
Next Submit an extension for UDP listeners