Summary

  • RFC 831 proposed a discussion design for reaching SATNET equipment during a partition. Its multihomed “Munger” would perform gateway-like source-route processing and rewrite both packet directions, but would remain a host and advertise no route.
  • The preferred hybrid learned a reverse address correspondence—called “soft state” in the memo—when an old endpoint could not return a source route. The document specified neither a timer nor authentication, cleanup, audit or crash recovery, and the ambiguous key admitted only one US host per SATNET target at a time.
  • The episode separates four claims that emergency access often collapses: a packet can enter, an operator can be identified, an action can be authorized, and the intended maintenance can finish. RFC 831 addressed the first claim; the rest still required local control and evidence.

A gateway algorithm without a gateway's mandate

In December 1982, Robert Braden circulated RFC 831 to focus discussion on a narrow contingency. If SATNET divided into two disconnected parts, how could engineers in the United States reach equipment on its European side for software maintenance? The memo called the alternate entrance a “back door”, but it explicitly said that the proposal was not intended as a standard at that time. It described an architecture to debate, not a deployment record.

The decisive rule appeared before the packet mechanics. The endpoint of the alternate tunnel at University College London had to be a host, not a gateway. If the VAN gateway learned a general route to UCLNET through that endpoint, it could divert ordinary UCL or RSRE traffic into the VANNET tunnel. A maintenance exception would then have become an accidental transit path.

RFC 831 therefore gave one machine the source-routing algorithm of a gateway while withholding the social and routing authority normally associated with that role. It could inspect a selected packet, advance its source route and alter headers. It would not announce reachability, participate in topology exchange or invite the rest of the network to use it.

That negative permission was not an implementation footnote. It defined the safety boundary: execute this forwarding operation for this exceptional exchange, but do not make the exception discoverable as a route.

The ordinary path failed in both directions

The normal diagnostic path began at a US control host, H. It crossed the Internet to BBN gateway B, entered SATNET through satellite interface message processor S1, traversed the satellite network to S2, and then reached the UCL gateway G. During a partition, the addresses of S2, G and a UCL terminal access controller were not reachable from US gateways. A packet addressed in the ordinary way would be discarded and could produce ICMP Unreachable.

The reverse direction was equally important. H was not reachable from the UK side during the same partition. Even if an engineer managed to place a request near S2, an ordinary reply addressed back to H would fail. “There is an alternate way in” was only half a design; a usable maintenance path needed a return graph.

The proposed graph ran H → Internet → VAN gateway → VANNET IP tunnel → a UCL endpoint → UCLNET → G → S2. RFC 831 allowed special code in H and/or the UCL endpoint, but not in G, S2 or the VAN gateway. Recovery logic was concentrated in the two systems willing to carry it instead of imposing a new requirement on every device along the way.

The ordinary UCL tunnel host, U, could not simply be promoted into a router. The document instead introduced a multihomed variant called the Header Munger, M. M appeared as M2 on VANNET and M1 on UCLNET. Those two identities were not decorative aliases. They formed the joints at which an otherwise unroutable conversation could be turned around.

One request required two transformations

H could reach M's VANNET side, so it sent the maintenance request toward M2. M then changed the packet's source to M1 and its destination to S2 before forwarding it on UCLNET. To the UK-side network, the exchange now had locally reachable endpoints.

The reply returned from S2 toward M1. M rewrote it again, producing a packet able to travel through VANNET and the Internet toward H. The two edits solved different reachability failures. Changing only the outbound destination would not create a valid reply path. Changing only the source would not make the original SATNET destination reachable from US routing.

Header rewriting also changed what addresses downstream systems could observe. A successful response proved that a particular chain—H, M2, the rewriting function, M1, G and S2—had carried enough traffic for the exchange. It did not prove that S2 knew H's ordinary address, that M authenticated the human operator, or that the requested maintenance action completed.

This is why the design should not be flattened into the modern word “NAT”. RFC 3022, published much later, formalized static and dynamic address translation and described the cost of losing end-to-end address significance in exchange for state inside the network. That is a useful comparison. It does not make RFC 831 NAT, its inventor or its documented ancestor.

Three return strategies exposed the state problem

RFC 831 considered three ways to make the path work.

The first was a fixed correspondence. M could answer for a set of M1/M2 addresses, each associated with a US host and a SATNET target. It was mechanically simple and administratively rigid. Every useful pair consumed planned address state.

The second used IPv4 source routing in both directions. RFC 791 defined Loose and Strict Source and Record Route options. The sender supplied intermediate addresses; as the packet reached one listed address, the next replaced the IP destination and the current interface address entered the route record. A receiver able to reverse the recorded path could construct the reply.

G supported source routing, but S2 and the terminal access controller might not know how to reverse a recorded route. The preferred alternative was therefore a hybrid. H placed the exceptional waypoint in its outbound source route. As M advanced that request, it learned a correspondence between the US source and the SATNET destination. A reply with no return source route could then be recognized at M1 and rewritten toward H.

RFC 831 called this mapping “soft state”. The phrase must be kept at the document's scale. The memo described how the correspondence was learned and used; it did not give a refresh interval, expiry timer, deletion rule, restart procedure or audit trail. It did not say how a stale record would be distinguished from a still-authorized maintenance session.

The key was also ambiguous. Only one US host at a time could access a given SATNET host through this scheme. If two sources shared the target, a source-route-free reply did not carry enough information for M to choose the correct H. That limit is not an early capacity target. It is direct evidence that the reverse path depended on hidden, lossy context.

Physical lines and telephone economics shaped the graph

The packet diagram rested on a switched X.25 service. The party placing a call paid its charges. UCL normally opened the tunnel from U, while the US end opened the tunnel toward M2. Direction therefore affected who incurred the bill and which endpoint had to initiate connectivity.

There was also one physical PSS line at UCL. To host both the ordinary U endpoint and M on that line, the design required separate X.25 subaddresses. The VAN gateway had to accept 14-digit as well as 12-digit X.121 addresses. A graceful IP-layer proposal could fail on an addressing field two layers below it.

These details should not be enlarged into a universal theory of network economics. They show something more practical. Recovery architecture inherits the call direction, addressing width, billing boundary and interface inventory of the service it crosses. If those facts are absent from the runbook, a correct packet algorithm can remain unusable.

Later host rules made the exceptional role explicit

RFC 1122 later allowed a host to act as an intermediate hop for a source-routed packet, but under gateway-like disciplines. It had to handle time to live, ICMP errors and option processing appropriately. Forwarding a non-local source route required a configurable switch that defaulted to disabled and was subject to policy filters.

That rule clarified the category RFC 831 had exploited: a host could perform an intermediate routing operation without becoming a general router. The operation still carried router-grade consequences. TTL, errors, route records and policy could not be ignored merely because the executable lived in a host process.

The operational default did not change all at once. RFC 1812 still required routers in 1995 to support source-route options on forwarded packets and described a discard switch that was not enabled by default. The point is historical, not a recommendation to reproduce that posture now.

By 2011, RFC 6274 judged the security risks of source routing greater than its diagnostic utility. It listed firewall bypass, access to otherwise unreachable systems, stealthy connections, topology discovery and resource exhaustion, and recommended default drop. RFC 7126 then observed that widespread filtering had made LSRR virtually unusable for troubleshooting. Its advice was option-specific and documented control, with drop as the default and local processing only for an explicitly justified exception.

This later history does not erase RFC 831's logic. It reveals the dependency hidden in the proposal: an emergency path based on a voluntary IP option works only while each independent operator on the path accepts that option. A published mechanism is not a promise of transit.

A later taxonomy names the intermediary, not its authority

RFC 3234 later used “middlebox” for an intermediary that did more than ordinary IP routing, including transforming or diverting a flow. In that analytic vocabulary, M looks middlebox-like. It changed addresses, depended on per-flow correspondence and added a place where configuration or state could fail.

But vocabulary can conceal as much as it reveals. Calling M a middlebox says what it did to packets. It does not answer who could invoke it, which destinations were eligible, how long its learned map survived or who could close the exception. Calling it a gateway would be worse: that label could imply general forwarding authority that the memo expressly denied.

The cleanest description remains the one encoded by the proposal itself. M was a multihomed host performing gateway-like work for selected maintenance traffic and sending no routing updates. Its power was executable but intentionally non-advertised.

Maintenance reachability was not maintenance authority

RFC 831 solved an engineering question about address and path continuity. It did not define identity proof, destination authorization, encryption, application commands, change approval or a maintenance-success receipt. The word “back door” in this memo names an alternate path; it is not evidence of an exploit. Still, alternate reachability creates a control surface because it lets traffic cross a boundary that the ordinary topology no longer crosses.

A defensible operator therefore has to preserve four separate verdicts:

  1. the request reached the exceptional ingress;
  2. the principal was identified;
  3. the requested target and operation were authorized;
  4. the target reported the intended result.

A rewritten reply can support the first verdict. It cannot silently substitute for the other three.

RFC 831's enduring achievement is the restraint inside its topology. The designers did not ask the network to believe a new general route merely because maintenance was urgent. They localized special code, bounded the visible path and refused to let the recovery endpoint advertise itself as transit.

The back door was not a route. That was the reason it could remain a door.