これはいくつかの理由で便利です。
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 Flood を含む任意の IP とは対照的です) 。
出口ポリシーは、IP パケットを転送できるようになるとさらに重要になります。
また、クライアントがどのノードが自分のパケットの出口を許可するかを予測できるように、Tor ディレクトリーに出口ポリシーをコンパクトに記述する必要があります。
クライアントは、出口ノードを選択する前に、セッションで送信するすべてのパケットを予測する必要もあります！
Tor 内部の名前空間を再設計する必要があります。
私たちは、Tor クライアントに渡されるアドレスを途中で留めることで、Onion Service の「.onion」アドレスをサポートしています。
IP レベルでこれを行うには、Tor とローカル DNS リゾルバーの間のより複雑なインタフェースが必要になります。