Zusammenfassung

  • RFC 831 erschien im Dezember 1982 ausdrücklich als Diskussionsvorschlag, nicht als Standard oder Einsatzbericht. Es ging um Softwarewartung auf der europäischen Seite eines partitionierten SATNET.
  • Der „Header Munger“ M sollte Source-Routing verarbeiten und Adressen in beiden Richtungen ändern, dabei aber Host bleiben und keine Routing-Updates versenden. Gateway-Algorithmus und allgemeine Transitbefugnis wurden getrennt.
  • Konnte das alte Ziel keine Rückroute erzeugen, lernte M eine im Memo „soft state“ genannte Zuordnung. Frist, Löschung, Authentifizierung, Audit und Neustartverhalten blieben offen; wegen des mehrdeutigen Schlüssels war pro SATNET-Ziel nur ein US-Host gleichzeitig möglich.

Der Vorschlag war eine Frage, keine Einsatzmeldung

Robert Braden veröffentlichte RFC 831, um eine konkrete Architektur zur Diskussion zu stellen. Wenn SATNET in zwei nicht mehr verbundene Teile zerfiel, sollten Techniker in den Vereinigten Staaten weiterhin Software auf der europäischen Seite warten können. Das Memo nannte den alternativen Zugang „back door“, erklärte aber zugleich, er sei damals nicht als Standard vorgesehen. Es dokumentiert weder eine Einführung noch eine tatsächlich so bewältigte Störung.

Der normale Diagnoseweg begann beim US-Steuerrechner H. Er lief über das Internet zum BBN-Gateway B, über den SIMP S1 in SATNET, zum SIMP S2 und schließlich zum UCL-Gateway G. In der Partition kannten amerikanische Gateways keinen normalen Weg mehr zu S2, G oder dem UCL-Terminalzugangsrechner. Ein gewöhnlich adressiertes Paket wurde verworfen und konnte ICMP Unreachable auslösen.

Auch der Rückweg war unterbrochen. Von der britischen Seite aus war H nicht erreichbar. Ein Notzugang, der nur eine Anfrage vor S2 ablegte, hätte also keine brauchbare Antwort zurückgebracht.

Der vorgeschlagene Umweg führte von H über ein VAN-Gateway und einen VANNET-IP-Tunnel zu einem System am UCL, weiter über UCLNET zu G und S2. Sondercode sollte nur in H und/oder am UCL-Ende nötig sein, nicht in G, S2 oder dem VAN-Gateway. Die Ausnahme blieb bei den Systemen, die sie ausdrücklich tragen konnten.

Das gewöhnliche Tunnelende durfte kein Gateway werden

Ein naheliegender Plan wäre gewesen, das reguläre Tunnelende U als Gateway einzurichten. Genau das wollte RFC 831 vermeiden. Hätte das VAN-Gateway eine allgemeine UCLNET-Route über U gelernt, hätte es auch normalen UCL- oder RSRE-Verkehr in den VANNET-Tunnel statt über SATNET schicken können. Ein Wartungsbehelf hätte fremden Produktionsverkehr eingefangen.

An U trat deshalb M, der Header Munger, mit zwei Netzidentitäten: M2 auf VANNET und M1 auf UCLNET. M benötigte den Source-Routing-Algorithmus eines Gateways, sollte sich ansonsten aber wie zwei Hosts verhalten und keine Routing-Updates aussenden.

Das ist mehr als Wortwahl. Ein Algorithmus entscheidet, was mit einem ausgewählten Paket geschieht. Eine Routenankündigung beansprucht, für eine ganze Zielmenge der richtige nächste Hop zu sein. RFC 831 delegierte die Paketoperation, nicht den Anspruch auf allgemeinen Transit.

Die negative Befugnis — etwas ausdrücklich nicht bekanntzumachen — schützte den Rest des Netzes. Eine Notlage erweiterte die technische Funktion, aber nicht automatisch das Mandat.

Der Munger reparierte zwei verschiedene Unzuständigkeiten

H konnte M2 erreichen und schickte die Wartungsanfrage dorthin. M ersetzte die Quelladresse durch M1 und die Zieladresse durch S2, bevor es das Paket in UCLNET weitergab. Auf der europäischen Seite erschienen damit wieder lokal erreichbare Enden.

S2 antwortete an M1. M formte die Antwort erneut um, sodass sie über VANNET und Internet zu H gelangen konnte. Beide Änderungen waren notwendig. Nur das Ziel der Anfrage zu ändern schuf keinen Rückweg zu H; nur die Quelle zu ändern brachte die Anfrage nicht zum isolierten S2.

Die Umschreibung veränderte zugleich die Beweislage. Ein Protokoll bei S2 konnte M1 statt H nennen, während ein System vor dem Tunnel nur M2 sah. Eine Antwort belegte die Funktionsfähigkeit dieser bestimmten Kette. Sie authentifizierte nicht den Menschen, genehmigte keine Wartungsaktion und bewies nicht deren Anwendungserfolg.

Spätere Adressübersetzung liefert einen Vergleich, keine Abstammungslinie. RFC 3022 beschrieb statische und dynamische Übersetzungen und den Tausch von Ende-zu-Ende-Adressbedeutung gegen Zustand im Netz. Daraus folgt weder, dass RFC 831 NAT war, noch dass es NAT erfand oder nachweislich hervorbrachte.

Drei Rückwege machten die Informationslücke sichtbar

Die erste Möglichkeit war eine feste Korrespondenz. M konnte eine Reihe von M1/M2-Adressen vertreten, die vorher US-Hosts und SATNET-Zielen zugeordnet wurden. Das war berechenbar, benötigte aber für jedes Paar Planung und Adressraum.

Die zweite Möglichkeit verwendete IP Source Routing für Hin- und Rückweg. RFC 791 definierte Loose und Strict Source and Record Route. Der Sender trug Zwischenpunkte ein; beim Erreichen eines Punktes wurde der nächste zur IP-Zieladresse, während die aktuelle Schnittstellenadresse in die Aufzeichnung wanderte. Ein Empfänger, der die Aufzeichnung umkehren konnte, erhielt eine Rückroute.

G unterstützte Source Routing. Bei S2 oder dem Terminalzugangsrechner war jedoch nicht sicher, dass sie eine aufgezeichnete Route umdrehen konnten. Daher bevorzugte RFC 831 eine Mischform. H lieferte den besonderen Hinweg. Während M die Anfrage verarbeitete, lernte es eine Zuordnung zwischen US-Quelle und SATNET-Ziel. Eine gewöhnliche Antwort an M1 konnte anschließend mit dieser Zuordnung H erreichen.

Das Memo nannte die Zuordnung „soft state“. Mehr sagt die Bezeichnung dort nicht. Es gibt kein Aktualisierungsintervall, keinen Ablauf-Timer, keine Löschregel, kein Verhalten nach einem Absturz und keine Auditspur. Auch die Berechtigung zur Anlage des Zustands blieb unbeschrieben.

Der Schlüssel unterschied nicht alle Fälle. Je SATNET-Ziel konnte nur ein US-Host zur selben Zeit zugreifen. Bei zwei Quellen enthielt eine Antwort ohne Source Route zu wenig Information, um das richtige H zu wählen. Diese Grenze ist keine frühe Leistungsvorgabe, sondern ein sichtbares Symptom verlorenen Kontextes.

Unter dem IP-Diagramm lag eine kostenpflichtige Verbindung

VANNET nutzte einen vermittelten X.25-Dienst, dessen Anrufer die Gebühren trug. Normalerweise öffnete UCL den Tunnel von U aus; die Verbindung zu M2 sollte die US-Seite eröffnen. Die Richtung des Rufaufbaus entschied damit über Verantwortung und Rechnung.

Am UCL gab es nur eine physische PSS-Leitung. Sollten U und M sie teilen, brauchten sie verschiedene X.25-Unteradressen. Das VAN-Gateway musste zudem vierzehnstellige statt nur zwölfstellige X.121-Adressen verarbeiten. Zwei Ziffern in einer tieferen Schicht konnten die ganze IP-Idee blockieren.

Das ist keine allgemeine Wirtschaftstheorie. Es zeigt, welche Fakten ein Notfallplan neben dem IP-Pfad braucht: Leitung, Anrufer, Unteradresse, Gerätefähigkeit und Kostenstelle. Eine logische Topologie baut selbst keine Verbindung auf.

Eine Host-Implementierung trug Routerpflichten

RFC 1122 erlaubte später einem Host, Zwischenstation einer Source Route zu sein, verlangte dann aber gatewayähnliche Regeln für TTL, ICMP-Fehler und Optionsverarbeitung. Weiterleitung zu einem nicht lokalen Ziel brauchte einen konfigurierbaren, standardmäßig ausgeschalteten Schalter und Policy-Filter.

Diese Formulierung trifft M genau. Die Software blieb auf einem Host; die Zwischenoperation hatte trotzdem Routingfolgen. Die Gerätebezeichnung entband nicht von den Pflichten des ausgeführten Schrittes.

Der operative Standard änderte sich schrittweise. RFC 1812 verlangte 1995 von Routern noch Unterstützung für Source-Route-Optionen beim Weiterleiten und beschrieb einen Verwerfungsschalter, der nicht standardmäßig aktiv war. Das ist historischer Kontext, keine heutige Empfehlung.

RFC 6274 bewertete später Firewall-Umgehung, Zugriff auf sonst unerreichbare Systeme, verdeckte Verbindungen, Topologieerfassung und Ressourcenerschöpfung als Risiken, die den Diagnosewert überwogen, und empfahl standardmäßiges Verwerfen. RFC 7126 stellte fest, dass verbreitetes Filtern LSRR für Fehlersuche nahezu unbrauchbar gemacht hatte, und verlangte dokumentierte, optionsspezifische Kontrolle mit Drop als Voreinstellung.

Eine veröffentlichte Option war also nie eine Zusage jedes Betreibers, sie zu transportieren. Der RFC-831-Weg hing von freiwilligen lokalen Entscheidungen entlang der ganzen Strecke ab.

„Middlebox“ beschreibt den Eingriff, nicht die Erlaubnis

Der spätere RFC 3234 bezeichnete als Middlebox einen Vermittler, der mehr als gewöhnliches IP-Routing tut, etwa einen Datenstrom verändert oder umleitet. Analytisch passt M: Headeränderung, Zuordnungszustand und zusätzliche Fehler- sowie Konfigurationsflächen. RFC 831 selbst verwendete den Begriff nicht.

Die Kategorie beantwortet auch keine Autoritätsfrage. Wer durfte M aufrufen? Welche Ziele waren zulässig? Wann endete der Zustand? Wer bestätigte die Entfernung? Die bloße Bezeichnung als Gateway wäre noch irreführender, weil sie den ausdrücklich verweigerten allgemeinen Transit nahelegt.

Die präzise Beschreibung bleibt deshalb sperrig: ein multihomed Host mit gatewayähnlicher Verarbeitung für ausgewählten Wartungsverkehr, ohne Routenankündigung. Die Sperrigkeit bewahrt den entscheidenden Unterschied.

Erreichbarkeit war keine Wartungsberechtigung

RFC 831 definierte weder Identitätsnachweis noch Zielautorisierung, Verschlüsselung, Wartungsbefehl, Änderungsfreigabe oder Erfolgsquittung. „Back door“ meinte einen alternativen Zugang, nicht den Beleg eines Angriffs. Dennoch öffnet jeder alternative Pfad eine Kontrollfläche über eine Grenze, die der normale Weg gerade nicht überquert.

Vier Aussagen müssen getrennt bleiben: Die Anfrage erreichte den Eingang; der Akteur wurde identifiziert; Ziel und Handlung waren genehmigt; das Zielsystem bestätigte das Ergebnis. Eine von M zurückgebrachte Antwort stützt die erste Aussage, nicht automatisch die übrigen.

Die dauerhafte Lehre des Entwurfs ist sein Verzicht auf eine umfassende Befugnis im Störfall. Sondercode blieb lokal, gewöhnlicher Verkehr sollte unverändert laufen, und der Wiederherstellungsrechner durfte sich nicht als Transit anbieten.

Die Hintertür blieb eine Tür, weil sie sich nicht als Route ausgab.