Questo sarebbe utile per una serie di ragioni:
Renderebbe Tor più capace di gestire nuovi protocolli come il VoIP.
Potrebbe risolvere l'intera necessità di sockificare le applicazioni.
I relè di uscita non avrebbero bisogno di allocare molti descrittori di file per tutte le connessioni di uscita.
Stiamo andando in questa direzione. Alcuni dei problemi più difficili sono:
I pacchetti IP rivelano le caratteristiche del sistema operativo.
Avremmo ancora bisogno di normalizzare i pacchetti a livello IP, per bloccare attacchi come il TCP fingerprinting.
Data la diversità e la complessità degli stack TCP, insieme agli attacchi di fingerprinting dei dispositivi, sembra che la cosa migliore sia la spedizione di un proprio stack TCP per lo spazio utente.
I flussi a livello di applicazione devono ancora essere analizzati.
Avremo ancora bisogno di applicazioni lato utente come Torbutton.
Quindi non si tratterà solo di catturare i pacchetti e renderli anonimi a livello IP.
Alcuni protocolli continuano a far trapelare informazioni.
Per esempio, dobbiamo riscrivere le richieste DNS in modo che vengano consegnate a un server DNS non collegabile piuttosto che al server DNS dell'ISP dell'utente; quindi, dobbiamo comprendere i protocolli che stiamo trasportando.
DTLS (datagram TLS) non ha praticamente utenti, mentre IPsec è sicuramente grande.
Una volta scelto il meccanismo di trasporto, dobbiamo progettare un nuovo protocollo Tor end-to-end per evitare gli attacchi di tagging e altri potenziali problemi di anonimato e integrità, ora che sono consentite cadute, reinvio, eccetera.
I criteri di uscita per i pacchetti IP arbitrari significano costruire un sistema di rilevamento delle intrusioni (IDS) sicuro.
I nostri operatori di nodi ci dicono che le politiche di uscita sono una delle ragioni principali per cui sono disposti a utilizzare Tor.
L'aggiunta di un IDS per gestire le politiche di uscita aumenterebbe la complessità della sicurezza di Tor, e probabilmente non funzionerebbe comunque, come dimostrato dall'intero campo degli IDS e dei contro-IDS.
Molti potenziali problemi di abuso sono risolti dal fatto che Tor trasporta solo flussi TCP validi (al contrario di IP arbitrari che includono pacchetti malformati e IP flood).
Le politiche di uscita diventano ancora più importanti quando siamo in grado di trasportare pacchetti IP.
Abbiamo anche bisogno di descrivere in modo compatto le politiche di uscita nella directory Tor, in modo che i clienti possano prevedere quali nodi permetteranno ai loro pacchetti di uscire.
I client devono anche prevedere tutti i pacchetti che vorranno inviare in una sessione prima di scegliere il nodo di uscita!
Gli spazi dei nomi interni a Tor dovrebbero essere riprogettati.
Supportiamo gli indirizzi ".onion" dei servizi a cipolla intercettando gli indirizzi quando vengono passati al client Tor.
Fare ciò a livello IP richiederà un'interfaccia più complessa tra Tor e il resolver DNS locale.
