Wiki · Concept · Last reviewed June 25, 2026

MASQUE

MASQUE is an IETF protocol family for proxying UDP, IP, and related traffic over HTTP using request semantics, multiplexing, encryption, and datagram support.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: privacy, HTTP, proxies, agents, surveillance

Definition

MASQUE stands for Multiplexed Application Substrate over QUIC Encryption. The IETF Datatracker lists MASQUE as an active working group in the Web and Internet Transport area. Its charter says the primary goal is to let multiple proxied stream and datagram flows run concurrently inside an HTTP connection.

The useful boundary is that MASQUE is not a consumer VPN brand, an anonymity guarantee, or an AI-specific protocol. It is a standards family for HTTP-based proxying. The working group charter identifies CONNECT-UDP and CONNECT-IP as the core mechanisms for proxying UDP and IP traffic.

MASQUE belongs next to Oblivious HTTP and IP Protection, but it should not be collapsed into either. OHTTP separates request content from client network identity for selected HTTP messages. A browser IP-protection system may use MASQUE forwarding primitives. MASQUE itself is the lower routing substrate: how a client and proxy move non-TCP traffic through HTTP.

Mechanism

RFC 9297 defines HTTP Datagrams and the Capsule Protocol. HTTP Datagrams are associated with an HTTP request and are intended for HTTP extensions rather than ordinary application message bodies. In HTTP/3, datagrams can use the QUIC DATAGRAM extension. When that is unavailable or undesirable, the Capsule Protocol provides a reliable path.

RFC 9298 defines proxying UDP in HTTP. It gives HTTP clients a way to create UDP tunnels through an HTTP server acting as a UDP proxy, filling the gap left by traditional HTTP CONNECT, which was built around TCP tunneling. The specification says the protocol supports existing HTTP versions through HTTP Datagrams, using Extended CONNECT for HTTP/2 and HTTP/3 and HTTP Upgrade for HTTP/1.x.

RFC 9484 defines proxying IP in HTTP and updates RFC 9298. It extends the pattern from UDP payloads to IP packets, allowing an HTTP client to create an IP tunnel through an HTTP server acting as an IP proxy. The RFC names use cases such as remote-access VPN, site-to-site VPN, secure point-to-point communication, and general-purpose packet tunneling.

Agent Context

MASQUE matters for AI Agent Observability because agent systems increasingly act through browsers, APIs, remote desktops, code sandboxes, and enterprise networks. Those actions can be routed through proxies for security, privacy, policy enforcement, performance, or geography.

If an agent reaches a service through a MASQUE-style path, the target may see the proxy egress point rather than the user's ordinary network address. The proxy may see enough routing metadata to enforce policy or attribute abuse. The application layer may still carry account cookies, tokens, prompts, files, device identifiers, or timing patterns. For agent governance, that means proxying is only one layer of identity control.

Governance Use

A governed MASQUE deployment should record the client class, proxy operator, target selection rule, HTTP version, method family, authentication method, logging policy, retention period, geographic policy, rate limit, abuse handling rule, and whether UDP, IP, or another extension is in use. For CONNECT-UDP, include the configured target-host and target-port template. For CONNECT-IP, include address assignment, route advertisement, and packet-scope restrictions.

The policy question is who can ask for a tunnel, to which destinations, under whose authority, with which logs, and with what recourse when the proxy path changes what a user or agent sees.

Limits

MASQUE does not prove consent, anonymity, non-tracking, or safety. A proxy can hide one network address from one target while creating a new trusted intermediary. The target can still identify a user through account state or application data. The proxy can still face abuse, attribution, logging, and lawful-access pressure.

The RFCs also name concrete security concerns. RFC 9298 warns that arbitrary UDP tunnels create abuse risk and says UDP proxying ought to be restricted to authenticated users. RFC 9484 gives a similar warning for IP proxying. Those notes are why route governance belongs in the design, not only the incident response plan.

Review Record

Source Discipline

Claims about MASQUE working-group scope should cite the IETF MASQUE charter. Claims about HTTP Datagrams and Capsule behavior should cite RFC 9297. Claims about UDP proxying and CONNECT-UDP should cite RFC 9298. Claims about IP proxying and CONNECT-IP should cite RFC 9484. Product-deployment claims require operator documentation.

Spiralist Reading

Spiralism reads MASQUE as routed opacity. The web cannot run without addresses and paths, but every path is also a record-making institution. MASQUE can reduce direct exposure to a target and make modern proxying less brittle. It can also concentrate power in the proxy route. The serious practice is to name the route, govern the route, and keep enough evidence to challenge the route when it silently changes what the user, agent, proxy, or target is allowed to know.

Sources

Return to Wiki