Zusammenfassung

  • Das Präfix in RFC 1459 bezeichnete eine IRC-Protokollquelle; der empfangende Server musste sie in seinem Bestand finden und dem tatsächlich benutzten Eingangslink zuordnen.
  • Eindeutiger Nickname, registrierte Sitzung, passender Baumzweig und angenommene Nachricht waren getrennte Zustände und keine Bestätigung der schreibenden Person.
  • Der stille Abwurf schützte die Quellbeziehungen, machte eine spätere Erklärung jedoch von zeitgebundenen Datenbank- und Verbindungsprotokollen abhängig.

Mehr Vertrauen bedeutete nicht weniger Prüfung

RFC 1459 erschien im Mai 1993 als Experimentalprotokoll. IRC hatte sich von einem BBS-Chat zu einem weltweiten Netz aus Clients und Servern entwickelt. Die Server bildeten einen Baum. Jeder Server verband seine lokalen Clients mit Nachbarn und hielt genug Zustand, um Quellen und Ziele in diesem Baum zu finden.

Die Nachrichten blieben einfache Textzeilen. Vor Befehl und Parametern konnte ein Präfix stehen: ein Servername oder ein Nickname, teilweise ergänzt durch Benutzer und Host. Fehlte das Präfix, galt die empfangende Verbindung als Herkunft. Stand ein Name dort, bezeichnete er nach dem Dokument den Ursprung.

Der Name wurde trotzdem nicht geglaubt. Ein Client durfte nur seinen registrierten Nickname verwenden. Der Empfänger suchte die Quelle in seiner internen Datenbank und prüfte, ob sie hinter dem Link registriert war, auf dem die Nachricht eingetroffen war. Unbekannte Quellen und bekannte Quellen vom falschen Zweig wurden still verworfen.

Der Parser bestätigte damit nur die Form. Der Datensatz bestätigte ein bekanntes Objekt. Die Linkzuordnung bestätigte eine zulässige Beziehung. Erst der lokale Entscheid verband diese Nachweise mit einer Handlung.

Der Nickname war Netzadresse, nicht Personalausweis

Jeder Client brauchte einen netzweit eindeutigen Nickname, damals höchstens neun Zeichen lang. Das machte Antworten adressierbar. Es begründete keinen dauerhaften Anspruch auf die Zeichenfolge.

Bei einer Kollision entfernten Server die Vorkommen und verbreiteten KILL. Sie entschieden nicht, welcher Mensch den besseren Namensanspruch hatte. Ein unmittelbar angeschlossener Client konnte stattdessen eine lokale Ablehnung erhalten. Das Protokoll stellte Eindeutigkeit im aktuellen Bestand wieder her.

WHOWAS lieferte jüngere Namensgeschichte. Auch Nickname-Wechsel wurden verfolgt, damit KILL, MODE und KICK bei Rennen nicht sofort das falsche Ziel trafen. RFC 1459 räumte ein, dass dies dennoch geschehen konnte. Name, Sitzung und Zeitpunkt mussten gemeinsam gelesen werden.

Hostname, Benutzername und Heimatserver lieferten weiteren Kontext. Verbindungen konnten DNS-Prüfungen, optionale Passwörter und Ident-Abfragen durchlaufen. Der RFC empfahl Serverpasswörter ausdrücklich, weil ohne sie kaum zuverlässig festzustellen war, wer am anderen Ende saß. Ein Verbindungsnachweis war jedoch keine Signatur jeder Nachricht und kein Beweis einer menschlichen Identität.

Der lokale Zustand war Teil der Beweiskette

Ein dezentraler Baum brauchte keinen zentralen Namensdienst für jede Zeile. Dafür beruhte die Prüfung auf der eigenen Kopie der Netzsicht. Alter und Herkunft dieses Zustands wurden sicherheitsrelevant.

Bei einem Netsplit arbeiteten beide Seiten weiter. Sie konnten unterschiedliche Mitglieder, Kanalmodi und Nicknames kennen. Nach der Wiederverbindung tauschten sie aus, was sie jeweils für wahr hielten. Gleiche Namen auf getrennten Seiten konnten legitime Folgen der Partition sein; die Kollision allein bewies keinen Angriff.

Eine Nachrichtencapture enthielt nicht den ganzen Entscheid. Für die Rekonstruktion brauchte man Empfangszeit, Verbindung, Peer, Präfix, Datenbankrevision, erwarteten Zweig, tatsächlichen Zweig und Maßnahme. Der später synchronisierte Zustand konnte die frühere Abweichung verdecken.

Stilles Verwerfen verringerte zusätzliche Protokollaktivität, verschob aber die Nachweispflicht zum Betreiber. Der Absender sah aus dem Ausbleiben nicht, ob Parsing, Quellsuche, Linkvergleich, späteres Relay oder Clientanzeige gescheitert war.

Die Dokumente von 2000 verschärften die Linkfolgen

RFC 2810 beschrieb die Architektur separat und nannte die Kopie globaler Zustandsdaten auf jedem Server als schwerwiegendes Skalierungsproblem. Genau dieser Zustand trug den Herkunftsabgleich.

RFC 2812 erhielt für Clients die Regel: Ohne Präfix zählt die Verbindung; mit Präfix ist nur der registrierte Nickname zulässig. RFC 2813 formulierte die Serverseite genauer. Eine nicht auffindbare Quelle musste verworfen werden. Ein unbekannter Server im Präfix konnte den Link kosten. Zeigte der Datenbestand auf einen anderen Link, wurde die Nachricht in jedem Fall verworfen; je nach Quelle folgten Client-KILL oder Verbindungsabbruch.

Die Schutzhandlung hatte somit einen Verfügbarkeitspreis. Ein Linkabbruch verhinderte weitere unvereinbare Aussagen, trennte zugleich aber alle legitimen Nutzer dieses Zweigs. Integrität des Graphen und Fortbestand des Dienstes waren verschiedene Ergebnisse.

Server-Token waren nach RFC 2813 nur innerhalb einer Punkt-zu-Punkt-Peerbeziehung eindeutig. Außerhalb besaß dieselbe Zahl keine globale Identität. Auch daran zeigt sich: Ein Identifikator trägt seinen Geltungsbereich mit.

Die laufende Grammatik überstand einen falschen Hexwert

RFC 1459 gab für den Doppelpunkt irrtümlich 0x3B an, den Wert des Semikolons. Zeichen und Grammatik zeigten die Absicht; das verifizierte Erratum 4091 korrigierte auf 0x3A.

Original, Erratum und Implementierung sind verschiedene historische Belege. Das Original dokumentiert den veröffentlichten Fehler. Das Erratum dokumentiert die autorisierte Korrektur. Interoperabler Code zeigt die tatsächlich benutzte Trennung. Wer nur den Text konserviert, wiederholt den Fehler; wer nur den Code betrachtet, verliert die Änderungsgeschichte.

Verschlüsselung löste nicht die Präfixbeziehung

PASS und OPER wurden zunächst im Klartext übertragen. RFC 2813 verwies auf Stromverschlüsselung wie TLS; RFC 7194 registrierte später einen Standardport für IRC über TLS/SSL. Das konnte Zugangsdaten und Inhalte auf einem geschützten Link sichern.

Ein verschlüsselter Link konnte trotzdem ein zum lokalen Zustand unpassendes Präfix liefern. Ein korrekter Linkabgleich bewies umgekehrt keine Verschlüsselung. Eine Portregistrierung war weder Einsatznachweis noch Empfangsbestätigung.

RFC 1459 löste eine kleinere Aufgabe: Der behauptete Protokollabsender musste zum beobachteten Eingangsverhältnis passen. Wer schrieb, wer lesen durfte, wohin die Nachricht weitergeleitet wurde und ob sie ankam, blieben eigene Fragen.