RFC 3093: HTTP Admission Was Not Packet Approval

Summary

RFC 3093's Firewall Enhancement Protocol carried a full IP datagram in an HTTP body and asked an inside host to decode and inject it into its own protocol stack.
Passing the HTTP connection proved only that an outer carrier crossed. It did not prove that firewall policy approved the inner addresses, ports, application, user, reinjection or result.

The opening was for the Web, not for everything the Web could carry

The paper began with a recognizable architectural conflict. End-to-end transparency let new applications appear at hosts without asking the network to understand them. Corporate firewalls added a control point in the path. A new application could be technically sound and still fail because its traffic did not match the rules at that point.

RFC 3093 answered with deliberately excessive literalism. If HTTP usually crossed the firewall, then arbitrary traffic could dress as HTTP. An outside application's TCP/IP datagram would enter FEP software, become an HTTP message, cross on the ordinary HTTP path, reach cooperating software inside, be decoded, and return to the protected host's IP stack “as if the Firewall never existed.” The operator was not asked to authorize a new application.

That path makes the evidence boundary unusually clear. The firewall observed and admitted an outer session. The inner packet retained its own source, destination, transport fields and application meaning. Approval of the carrier did not automatically extend to the cargo.

A collaborator inside changed the control surface

The memo insisted that it preserved the firewall's security model because an internal host had to cooperate. Its premise was that firewalls addressed external threats while ignoring internal ones. That is the document's argument, not a general assurance. An internal process able to decapsulate arbitrary traffic is precisely a new policy-bearing component.

The firewall operator controlled the permitted outer connection. The inside host operator controlled whether FEP ran and whether reconstructed datagrams entered the local stack. A user or application generated demand. The tunnel implementation decided how to encode and reconstruct fields. None of those facts proved that the organization had approved the combined behavior.

This separation also prevents a misleading incident narrative. A log showing accepted HTTP is not a log of the embedded flow. A record that the tunnel endpoint received a message is not proof that it injected a packet. Injection is not proof that a local socket accepted it, that an application processed it, or that an external effect occurred.

Readable duplicates were not the packet's authority

RFC 3093 placed the entire IP datagram in the HTTP body, using an IP-over-MIME idea. It also copied TCP fields, and optionally IP fields, into new readable HTTP headers. Port numbers became decimal strings. Urgency influenced letter case. Hop limit became prose. Apparent addresses could become domain names.

The memo itself admitted that the copies were strictly for human readability because the complete datagram was already in the body. That makes them an excellent example of database-export-looking evidence that must not be promoted into authority. A readable TCP_Dport string did not authenticate the underlying destination. Two representations could disagree. Only explicit parsing, validation and policy could decide which record controlled reconstruction.

The design also used GET requests or GET responses in either direction to resemble acceptable HTTP. This was not an application requesting a web resource in the ordinary sense. HTTP syntax was the visible envelope chosen because an intermediary might recognize it. The more a firewall inspected only familiar surface forms, the more the proposal demonstrated that protocol recognition and intent recognition were different tasks.

The joke documented a real policy failure mode

The date, whimsical fields and claim of no real security considerations locate RFC 3093 as an Informational provocation, not a safe deployment guide. The article need not invent authorial intent to use the record. The mechanism on the page is enough: a coarse allow rule can become a general transport when an endpoint is willing to tunnel.

Adjacent work kept the layers separate. RFC 2775 described diminishing Internet transparency. RFC 2979 discussed firewall behavior and configurable policy. RFC 2663 and RFC 3027 documented NAT complications; RFC 3234 later named the wider class of middleboxes. SOCKS5 negotiated through an explicit gateway and optional authentication methods. None proves that FEP ran in production.

The durable lesson is therefore narrower than “firewalls are useless” or “tunneling wins.” A rule can reliably admit an HTTP connection and still be silent about its embedded semantics. To claim policy enforcement, an operator must identify the actual decision surface: authenticated tunnel endpoint, permissible inner protocol, destination, reinjection privilege, application acceptance and observable outcome. One green outer-layer event cannot stand in for that chain.

The Firewall Allowed HTTP. It Had Not Approved the Packet Inside: RFC 3093

Why it matters

Summary

The opening was for the Web, not for everything the Web could carry

A collaborator inside changed the control surface

Readable duplicates were not the packet's authority

The joke documented a real policy failure mode

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing