Summary

  • Revision 15 of the IETF MASQUE draft lets an HTTP client establish an encrypted tunnel for complete Ethernet frames, but the authenticated HTTP principal is not automatically bound to the source MAC inside each frame.
  • A 101 or 2xx response is a tunnel-establishment receipt. Source filtering, VLAN meaning, bridge-loop prevention, frame egress and destination effect remain separate controls with separate evidence.

The remote employee passed mutual TLS. The authorization service approved access to the laboratory network. The HTTP/3 request received a successful response, the Capsule Protocol began, and the operations console turned the tunnel green. The first encapsulated frame nevertheless claimed the MAC address of a controller the employee did not own.

Nothing in that sequence requires the HTTP authentication to be false. It exposes a more useful fact: the principal authenticated at the HTTP boundary and the identity asserted inside an Ethernet header occupy different evidence layers.

draft-ietf-masque-connect-ethernet-15, posted on 30 September 2026, specifies how an HTTP client and an Ethernet proxy can exchange Layer 2 frames. The draft is active MASQUE Working Group work intended for Proposed Standard. Its Datatracker record is in IESG Evaluation with the substate AD Followup; posting revision 15 returned the IANA review to “Version Changed - Review Needed”. It is not an RFC, and the frozen record is not evidence of production adoption, conformance, performance or a security incident.

That status matters because the draft describes a proposed contract, not a universal property of deployed VPNs. The contract is still precise enough to reveal where an operator's authority begins and ends.

What the successful response actually says

HTTP/1.1 uses a GET request with Upgrade: connect-ethernet; success requires 101 Switching Protocols. HTTP/2 and HTTP/3 use Extended CONNECT with :protocol = connect-ethernet; a qualifying 2xx response starts the Capsule Protocol. In each case, success means that the proxy has established an Ethernet tunnel and is willing to proxy frames. The stream lifetime bounds the tunnel lifetime.

That is an important and limited receipt. It does not acknowledge any frame that has not yet arrived. It does not say which source addresses the client may assert. It does not prove how an 802.1Q tag will be interpreted. It does not establish that a bridge is loop-free, that an egress interface accepted a frame, that a destination received it or that an application changed state.

The draft requires Ethernet proxying to run over TLS, QUIC encryption or equivalent protection. That protects confidentiality and integrity and authenticates the transport relationship. But encryption around a frame does not make every field inside the frame an authenticated identity statement. A secure courier can prove who opened the courier account without proving that every return address printed on every envelope belongs to that account holder.

The distinction is not academic. The security considerations explicitly say that users can send arbitrary Ethernet frames, including frames with arbitrary source MAC addresses. The resulting capability can impersonate another host, poison ARP, IPv6 Neighbor Discovery or a switch's CAM table, and deny service to other hosts. Those are the powers of Layer 2 attachment, carried through a modern HTTP security boundary.

Context zero is a format, not a principal

CONNECT-ETHERNET uses HTTP Datagrams. Context ID 0 means that the payload is an Ethernet frame, from the destination-address field through the last byte before the frame check sequence. The FCS is omitted because interfaces ordinarily remove it at ingress and regenerate it at egress.

Context ID 0 therefore answers a parsing question: how should these bytes be interpreted? It does not answer an identity question: which principal is entitled to assert the source MAC? Nor does the regenerated FCS prove the provenance of the original frame. Link-level checking can establish that a particular transmission was not corrupted according to that link's check; it cannot retroactively bind the enclosed address to the HTTP user.

The same discipline applies to future nonzero contexts. Even a correctly registered context identifies agreed semantics within one request. The numeric value may be reused with different semantics in another request, and registration can arrive after a datagram because of reordering. Unknown contexts may be dropped silently or briefly buffered. A context is protocol state, not an enduring identity or authorization token.

Source authority must be made explicit

The draft offers examples of local controls without pretending that the tunnel negotiates them. A point-to-site implementation might restrict a client to one source MAC. Endpoints might use a configured allow-list. IEEE 802.1X might authenticate access at another layer. The proxy should restrict service to authenticated, authorized users and can rate-limit abuse. Dynamic negotiation of MAC filtering is left to future extensions.

This leaves a concrete operating decision: is authorization attached only to the URI, or also to a set of MAC addresses, destination classes, EtherTypes, VLANs and rate limits? If a user's device runs virtual machines or containers, who approves additional addresses? How are moves, hardware replacement and emergency access reconciled without turning the allow-list into a permanent exception ledger?

A robust decision record binds the HTTP principal, service URI, policy version, permitted Layer 2 claims and expiry time. It also records the result for each relevant frame. “Tunnel up” is too coarse because it collapses admission to the service with authority inside the service.

A transparent VLAN tag can still be politically opaque

The draft forwards 802.1Q tags transparently by default. If either endpoint interprets the tag, both sides need a signaled or manually configured agreement about consistent processing. The draft does not define that agreement. A deployment may map each VLAN to a distinct URI, and it may strip and reapply tags, but that makes the URI-to-VLAN mapping a high-value policy object.

Suppose the client asks for /ethernet/lab, receives 200, and sends a frame tagged for VLAN 37. If one end treats 37 as a tenant identifier and the other treats it as a privileged operations segment, the HTTP exchange remains valid while the control policy fails. Transport conformance cannot repair semantic disagreement outside the transport contract.

The evidence ledger should therefore retain the requested URI, authenticated principal, received tag, ingress interpretation, any rewrite, egress tag, policy owner and version. A successful tunnel is one entry in that chain, not a substitute for it.

The bridge is a separate machine

An established CONNECT-ETHERNET request emulates a point-to-point Ethernet link. Once an endpoint attaches that link to an external network, it may inherit switch and bridge responsibilities: broadcast and multicast forwarding, PAUSE-frame termination, learning behavior and loop control. The draft deliberately leaves these functions outside its mechanism.

That boundary becomes visible during a loop. Two correctly configured tunnels and two individually valid bridge attachments can form a cycle. Broadcast traffic then multiplies until tunnel capacity, buffers or the attached segment fails. The draft recommends STP or RSTP, delegation to a component that provides loop prevention, or a topology known to be loop-free. Frame-rate monitoring and broadcast or multicast limits provide additional containment.

None of these controls is evidenced by 101 or 200. A dashboard that labels the whole service “healthy” because the HTTP stream is alive can remain green while a loop consumes the useful capacity. Operators need topology state, spanning-tree role, learned-address movement, broadcast rate and drop evidence beside tunnel state.

A live tunnel can selectively lose valid frames

Delivery also depends on transport mode and size. HTTP/3 can place Ethernet frames in QUIC DATAGRAM frames. Those datagrams are not fragmented; if the available payload is too small, the endpoint must drop the frame and must not quietly switch it to a DATAGRAM capsule. Capsules over a stream can carry a larger frame across multiple packets, but the system is not universally required to preserve frame order, especially when an intermediary re-encodes capsules into QUIC datagrams.

After decapsulation, a frame that exceeds the egress interface, destination network or receiving endpoint limit must be dropped. The draft recommends a counter for oversized drops. If an endpoint cannot deliver to the underlying segment, it drops the frame. These are correct protocol outcomes, not proof that the tunnel failed.

The useful receipt is consequently frame-specific: ingress acceptance; context and mode; size against the current limit; policy decision; VLAN treatment; queue result; egress-interface result; drop reason; and, where required, a higher-layer observation. Tunnel establishment is necessary context but insufficient evidence of delivery.

The standard can stay narrow because operations must stay exact

Heng Lu's Running-Code Primacy, Minimum Initial Specification and agency analysis provide a disclosed editorial lens for this boundary. The common specification is strongest when it defines an interoperable link without pretending to own every local bridge decision. Running systems remain responsible for proving the additional claims they make. The agency question is not merely who may open the tunnel, but who may create effects inside the broadcast domain and who can revoke, observe and audit that power.

This is an interpretation, not a claim about IETF intent. It leads to a practical rule: never let a receipt inherit authority from a neighboring layer. The HTTP handshake proves its own event. A source filter proves its own decision. A VLAN mapping proves its own translation. A bridge controller proves its topology state. An egress counter proves its own observation. Only a joined ledger can support the larger claim that an authorized principal caused an intended Layer 2 effect.

Sources