Blocked VPN connections are a daily frustration for travelers, remote workers, and anyone operating behind a restrictive firewall. A new set of requirements emerging from the Internet Engineering Task Force's MASQUE working group aims to fix a structural weakness in how virtual private networks move data: the protocols they rely on are often conspicuous, and conspicuous traffic gets throttled or blocked.
Established tunneling standards such as IKEv2/IPsec have long provided authenticated, encrypted channels between networks, but they carry a distinctive signature that firewalls and deep-packet-inspection systems can single out and restrict. That visibility problem has pushed engineers toward a different idea: build IP proxying directly on top of HTTP, the protocol underlying almost all ordinary Web traffic, so that a VPN session looks like routine browsing to anyone watching the wire. This matters for everyday users too, particularly those juggling several devices and connections, where tools marketed as a multi-device vpn depend on exactly this kind of resilient, hard-to-block transport working reliably across phones, laptops, and routers alike.
Why Disguising a VPN as Web Traffic Matters
The technical logic is straightforward. Large server operators have said they would rather extend protocols they already trust, namely QUIC and TLS, than add an entirely separate security stack to their infrastructure. QUIC, the transport layer behind HTTP/3, already provides encryption and multiplexing; building IP proxying on top of it means fewer moving parts to secure and audit. The new specification does not define a finished protocol, but a list of requirements: what any such protocol must be able to do, regardless of exactly how it is built.
Among the core requirements is the concept of an "IP Session," a negotiated agreement between client and server to forward IP traffic under specific conditions, comparable to a Child Security Association in IKEv2. Sessions are carried over "Data Transports," which may use either reliable streams or unreliable datagrams depending on what the application needs. Critically, the draft requires that packets be forwarded unmodified unless an extension explicitly allows alteration, preserving the integrity guarantees users expect from any serious privacy tool.
Covering Consumer VPNs, Site-to-Site Links, and Beyond
The requirements document is explicit about the range of use cases a compliant protocol must support. Consumer VPNs, which mask a user's location and browsing destinations from their internet provider, sit alongside point-to-point links such as those used in container networking, point-to-network setups for enterprise remote access, and full network-to-network site-to-site connections. A single underlying mechanism, the authors argue, should be flexible enough to serve all four without forcing separate standards for each.
Several requirements focus squarely on usability and resistance to blocking. The protocol must run over HTTP/3 where possible, falling back to HTTP/2 when UDP traffic is restricted on the network path, and it must allow multiple independent IP sessions over one HTTP connection. Perhaps most notably, the specification insists that a passive observer watching only the unencrypted portions of a connection should be unable to tell IP proxying apart from ordinary Web traffic - directly addressing the detectability problem that has long dogged conventional VPN protocols.
What Remains Open
The document deliberately leaves some questions unresolved. How IP addresses are allocated, managed, or translated, and who effectively "owns" a given address range, falls outside its scope, left instead to implementers and future extensions. Authentication of user identity, congestion control tuning, and packet compression are similarly flagged as extension points rather than core features. That modularity reflects a broader pattern in internet standards work: define a stable, minimal core, then let real-world deployment experience shape the optional layers on top, through continued discussion on the MASQUE mailing list and its public GitHub repository.