7. セキュリティに関する考慮事項

本節では SSM に関するセキュリティ上の問題を概説する. IPsec, サービス拒否攻撃, 送信元アドレスの偽装, 管理スコープに関するセキュリティ上の問題を扱う.

7.1. IPsec と SSM

受信者がマルチキャスト対応の IPsec 実装 ([RFC4301] で要求されるもの) を使用する場合, IPsec Authentication Header (AH) および Encapsulating Security Payload (ESP) を用いて SSM トラフィックを保護できる.

7.2. SSM と RFC 2401 IPsec の注意事項

[RFC4301] により置き換えられた RFC 2401 IPsec の既存実装には, SSM に関するいくつかの注意事項がある. RFC 2401 IPsec では SAD 検索のキーの一部として送信元アドレスを使用しない. その結果, 同じ SSM 宛先アドレスと同じ Security Parameter Index (SPI) を偶然使用する二つの送信者は, 両方のチャネルを受信する任意のホストの SAD で「衝突」する. チャネルアドレスと SPI はいずれも送信者が自律的に割り当てるため, 各送信者が一意の宛先アドレスまたは SPI を使用することを保証する合理的な方法はない.

受信者が, 送信元が偶然同じ IP 宛先アドレス (IPDA) と同じ IPsec SPI を使用している二つの無関係な IPsec チャネルを同時に購読すると問題が生じる. チャネル宛先アドレスは送信者が自律的に割り当てるため, 任意の二つのホストが同時に同じ宛先アドレスを使用でき, それを防ぐ合理的な方法はない. ただし <IPDA,SPI> タプルは通常ランダムに選択される 56 ビット (IP 宛先 24 ビットと SPI 32 ビット) から成るため, 偶然に衝突する可能性は低い.

このような衝突が起きると, 受信者は衝突した二つの送信元からの IPsec 保護トラフィックを同時に受信できない. 受信者は, 同じ SPI と同じ SSM 宛先アドレスを使用する二つの異なる送信元からトラフィックを受信していることにより, この状態を検出できる.

7.3. サービス拒否

購読要求は, 購読を記録するためルーターに (S,G) 状態を作成し, そのルーターで処理を実行させ, 隣接ルーターでも処理を発生させる可能性がある. ホストは多数の購読を要求することでサービス拒否攻撃を行える. 次の場合にサービス拒否が生じ得る.

• 本来不要な大量トラフィックが到着し, 配送のためのネットワークリソースと廃棄のためのホストリソースを消費する場合.

• ネットワークルーターに大量の Source-Specific Multicast 状態が作成され, 状態の保存と処理にルーターのメモリおよび CPU リソースを使用する場合.

• Source-Specific 状態の管理のために大量の制御トラフィックが生成され, ルーター CPU とネットワーク帯域幅を使用する場合.

このような攻撃による被害を減らすため, ルーターは例えば次の項目を制限する構成オプションを備えてもよい (MAY).

• 一つのインターフェース上のすべてのホストが購読を開始できる合計レート (偽装送信元アドレス攻撃による被害を制限するため).

• 一つのインターフェースまたはホストから開始できる購読の総数.

ただし将来のアプリケーションは多数のチャネルを使用する可能性があるため, 実装者が購読のレートまたは数を人為的に制限するかどうかは慎重に決定すべきである. チャネル購読のレートまたは数を厳しく制限すると, そのようなアプリケーションの展開を妨げる.

ルーターは, 購読要求の送信元が要求を受信したインターフェースにとって有効なアドレスであることを検証すべきである (SHOULD). 検証しないと, 偽装送信元アドレス攻撃を悪化させる.

これらの攻撃は SSM 固有ではなく, any-source multicast にも存在することに注意する.

7.4. 偽装された送信元アドレス

攻撃者はデータグラムの送信元アドレスを偽装することで, 別のホストに属するチャネル上でデータグラムを送信し, SSM サービスモデルに違反する可能性がある. したがって強い認証を必要とするアプリケーションは, 上位層の認証機構なしに, チャネルに到着するすべてのパケットが要求した送信元から送信されたと仮定すべきではない. 例えば IPSEC Authentication Header [RFC2401, RFC4301] を SSM 伝送の送信元認証に使用できる.

マルチキャストにおける偽装送信元アドレスへのある程度の保護は, すでにかなり普及している. 広く配備される IP マルチキャストルーティングプロトコル [PIM-DM, PIM-SM, DVMRP] が, マルチキャストパケットがその送信元アドレスに対して期待されるインターフェースから到着したことを検証する "reverse-path forwarding check" を組み込んでいるためである. SSM に使用するルーティングプロトコルもこのような検査を組み込むべきである (SHOULD).

送信元アドレス偽装と組み合わせた Source Routing [RFC791] (Loose と Strict の両方) は, 真のチャネル送信元になりすます者が SSM チャネルへパケットを注入できるようにする可能性がある. SSM ルーターは既定で SSM 宛先アドレスへの Source Routing を許可しないべきである (SHOULD). ルーターは Source Routing を許可する構成オプションを備えてもよい (MAY). ネットワークエッジでの送信元アドレスフィルタリングなど, 送信元アドレス偽装対策も強く推奨される.

7.5. 管理スコープ

管理スコープをセキュリティ対策として信頼すべきではない [ADMIN-SCOPE]. ただし, 場合によってはセキュリティ解決策の一部となる. IPv4 Source-Specific Multicast には管理スコープが存在しないことに注意する. 必要であれば, トラフィックフィルターを手動で構成してこのようなスコープを作る方法が代替となる.

さらに IPv6 では, 送信元アドレススコープも宛先アドレススコープもセキュリティ対策として使用すべきではない. 現在配備されている IPv6 ルーターの一部 ([SCOPINGv6] に準拠しないもの) では, スコープ境界が常にすべての送信元アドレスに適用されるとは限らない. 例えば実装がリンクローカルアドレスだけをフィルタリングし, ほかをフィルタリングしない場合がある. このようなルーターは, S に対するスコープ境界を越えて SSM チャネル (S,G) を誤って転送する可能性がある.