Summary

  • On 24 August 2026, the IESG approved revision 16 of draft-ietf-masque-connect-udp-listen as a Proposed Standard. At the evidence freeze it remained an Internet-Draft in the RFC Editor queue; the announcement reports interoperable Google Quiche and quic-go implementations.
  • Bound CONNECT-UDP gives one HTTP request a stable public UDP socket for multiple remote tuples. That public address is a reachability allocation, not universal sender authority: negotiated support, Context ID state, target policy and actual data-plane delivery remain separate decisions.

A listening socket is not an open mandate

Imagine a browser asking an HTTP proxy for a UDP address that a WebRTC peer can reach. The proxy accepts, binds a public IP address and port, and returns the tuple. Seconds later, packets arrive from two hosts: the peer selected by connectivity checks and an unrelated scanner that happened to find the same port.

The socket is open to both packets. The tunnel is not obliged to deliver both.

This is an illustrative boundary test, not a disclosed incident. It exposes the distinction at the centre of the IESG-approved “Proxying Bound UDP in HTTP” draft. A public tuple says where traffic can arrive. Authority still depends on the request, the remote tuple, the registered Context ID, the proxy's target rules and the client's choice about unknown senders.

Confusing allocation with authorization would turn a useful peer-to-peer extension into an implicit open relay. The protocol instead creates a sequence of narrow, observable transitions.

What the IESG approved

The IESG announcement records approval on 24 August at 17:58 UTC of revision 16 as a Proposed Standard. The MASQUE Working Group produced the document. Its technical problem begins with RFC 9298: ordinary CONNECT-UDP sends traffic to one host and port named by one HTTP request. That is well suited to client-server protocols such as HTTP/3.

WebRTC needs something different. ICE can test and use several candidate peers. Opening several ordinary CONNECT-UDP requests does not solve the problem because HTTP semantics do not guarantee that distinct requests reach the same proxy server or emerge from the same public address. The new extension lets one request retain a bound socket while datagrams identify changing remote tuples.

The announcement reports two implementations, Google Quiche and quic-go, as interoperable. That is valuable running-code evidence, but its scope is limited. It does not establish browser enablement, production scale, universal policy agreement or operational maturity.

At the 28 August evidence freeze, Datatracker still showed an Active Internet-Draft. The IESG state was RFC Ed Queue; IANA work was in progress with expert reviews complete; the RFC Editor was awaiting reference checking and formatting. Approval is real standards news. It is not yet a numbered RFC or a deployment result.

Binding requires agreement in both directions

The client asks for bound operation with the Boolean Connect-UDP-Bind: ?1. The proxy returns the same true field only if it supports the extension. An endpoint enables the mechanism after it has both sent and received that value. A field encoded as another type is treated as absent.

That bilateral rule matters. A client cannot infer capability from a successful HTTP status alone, and a proxy cannot silently reinterpret an ordinary fixed-target request as a multi-peer socket.

The request has two modes. It may name a valid host and port, preserving that fixed target as fallback if binding is unavailable. Or it may place * in both target variables to request bind-only operation. A star in only one variable is malformed and requires a client-error response. The exact request state therefore remains part of later evidence: bind requested, bind accepted, fallback present or bind-only.

The public address is an allocation record

After acceptance, the proxy chooses at least one public IP address and open UDP port. It advertises the resulting tuples in Proxy-Public-Address and forwards packets received on them for the life of the tunnel.

With one tuple, the proxy must keep the address and port stable until the tunnel closes. With several, stability per address family is recommended. Because the address is carried in an HTTP response header, the proxy cannot use that field to announce a later change.

Those rules give ICE and a remote peer a usable rendezvous point. They do not identify an approved remote principal. A scanner and an intended peer can both reach the socket. What happens next depends on Context ID state.

This distinction also limits what logs may claim. public_address_assigned proves allocation. packet_received proves reachability. Neither proves that the remote tuple was registered, allowed, delivered to the client or accepted by the application.

Context IDs turn tuples into explicit state

HTTP Datagrams carry Context IDs. Clients allocate even values and proxies odd values. In bind-only mode, Context ID zero is forbidden; when a real fixed fallback target exists, zero retains the RFC 9298 meaning for that target.

The new Capsules create a lifecycle:

  1. COMPRESSION_ASSIGN (0x11) proposes the semantics of one Context ID.
  2. COMPRESSION_ACK (0x12) confirms that the receiver saved the mapping.
  3. COMPRESSION_CLOSE (0x13) rejects a proposal or closes an established mapping.

An IP-version value of zero assigns uncompressed semantics. Each datagram then carries its own IP address and UDP port. In the client-to-proxy direction those fields name a target; in the reverse direction they name the packet's source. An IP version of four or six assigns a compressed context: the address and port are registered once, and later datagrams carry only the UDP payload under that ID.

The constraints prevent ambiguous authority. An ID cannot be assigned twice. Only one ID may represent a given remote tuple. A closed ID cannot be reused. If reordered data arrives under a closed ID, it is silently discarded rather than reviving old state.

An endpoint may optimistically send data before receiving an acknowledgment. The protocol permits the latency trade-off, but the sender accepts that those datagrams can be dropped if the assignment has not arrived or is rejected. “Sent under ID 12” is therefore not evidence that the peer accepted ID 12.

The client can close the unknown-sender door

Only the client can request the uncompressed context, and only one may be open. That context is powerful because each incoming datagram can carry a previously unseen source tuple. If the client never opens it, or later closes it, the proxy effectively filters unknown senders.

Existing compressed mappings remain usable after closure. The proxy, however, may not open new compressed contexts once the uncompressed context is closed. Otherwise it could reintroduce a source the client deliberately excluded.

This is the article's central authority boundary. The public socket stays allocated. Approved peer mappings can stay alive. Unknown senders lose a route into the tunnel. Reachability, mapping and permission are three different states.

The proxy still owns target policy

Bound operation does not erase the restrictions that protect a UDP proxy from becoming an access bypass. For every uncompressed client datagram, the proxy must check the named target against its disallowed-target policy. For compressed operation, it checks the address and port in each assignment and rejects prohibited mappings.

The policy can protect loopback, link-local, private, administrative or service-specific destinations according to the operator's environment. The draft does not dictate a complete commercial or security policy. It defines where that policy must be enforced so a changing tuple cannot evade the decision that a fixed-target request previously made at tunnel creation.

TURN offers a useful comparison without being identical. A TURN relay allocation gives a public relay address; permissions and channel bindings separately constrain peers and compact data handling. In both designs, obtaining an address is not the final grant of traffic authority.

Capacity is part of the security contract

Each accepted Context ID consumes memory. Each acknowledgment or closure waiting behind flow or congestion control consumes buffer space. The draft therefore requires limits on open IDs and pending compression responses. If the proxy's response buffer reaches its limit, it must abort the request stream.

The limits need observable ownership. A service should record the configured budgets, current occupancy, rejected assignments, response-queue pressure, stream aborts and the client population that triggers them. Otherwise a memory-exhaustion defence appears only as unexplained call failure.

Representation also changes path behaviour. An uncompressed datagram carries an address and port on every message; a compressed one does not. Moving between them changes the effective MTU and can disrupt Datagram Packetization Layer PMTU Discovery. Requesting compression early reduces that transition risk. A feature flag that says “compression enabled” cannot substitute for packet-size and loss evidence.

One public IP can hide many authority states

RFC 6269 describes the wider consequences of address sharing: attribution becomes coarser, reputation can spill between users, and abuse controls can punish the wrong participant. Bound UDP adds another multiplexing layer. The same visible proxy IP can represent many tunnels, clients, Context IDs and remote tuples.

An abuse record therefore needs more than the public IP and timestamp. At minimum it needs the bound port, tunnel identity, authenticated client, context state, remote tuple, policy result and actual forwarding outcome, under lawful retention rules. Without that chain, the operator can neither prove an allowed path nor distinguish unsolicited packets that were dropped at the edge.

The public address is useful precisely because it is shared infrastructure. Treating it as the identity or authority of every flow would destroy the evidence needed to operate it responsibly.

The evidence chain for one datagram

A defensible record should preserve:

  1. the authenticated request and tunnel identity;
  2. the exact bind negotiation in each direction;
  3. fixed-fallback or bind-only mode;
  4. each advertised public address and its lifetime;
  5. Context ID allocator and unique value;
  6. assignment, acknowledgment and closure state;
  7. compressed or uncompressed semantics;
  8. the exact remote source or target tuple;
  9. target-policy version and verdict;
  10. Context and response-buffer budget state;
  11. datagram acceptance, drop or temporary buffering;
  12. transmission or reception on the bound socket;
  13. delivery to the client and the ICE or application result.

The final step matters. ICE defines candidate-pair checks; WebRTC defines a transport architecture. A registered mapping may still lead to packet loss, a failed connectivity check or an application rejection. Protocol state authorizes handling. Only observed running behaviour establishes the usable path.

That is the Running-Code Primacy test. The approved document supplies a thin common rule set. Operators implement target policy, limits, telemetry and adoption locally. The specification can define a Context ID. It cannot make an unobserved packet successful, nor can a public address confer authority by declaration.

Sources