Zusammenfassung

  • RFC 1273 beschrieb 1991 eine geplante Längsschnittstudie: Sechs Läufe sollten 13 TCP-Dienste in rund 12.700 Internet-Domains prüfen. Das Dokument war noch kein Bericht über das Jahresergebnis.
  • Ein erfolgreicher Verbindungsaufbau wurde ohne Anwendungsdaten sofort beendet. Ablehnung und Zeitüberschreitung hatten getrennte Abbruchregeln; keine Beobachtung bewies Nutzbarkeit, Sicherheit, Organisationswillen oder Ausfallursache.
  • Einzelne Hinweise belasteten Netz und Verwaltung stärker als die Messung, breite Hinweise konnten Verhalten verändern, Einzelzustimmung eine selbstselektierte Gruppe schaffen. Vorabpublikation, erkennbare Quelle, Opt-out und Aggregation blieben getrennte Antworten.

Zuerst war die Beweismethode öffentlich

Die sechs Läufe waren für Januar, März, Mai, Juli, September und November 1992 vorgesehen. Jeder sollte ein bis zwei Tage dauern. RFC 1273 erschien im November 1991 als Informational Memo. Es konnte die spätere Entwicklung noch nicht berichten.

Öffentlich war stattdessen die Konstruktion der Evidenz. Das Programm sollte daytime, netstat, FTP, Telnet, SMTP, DNS, Finger, Sun portmap, rlogin, rsh, UUCP, klogin sowie krcmd oder kshell in etwa 12.700 Domains ansprechen. Gegenstand war Erreichbarkeit auf Dienstebene, nicht bloß IP-Konnektivität.

Die Autoren wollten daraus auf die Bereitschaft von Organisationen zur organisationsübergreifenden Datenverarbeitung schließen. Doch die Antwort eines Ports auf einem ausgewählten Rechner war nicht die Organisation. Protokollzustand, Dienstbetrieb, Zugangspolitik und institutionelle Absicht gehörten zu verschiedenen Wirklichkeitsebenen.

Der Erfolg endete am TCP-Aufbau

Kam eine Verbindung zustande, wurde sie sofort geschlossen und gezählt. Anwendungsdaten flossen nicht. RFC 1273 betonte, dass die Sicherheitsmechanismen hinter den Diensten nicht getestet würden und die Untersuchung keine Sicherheitsstudie sei.

Erfolg bedeutete damit nur, dass das Ziel zu diesem Zeitpunkt den TCP-Aufbau annahm. Er bedeutete weder Anmeldung noch Dateizugriff, Mailzustellung, korrekte Antwort, Berechtigung oder brauchbare Zusammenarbeit.

Auch Misserfolg blieb aufgeteilt. Nach drei Verbindungsablehnungen endeten die Versuche für diesen Dienst in der Domain. Nach drei Zeitüberschreitungen wurde die Domain aufgegeben, eventuell mit einem neuen Versuch am Folgetag, um vorübergehende Netzprobleme zu berücksichtigen. Ablehnung war eine Antwort; Timeout war das Ende des Wartens. Beide enthielten keine fertige Kausalerklärung.

Als weniger invasiver Ersatz kamen DNS-Einträge für bekannte Dienste in Betracht. Das Dokument verwarf sie als unvollständig und inkonsistent, weil sie für den Netzbetrieb nicht erforderlich waren. Ein Verzeichniseintrag und eine direkte Verbindung beobachteten verschiedene Projektionen und konnten auf unterschiedliche Weise falsch oder unvollständig sein.

Belastungsgrenzen gehörten zum Messgerät

Nach einem Erfolg wurde derselbe Dienst in der Domain während des Laufs nicht erneut geprüft. Grenzwerte für Ablehnungen und Timeouts begrenzten erfolglose Arbeit. Der berechnete Höchstfall lag bei 37 Verbindungsanfragen pro Domain.

Ein Testlauf im August 1991 führte 50.549 DNS-Abfragen und 73.760 Verbindungsversuche in ungefähr zehn Stunden durch. Mehr als zwanzig Netzoperationen liefen nie gleichzeitig. Eine zentrale Stelle überwachte Protokoll und Last und konnte die Erhebung jederzeit stoppen.

Diese Zahlen belegen den von den Autoren beschriebenen Testlauf. Sie belegen weder die späteren sechs Läufe noch Wirkungslosigkeit an jedem Standort oder heutige Verhältnisse. Anteil am Backbone-Verkehr und Untersuchungszeit eines entfernten Administrators sind verschiedene Kosten.

Die Ankündigung trat in das Experiment ein

Frühe Hinweise liefen über alt.security und einzelne E-Mails. Etwa die Hälfte der Administratornachrichten kam als unzustellbar zurück. RFC 1273 berichtet, dass Netz- und Verwaltungsaufwand der Hinweise die Messung weit überstiegen; manche Standorte empfanden die Nachricht selbst als unnötige Zumutung.

Ein breiter Hinweis konnte die Erreichbarkeit vor dem Messzeitpunkt verändern. Einzelne Zustimmung wiederum hätte eine selbstselektierte Population erzeugt, die vermutlich seltener die Internet-Dienste abschaltete. Das Verfahren zur Legitimation beeinflusste die Verteilung, die es absichern sollte.

Das hob die Betreiberentscheidung nicht auf. RFC 1262 bewahrte die allgemeine Grenze von minimaler Wirkung, Providerkontakt und ausdrücklicher Erlaubnis vor unangemessener Belastung. RFC 1273 hielt die konkrete Lösung fest: Vorabveröffentlichung als RFC, ergänzende Listennachrichten, ein per Finger erklärbares testnet-Konto, direkter Kontakt und Entfernung eines Standorts auf Wunsch.

Nachverfolgbarkeit war kein Nachweis individueller Zustellung. Sie sollte demjenigen, der Verkehr bemerkte, eine Identifikation, Rückfrage und Beendigung ermöglichen.

Rohdaten blieben hinter der öffentlichen Statistik

Eine standortgenaue Liste erreichbarer Dienste konnte zur Karte werden. Daher sollten Rohdaten privat bleiben und nur globale, von den Standorten getrennte Statistiken veröffentlicht werden. Das war eine erklärte Verwahrungsgrenze, keine Garantie perfekter Anonymität.

Dieser Artikel stützt sich auf RFC 1273; RFC 1262 markiert nur die benachbarte allgemeine Richtlinie. Die Quellen enthalten kein abgeschlossenes Längsschnittergebnis, keinen Beleg für die planmäßige Durchführung 1992 und keine Ursache eines späteren Wandels.

Der historische Wert liegt in der Reihenfolge. Der Plan wurde prüfbar, solange die Antwort fehlte. Ein späteres Ergebnis konnte Stichprobe, Probe, Last, Ankündigung, Rückzug und Datenverwahrung nicht mehr redlich als eine einzige Tatsache ausgeben.