Summary

  • RFC 2979 separated an intentional security refusal from an unintended failure of compliant protocol use, placing responsibility for the latter on firewalls and their associated software.
  • Its concrete examples—Path MTU Discovery errors and partially understood SMTP extensions—showed how a middlebox could break a conversation while appearing to enforce a simple rule.

The policy decision and the protocol failure were not the same thing

The Internet's end-to-end ideal met a practical boundary around 2000: organisations increasingly connected valuable internal systems to a network they did not fully trust. Firewalls offered a screening point. But screening systems were often underspecified, and their behavior varied enough to cause problems beyond the policy they were meant to enforce.

RFC 2775 had already described “transparency” as several architectural properties, including end-to-end function, performance and address transparency. RFC 2979 narrowed the question to a particular operational contract. Its central rule said introducing a firewall, tunnel or access-negotiation facility must not cause an unintended failure of legitimate, standards-compliant use that would work in its absence. If it did, the firewall and associated software should be fixed; changing an existing protocol or its implementation should not be necessary.

That was not a demand to pass every packet. RFC 2979 explicitly preserved a site's right to block access it considered illegitimate, even when the attempted traffic followed a standard. It also allowed extra authentication or authorization facilities such as SOCKS, including configurations that required them. The important distinction was between a deliberate refusal under policy and an accidental breakage caused by an intermediary that misunderstood the traffic.

A dropped error could strand an otherwise valid flow

The Path MTU Discovery example made the rule concrete. IPv4 senders could transmit packets with the Don't Fragment bit set. When a packet was too large for a later link, a router returned an ICMP “Destination Unreachable / Fragmentation Needed” message so the sender could reduce its packet size. A firewall that allowed the outgoing packet but discarded the matching response could leave the sender repeating traffic that would never fit—a black hole, not a meaningful security decision.

RFC 2979 did not say every ICMP message had to pass. It treated an error tied to legitimate outbound traffic differently from Echo requests, redirects or unrelated errors, which a site could block. Context and purpose mattered: the same protocol family contained both control information necessary for a valid exchange and traffic a policy might reasonably reject.

An extension list could become a three-party mismatch

The SMTP example exposed a subtler failure. A client asks a server for extensions with EHLO; the server advertises what it supports; the client may then select an extension. A proxy that merely added EHLO to its accepted-command list, without filtering the server's response, could let the endpoints agree on a capability the proxy did not understand. Each endpoint had behaved plausibly, yet the middlebox had put them into a conversation it could not carry correctly.

The lesson was not that every firewall must implement every new extension. RFC 2979 recommended that application protocols facilitate firewall operation when doing so did not damage the application, and that specifications could explain what a firewall needed to handle. It cautioned against hiding a new protocol inside HTTP simply because port 80 was likely to be open; a secure subset, a suitable traversal facility or a separately registered port could be more honest design choices.

What the RFC changed—and what it cannot prove

RFC 2979 was published as an Informational memo, not an Internet Standard. The draft history records IESG approval in August 2000; publication followed in October. The record establishes a documented design principle and examples, not product adoption, compliance rates, a reduction in circumvention, or better security outcomes.

Its historical contribution was a boundary of accountability: security policy could refuse a flow, but accidental incompatibility should not silently become an application developer's obligation to tunnel around. A modern operator can use that boundary to classify a failure before changing anything: was the flow intentionally denied by policy, or did a filter, proxy or parser break compliant behavior? That diagnostic is an inference from the RFC, not a measurement of what operators actually did.

RFC 3093's later “Firewall Enhancement Protocol” proposed carrying IP/TCP inside HTTP and was dated April 1, 2001. It is a neighboring response to firewall barriers, not evidence that RFC 2979 failed or that the tunnel was deployed. Nor should firewall behavior be conflated with NAT: RFC 2979 explicitly treated them as separate functions, even when one appliance performed both.

Sources: RFC 2979; RFC 2775; RFC 3093; draft history; RFC 1191; RFC 1869.