Zusammenfassung

  • Ein Sender durfte SRC setzen, wenn seine 32-Bit-FROM-Adresse nach dem Vertauschen der Trägeradressen zum Ursprung zurückführte. Jeder Zwischenadapter durfte diese Behauptung bei einem Bruch der Rückwegbedingung löschen.
  • Ein erhaltenes Bit belegte nur, dass die vertauschten Adressen den ursprünglichen Prozess erreichten. CRC, physische Verwahrung, Protokollserverwahl, menschliche Identität und die Berechtigung der Anfrage blieben davon getrennt.

Die im Februar 1988 veröffentlichte RFC 1044 beschrieb IP und verwandte Protokolle auf Network Systems HYPERchannel. Sie führte eine 32-Bit-Adressierung neben der verbreiteten 16-Bit-Praxis ein, registrierte Nachrichtentypen und skizzierte den Übergang von lokalen Tabellen über einen ARP-Server zu künftigem verteiltem Broadcast-ARP. Ihre bleibende Pointe liegt jedoch in der engen Definition dessen, was ein „korrekter“ Quellwert tatsächlich belegen konnte.

Der Träger brauchte eine Adresse für die Antwort

Im Grundformat wählte TO das Ziel. FROM wurde mitgeführt, damit der Empfänger eine Nachricht zurücksenden konnte; für die Zustellung der ausgehenden Nachricht selbst wurde das Feld nicht benutzt. Bei der 16-Bit-Form sollten vertauschte Adressfelder und Trunk-Masken im Allgemeinen zuverlässig zum Ursprung zurückleiten.

Damit ist eine Verkehrsbeziehung beschrieben, keine Identität. Ein antwortfähiger Prozess kann unter einem kompromittierten Programm laufen, von einer unberechtigten Person gesteuert werden oder eine verbotene Wirkung verlangen. Die Lieferadresse klärt, wohin die Antwort geht. Sie sagt nicht, wem das Konto gehört oder ob der Dienst handeln darf.

Auch der logische Anteil von TO erfüllte eine eigene Aufgabe: Er wählte den registrierten Protokollserver. Sobald die vollständige Adresse den Endserver bestimmte, konnte das Nachrichtentypfeld die Zustellung nicht an einen anderen Server umleiten, obwohl Zwischenhardware den Typ zur Behandlung unterwegs heranziehen durfte. Endpunktwahl und Transitklassifikation waren also schon getrennt.

GNA, CRC und SRC waren keine drei Stufen desselben Urteils

Die erweiterte Adresse fügte Domänen- und Netzkoordinaten hinzu. GNA sagte, dass diese Form vorlag. CRC verlangte oder meldete eine Ende-zu-Ende-Prüfung durch dafür ausgerüstete Adapter. SRC behauptete dagegen, dass die angegebene Quelle als Ziel einer umgekehrten Nachricht tauge.

Der Sender setzte SRC, nachdem er sich bemüht hatte, die vollständige FROM-Adresse seiner Adapter-Schnittstelle anzugeben. Jeder Adapter auf dem Weg konnte das Bit löschen, wenn diese Adresse als vertauschtes TO nicht zum absendenden Prozess führen würde. Der Empfänger bekam damit keine Reihe positiver Beglaubigungen. Er sah lediglich eine Behauptung, die keine beteiligte Station aufgrund genau dieses Fehlers zurückgenommen hatte.

Das Verfahren ist deshalb weder Signatur noch Geheimnis. Der Absender darf die Ausgangsbehauptung selbst schreiben. Die Stationen besitzen ein Widerrufsrecht, aber sie bestätigen weder einen Menschen noch dessen Zweck. Wenn das Bit fehlt, ist selbst der Grund offen: fehlende Unterstützung, unterlassene Setzung, berechtigte Löschung, veränderte Topologie oder Implementierungsfehler sind verschiedene Möglichkeiten.

So entsteht ein asymmetrisches Signal. Ein gelöschtes SRC kann die stärkste Rückwegannahme verhindern. Ein erhaltenes SRC bleibt von der Richtigkeit und Verwahrung aller Geräte abhängig, die es stehen ließen.

Die zugesicherte Eigenschaft war präzise und begrenzt

RFC 1044 erläuterte „correct“ durch eine beobachtbare Folge: Werden TO und FROM vertauscht, erreicht die neue Nachricht den Prozess, der die erste erzeugt hat. Das ist mehr als bloße Erreichbarkeit, denn der Rückweg wird an einen bestimmten Herkunftsprozess innerhalb des HYPERchannel-Modells gebunden.

Authentifizierung ist es trotzdem nicht. Ein Prozess kann Urheber einer Nachricht und zugleich unbefugt sein. Ein physisch richtig adressierter Rechner kann manipulierte Software ausführen. Ein erfolgreich zurückgesandtes Ergebnis kann zu einer bösartigen oder veralteten Anfrage gehören. Rückkehrfähigkeit beantwortet die Ortsfrage; Autorisierung beantwortet die Wirkungsfrage.

Das Dokument benennt seine externe Voraussetzung ausdrücklich. Ein hoher Sicherheitsgrad aus der FROM-Adresse sei möglich, wenn der physischen Sicherheit der Adapter und Zwischenverbindungen sorgfältige Aufmerksamkeit gelte. Die Vertrauensgrenze liegt damit in Gebäuden, Leitungen, Gerätezuständigkeit und Konfiguration. SRC erzeugt diese Verwahrung nicht und kann sie aus dem Paket heraus nicht prüfen.

Eine CRC schützt Inhalt, nicht Anspruch

Der gesonderte CRC-Schalter zeigt, wie eng die Zuständigkeiten waren. Geeignete Adapter konnten eine 32-Bit-Prüfsumme über die Netzwerknachricht durch Zwischenhardware und Netze hindurch ergänzen und kontrollieren. Ein erfolgreicher Test sprach für unveränderte Bits auf diesem Pfad.

Er machte die FROM-Adresse nicht rückführbar. Umgekehrt prüfte SRC die transportierten Daten nicht. Keines von beiden wies einen Benutzer aus, legitimierte die eingebettete IP-Quelle oder erteilte eine Anwendungsberechtigung. Wer in einem Auditprotokoll nur „validiert“ speichert, verliert die entscheidende Information darüber, ob Adresse, Daten, Serverauswahl oder Geschäftsentscheidung gemeint war.

Die in RFC 791 definierte IPv4-Schicht bringt ihr eigenes Quell- und Zieladresspaar, ein Protokollfeld, die Gesamtlänge und eine Kopfprüfsumme mit. Diese Felder liegen in einem HYPERchannel-Rahmen mit eigenen Adressen und Flags. Übereinstimmung zwischen IP-Quelle und aufgelöstem FROM kann eine weitere Beobachtung sein; zwei stimmige Koordinaten ergeben aber noch keinen berechtigten Akteur.

Die Adressauflösung hatte eine eigene Herkunft

RFC 1044 schildert mehrere Generationen der Zuordnung: zunächst abgeschnittene niedrige Adressteile, dann lokale Konfigurationsdateien, anschließend einen bekannten ARP-Server und schließlich ein erwartetes verteiltes Broadcast-Verfahren. Dafür griff sie auf das generische Abbildungsformat aus RFC 826 zurück.

Eine solche Auflösung entscheidet, welchen HYPERchannel-Kopf ein IP-Datagramm zum lokalen Host oder nächsten Gateway tragen soll. Sie beweist weder den Besitzer des Eintrags noch seine Aktualität. Eine statische Datei, eine zentrale Antwort und eine Broadcast-Antwort haben verschiedene Provenienz. Keine davon wird durch ihre technische Brauchbarkeit zur Anwendungsberechtigung.

SRC kann eine nach der Auflösung gewählte Rückadresse unterwegs erhalten. Es kann aber eine falsche Zuordnung nicht wahr machen, nur weil sie in sich umkehrbar ist. Konsistenz und Wahrheit sind getrennte Prüfgrößen.

Der empfangende IP-Treiber sollte zunächst nichts tun

Für sendende IP-Treiber empfahl RFC 1044, Source Address Correct zu setzen, sobald sie sich um die vollständige richtige FROM-Adresse der verwendeten Schnittstelle bemüht hatten. Empfangende IP-Treiber sollten auf das Bit zu diesem Zeitpunkt jedoch nicht reagieren. Erst weitere Arbeit sollte klären, was beim fehlenden Flag in einem wirklichen oder angenommenen Sicherheitsverstoß geschehen müsse.

Diese Zurückhaltung ist ein Teil des Entwurfs. Ein neu transportierbares Indiz ist noch keine ausgereifte Zulassungspolitik. Dafür braucht es Kenntnisse über alte Implementierungen, definierte Fehlerfälle, eine belastbare physische Vertrauensgrenze und ein Verfahren, das Nichtunterstützung von einer gebrochenen Route unterscheidet. Alles Unmarkierte zu verwerfen schafft leicht einen Ausfall; alles Markierte zu erlauben schafft ein Privileg aus Erreichbarkeit.

RFC 1044 löste Quellenauthentifizierung nicht. Sie machte eine Eigenschaft des physischen Netzes so explizit, dass sie gesetzt, unterwegs verworfen und am Ziel getrennt ausgewertet werden konnte. Die Spezifikation ist damit ein frühes Beispiel dafür, nützliche Evidenz zu transportieren, ohne ihr mehr Entscheidungsmacht zuzuschreiben, als sie verdient.

Quellen und Beweisgrenzen

RFC 1044 liefert Nachrichtenformate, Adressumkehr, Serverwahl, Flag-Semantik, physische Sicherheitsannahme, Treiberhinweise und die Stufen der Adressauflösung. RFC 791 definiert den eingebetteten IPv4-Kopf mit seinen separaten Adress-, Längen- und Prüffeldern. RFC 826 stellt das allgemeine Modell der Protokoll-zu-Link-Adressauflösung bereit.

Diese Texte belegen die Spezifikation und ihre erklärten Annahmen. Sie belegen nicht, dass eine konkrete Installation SRC verwendete, jeder Adapter korrekt löschte, die physische Grenze geschützt war, ein berechtigter Mensch anfragte oder die verlangte Wirkung eintrat.