Der Lebenszyklus eines Tor Relays - Guard Relays (Entry Relays) - Middle Relays - Exit Relays
In diesem Post erörtere ich den Lebenszyklus eines neuen schnellen Tor Non-Exit-Relays. Da die Bandbreitenschätzung und das Loadbalancing vom gesamten Tor Netzwerk in den letzten Jahren viel komplizierter geworden ist und viele Unterstützer die ein frisches Tor Relay installiert haben sich diese Frage stellen.
Ich hoffe, dass diese Zusammenfassung für Relaisbetreiber nützlich ist. Sie liefert auch Hintergrundinformationen zum Verständnis einiger Funktionen zur Anonymitätsanalyse.
Ein neuer Server, vorausgesetzt er ist zuverlässig und hat genügend Bandbreite, durchläuft vier Phasen: die ungemessene Phase (Tage 0-3), in der er kaum genutzt wird, die Fernmessungsphase (Tage 3-8), in der die Last zu steigen beginnt, die Hochlaufphase (Tage 8-68), in der die Last kontraintuitiv sinkt und dann wieder steigt, und die Steady-State-Phase (Tage 68+).
Wenn dein Server zum ersten Mal startet, führt er einen Selbsttest der Bandbreite durch: Er baut vier Verbindungen zum Tor-Netzwerk und zurück zu sich selbst auf und sendet dann 125KB Datenpakete über jede Verbindung. Dieser Schritt startet Tors passives Bandbreitenmesssystem, das die Bandbreite des Tor Relays mit dem Wert des größten Bursts schätzt, den das Relay innerhalb von 10 Sekunden gemacht hast.
Die Tor Verzeichnisdienste listen das neue Tor-Relay im Tor Netzwerkverbund auf, und die Clients erhalten eine gute Bandbreitenleistung, Sie gleichen die Netzwerklast aus, indem sie Relays proportional zu der im Netzwerkverbund aufgelisteten Bandbreiten auswählen.
Ursprünglich haben die Verzeichnisdienste einfach die geschätzte Bandbreite verwendet, die Sie in Ihrem Relay-Deskriptor angegeben haben. Wie man sich vorstellen kann, war es bei diesem Ansatz nicht besonders stabil und der eine oder andere versucht Verkehr „unererlaubt“ anzuziehen. Seit längerem werden Skripte der "Bandbreitenautoritäten" verwendet, bei denen eine Gruppe von schnellen Servern im Internet (bwauths genannt) aktive Messungen an jedem Relay durchführt und die Verzeichnisdienste die Konsensbandbreite nach oben oder unten anpassen, je nachdem, wie das Relay im Vergleich zu anderen Relays mit ähnlichen Geschwindigkeiten abschneidet. (Technisch gesehen nennen wir die Konsenszahl eher eine "Gewichtung" als eine Bandbreite, da es nur darum geht, wie die Zahl Ihres Relays im Vergleich zu den anderen Zahlen ist, und sobald wir anfangen, sie anzupassen, handelt es sich nicht mehr wirklich um Bandbreiten).
Der bwauth-Ansatz ist nicht unangreifbar, aber er ist viel besser als das alte Design.
Das ist also Phase eins: Ihr neues Relais wird in den ersten Tagen seines Lebens wegen der niedrigen 20KB-Grenze praktisch nicht benutzt, während es darauf wartet, dass ein Schwellenwert von bwauths gemessen ist.
Phase zwei: Fernmessung (Tage 3-8).
Zu Beginn dieser Phase hat das Tor Relay noch nicht viel Verkehr gesehen, also sind Ihre Peers die anderen Relays, die noch nicht viel Verkehr gesehen haben. Im Laufe der Zeit werden jedoch einige Clients Verbindungen über Ihr Tor Relays aufbauen und etwas Verkehr erzeugen, und die passive Bandbreitenmessung wird eine neue, höhere Schätzung liefern. Jetzt werden die Bwauths dich mit deinen neuen (schnelleren) Servern vergleichen und dir ein höheres Konsensgewicht geben, was mehr Clients dazu bringt, das neue Tor Relay zu benutzen, was wiederum deine Bandbreitenschätzung erhöht, und so weiter.
Tor-Clients machen in der Regel drei Sprünge (d.h. Pfade, die durch drei Tor Relays). Die erste Position im Pfad, das sogenannte Guard-Relay, ist besonders, weil es gegen einen bestimmten Angriff hilft, der die Anonymität aufhebt. Der Angriff funktioniert wie folgt: Wenn man immer wieder neue Pfade nach dem Zufallsprinzip auswählt und der Gegner durch mehrere Tor Relays geht, sinkt mit der Zeit die Wahrscheinlichkeit auf Null, dass *jeder* einzelne Pfad, den man erstellt hat, vor dem Gegner unsicher ist. Die Verteidigung besteht darin, eine kleine Anzahl von Relays (Guard genannt) zu wählen und immer eines davon für den ersten Sprung zu benutzen - entweder man hat die falsche Wahl getroffen und einer der Tor Guard Relays wird vom Gegner ausgeführt oder man hat die richtige Wahl getroffen und alle seine Pfade sind sicher.
Nur stabile, bereits länger im Betrieb befindliche und zuverlässige Relays können als Guard Relay eingesetzt werden, im jetzigen Status wird also kein Client, Ihr brandneues Tor Relay als ersten Hop zu verwenden. Und da sind bei Ihrem Tor Relay um ein Non-Exit-Relay handelt (d.h. das Relay wird nicht das System sein, das tatsächlich Verbindungen zu externen Diensten wie Websites herstellt), wird auch ihr Tor Relay von keinem Client als dritter Hop verwenden. Das bedeutet, dass der gesamte Datenverkehr Ihres Relays über den Second Hop in Circuits läuft.
Das ist also Phase zwei: Sobald die Bwauths das Tor Relay vermessen hat und die Verzeichnisdienste das 20KB-Limit aufheben, wird das Tor Relay mehr und mehr Verkehr anziehen, der aber immer noch begrenzt sein wird, weil das Tor Relay immer noch ein Middle Hop ist.
Phase drei: Ausbau zum Guard-Relay (Tage 8-68).
Dies ist der Punkt, an dem das Guard -Flags einführt wird. Die Verzeichnisautoritäten vergeben das Guard-Flag an die Relays auf der Grundlage von Eigenschaften wie: "Bandbreite" (sie müssen ein ausreichend großes Konsensgewicht haben), "gewichtete Betriebszeit" (das Tor Relay muss störungsfrei, längere Zeit Online sein). Die letzte Eigenschaft, die Störungsfreie Onlinezeit ist hier am wichtigsten: Im heutigen Tor-Netzwerk kann ein neues Tor Relay am achten Tag zum ersten Mal ein Guard-Flag erhalten.
Clients sind nur bereit, das Tor Relay für ihren ersten Hop auszuwählen, wenn du das Guard-Flag hast. Aber hier ist der Haken: Sobald du das "Guard"-Flag bekommst, werden alle anderen Clients dich nicht mehr für ihre mittleren Hops benutzen, weil sie, wenn sie das "Guard"-Flag sehen, annehmen, dass du bereits viel Last von Clients hast, die dich als ersten Hop benutzen. Diese Annahme wird sich im Steady-State bewahrheiten (d.h. wenn genügend Clients das Relay als Guard-Knoten ausgewählt haben), werden wir einen Einbruch des Datenverkehrs bemerken, sobald das Tor Relay das Guard-Flag erhalten hat.
Warum vermeiden Clients die Verwendung von Relays mit Guard-Flag für ihren Middle Hop? Clients berücksichtigen die Knappheit der Guard-Kapazität und die Knappheit der Exit-Kapazität und vermeiden entsprechend der Verwendung von Relays für Positionen im Pfad, die nicht knapp sind. Auf diese Weise werden die verfügbaren Ressourcen am besten verteilt: Relays mit dem Exit-Flag werden hauptsächlich zum Verlassen verwendet, wenn sie knapp sind, und Tor Relays mit dem Guard-Flag werden hauptsächlich zum Eintreten verwendet, wenn sie knapp sind.
Es ist nicht optimal, diesen vorübergehenden Einbruch des Verkehrs zuzulassen (da wir keinen Nutzen aus den Ressourcen ziehen, die Sie beizusteuern versuchen), aber es handelt sich insgesamt um eine kurze Zeitspanne: Kunden wechseln ihre Guard-Knoten alle 4-8 Wochen, also werden einige von ihnen ziemlich bald zu Ihrem Relay wechseln.
Um es klar zu sagen: Es gibt zwei Gründe, warum wir Kunden dazu bringen, ihre Wächter-Relays zu rotieren, und diese Gründe sind zwei Seiten derselben Medaille: Erstens das oben beschriebene Problem, dass neue Wächter kaum genutzt würden (da nur neue Kunden, die ihre Wächter zum ersten Mal auswählen, einen neuen Wächter nutzen würden), und zweitens, dass alte, etablierte Wächter eine ständig wachsende Last anhäufen würden, da sie den Verkehr von allen Kunden hätten, die sie jemals als Wächter ausgewählt haben.
Einer der Gründe für diesen Blogeintrag ist es, Ihnen Hintergrundinformationen zu geben, damit Sie, wenn ich später erkläre, warum wir die Rotation der Wächter auf mehrere Monate ausdehnen müssen, verstehen, warum wir nicht einfach die Anzahl der Wächter erhöhen können, ohne auch einige andere Teile des Systems zu ändern, um Schritt zu halten. Bleiben Sie dran, wenn Sie weitere Einzelheiten erfahren möchten. Wenn Sie nicht warten möchten, können Sie auch die ursprünglichen Forschungsfragen und die nachfolgenden Forschungsarbeiten von Elahi et al. und Johnson et al. lesen.
Vierte Phase: Guard Relay im Dauerbetrieb (ab Tag 68).
Wenn dein Server für die gesamte Dauer der neuen Bestimmungen der Status Flags ein Guard Relay war
(bis zu 12 Wochen), sollte das Relay einen stabilen Zustand erreichen. Die Anzahl der Clients die das Relay als Einstiegspunkt und als Middel Relay nutzen haben sich ausgeglichen. Das Tor Relay erfüllt nun beide Funktionen.