Zusammenfassung

  • PPPs Magic-Number machte bestimmte Rückschleifen durch lokal gewählte Werte und einen geregelten Austausch erkennbar; die Zahl war kein globaler Geräteausweis.
  • Gleiche Werte konnten eine Kollision, eine Reflexion oder eine korrekte Bestätigung bedeuten. Pakettyp und Verhandlungshistorie entschieden über die Auslegung.
  • Die gemeinsame Erkennungsvorschrift schrieb keine universelle Wiederherstellung vor. Bitintegrität, eigenständige Gegenstelle und authentisierte Identität blieben getrennte Aussagen.

Der Befund enthielt noch keinen Betriebsauftrag

Im Juli 1994 beschrieb RFC 1661, wie PPP mit einer Magic-Number zurückgeschleifte Verbindungen und andere Anomalien der Sicherungsschicht erkennen konnte. Bei der anschließenden Wiederherstellung blieb der Text bewusst offen.

Als Möglichkeiten nannte er unter anderem, die Verbindung als Down zu behandeln und später erneut zu öffnen, oder mit Echo-Verkehr im passenden Zustand nach dem Ende der Rückschleife zu suchen. Ein allgemeingültiger Zähler für Fehlversuche oder eine feste Wartezeit für jede Installation stand dort nicht.

Diese Offenheit war keine Lücke in der Zahlenprüfung. Sie markierte eine Zuständigkeitsgrenze. Zwei Implementierungen mussten ausreichend gemeinsame Regeln besitzen, um denselben Austausch kompatibel zu deuten. Sie mussten deshalb nicht dieselben Unterbrechungskosten tragen oder denselben Wiederanlauf bevorzugen.

Um diese Trennung zu verstehen, lohnt sich der Blick darauf, was die kleine Zahl überhaupt feststellen konnte. Sie lieferte weniger als einen Gesundheitsnachweis für eine Verbindung, aber mehr als die bloße Beobachtung, dass wieder Bits eingetroffen waren.

Die unbeschädigte eigene Sendung

Bei einer Punkt-zu-Punkt-Verbindung scheint der Gegenüber selbstverständlich. Eine Seite sendet, die andere empfängt. Eine Rückschleife kann diese Annahme jedoch unterlaufen: Der Ausgang einer Maschine gelangt wieder an ihren eigenen Eingang, ohne dass der erwartete Peer eine unabhängige Antwort erzeugt.

Die Daten können dabei unverändert bleiben. Die in RFC 1662 beschriebene HDLC-ähnliche Rahmung von PPP prüft mit einer Frame Check Sequence die dafür vorgesehenen Felder. Standardmäßig ist diese Prüffolge zwei Oktette lang; eine Vier-Oktett-Variante ist ebenfalls definiert.

Ein unverändert zurückkehrender Rahmen kann die Prüfung bestehen. Das widerspricht ihrem Zweck nicht. Sie untersucht die Übereinstimmung von Rahmeninhalt und Prüfergebnis, nicht die Unabhängigkeit des Absenders. Für eine Schleifenerkennung war deshalb eine andere Art von Information nötig.

Magic-Number ergänzte einen lokal gewählten Zustand. Wenn beide Enden tatsächlich unabhängig handelten, sollten sie unterschiedliche Zahlen erzeugen können. Genau diese Möglichkeit sollte der Steuerungsaustausch sichtbar machen.

Eine vorbereitete Erweiterung bekam Verhaltensregeln

Die Vorgeschichte reicht über RFC 1661 hinaus. Bereits RFC 1134 vom November 1989 teilte PPP in Kapselung, ein erweiterbares Link Control Protocol und Network Control Protocols für die jeweiligen Netzwerkschichtprotokolle.

LCP sollte die Verbindung herstellen und prüfen, bevor die entsprechenden Netzwerkprotokolle konfiguriert und darüber genutzt wurden. Diese Aufteilung verhinderte, dass alle Voraussetzungen der Kommunikation in einer einzigen Erfolgsanzeige verschwanden.

In den Echo- und Discard-Formaten war schon ein vier Oktette langes Magic-Number-Feld vorhanden. Ohne eine abweichende Konfigurationsoption wurde es mit null gesendet und beim Empfang ignoriert. Seine weitergehende Verwendung lag an dieser Stelle außerhalb der Beschreibung.

RFC 1172 vom Juli 1990 erläuterte dann die anfänglichen Optionen einschließlich Zahlenauswahl, Kollisionsbehandlung und gegenseitigen Verhaltenspflichten. RFC 1331 vom Mai 1992 führte den Mechanismus fort. Im Text von 1994 stand er in Abschnitt 6.4.

Das ist eine Entwicklung von vorhandener Erweiterungsfläche zu geteilter Verfahrenskenntnis, keine plötzliche Erfindung eines Feldes. Ebenso wenig beweist die Folge der Dokumente, wann einzelne installierte Geräte die Regeln tatsächlich umsetzten.

Zwei gleiche Vorschläge sind zunächst mehrdeutig

Bevor eine Implementierung Magic-Number anbietet, wählt sie ihren Wert. Ziel ist eine mit hoher Wahrscheinlichkeit unterschiedliche Zahl an den beiden Enden dieser Verbindung, nicht eine weltweit einmalige Kennung.

Trifft ein Configure-Request mit der Option ein, wird dessen Wert mit dem Wert des zuletzt lokal gesendeten Configure-Request verglichen. Unterschiedliche Zahlen sprechen im vorgesehenen Modell gegen die einfache Rückkehr der eigenen Anforderung. Gleichheit lässt dagegen zwei Erklärungen zu: Rückschleife oder zufällige Übereinstimmung zweier echter Peers.

Die Reaktion auf diese Gleichheit ist ein Configure-Nak mit einem anderen vorgeschlagenen Wert. Ein neuer Configure-Request soll nicht willkürlich zusätzlich ausgesendet werden, sondern aus dem normalen Ablauf entstehen, etwa nach einem empfangenen Nak oder nach Ablauf des Restart-Timers.

Danach folgt ein anders bezogener Vergleich: Der Wert eines empfangenen Nak wird mit dem des zuletzt selbst gesendeten Nak verglichen. Erneute Gleichheit verstärkt den Schleifenverdacht und verlangt eine neue Auswahl. Unterschiedliche Werte zeigen im konformen Modell eine andere Entscheidung. Ein neuer Configure-Request soll den neuen Wert verwenden.

Bei einer wirklichen Rückschleife können sowohl Anforderungen als auch Änderungsvorschläge immer wieder beim Absender landen. Unabhängige Enden sollten dagegen bald auseinanderlaufen. Das Verfahren versucht also, eine zunächst mehrdeutige Gleichheit aufzulösen. Es erklärt nicht die erste Kollision bereits zum sicheren Fehler.

Eine Bestätigung muss gerade gleich bleiben

Der Pakettyp ist dabei unverzichtbar. Ein gültiger Configure-Ack muss die angebotenen Optionen unverändert und in derselben Reihenfolge zurückgeben; auch der Identifier muss passen.

Die eigene Magic-Number in einer solchen Bestätigung ist somit erwartetes Verhalten. Dieselben vier Oktette in einem neuen Configure-Request des vermeintlichen Peers haben eine andere Bedeutung. Ein Zähler, der ohne Paketcode jede Gleichheit als Rückschleife wertet, würde korrekte Verhandlungen als Fehler behandeln.

Auch bei Echo sind die Felder nicht austauschbar. Ein Echo-Reply übernimmt den Identifier aus der Anfrage, damit sich beide Nachrichten zuordnen lassen. Seine Magic-Number ist nach erfolgreicher Verhandlung jedoch die Zahl des Antwortsenders, nicht einfach eine Kopie der Zahl des Anfragenden.

Zuordnung und Herkunftshinweis bleiben getrennt. Das ist der Grund, weshalb eine vollständig untypisierte Sammlung von Zahlen für die Diagnose nicht genügt. Man benötigt die Handlung, zu der jeder Wert gehört.

Zufall ist eine Voraussetzung, keine Beschriftung

Die historischen Texte nennen für gleichverteilte 32-Bit-Auswahl eine idealisierte Kollisionswahrscheinlichkeit von ungefähr 2,3 × 10^-10 für eine Übereinstimmung. Diese Zahl ist kein gemessener Fehlalarmanteil eines Gerätebestands.

Zwei Generatoren mit gleichem Startzustand und identischem Ablauf können weiter dieselben Werte liefern. Mehrere empfangene Kopien derselben Nachricht sind ebenfalls keine unabhängigen Versuche. Die Multiplikation von Wahrscheinlichkeiten setzt neue, unabhängige Entscheidungen voraus.

Hinzu kommt eine kleine, aber lehrreiche Präzisierung: Null ist als angebotener Wert der Konfigurationsoption unzulässig. Wer ausschließlich zulässige Nichtnullwerte gleichverteilt auswählt, hat einen etwas anderen Wertebereich als das vollständige 32-Bit-Modell der historischen Tabelle. Die entscheidende betriebliche Unsicherheit liegt allerdings meist in der Unabhängigkeit, nicht in dieser arithmetischen Feinheit.

Die RFCs empfehlen, Magic-Number ohne brauchbare Quelle für Einzigartigkeit oder Zufälligkeit nicht selbst anzubieten. Eingehende Angebote dürfen dann bestätigt oder zurückgewiesen werden. Die lokale Erkennung wird dadurch begrenzt, während der Peer möglicherweise weiterhin eigene Hinweise gewinnen kann.

Ein Merkmal nicht zu verwenden ist etwas anderes, als seine Voraussetzungen vorzutäuschen. Das Protokoll konnte eine Auswahlregel empfehlen; es konnte keine gute Initialisierung in eine bestehende Implementierung hineinveröffentlichen.

Warum eine Ablehnung aufschlussreich sein konnte

Wer die Option selbst anbietet, darf dieselbe Option des Peers nicht mit Configure-Reject ablehnen. Diese Gegenseitigkeit stützt eine besondere Schlussfolgerung.

Kommt auf das eigene Angebot ein Configure-Reject zurück, weiß eine konforme Implementierung, dass sie diese Antwort nicht auf ihre eigene reflektierte Anforderung erzeugen würde. Im beschriebenen Modell zeigt die Ablehnung deshalb einen anderen Teilnehmer.

RFC 1661 sieht vor, sich dann so zu verhalten, als sei die Verhandlung gelungen, und zugleich zu berücksichtigen, dass der Peer keine Magic-Numbers verwenden wird. Das bedeutet weder identische Fähigkeiten in beiden Richtungen noch eine nachgewiesene Identität.

Die Folgerung ist an korrektes Protokollverhalten gebunden. Ein Angreifer muss diese Regeln nicht einhalten. Eine Handlung, die vom eigenen erwartbaren Verhalten abweicht, ist ein begrenzter Hinweis und kein kryptografischer Herkunftsnachweis.

Null kann der richtige Diagnosewert sein

Bis zur erfolgreichen Verhandlung wird im entsprechenden Diagnosefeld null gesendet. Hat der Peer keine eigene Zahl ausgehandelt, besitzt dieser Nullwert eine definierte Bedeutung. Er ist nicht automatisch ein Fehler.

Eine null innerhalb des angebotenen Magic-Number-Optionswerts ist dagegen unzulässig und muss mit Nak beantwortet werden, sofern die Option nicht zurückgewiesen wird. Das gleiche Bitmuster kann also einen gültigen Standardzustand oder einen ungültigen Konfigurationsvorschlag darstellen.

Im laufenden Betrieb weist die eigene ausgehandelte Zahl beim Empfang im Protokollmodell auf Rückschleife hin. Der erwartete Peer-Wert beziehungsweise dessen gültige null ist der normale Fall. Ein davon abweichender dritter Wert deutet auf Kommunikation mit einem anderen Peer.

Hinzu kommen Zustandsgrenzen. Echo-Request und Echo-Reply dürfen nur im LCP-Zustand Opened gesendet werden. Eine dort empfangene Echo-Anforderung verlangt eine Antwort; außerhalb dieses Zustands empfangene Echo-Pakete sollen still verworfen werden. Discard-Request hingegen ist eine Senkenfunktion ohne Antwort.

Diese Regeln machen aus Echo keine allgemeine Vorabsonde und aus Magic-Number keinen Beweis einer funktionierenden IP-Strecke. Der Beobachtungsbereich bleibt der Link-Control-Austausch.

Gemeinsame Typen, lokal gewählte Zahlen

Das PPP-Register von IANA führt Magic-Number als LCP-Konfigurationsoption Typ 5. Die Option ist sechs Oktette lang, davon vier für den Wert. Authentication-Protocol steht getrennt als Typ 3 im Register.

Das Register koordiniert die Bedeutung eines Optionstyps, nicht die Zahl jedes einzelnen Endpunkts. Eine lokale Auswahl benötigt deshalb keine globale Reservierung. Umgekehrt bescheinigt ein Registereintrag weder den Betrieb der Option auf einer konkreten Leitung noch den Namen eines Peers.

Für Authentisierung ist eine andere Grundlage nötig. RFC 1994 vom August 1996 beschreibt CHAP mit einer Herausforderung und einer aus einem gemeinsamen Geheimnis berechneten Antwort. Dieser historische Vergleich ist keine Empfehlung für heutige Authentisierungsalgorithmen. Er zeigt, welche Aufgabe eine offen sichtbare Magic-Number nicht erfüllt.

Eine intakte Übertragung, eine eigenständige Gegenstelle und eine authentisierte Identität sind verschiedene Befunde. Erst wenn diese Trennung erhalten bleibt, lässt sich auch die offene Wiederherstellungspolitik richtig verstehen: Die gemeinsame Zahlenauswertung sollte den Betrieb informieren, nicht ihn vollständig regieren.