Dies wäre aus mehreren Gründen praktisch:
Es würde Tor besser in die Lage versetzen, neue Protokolle wie VoIP zu verarbeiten.
Damit könnte die Notwendigkeit der Socketierung von Anwendungen vollständig gelöst werden.
Ausgangs-Relays müssten auch nicht viele Dateideskriptoren für alle Ausgangs-Verbindungen zuweisen.
Wir sind auf dem Weg in diese Richtung. Einige der schwierigen Probleme sind:
IP-Pakete verraten die Merkmale des Betriebssystems.
Wir müssten immer noch eine Normalisierung der Pakete auf IP-Ebene vornehmen, um Angriffe wie TCP-Fingerprinting zu verhindern.
In Anbetracht der Vielfalt und Komplexität der TCP-Stacks und der Angriffe durch Geräte-Fingerprinting sieht es so aus, als ob es am besten wäre, einen eigenen User-Space-TCP-Stack zu entwickeln.
Streams auf Anwendungsebene müssen noch bereinigt werden.
Wir werden weiterhin benutzerseitige Anwendungen wie Torbutton benötigen.
Es wird also nicht nur darum gehen, Pakete zu erfassen und sie auf dem IP-Layer zu anonymisieren.
Bei bestimmten Protokollen existieren immer noch Informationslecks.
So müssen wir beispielsweise DNS-Anfragen so umschreiben, dass sie an einen nicht verlinkbaren DNS-Server und nicht an den DNS-Server des Internetanbieters des Benutzers weitergeleitet werden; wir müssen also die Protokolle verstehen, die wir transportieren.
DTLS (Datagram-TLS) hat im Grunde keine Benutzer, und IPsec ist wirklich groß.
Sobald wir uns für einen Transportmechanismus entschieden haben, müssen wir ein neues Ende-zu-Ende-Tor-Protokoll entwerfen, um Markierungsangriffe und andere potenzielle Anonymitäts- und Integritätsprobleme zu vermeiden, da wir nun Abbrüche, erneutes Senden usw. erlauben.
Ausgangsrichtlinien für beliebige IP-Pakete bedeuten den Aufbau eines sicheren Intrusion-Detection-Systems (IDS).
Unsere Knotenbetreiber sagen uns, dass die Ausgangsrichtlinien einer der Hauptgründe sind, warum sie bereit sind, Tor zu betreiben.
Ein IDS hinzuzufügen, um Ausgangsrichtlinien zu handhaben, würde die Sicherheitskomplexität von Tor erhöhen und würde wahrscheinlich sowieso nicht funktionieren, wie der gesamte Bereich der IDS- und Gegen-IDS-Papiere beweist.
Viele potentielle Missbrauchsprobleme werden durch die Tatsache gelöst, dass Tor nur gültige TCP-Streams transportiert (im Gegensatz zu beliebiger IP, einschließlich fehlerhafter Pakete und IP-Floods).
Mit der Möglichkeit, IP-Pakete zu transportieren, gewinnen die Ausgangsrichtlinien noch mehr an Bedeutung.
Wir müssen auch die Ausgangsrichtlinien im Tor-Verzeichnis kompakt beschreiben, sodass die Clients vorhersagen können, durch welche Knoten ihre Pakete hinausgelassen werden.
Außerdem müssen die Clients alle Pakete, die sie in einer Sitzung senden wollen, vorhersagen, bevor sie ihren Ausgangsknoten auswählen!
Die Tor-internen Namensräume müssten umgestaltet werden.
Wir unterstützen die „.onion“-Adressen des Onion-Dienstes, indem wir die Adressen abfangen, wenn sie an den Tor-Client übergeben werden.
Dies auf IP-Ebene zu tun, erfordert eine komplexere Schnittstelle zwischen Tor und dem lokalen DNS-Resolver.