22. IAB Considerations (IAB の考慮事項)

IAB は、「一方的な自己アドレス修復」（Unilateral Self-Address Fixing）の問題を研究してきました。これは、エージェントが協調プロトコル反射メカニズム [RFC3424] を介して NAT の反対側にある別のレルム内の自身のアドレスを決定しようとする一般的なプロセスです。ICE は、この種の機能を実行するプロトコルの例です。興味深いことに、ICE のプロセスは一方的ではなく双方向であり、その違いは IAB によって提起された問題に大きな影響を与えます。実際、ICE は UNSAF プロトコルではなく、B-SAF（双方向自己アドレス修復）プロトコルと見なすことができます。それにもかかわらず、IAB は、この目的のために開発されたすべてのプロトコルが特定の考慮事項のセットを文書化することを義務付けています。このセクションでは、これらの要件を満たしています。

22.1. Problem Definition (問題の定義)

RFC 3424 より、UNSAF の提案は以下を提供する必要があります。

UNSAF の提案で解決される特定の範囲限定の問題の正確な定義。短期的な修正を一般化して他の問題を解決するべきではありません。これが、「短期的な修正は通常そうではない」理由です。

ICE によって解決されている特定の問題は次のとおりです。

• 2 つのピアが通信に使用できるトランスポートアドレスのセットを決定する手段を提供する。

• エージェントが、通信したい別のピアから到達可能なアドレスを決定する手段を提供する。

22.2. Exit Strategy (出口戦略)

RFC 3424 より、UNSAF の提案は以下を提供する必要があります。

出口戦略/移行計画の説明。より良い短期的な修正とは、適切な技術が導入されるにつれて自然に使用が減少するものです。

ICE 自体は簡単には段階的に廃止されません。ただし、ルーターの障害によって接続が一時的に中断されたかどうかを検出する手段としてなど、世界的に接続されたインターネットでも役立ちます。ICE は、NAT とは関係のない特定のセキュリティ攻撃を防ぐのにも役立ちます。ただし、ICE が行うことは、他の UNSAF メカニズムの段階的な廃止を支援することです。ICE はそれらのメカニズムの中から効果的に選択し、より良いものを優先し、より悪いものの優先順位を下げます。ローカル IPv6 アドレスが優先される場合があります。IPv6 の導入に伴い NAT が解消され始めると、ネイティブホスト候補への優先順位の高い接続が存在するため、サーバー反射およびリレー候補（どちらも UNSAF アドレスの形式）は単に使用されなくなります。したがって、サーバーの使用はますます少なくなり、最終的に使用量がゼロになったときに削除できます。

実際、ICE は IPv4 から IPv6 への移行を支援できます。2 つのデュアルスタックホストが SIP で通信するときに、IPv6 と IPv4 のどちらを使用するか（IPv6 が使用される）を決定するために使用できます。また、6to4 とネイティブ v6 接続の両方を持つネットワークが、ピアと通信するときに使用するアドレスを決定できるようにすることもできます。

22.3. Brittleness Introduced by ICE (ICE によって導入された脆弱性)

RFC 3424 より、UNSAF の提案は以下を提供する必要があります。

システムをより「脆弱」にする可能性のある特定の問題についての議論。たとえば、複数のネットワーク層でデータを使用するアプローチは、依存関係を増やし、デバッグの課題を増やし、移行を困難にします。

ICE は実際、既存の UNSAF メカニズムから脆弱性を取り除きます。特に、従来の STUN（RFC 3489 [RFC3489] で説明されている）には、いくつかの脆弱な点があります。その 1 つは、エージェントが背後にある NAT の種類を分類しようとする必要がある検出プロセスです。このプロセスはエラーが発生しやすいです。ICE では、その検出プロセスは単に使用されません。アドレスの有効性を一方的に評価するのではなく、その有効性はピアへの接続を測定することによって動的に決定されます。接続を決定するプロセスは非常に堅牢です。

従来の STUN およびその他のあらゆる一方的なメカニズムにおけるもう 1 つの脆弱な点は、追加のサーバーへの絶対的な依存です。ICE は一方的なアドレスを割り当てるためにサーバーを使用しますが、可能であればエージェントが直接接続することを許可します。したがって、場合によっては、ICE が使用されている場合、STUN サーバーの障害が発生しても通話を続行できます。

従来の STUN におけるもう 1 つの脆弱な点は、STUN サーバーがパブリックインターネット上にあると想定していることです。興味深いことに、ICE ではその必要はありません。さまざまなアドレスレルムに多数の STUN サーバーが存在する可能性があります。ICE は、使用可能なアドレスを提供したサーバーを検出します。

従来の STUN における最も厄介な脆弱な点は、すべてのネットワークトポロジで機能するわけではないことです。各エージェントと STUN サーバーの間に共有 NAT がある場合、従来の STUN は機能しない可能性があります。ICE では、その制限は取り除かれます。

従来の STUN には、セキュリティ上の考慮事項もいくつか導入されています。幸いなことに、それらのセキュリティ上の考慮事項も ICE によって軽減されます。

その結果、ICE は従来の STUN で導入された脆弱性を修復する役割を果たし、システムに追加の脆弱性を導入することはありません。

これらの改善の代償として、ICE はセッション確立時間を増加させます。

22.4. Requirements for a Long-Term Solution (長期的な解決策の要件)

RFC 3424 より、UNSAF の提案は以下を提供する必要があります。

... 長期的で健全な技術的ソリューションの要件 -- 正しい長期的なソリューションを見つけるプロセスに貢献します。

RFC 3489 からの私たちの結論は変わりません。しかし、ICE は長期的な解決策の一部になり得ると信じているため、実際には役立つと感じています。

22.5. Issues with Existing NAPT Boxes (既存の NAPT ボックスの問題)

RFC 3424 より、UNSAF の提案は以下を提供する必要があります。

既存の展開されている NA[P]T で指摘された実際的な問題の影響と経験報告についての議論。

現在、「汎用」ALG 機能を提供しようとする多くの NAT ボックスが市場に展開されています。これらの汎用 ALG は、パケット内のテキスト形式またはバイナリ形式の IP アドレスを探し、バインディングと一致する場合はそれらを書き換えます。これは従来の STUN に干渉します。ただし、STUN の更新 [RFC5389] では、汎用 ALG からこれらのバイナリアドレスを隠すエンコーディングを使用しています。

既存の NAPT ボックスには、UDP ベースのバインディングに対して非決定論的で通常は短い有効期限があります。これには、実装が定期的なキープアライブを送信してそれらのバインディングを維持する必要があります。ICE はデフォルトの 15 秒を使用しますが、これは非常に保守的な見積もりです。最終的に、時間の経過とともに、NAT ボックスが behave [RFC4787] に準拠するようになると、この最小キープアライブは決定的で周知のものになり、ICE タイマーを調整できるようになります。最小キープアライブ間隔を検出して制御する方法があれば、さらに良いでしょう。