これはいくつかの理由で便利です。
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 リゾルバーの間のより複雑なインタフェースが必要になります。
いいえ、ネットワークを信頼して回線を選択することはできません。
悪意のあるリレーは、共謀したリレーを介してあなたの活動を結びつけることができます。
これにより、敵対者はすべてのトラフィックを端から端まで監視できるようになります。
すべての Tor ユーザーにリレーを要求することは、すべてのユーザーを処理するためのネットワークの拡張に役立つでしょうし、Tor リレーを実行することはあなたの匿名性を高めるかもしれません。
ただし、多くの Tor ユーザーは中継に適していません。例えば、一部の Tor クライアントは制限のあるファイアウォールの内側から動作しているか、モデム経由で接続しているか、またはトラフィックを中継できる位置にいません。
多くの Tor ユーザーがこれらの制約や類似の制約を受けており、これらのクライアントを含めると匿名性セットのサイズが大きくなるため、これらのクライアントへのサービスを提供することは、すべての人に効果的な匿名性を提供する上で重要な役割を果たします。
とはいえ、Tor ユーザーにリレーの実行を奨励したいので、本当にやりたいことは、リレーのセットアップとメンテナンスのプロセスを簡素化することです。
ここ数年で、簡単な設定ができるようになりました。Tor は接続可能かどうかと、どれだけの帯域幅を提供できるかを自動的に検出するのが得意です。
しかし、その前に4つのステップに取り組む必要があります。
第一に、許容できる適切な帯域幅を自動的に推定する能力を向上させる必要があります。
UDPトランスポートへの切り替え が最も簡単な答えかもしれませんが、残念ながら、これはまったく簡単な答えではありません。
第二に、ネットワーク (すべての Tor リレーがすべての Tor リレーに接続できることを要求しない方法) とディレクトリ (すべての Tor ユーザがすべての Tor リレーについて知っていることを要求しない方法) の両方のスケーラビリティに取り組む必要があります。
このような変更は、潜在的な匿名性と実際の匿名性に大きな影響を与える可能性があります。
詳細につきましては、課題のセクション5をご覧ください。
ここでもUDPトランスポートが役に立ちます。
第三に、匿名化されたトラフィックを開始している間に、攻撃者がリレーを介してトラフィックを送信することによるリスクをよりよく理解する必要があります。
3つの 異なる 論文 は、トラフィックをリレー候補に通し、回線がアクティブな間にトラフィックの落ち込みを探すことによって、回線内のリレーを特定する方法を記述しています。
Tor の環境では、リレーがクライアントでもない限り、このような詰まり攻撃はそれほど恐ろしいものではありません。
しかし、（ブリッジリレー または通常のリレーとして）リレー機能も有効にするように、より多くのクライアントを奨励しようとしている場合は、この脅威をよりよく理解し、軽減する方法を学ぶ必要があります。
第四に、他の人のためにトラフィックを中継したり、出口ノードになったりすることを奨励するために、何らかのインセンティブスキームが必要になるかもしれません。
Tor のインセンティブについての現在の考えはこちら。
これらすべてを手伝ってください！
サイトがカバーできるすべてのIPアドレス空間を知ることを要求する （そして、それらのIPアドレスで他のサイトもブロックする）のではなく、中継オペレーターが出口ポリシーでreject www.slashdot.orgなどと言えるようにすると良いでしょう。
しかし、2つの問題があります。
まず、ユーザーはこれらのブロックを回避することができます。
例えば、Tor ネットワークからの終了時にホスト名ではなくIPアドレスを要求できます。
つまり、オペレーターは問題の宛先のすべてのIPアドレスを学習する必要があります。
2つ目の問題は、リモートの攻撃者が任意のサイトを検閲できるようになることです。
例えば、Tor オペレーターが www 1.slashdot.org をブロックした後、攻撃者が Tor リレーの DNS をポイズニングしたり、ホスト名を変更して主要なニュースサイトのIPアドレスに解決したりすると、その Tor リレーは突然ニュースサイトをブロックします。
