これはいくつかの理由で便利です。
Tor はVoIPのような新しいプロトコルに対応できるようになるでしょう。
アプリケーションをSOCKS化する必要性をすべて解決できるかもしれません。
出口リレー も、すべての出口接続に多くのファイル記述子を割り当てる必要はありません。
この方向に向かっています。難しい問題には次のようなものがあります。
IPパケットにはOSの特徴が現れます。
TCPフィンガープリント攻撃のようなものを防ぐためには、IPレベルのパケット正規化を行う必要があります。
TCPスタックの多様性と複雑さ、デバイスのフィンガープリント攻撃を考えると、私たちの最善策は、独自のユーザー空間TCPスタックを出荷することだと思われます。
アプリケーション・レベルのストリームでもスクラブが必要です。
Torbutton のようなユーザー側のアプリケーションがまだ必要です。
したがって、単にパケットをキャプチャしてIP層で匿名化すればいいという問題にはなりません。
一部のプロトコルは依然として情報を漏らします。
例えば、ユーザーの ISP の DNS サーバーではなく、リンクされていない DNS サーバーに配信されるように DNS 要求を書き換える必要があります。したがって、転送するプロトコルを理解する必要があります。
DTLS （Datagram TLS） は基本的にユーザーがおらず、IPsecは確かに大きいです。
転送メカニズムを選択したら、タグ付け攻撃やその他の潜在的な匿名性と整合性の問題を回避するために、新しいエンドツーエンドの Tor プロトコルを設計する必要があります。
任意のIPパケットに対する出口ポリシーは、安全な侵入検知システム（IDS）の構築を意味します。
私たちのノードオペレーターは、出口ポリシーが Tor を実行する主な理由の1つだと言っています。
出口ポリシーを処理するためにIDSを追加することは、Tor のセキュリティの複雑さを増大させ、いずれにしても機能しない可能性が高いことは、IDSおよび対IDS論文の全分野で証明されています。
Tor が有効なTCPストリームのみを転送するという事実によって、多くの潜在的な悪用問題が解決されます（不正なパケットやIPフラッドを含む任意のIPとは対照的です）。
出口ポリシーは、IPパケットを転送できるようになるとさらに重要になります。
また、クライアントがどのノードが自分のパケットの出口を許可するかを予測できるように、Tor ディレクトリーに出口ポリシーをコンパクトに記述する必要があります。
クライアントは、出口ノードを選択する前に、セッションで送信するすべてのパケットを予測する必要もあります！
Tor内部の名前空間を再設計する必要があります。
私たちは、Tor クライアントに渡されるアドレスを途中で留めることで、Onion Service の「.onion」アドレスをサポートしています。
IP レベルでこれを行うには、Tor とローカル DNS リゾルバーの間のより複雑なインタフェースが必要になります。