Appendix B. Design Motivations (設計の動機)

ICE には、それ自体は単純かもしれませんが、さらに議論に値する複雑または自明ではない考え方やユースケースに由来する多くの規範的な動作が含まれています。これらの設計の動機は実装の目的で理解する必要はないため、ここでは仕様の付録で説明します。このセクションは非規範的です。

B.1. Pacing of STUN Transactions (STUN トランザクションのペーシング)

候補を収集し、接続を確認するために使用される STUN トランザクションは、Ta ミリ秒ごとに 1 つの新しいトランザクションのおおよそのレートでペース配分されます。各トランザクションには、同様に Ta の関数である再送信タイマー RTO があります。なぜこれらのトランザクションはペース配分され、なぜこれらの式が使用されるのですか？

これらの STUN リクエストの送信は、多くの場合、クライアントと STUN サーバー間の NAT デバイスにバインディングを作成する効果があります。経験上、多くの NAT デバイスには、新しいバインディングを作成するレートに上限があることが示されています。実験では、20 ミリ秒に 1 回は十分にサポートされていますが、それよりはるかに低いレートはサポートされていないことが示されています。これが、Ta の下限が 20 ミリ秒である理由です。さらに、ネットワーク上でのこれらのパケットの送信は帯域幅を使用するため、エージェントによるレート制限が必要です。このドキュメントの以前のドラフトバージョンに基づく展開では、レート制約のあるアクセスリンクに過負荷がかかり、全体的にパフォーマンスが低下し、ネットワークに悪影響を与える傾向がありました。その結果、ペーシングにより、NAT デバイスが過負荷にならず、トラフィックが妥当なレートに保たれることが保証されます。

B.2. Candidates with Multiple Bases (複数のベースを持つ候補)

セクション 4.1.3 では、同じトランスポートアドレスとベースを持つ候補を排除することについて説明しています。ただし、同じトランスポートアドレスでベースが異なる候補は冗長ではありません。エージェントが、同じ IP アドレスとポートでベースが異なる 2 つの候補を持つことができるのはいつですか？

オファー側がマルチホームである場合を考えてみましょう。プライベートネットワーク C に 1 つの IP アドレスがあり、ネットワーク A に別の IP アドレスがあり、ネットワーク A はネットワーク B に NAT されています。オファー側は C でホスト候補を取得し、A でホスト候補を取得します。A から STUN クエリを実行します。これは NAT を通過し、C の IP:ポートとたまたま一致するバインディングが割り当てられます。これで、オファー側は、ホスト候補と同一のトランスポートアドレスを持つサーバー反射候補を取得しました。ただし、サーバー反射候補はホスト候補とは異なるベースを持っています。

B.3. Purpose of the <rel-addr> and <rel-port> Attributes (<rel-addr> および <rel-port> 属性の目的)

candidate 属性には、ICE 自体ではまったく使用されない 2 つの値 -- <rel-addr> と <rel-port> が含まれています。なぜ存在するのですか？

それを含める動機は 2 つあります。1 つ目は診断です。さまざまなタイプの候補間の関係を知ることは非常に役立ちます。それを含めることで、エージェントは、どのリレー候補がどの反射候補に関連付けられ、それが特定のホスト候補に関連付けられているかを知ることができます。ある候補のチェックが成功し、他の候補のチェックが成功しない場合、これはネットワークで何が起こっているかについての有用な診断を提供します。

2 つ目の理由は、オフパスの Quality of Service (QoS) メカニズムに関係しています。PacketCable 2.0 などの環境で ICE が使用される場合、プロキシは SDP を検査し、メディアトラフィックの IP アドレスとポートを抽出して、保証された QoS を確立します。リレー候補が選択されると、プロキシはアクセスルーターから QoS を要求するために、TURN サーバーに向かうサーバー反射候補を必要とします。SDP で変換を伝送することで、プロキシはそのトランスポートアドレスを使用できます。

B.4. Importance of the STUN Username (STUN ユーザー名の重要性)

ICE では、短期資格情報機能を使用した STUN でのメッセージ整合性の使用が必要です。実際の短期資格情報は、SDP オファー/アンサー交換でユーザー名フラグメントを交換することによって形成されます。このメカニズムの必要性は、単なるセキュリティを超えています。実際、そもそも ICE が正しく動作するために必要です。

重複するプライベートネットワーク内のエージェント L、R、および Z を考えてみましょう。L は Z にオファーを送信します。Z はホスト候補を提供します。R はたまたま Z と同じ IP:ポートを使用しています。L は STUN リクエストを送信しますが、これは Z ではなく R に送られます。R が単に応答した場合、L は Z への接続があると信じます。これを修正するために、STUN 短期資格情報メカニズムが使用されます。ユーザー名フラグメントは十分にランダムであるため、R が Z と同じ値を使用している可能性は非常に低いです。その結果、資格情報が無効であるため、R は STUN リクエストを拒否します。

B.5. The Candidate Pair Priority Formula (候補ペア優先順位の式)

候補ペアの優先順位は奇妙な形式をしています。それは次のとおりです。

pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

これはなぜですか？候補ペアがこの値に基づいてソートされると、結果のソートには MAX/MIN プロパティが含まれます。これは、ペアが最初に 2 つの優先順位の最小値の降順に基づいてソートされることを意味します。最小優先順位の値が同じペアの場合、それらの間でソートするために最大優先順位が使用されます。最大優先順位と最小優先順位が同じ場合、制御エージェントの優先順位がタイブレーカーとして使用されます。これにより、MAX/MIN ソートが作成されます。MAX/MIN は、特定のエージェントについて、すべての優先順位の高い候補が試されるまで、優先順位の低い候補が使用されないことを保証します。

B.6. The remote-candidates Attribute (remote-candidates 属性)

a=remote-candidates 属性は、更新されたオファーと、候補を有効リストに移動した STUN Binding リクエストへの応答との間の競合状態を排除するために存在します。この状態を排除するために、オファー側によって選択された R の実際の候補（リモート候補）がオファー自体に含まれ、アンサー側はそれらのペアが検証されるまでアンサーを遅延させます。

B.7. Why Are Keepalives Needed? (なぜキープアライブが必要なのですか？)

候補ペアでメディアが流れ始めると、セッションの間、中間の NAT でバインディングを維持する必要があります。通常、メディアストリームパケット自体がこの目的を達成します。ただし、メディアが保留になっている場合、または無音抑制が使用されている場合、メディア送信は NAT バインディングがタイムアウトするのに十分な時間停止する可能性があります。これらの理由から、メディアパケット自体に依存することはできません。ICE は、STUN Binding indication を利用した単純な周期的キープアライブを定義します。

B.8. Why Prefer Peer Reflexive Candidates? (なぜピア反射候補を優先するのですか？)

セクション 4.1.2 では、ピア反射候補のタイプ優先順位が常にサーバー反射よりも高い必要があるとされています。それはなぜですか？理由はセキュリティ上の考慮事項に関係しています。攻撃者がエージェントに偽のサーバー反射候補を使用させることは、攻撃者がエージェントに偽のピア反射候補を使用させることよりもはるかに簡単です。その結果、Binding リクエストによるアドレス収集に対する攻撃は、ピア反射候補を優先することによって ICE によって阻止されます。

B.9. Why Send an Updated Offer? (なぜ更新されたオファーを送信するのですか？)

両方のエージェントは、更新されたオファーを待たずに、ICE チェックが完了するとすぐにメディアを送信できます。実際、更新されたオファーの唯一の目的は、メディアのデフォルトの宛先が、ICE 手順に基づいてメディアが送信されている場所（これは最も優先順位の高い指名された候補ペアになります）と一致するように SDP を「修正」することです。

なぜ更新されたオファー/アンサー交換がそもそも必要なのですか？実際には、シグナリングパスに沿った多数のコンポーネントが SDP 情報を調べます（たとえば、QoS、NAT トラバーサル、診断のため）。これらのツールが変更なしで機能し続けるには、SDP のコアプロパティ（メディアに使用されるアドレスの既存の ICE 前の定義）を保持する必要があります。このため、更新されたオファーを送信する必要があります。

B.10. Why Are Binding Indications Used for Keepalives? (なぜ Binding Indication がキープアライブに使用されるのですか？)

主な理由は、ネットワーク QoS メカニズムに関係しています。エージェントがメディアパケットを送信していて、Binding リクエストを受信した場合、メディアパケットとともに応答パケットを生成する必要があります。これにより、実際の帯域幅要件が増加し、ジッターが発生します。Binding Indication を使用すると、整合性を無効にすることができ、パフォーマンスが向上します。

B.11. Why Is the Conflict Resolution Mechanism Needed? (なぜ競合解決メカニズムが必要なのですか？)

両方のエージェントが制御されていると信じている状態は、サードパーティのコール制御ケースに現れます。たとえば、コントローラーはエージェント A にオファーなしの INVITE を送信し、エージェント A はオファーで応答します。次に、コントローラーはエージェント B にオファーなしの INVITE を送信し、エージェント B はオファーで応答します。コントローラーはオファーを使用してアンサーを生成します。このフローが使用されると、ICE はエージェント A と B の間で実行されますが、両方とも制御役割にあると信じます。役割の競合解決手順を使用すると、このフローは適切に機能します。