18. Security Considerations (セキュリティに関する考慮事項)

ICE システムでは、いくつかの種類の攻撃が可能です。このセクションでは、これらの攻撃とその対策について検討します。これらの対策には以下が含まれます。

• SIPS などの安全なシグナリング技術と組み合わせて ICE を使用する。

• 接続性チェックの総数を 100 に制限し、オプションでオファーまたはアンサーで受け入れる候補の数を制限する。

18.1. Attacks on Connectivity Checks (接続性チェックに対する攻撃)

攻撃者は、STUN 接続性チェックを妨害しようとする可能性があります。最終的に、これらの攻撃はすべて、エージェントをだまして接続性チェックの結果について何か間違ったことを考えさせます。攻撃者が試みて引き起こす可能性のある誤った結論は次のとおりです。

False Invalid (偽の無効): : 攻撃者は、エージェントのペアをだまして、候補ペアが無効であると実際にはそうではないのに思わせることができます。これを使用して、エージェントに別の候補（攻撃者が挿入した候補など）を優先させたり、すべての候補を強制的に失敗させて通話を妨害したりできます。

False Valid (偽の有効): : 攻撃者は、エージェントのペアをだまして、候補ペアが有効であると実際にはそうではないのに思わせることができます。これにより、エージェントはセッションを続行できますが、その後メディアを受信できなくなります。

False Peer Reflexive Candidate (偽のピア反射候補): : 攻撃者は、エージェントに新しいピア反射候補を発見させることができますが、そうすべきではありませんでした。これは、盗聴やその他の目的で、メディアストリームをサービス拒否（DoS）ターゲットまたは攻撃者にリダイレクトするために使用できます。

False Valid on False Candidate (偽の候補に対する偽の有効): : 攻撃者はすでにエージェントに、実際にはそのエージェントにルーティングされないアドレスを持つ候補があることを確信させています（たとえば、偽のピア反射候補または偽のサーバー反射候補を挿入することによって）。次に、エージェントにこの候補が有効であると信じ込ませる攻撃を開始する必要があります。

攻撃者が偽のピア反射候補または偽の候補に対する偽の有効を引き起こすことができる場合、[RFC5389] で説明されている攻撃のいずれかを開始できます。

偽の無効な結果を強制するために、攻撃者はエージェントの 1 つからの接続性チェックが送信されるのを待つ必要があります。送信された場合、攻撃者は 400 などの回復不可能なエラー応答を含む偽の応答を挿入する必要があります。ただし、候補は実際には有効であるため、元の要求はピアエージェントに到達し、成功応答が返される可能性があります。攻撃者は、DoS 攻撃、レイヤー 2 ネットワークの中断、またはその他の手法によって、このパケットまたはその応答を強制的にドロップさせる必要があります。そうしないと、成功応答も発信者に到達し、攻撃の可能性を警告します。幸いなことに、この攻撃は STUN 短期認証情報メカニズムによって完全に軽減されます。攻撃者は偽の応答を挿入する必要があり、この応答が処理されるためには、攻撃者はパスワードを必要とします。オファー/アンサーシグナリングが保護されている場合、攻撃者はパスワードを持っておらず、その応答は破棄されます。

偽の有効な結果を強制することも同様に機能します。エージェントは、各エージェントからの Binding 要求を待ち、偽の成功応答を挿入する必要があります。候補が無効な場合、おそらくとにかく受信されないため、攻撃者は実際の応答を妨害することを心配する必要はありません。ただし、偽の無効攻撃と同様に、この攻撃は、安全なオファー/アンサー交換と組み合わせた STUN 短期認証情報メカニズムによって軽減されます。

偽のピア反射候補の結果を強制することは、偽の要求または応答、あるいはリプレイのいずれかで行うことができます。最初に偽の要求と応答のケースを検討します。攻撃者は、偽の候補の送信元 IP アドレスとポートを使用して、1 つのエージェントに Binding 要求を送信する必要があります。さらに、攻撃者は他のエージェントからの Binding 要求を待ち、偽の候補を含む XOR-MAPPED-ADDRESS 属性を持つ偽の応答を生成する必要があります。ここで説明されている他の攻撃と同様に、この攻撃は STUN メッセージ整合性メカニズムと安全なオファー/アンサー交換によって軽減されます。

パケットリプレイで偽のピア反射候補の結果を強制することは異なります。攻撃者は、エージェントの 1 つがチェックを送信するまで待ちます。この要求を傍受し、偽装された送信元 IP アドレスを使用して他のエージェントに向けてリプレイします。また、DoS 攻撃を開始してパケットをドロップさせるか、レイヤー 2 メカニズムを使用して強制的にドロップさせることによって、元の要求がリモートエージェントに到達するのを防ぐ必要があります。リプレイされたパケットは他のエージェントで受信され、整合性チェックに合格するため受け入れられます（整合性チェックは送信元 IP アドレスとポートをカバーできず、カバーしません）。その後、応答されます。この応答には、偽の候補を含む XOR-MAPPED-ADDRESS が含まれ、その偽の候補に送信されます。攻撃者はそれを受信し、発信者に向けてリレーする必要があります。

その後、他のエージェントはその偽の候補に向けて接続性チェックを開始します。この検証は成功する必要があります。これには、攻撃者が偽の候補に対して偽の有効を強制する必要があります。この目標を達成するために偽の要求または応答を挿入することは、STUN およびオファー/アンサー交換の整合性メカニズムを使用して防止されます。したがって、この攻撃はリプレイを通じてのみ開始できます。これを行うには、攻撃者はこの偽の候補に向けたチェックを傍受し、他のエージェントに向けてリプレイする必要があります。次に、応答を傍受してリプレイバックする必要があります。

攻撃者が偽の候補によって識別されない限り、この攻撃を開始することは非常に困難です。これは、攻撃者が 2 つの異なるホストによって送信されたパケットを傍受してリプレイする必要があるためです。両方のエージェントが異なるネットワーク上にある場合（たとえば、パブリックインターネット全体）、この攻撃は、ネットワークの異なる部分にある 2 つの異なるエンドポイントに対して同時に発生する必要があるため、調整が難しい場合があります。

攻撃者自体が偽の候補によって識別される場合、攻撃の調整は容易になります。ただし、SRTP が使用されている場合 [RFC3711]、攻撃者はメディアパケットを再生できず、破棄することしかできず、通話のメディアストリームを事実上無効にします。ただし、この攻撃では、接続性チェックがターゲットに到達するのをブロックするために、エージェントがパケットを妨害する必要があります。その場合、目標がメディアストリームを妨害することである場合、ICE を攻撃するよりも、同じメカニズムで単に妨害する方がはるかに簡単です。

18.2. Attacks on Server Reflexive Address Gathering (サーバー反射アドレス収集に対する攻撃)

ICE エンドポイントは、STUN サーバーからサーバー反射候補を収集するために STUN Binding 要求を利用します。これらの要求はいかなる方法でも認証されません。その結果、攻撃者がクライアントに偽のサーバー反射候補を提供するために採用できる多数の手法があります。

• 攻撃者は DNS を侵害し、DNS クエリが不正な STUN サーバーアドレスを返すようにする可能性があります。そのサーバーは、クライアントに偽のサーバー反射候補を提供する可能性があります。この攻撃は DNS セキュリティによって軽減されますが、対処するために DNS-SEC は必要ありません。

• STUN メッセージを監視できる攻撃者（WiFi などの共有ネットワークセグメント上の攻撃者など）は、有効でクライアントに受け入れられる偽の応答を挿入できます。

• 攻撃者はウイルスによって STUN サーバーを侵害し、誤ったマップされたアドレスを持つ応答を送信させる可能性があります。

これらの攻撃によって学習された偽のマップされたアドレスは、ICE 交換でサーバー反射候補として使用されます。この候補が実際にメディアに使用されるためには、攻撃者は接続性チェックも攻撃し、特に偽の候補に対して偽の有効を強制する必要があります。偽のアドレスが第 4 者（オファー側、アンサー側、攻撃者のいずれでもない）を識別する場合、この攻撃を開始することは非常に困難です。セッション内の各エージェントによって生成されたチェックを攻撃する必要があり、攻撃者自身を識別する場合は SRTP によって防止されるためです。

攻撃者が接続性チェックを攻撃しないことを選択した場合、最悪の場合、サーバー反射候補の使用を防ぐことができます。ただし、ピアエージェントに攻撃を受けているエージェントが到達可能な候補が少なくとも 1 つある場合、STUN 接続性チェック自体が、メディアの交換に使用できるピア反射候補を提供します。ピア反射候補は一般に、サーバー反射候補よりも優先されます。そのため、STUN アドレス収集のみに対する攻撃は通常、セッションにまったく影響を与えません。

18.3. Attacks on Relayed Candidate Gathering (リレー候補収集に対する攻撃)

攻撃者はリレー候補の収集を妨害し、クライアントに偽のリレー候補があると信じ込ませようとする可能性があります。TURN サーバーとの交換は、長期的な認証情報を使用して認証されます。その結果、偽の応答または要求の挿入は機能しません。さらに、Binding 要求とは異なり、Allocate 要求は、送信元 IP アドレスとポートがクライアントにリレー候補を提供するために利用されないため、変更された送信元 IP アドレスとポートを使用したリプレイ攻撃の影響を受けません。

ただし、TURN サーバーは、DNS 攻撃や、ゾンビサーバーまたは不正なサーバーに変えることを目的とした TURN サーバーを標的としたウイルスの影響を受けやすくなっています。これらの攻撃は、DNS-SEC と、TURN サーバー上の優れたボックスおよびソフトウェアセキュリティによって軽減できます。

攻撃者がクライアントに偽のリレー候補を信じ込ませたとしても、接続性チェックにより、そのような候補は成功した場合にのみ使用されます。したがって、攻撃者は上記のように、偽の候補に対して偽の有効を開始する必要がありますが、これは調整が非常に難しい攻撃です。

18.4. Attacks on the Offer/Answer Exchanges (オファー/アンサー交換に対する攻撃)

オファー/アンサー交換自体を変更または妨害できる攻撃者は、ICE を使用してさまざまな攻撃を容易に開始できます。彼らはメディアを DoS 攻撃のターゲットに向けたり、メディアストリームに自分自身を挿入したりできます。これらは、オファー/アンサー交換の一般的なセキュリティに関する考慮事項に似ており、RFC 3264 [RFC3264] のセキュリティに関する考慮事項が適用されます。これらには、オファーとアンサーのメッセージの整合性と暗号化のための技術が必要であり、SIP が使用されている場合は SIPS メカニズム [RFC3261] によって満たされます。そのため、ICE での SIPS の使用は RECOMMENDED です。

18.5. Insider Attacks (内部者攻撃)

攻撃者が偽のオファー、アンサー、または stun メッセージを挿入しようとする第三者である攻撃に加えて、攻撃者が ICE 交換の認証された有効な参加者である場合、ICE でいくつかの攻撃が可能です。

18.5.1. The Voice Hammer Attack (ボイスハンマー攻撃)

ボイスハンマー攻撃は増幅攻撃です。この攻撃では、攻撃者は他のエージェントへのセッションを開始し、SDP でシグナリングされたメディアトラフィックの宛先として DoS ターゲットの IP アドレスとポートを悪意を持って含めます。これにより、大幅な増幅が発生します。単一のオファー/アンサー交換により、継続的なメディアパケットの洪水が発生する可能性があり、おそらく高いレートで発生します（ビデオソースを考慮してください）。この攻撃は ICE に固有のものではありませんが、ICE は修復を提供するのに役立ちます。

具体的には、ICE が使用されている場合、悪意のある SDP を受信したエージェントは、そこにメディアを送信する前に、まずメディアのターゲットに対して接続性チェックを実行します。このターゲットがサードパーティのホストである場合、チェックは成功せず、メディアは送信されません。

残念ながら、ICE が使用されていない場合、ICE は役に立ちません。その場合、攻撃者は ICE パラメータなしでオファーを送信するだけです。ただし、クライアントのセットがわかっており、ICE をサポートするものに限定されている環境では、サーバーは ICE サポートを示さないオファーまたはアンサーを拒否できます。

18.5.2. STUN Amplification Attack (STUN 増幅攻撃)

STUN 増幅攻撃はボイスハンマーに似ています。ただし、音声パケットがターゲットに向けられる代わりに、STUN 接続性チェックがターゲットに向けられます。攻撃者は、多数の候補（たとえば 50）を含むオファーを送信します。アンサー側はオファーを受信し、チェックを開始します。チェックはターゲットに向けられているため、応答は生成されません。アンサー側は、Ta ミリ秒ごとに新しい接続性チェックを開始します（たとえば、Ta=20ms）。ただし、候補の数が多いため、再送タイマーは大きな数に設定されます。その結果、パケットは Ta ミリ秒ごとに 1 つの間隔で送信され、その後間隔が長くなります。したがって、STUN はメディアが送信されるよりも速いレートでパケットを送信せず、STUN パケットはセッションの ICE が失敗するまで短時間しか持続しません。それにもかかわらず、これは増幅メカニズムです。

増幅を排除することは不可能ですが、さまざまなヒューリスティックによってボリュームを減らすことができます。エージェントは、実行する接続性チェックの総数を 100 に制限すべきです (SHOULD)。さらに、エージェントは、オファーまたはアンサーで受け入れる候補の数を制限してもかまいません (MAY)。

頻繁に、この種の攻撃を回避したいプロトコルは、次のメッセージを送信する前に開始に応答を待つことを強制します。ただし、ICE の場合、これは不可能です。次の 2 つのケースを区別することはできません。

• 開始者が応答しない無防備なターゲットに対して DoS 攻撃を開始するために使用されているため、応答がありませんでした。

• IP アドレスとポートが開始者によって到達できないため、応答がありませんでした。

2 番目のケースでは、次の機会に別のチェックを送信する必要がありますが、前者のケースでは、それ以上のチェックを送信すべきではありません。

18.6. Interactions with Application Layer Gateways and SIP (アプリケーション層ゲートウェイおよび SIP との相互作用)

アプリケーション層ゲートウェイ（ALG）は、アプリケーションプロトコルの NAT トラバーサルを容易にするために、パケットの内容を検査して変更する NAT デバイスに存在する機能です。セッションボーダーコントローラー（SBC）は ALG の近いいとこですが、実際にはアプリケーション層 SIP 仲介者として存在するため、透明性は低くなります。ICE は SBC および ALG と相互作用します。

ALG が SIP を認識しているが ICE を認識していない場合、ALG が SDP を正しく変更する限り、ICE はそれを介して機能します。正しい ALG 実装は次のように動作します。

• ALG は、m 行と c 行、または rtcp 属性に外部アドレスが含まれている場合、それらを変更しません。

• m 行と c 行に内部アドレスが含まれている場合、変更は ALG の状態によって異なります。

  ALG が、外部ポートを m 行と c 行または rtcp 属性の値と一致する内部 IP アドレスおよびポートにマッピングするバインディングをすでに確立している場合、ALG は新しいバインディングを作成する代わりにそのバインディングを使用します。

  ALG がまだバインディングを持っていない場合、新しいバインディングを作成し、SDP を変更して、m 行と c 行および rtcp 属性を書き換えます。

残念ながら、多くの ALG は、これらのコーナーケースではうまく機能しないことが知られています。ICE は壊れた ALG を回避しようとしません。これはその機能の範囲外だからです。ICE はこれらの状態を診断するのに役立ちます。これは、候補のセットと m 行と c 行および rtcp 属性の間の不一致として現れることがよくあります。ice-mismatch 属性は、この目的で使用されます。

シグナリングが TLS 上で実行される場合、ICE は ALG を介して最適に機能します。これにより、ALG が SDP メッセージを操作し、ICE 操作に干渉するのを防ぎます。ALG の背後に展開されることが予想される実装は、SDP の TLS トランスポートを提供すべきです (SHOULD)。

SBC が SIP を認識しているが ICE を認識していない場合、結果は SBC の動作によって異なります。適切な Back-to-Back User Agent（B2BUA）として機能している場合、SBC は ICE 属性を含む理解できない SDP 属性を削除します。その結果、通話は、相手側が ICE をサポートしていないかのように両方のエンドポイントに表示されます。これにより、ICE が無効になり、SBC が要求した場合、メディアが SBC を介して流れます。ただし、SBC が変更なしで ICE 属性を渡すが、メディアのデフォルトの宛先（m 行と c 行および rtcp 属性に含まれる）を変更する場合、これは ICE の不一致として検出され、通話の ICE 処理は中止されます。SBC を「回避する」ためのツールとして機能することは、ICE の範囲外です。SBC が存在する場合、ICE は使用されず、SBC 技術が優先されます。