この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、IPマルチキャストネットワークインフラストラクチャを保護するためのベストプラクティスに関する一般的なガイダンスについて説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
このドキュメントでは、基本的な概念と用語について説明し、次のトピックについて説明します。
IPマルチキャストには、2つの従来のサービスモデルがあります。
1. 任意の送信元マルチキャスト(ASM)
2. Source Specific Multicast(SSM)
ASMでは、受信者はInternet Group Membership Protocol(IGMP)またはMulticast Listener Discovery(MLD)メンバーシップレポートを介してグループGに参加し、グループを示します。このレポートは、任意の送信元からグループGに送信されるトラフィックを要求します。したがって、「任意の送信元」という名前が付けられます。 これに対して、SSMでは、受信側は発信元Sによって定義された特定のチャネルに参加し、発信元はグループGに送信します。これらの各サービスモデルについて詳しく説明します。
ASMモデルの特徴は、次の2つのクラスのプロトコルです。「dense mode flood-and-prune」と「sparse mode explicit join」。
i)デンスモードのフラッドアンドプルーンプロトコル(DVMRP/MOSPF/PIM-DM)
稠密モードプロトコルでは、ネットワーク内のすべてのルータがすべてのツリーとその送信元および受信側を認識します。Distance Vector Multicast Routing Protocol(DVMRP)やProtocol Independent Multicast(PIM)デンスモードなどのプロトコルは、ネットワーク全体に「アクティブな送信元」情報をフラッディングし、特定のツリーのトラフィックが不要なトポロジ部分に「プルーニング状態」を作成することで、ツリーを構築します。フラッドアンドプルーニングプロトコルとも呼ばれる。マルチキャストOpen Shortest Path First(MOSPF)では、ツリーの構築をサポートするために、レシーバに関する情報がネットワーク全体にフラッディングされます。
ネットワークの一部に組み込まれたすべてのツリーによって、ネットワーク内のすべてのルータ(設定されている場合は管理スコープ内)で(コンバージェンスの影響を受けて)リソースの使用率が常に発生する可能性があるため、高密度モードプロトコルは望ましくありません。これらのプロトコルについては、この記事の後半では詳しく説明しません。
(ロ)スパースモードExplicit Join Protocols(PIM-SM/PIM-BiDir)
スパースモードの明示的な加入プロトコルでは、受信側がグループに対する明示的なIGMP/MLDメンバーシップレポート(または「加入」)を送信しない限り、デバイスはネットワーク内にグループ固有の状態を作成しません。このASMのバリエーションは拡張性が高いことで知られており、マルチキャストパラダイムに焦点を当てています。
これがPIMスパースモードの基盤であり、これまではほとんどのマルチキャスト導入で使用されていました。これは双方向PIM(PIM-BiDir)の基盤でもあり、MANY(送信元)からMANY(受信者)のアプリケーションに対して導入される傾向が高まっています。
これらのプロトコルは、「スパース」レシーバ群を持つIPマルチキャスト配信ツリーを効率的にサポートし、送信元とレシーバ間のパスにあるルータ上と、ランデブーポイント(RP)であるPIM-SM/BiDir上でのみコントロールプレーンステートを作成するため、スパースモードと呼ばれます。ネットワークの他の部分でステートを作成することはありません。ルータ内のステートは、ダウンストリームルータまたはレシーバから参加を受信した場合にのみ明示的に構築されるため、「明示的な参加プロトコル」という名前が付けられます。
PIM-SMとPIM-BiDirはどちらも「共有ツリー」を採用しており、任意の送信元からのトラフィックを受信側に転送できます。共有ツリーのマルチキャスト状態は(*,G)状態と呼ばれ、*はANY SOURCEのワイルドカードです。また、PIM-SMは、特定の送信元からのトラフィックに関連する状態の作成をサポートします。これらはソースツリーと呼ばれ、関連付けられた状態は(S,G)状態と呼ばれます。
SSMは、受信側(または一部のプロキシ)が(S、G)を「join」して、送信元SからグループGに送信されたトラフィックを受信することを示すときに使用されるモデルです。これは、IGMPv3/MLDv2の「INCLUDE」モードメンバーシップレポートで可能です。このモデルは、Source-Specific Multicast(SSM)モデルと呼ばれます。SSMでは、ルータ間での明示的参加プロトコルの使用が義務付けられています。これに対する標準プロトコルはPIM-SSMで、これは(S,G)ツリーの作成に使用されるPIM-SMのサブセットにすぎません。SSMには共有ツリー(*,G)状態はありません。
これにより、マルチキャスト受信側はASMグループGに「参加」したり、SSM(S,G)チャネルに「参加」(またはより正確に「サブスクライブ」)したりできます。「ASMグループまたはSSMチャネル」という用語の繰り返しを避けるために、(マルチキャスト)フローという用語が使用されます。これは、フローがASMグループまたはSSMチャネルのいずれかであることを意味します。
マルチキャストネットワークを保護するには、一般的に発生するパケットの種類と、それらから保護する方法を理解することが重要です。3つの主要なプロトコルに注意する必要があります。
1. IGMP/MLD
2.PIM
3.MSDP
次のセクションでは、これらの各プロトコルと、各プロトコルで発生する可能性のある問題について説明します。
IGMP/MLDは、マルチキャスト受信側が、特定のマルチキャストグループのコンテンツを受信するようにルータに信号を送信するために使用するプロトコルです。Internet Group Membership Protocol(IGMP)はIPv4で使用されるプロトコルで、Multicast Listener Discovery(MLD)はIPv6で使用されるプロトコルです。
IGMPには、IGMPv2とIGMPv3の2つのバージョンが一般的に導入されています。また、一般的に展開されるMLDには、MLDv1とMLDv2の2つのバージョンがあります。
IGMPv2とMLDv1は機能的に同等であり、IGMPv3とMLDv2は機能的に同等です。
これらのプロトコルは、次のリンクで指定されています。
IGMPv2:RFC 2236
MLDv1:RFC 3590
IGMPv3およびMLDv2:RFC 4604
IGMPv2とIGMPv3はプロトコルであるだけでなく、IPv4 IPプロトコル(具体的にはプロトコル番号2)でもあります。これらのRFCで説明されているように、マルチキャストグループメンバーシップの報告に使用されるだけでなく、DVMRP、PIMバージョン1、mtrace、mrinfoなどの他のIPv4マルチキャストプロトコルでも使用されます。IGMPのフィルタリングを(Cisco IOS® ACLなどを使用して)試みる際に、注意が必要です。IPv6では、MLDはIPv6プロトコルではありません。代わりに、ICMPv6を使用してMLDパケットが伝送されます。PIMバージョン2は、IPv4とIPv6(プロトコル番号103)で同じプロトコルタイプです。
このセクションでは、マルチキャストおよびユニキャストPIM制御パケットについて説明します。Auto-RPとブートストラップルータ(BSR)(PIM-SMネットワークでランデブーポイントを選択し、グループ間の割り当てを制御する方法)について説明します。
マルチキャストPIM制御パケットには次のものがあります。
ユニキャストPIM制御パケットは、RPに送信されるか、RPから送信され、次の内容が含まれます。
図1:PIMユニキャストパケット
これらのパケットはユニキャストであるため、このようなパケットを悪用する攻撃は、任意の場所から発生する可能性があります。
Auto-RPは、PIMv2 BSRと同じ目的で動作するシスコが開発したプロトコルです。Auto-RPはBSRよりも前に開発されており、IPv4のみをサポートしています。BSRはIPv4とIPv6をサポートします。Auto-RPのMapping Agentは、BSRのブートストラップルータと同じ機能を果たします。BSRでは、C-RPからのメッセージはブートストラップルータへのユニキャストです。Auto-RPでは、メッセージはマルチキャストを介してMapping Agentに送信されます。これにより、後述するように、境界でのフィルタが容易になります。Auto-RPについては、次のリンクで詳しく説明します。http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html
Cisco IOSでは、AutoRP/BSRパケットは常に転送され、現在は無効にされていません。これは、Auto-RPの場合、特定のセキュリティ上の問題を引き起こす可能性があります。
図2:Auto-RPパケット
注:自動RPはPIM-SM RPアナウンスおよびディスカバリのメカニズムとして使用されていますが、PIMパケット(IPプロトコル103)を使用せず、代わりにマルチキャストアドレスでユーザデータグラムプロトコル(UDP)ポート496パケットを使用します。
?Auto-RPでは、次の2種類のパケットが使用されます。
C-RP-Announceパケット:これらのパケットはすべてのマッピングエージェントに対してマルチキャストであり、Internet Assigned Numbers Authority(IANA)によって予約された「既知」のアドレス(224.0.1.39)を使用します。これらはC-RPから送信され、RPアドレスと、RPがRPとして動作できるグループ範囲をアナウンスします。
C-RPディスカバリパケット:これらのパケットはすべてのPIMルータへのマルチキャストであり、IANAによって予約された「既知」のアドレス(224.0.1.40)を使用します。これらは、特定のグループ範囲のRPとして選択された特定のC-RPをアナウンスするために、Auto-RP Mapping Agentによって送信されます。
これらのパケットタイプはそれぞれ、ネットワークを介してフラッディングされることを目的としています。
Cisco IOSでは、PIMデンスモードで224.0.1.39と224.0.1.40の両方が転送されます。これは、グループがRP情報の配信に使用される際に、そのグループのRPに関する事前情報がないという問題を回避するためです。これは、PIMデンスモードの唯一の推奨される使用方法です。
Cisco IOS XRでは、Auto-RPメッセージは、Reverse Path Forwarding(RPF;リバースパス転送)によってネイバーからネイバーにホップ単位でフラッディングされます。したがって、Cisco IOS XRでAuto-RPをサポートするためにPIM DM mroute状態を作成する必要はありません。実際、Cisco IOS XRはPIM-DMをまったくサポートしていません。
MSDPは、あるドメイン内の送信元をそれぞれのランデブーポイントを介して別のドメイン内の受信者にアナウンスできるようにするIPv4プロトコルです。MSDPはRFC 3618で指定されています。
PIMドメイン間でアクティブな送信元に関する情報を共有するには、MSDPが使用されます。あるドメインで送信元がアクティブになった場合、MSDPによってすべてのピアドメインがこの新しい送信元についてタイムリーに学習されるため、他のドメインの受信者が、受信者が関心を持っているグループに送信した場合でも、この新しい送信元に迅速に連絡できます。MSDPはASM/PIM-SMマルチキャスト通信に必要で、各ドメインのランデブーポイント(RP)間に設定されたユニキャストTransport Control Protocol(TCP)接続上で実行されます。
このセクションは、ネットワーク内の機能エンティティ別にまとめられています。ここで説明する脅威モデルは、これらのエンティティを中心に形成されています。たとえば、このドキュメントでは、ルータの導入場所に関係なく、マルチキャストネットワーク内のルータを(マルチキャストの観点から)保護する方法について説明します。同様に、ネットワーク全体のセキュリティ対策、または代表ルータやランデブーポイントでの対策の展開方法についても考慮する必要があります
ここで説明する脅威もこのロジックに従い、ネットワーク内の論理機能別に編成されます。
抽象的なレベルでは、あらゆるマルチキャスト展開が、セキュリティのさまざまな側面に関する多くの脅威の対象となる可能性があります。セキュリティの重要な側面は、機密性、整合性、および可用性です。
機密保持に対する脅威:ほとんどのアプリケーションでは、マルチキャストトラフィックは暗号化されないため、パス内の任意の回線またはネットワーク要素で受信またはキャプチャを行う任意のユーザに対してオープンです。「GET VPN」の項では、このような攻撃を防ぐためにマルチキャストトラフィックを暗号化する方法について説明しています。
トラフィック整合性に対する脅威:アプリケーションレベルのセキュリティやネットワークベースのセキュリティ(GET VPNなど)を使用しないと、マルチキャストトラフィックは送信中に変更される可能性があります。これは、OSPF、PIM、その他多数のプロトコルなど、マルチキャストを使用するコントロールプレーントラフィックにとって特に重要です。
ネットワーク整合性に対する脅威:このドキュメントで説明されているセキュリティメカニズムがないと、許可されていない送信者、受信者、またはネットワーク要素がマルチキャストネットワークにアクセスしたり、許可されていないトラフィックの送受信(サービスの盗難)を行ったり、ネットワークリソースを過負荷状態にする可能性があります。
アベイラビリティに対する脅威:正規のユーザがリソースを使用できないようにするために、サービス拒否攻撃が数多く発生する可能性があります。
次のセクションでは、ネットワーク内の各論理機能の脅威について説明します。
ルータに対する基本的な脅威は数多く存在します。これらの脅威は、ルータがマルチキャストをサポートするかどうか、および攻撃がマルチキャストトラフィックとプロトコルのどちらを対象とするのかには関係ありません。
サービス拒否(DoS)攻撃は、ネットワークにおける最も重要な一般的な攻撃です。原則として、すべてのネットワーク要素がDoS攻撃の対象となる可能性があります。これにより要素が過負荷状態になり、正当なユーザに対するサービスが失われたり低下したりする可能性があります。ユニキャストに適用される基本的なネットワークセキュリティの推奨事項に従うことは、最も重要です。
注目すべき点は、マルチキャスト攻撃は必ずしも意図的なものではなく、多くの場合偶発的なものであることです。たとえば、2004年3月に初めて観察されたウィッティワームは、IPアドレスに対するランダムな攻撃を通じて広がったワームの一例です。アドレス空間が完全にランダム化された結果、マルチキャストIPの宛先もこのワームの影響を受けました。多くの組織では、ワームが多数の異なるマルチキャスト宛先アドレスにパケットを送信したため、多数のファーストホップルータが集約されました。しかし、ルータは、関連するステートの作成によるマルチキャストトラフィックの負荷の範囲を特定できず、リソースの枯渇が発生しました。これは、マルチキャストが企業で使用されていない場合でも、マルチキャストトラフィックを保護する必要性を示しています。
ルータに対する一般的な脅威には次のものがあります。
ルータでマルチキャストが有効になっている場合は、ユニキャストに加えてマルチキャストも保護する必要があります。IPマルチキャストを使用しても、基本的な脅威モデルは変わりませんが、攻撃の対象となる可能性のある追加プロトコル(PIM、IGMP、MLD、MSDP)を有効にするので、これを明確に保護する必要があります。これらのプロトコルでユニキャストトラフィックが使用されている場合、脅威モデルはルータによって実行される他のプロトコルと同じです。
マルチキャストトラフィックは、ルータを攻撃するユニキャストトラフィックと同じ方法で使用できないことに注意してください。これは、マルチキャストトラフィックは基本的に「レシーバ駆動」であり、リモート宛先を対象とすることができないためです。攻撃ターゲットは、マルチキャストストリームに明示的に「参加」する必要があります。ほとんどの場合(Auto-RPが主な例外)、ルータは「リンクローカル」マルチキャストトラフィックのみをリッスンして受信します。リンクローカルトラフィックは転送されません。したがって、マルチキャストパケットを使用したルータへの攻撃は、直接接続された攻撃者からのみ発生する可能性があります。
マルチキャストソース(PCまたはビデオサーバのいずれもネットワークと同じ管理制御下にない場合があります)。したがって、送信側は、ネットワークオペレータの観点からは、ほとんどの場合、信頼できないと見なされます。PCやサーバの強力な機能と、それらが持つ複雑なセキュリティ設定は不完全であることが多いため、送信側はマルチキャストを含むあらゆるネットワークに対して重大な脅威を与えます。脅威には次のようなものがあります。
注:通常、ホストはPIMパケットを送受信しません。これを行うホストは、攻撃を試みる可能性があります。
また、レシーバは通常、CPUパワーと帯域幅が大きいプラットフォームであり、さまざまな攻撃形態に対応できます。これらは送信側の脅威とほとんど同じです。レイヤ2攻撃は、依然として重要な攻撃ベクトルです。偽のレシーバとサービスの盗難は、受信側でも発生する可能性があります。ただし、攻撃ベクトルは通常、IGMP(または前述のようにレイヤ2攻撃)です。
PIM-SM RPおよびPIM-BSRはマルチキャストネットワークの重要なポイントであり、攻撃者にとって重要なターゲットです。どちらのルータもファーストホップルータでない場合は、PIMユニキャストを含むユニキャスト攻撃フォームのみを、これらの要素に対して直接標的にすることができます。RPとBSRに対する脅威には次のものがあります。
図3のトポロジを考えてみます。このトポロジでは、送信元、3つのレシーバ(A、B、C)、スイッチ(S1)、および2つのルータ(R1とR2)が示されています。青い線はユニキャストストリームを表し、赤い線はマルチキャストストリームを表します。3つのレシーバはすべてマルチキャストフローのメンバーです。
図3:ルータとスイッチでの複製
特定の送信元から特定の受信者へのトラフィックフローを禁止するには、次の手順を実行します。
この項は、ASMとSSMの両方のサービスモデルに適用されます。これらのサービスモデルでは、トラフィックは受信側の明示的なjoinの受信に基づいて転送されます。
ユニキャストストリームの場合、暗黙の受信者保護はありません。ユニキャスト送信元は、宛先がトラフィックを要求していない場合でも、その宛先にトラフィックを送信できます。そのため、エンドポイントを保護するために、ファイアウォールなどの防御メカニズムが通常使用されます。一方、マルチキャストには、プロトコルに組み込まれた暗黙的な保護機能があります。トラフィックは、問題のフローに参加している受信者だけに到達するのが理想的です。
ASMを使用すると、送信元は、アクティブなRPでサポートされている任意のグループへのマルチキャストトラフィック伝送を通じて、トラフィックの挿入またはDoS攻撃を開始できます。このトラフィックは理想的には受信側には到達しませんが、少なくともパス内のファーストホップルータだけでなくRPにも到達できるため、限定的な攻撃が可能です。ただし、悪意のある送信元がターゲットレシーバが対象とするグループを知っていて、適切なフィルタが配置されていない場合、そのグループにトラフィックを送信できます。このトラフィックは、レシーバがグループをリッスンしている限り受信されます。
SSMでは、受信側がその(S,G)チャネルに参加していない場合、トラフィックが停止するファーストホップルータでのみ、望ましくない送信元による攻撃が可能です。これは、受信側からの明示的な参加状態が存在しないSSMトラフィックをすべて破棄するため、ファーストホップルータに状態攻撃を引き起こすことはありません。このモデルでは、「結合」はソース固有であるため、悪意のあるソースがターゲットが対象とするグループを知るだけでは不十分です。この場合、スプーフィングされたIP送信元アドレスに加えて、ルーティング攻撃の可能性が必要になります。
レシーバがネットワークに存在しない場合でも、PIM-SMは送信元に最も近いファーストホップルータとランデブーポイントに(S、G)および(*、G)状態を作成します。したがって、発信元ファーストホップルータのネットワークとPIM-SM RPで状態攻撃が発生する可能性があります。
悪意のある送信元が複数のグループにトラフィックを送信し始めた場合、RP設定で問題のグループが許可されていれば、検出されたグループごとに、ネットワーク内のルータが送信元とRPでステートを作成します。
したがって、PIM-SMは、送信元による状態およびトラフィック攻撃の対象となります。送信元IPアドレスが正しいプレフィクスの範囲内でランダムに変更された場合、つまりアドレスのホストビットのみがスプーフィングされた場合、この攻撃は悪化する可能性があります。
図4:ASM RP攻撃
PIM-SSMと同様に、送信元からのPIM-BiDir状態生成攻撃は不可能です。PIM-BiDir内のトラフィックは、RPに転送されるトラフィックだけでなく、レシーバからのJoinによって作成された状態でも転送されるため、RPの背後にあるレシーバに到達できます。これは、JoinがRPのみに到達するためです。RPにトラフィックを転送するステートは(*,G/M)ステートと呼ばれ、RP設定(スタティック、Auto-RP、BSR)によって作成されます。送信元の存在下では変更されません。したがって、攻撃者はPIM-BiDir RPにマルチキャストトラフィックを送信できますが、PIM-SMとは異なり、PIM-BiDir RPは「アクティブ」なエンティティではなく、PIM-BiDirグループのトラフィックを転送または廃棄するだけです。
注:一部のCisco IOSプラットフォーム(*,G/M)では、状態はサポートされていません。このような場合、送信元は複数のPIM-BiDirグループにマルチキャストトラフィックを送信することでルータを攻撃し、(*,G)状態を作成する可能性があります。たとえば、Catalyst 6500スイッチは(*,G/M)状態をサポートしています。
攻撃はマルチキャスト受信側から発生する可能性があります。通常、IGMP/MLDレポートを送信する受信側は、ファーストホップルータでステートを作成します。ユニキャストには、これに相当するメカニズムはありません。
図5:受信側の明示的なJoinベースのトラフィック転送
受信側の攻撃には、次の3つのタイプがあります。
次のセクション「マルチキャストネットワーク内のセキュリティ」では、これらの種類の攻撃を軽減するさまざまな方法について説明します。
セキュリティは重要な機能ではなく、すべてのネットワーク設計に組み込まれている機能です。そのため、ネットワークのすべてのポイントでセキュリティを考慮する必要があります。すべてのネットワーク要素を適切に保護することが最も重要です。あらゆるテクノロジーに適用できる攻撃シナリオの1つに、侵入者によって破壊されたルータがあります。侵入者がルータを制御できるようになると、攻撃者はさまざまな攻撃シナリオを実行できるようになります。したがって、各ネットワーク要素は、あらゆる形態の基本攻撃および特定のマルチキャスト攻撃に対して適切に保護する必要があります。
注:Catalyst 9000シリーズスイッチなどの特定のプラットフォームでは、CoPPがデフォルトで有効になっており、この保護は置き換えられていません。 詳細については、『CoPPガイド』を参照してください。
実稼働中のネットワークでrACLまたはCoPPを調整、変更、または作成する場合は、注意が必要です。どちらの機能もコントロールプレーンへのすべてのトラフィックをフィルタリングできるため、必要なすべてのコントロールプレーンプロトコルと管理プレーンプロトコルを明示的に許可する必要があります。必要なプロトコルのリストは大きく、Terminal Access Controller Access Control System(TACACS)など、あまり目立たないプロトコルも見逃しやすい場合があります。デフォルト以外のすべてのrACLおよびCoPPの設定は、実稼働ネットワークに導入する前に、必ずラボ環境でテストする必要があります。さらに、初期導入は「許可」ポリシーだけで開始する必要があります。これにより、ACLヒットカウンタを使用した予期しないヒットの検証が可能になります。
マルチキャスト環境では、マルチキャストが正常に機能するために、必要なマルチキャストプロトコル(PIM、MSDP、IGMPなど)がrACLまたはCoPPで許可されている必要があります。PIM-SMシナリオでは、送信元からのマルチキャストストリームの最初のパケットがコントロールプレーンパケットとして使用され、デバイスのコントロールプレーンまでマルチキャスト状態が作成されることに注意してください。そのため、rACLまたはCoPPで関連するマルチキャストグループを許可することが重要です。プラットフォーム固有の例外が多数あるため、導入前に関連ドキュメントを参照し、計画されている設定をテストすることが重要です。
Cisco IOS XRでは、Local Packet Transport Service(LPTS)は、Cisco IOSのCoPPと同様に、ルータのコントロールプレーンへのトラフィックのポリサーとして機能します。また、ユニキャストおよびマルチキャストトラフィックを含む受信トラフィックをフィルタリングし、レート制限を行うことができます。
マルチキャスト対応ネットワークでは、各ネットワーク要素はマルチキャスト固有のセキュリティ機能で保護する必要があります。このセクションでは、一般的なルータ保護について説明します。すべてのルータに必要な機能ではありませんが、ネットワークの特定の場所にのみ必要な機能、およびルータ間のインタラクションが必要な機能(PIM認証など)については、次のセクションで説明します。
ip multicast route-limit <mroute-limit> <warning-threshold>
図6: Mrouteの制限
mroute制限により、マルチキャストルーティングテーブルに入ることを許可されるmrouteの数にしきい値を設定できます。マルチキャストルートの制限が有効になっている場合、設定されている制限を超えるマルチキャスト状態は作成されません。警告のしきい値もあります。mrouteの数が警告しきい値を超えると、syslog警告メッセージがトリガーされます。mrouteの制限では、ステートを引き起こすその他のパケットは廃棄されます。
ip multicast route-limitコマンドは、MVRFごとに利用することもできます。
SAPリッスンの無効化:no ip sap listen
sap listenコマンドを使用すると、ルータはSession Announcement Protocol/Session Description Protocol(SAP/SDP)メッセージを受信します。SAP/SDPは、マルチキャストバックボーン(MBONE)の時代から存在するレガシープロトコルです。これらのメッセージは、将来または現時点で利用可能なマルチキャストコンテンツに関するディレクトリ情報を示します。これは、ルータのCPUおよびメモリリソースに対するDoSの原因となる可能性があるため、この機能を無効にする必要があります。
mrinfo情報へのアクセスの制御:「ip multicast mrinfo-filter」コマンド
mrinfoコマンド(Cisco IOSと一部のバージョンのMicrosoft WindowsおよびLinuxで使用可能)は、さまざまなメッセージを使用してマルチキャストルータに情報を照会します。ip multicast mrinfo-filterグローバルコンフィギュレーションコマンドを使用して、この情報へのアクセスを一部の送信元に制限するか、まとめて無効にすることができます。
次の例では、192.168.1.1から送信されたクエリーを拒否し、その他のソースからのクエリーは許可します。
ip multicast mrinfo-filter 51 access-list 51 deny 192.168.1.1 access-list 51 permit any
次の例では、すべての送信元からのmrinfo要求を拒否しています。
ip multicast mrinfo-filter 52 access-list 52 deny any
注:他のACLと同様、deny はパケットがフィルタ処理されることを意味し、permitはパケットが許可されることを意味します。
mrinfoコマンドが診断目的で使用される場合、適切なACLを使用してip multicast mrinfo-filterコマンドを設定し、送信元アドレスのサブセットからのクエリーのみを許可することを強く推奨します。mrinfoコマンドによって提供される情報は、SNMPを介して取得することもできます。mrinfo要求の完全なブロック(デバイスのクエリからのすべてのソースをブロックする)を強く推奨します。
ip multicast group-range <std-acl> ipv6 multicast group-range <std-acl>
ACLによって拒否されたグループのいずれかに対してパケットが現れると、PIM、IGMP、MLD、MSDPを含むすべての制御プロトコルで廃棄され、データプレーンでも廃棄されます。したがって、これらのグループ範囲に対してIGMP/MLDキャッシュエントリ、PIM、Multicast Routing Information Base(RIB;マルチキャストルーティング情報ベース)/Multicast Forwarding Information Base(MRIB/MFIB;マルチキャスト転送情報ベース)状態が作成されず、すべてのデータパケットが即座に廃棄されます。
これらのコマンドは、デバイスのグローバルコンフィギュレーションで入力します。
ネットワーク外から発信されるすべてのマルチキャストトラフィックが制御されるように、このコマンドをネットワーク内のすべてのルータに、使用可能な場合は可能な場所で展開することを推奨します。これらのコマンドは、データプレーンとコントロールプレーンに影響することに注意してください。このコマンドは、標準ACLよりもカバレッジが広く、使用できる場合は優先されます。
PIMネイバー関係を確立するには、PIMルータがPIM Helloを受信する必要があります。PIMネイバーシップは、代表ルータ(DR)選出、DRフェールオーバー、およびPIM Join/Prune/Assertメッセージの送受信の基盤でもあります。
図7:PIMネイバー制御
不要なネイバーを禁止するには、図7に示されているip pim neighbor-filterコマンドを使用します。このコマンドは、Hello、Join/Pruneパケット、およびBSRパケットを含む、許可されていないすべてのネイバーPIMパケットからフィルタリングします。セグメント上のホストは、送信元IPアドレスをスプーフィングして、PIMネイバーであるかのように見せかけることがあります。セグメントでの送信元アドレスのスプーフィングを防ぐにはレイヤ2セキュリティメカニズム(IPソースガード)が必要で、ホストからのPIMパケットを防ぐにはアクセススイッチでVLAN ACLを使用します。キーワード「log-input」をACLで使用すると、ACEに一致するパケットをログに記録できます。
PIM Join/PruneパケットはPIMネイバーに送信され、そのネイバーを特定の(S,G)パスまたは(*,G)パスに追加または削除します。PIMマルチキャストパケットは、存続可能時間(TTL)=1で送信されるリンクローカルマルチキャストパケットです。これらのパケットはすべて、既知の全PIMルータアドレス224.0.0.13に対するマルチキャストです。つまり、このような攻撃はすべて、攻撃を受けたルータと同じサブネットから発生する必要があります。攻撃には、偽造されたHello、Join/Prune、およびAssertパケットが含まれます。
注:PIMマルチキャストパケットのTTL値を人為的に1より大きい値に増やしたり調整したりしても、問題は発生しません。All-PIM-Routersアドレスは常にルータでローカルに受信され、処理されます。通常のルータや正規のルータから直接転送されることはありません。
?PIM-SM登録メッセージのフラッディングからRPを保護するには、DRでこれらのメッセージをレート制限する必要があります。ip pim register-rate-limitコマンドを使用します。
ip pim register-rate-limit <count>
図8:PIM-SMレジスタトンネル制御
PIMユニキャストパケットを使用してRPを攻撃できます。そのため、RPはインフラストラクチャACLによってこのような攻撃から保護できます。マルチキャストの送信側と受信側はPIMパケットを送信する必要がないため、PIMプロトコル(IPプロトコル103)は通常、サブスクライバエッジでフィルタリングできます。
自動RP制御 – RPアナウンスフィルタ
ip pim rp-announce filter コマンドは、可能な場合はAuto-RPで設定できる追加のセキュリティ対策です。
ip pim rp-announce-filter
これは、どのルータがどのグループ範囲/グループモードの候補RPとして受け入れられるかを制御するために、マッピングエージェントで設定できます。
図9:Auto-RP - RPアナウンスフィルタ
Auto-RP制御 – Auto-RPメッセージの制限
multicast boundaryコマンドを使用して、AutoRPパケット、RP-announce(224.0.1.39)またはRP-discover(224.0.1.40)を特定のPIMドメインに制限します。
ip multicast boundary <std-acl>
access-list 1 deny 224.0.1.39
access-list 1 deny 224.0.1.40
224.0.1.39 (RP-announce) 224.0.1.40 (RP-discover)
図10:マルチキャスト境界コマンド
BSRコントロール – BSRメッセージの制約
PIMドメインの境界でBSRメッセージをフィルタリングするには、ip pim bsr-border コマンドを使用します。BSRメッセージはリンクローカルマルチキャストによってホップバイホップで転送されるため、ACLは必要ありません。
図11:BSR境界
この最後のセクションでは、PIM-SPおよびRPコントロールプレーンパケットに対するフィルタ、およびAuto-RP、BSR、MSDPメッセージについて説明します。
図12に、アドレススコープと組み合わせたAuto-RPフィルタの例を示します。領域をバインドする2つの異なる方法が示されています。Auto-RPの観点からは、2つのACLは同等です。
図12:Auto-RPフィルタ/スコープ
Auto-RPのインターフェイス境界フィルタの目的は、Auto-RPアナウンスがサポートするリージョンにのみ確実に到達するようにすることです。地域、会社、およびインターネット全体のスコープが定義され、それぞれのスコープにRPとAuto-RPアドバタイズメントがあります。管理者は、リージョナルRPがリージョナルルータに認識されること、企業RPがリージョナルおよび企業ルータに認識されること、およびインターネットRPがグローバルに使用可能であることを望んでいます。スコープのレベルを上げることができます。
図に示すように、Auto-RPパケットをフィルタリングするには、2つの根本的な方法があります。インターネット境界によってAuto-RP制御グループ(224.0.1.39と224.0.1.40)が明示的に呼び出され、その結果、すべてのAuto-RPパケットがフィルタリングされます。この方法は、Auto-RPパケットが通過しない管理ドメインのエッジで使用できます。領域境界では、filter-auto-rpキーワードを使用して、Auto-RPパケット内のrpからグループ範囲へのアナウンスメントを調査します。アナウンスメントがACLによって明示的に拒否されている場合は、パケットが転送される前にAuto-RPパケットから削除されます。この例では、エンタープライズ全体のRPがリージョン内で認識されますが、リージョン全体のRPはリージョンからエンタープライズの残りの部分までの境界でフィルタリングされます。
この例では、ISP1がPIM-SM中継プロバイダーとして機能します。ネイバーとのMSDPピアリングのみをサポートし、(S、G)トラフィックのみを受け入れ、(*、G)トラフィックは境界ルータでは受け入れません。
ドメイン間(通常は自律システム間)では、次の2つの基本的なセキュリティ対策を講じる必要があります。
図13は、ISP1の境界ルータの1つでインターフェイスフィルタを設定する例を示しています。
multicast boundaryコマンドを使用して、「host 0.0.0.0」および管理スコープアドレスに対するフィルタによってドメイン境界のインヒビット(*,G)結合でデータプレーンを保護するには、次の手順を実行します。
図13:ドメイン間(*,G)フィルタ
コントロールプレーンを保護するには、次の3つの基本的なセキュリティ対策によってMSDPを強化します。
1) MSDP SAフィルタ
これは、MSDP SAフィルタを使用してMSDPメッセージの内容をフィルタリングする「ベストプラクティス」です。このフィルタの主な目的は、インターネット全体のアプリケーションではなく、送信元ドメインを越えて転送する必要のないアプリケーションやグループに対して、マルチキャスト状態が伝搬されないようにすることです。理想的には、セキュリティの観点から、フィルタは既知のグループ(および潜在的な送信者)のみを許可し、未知の送信者やグループを拒否します。
通常、許可されたすべての送信者またはグループ(あるいはその両方)を明示的にリストすることはできません。グループごとに1つのRPがある(MSDPメッシュグループがない)PIM-SMドメインに対しては、デフォルトの設定フィルタを使用することをお勧めします。
!--- Filter MSDP SA-messages. !--- Replicate the following two rules for every external MSDP peer. ! ip msdp sa-filter in <peer_address> list 111 ip msdp sa-filter out <peer_address> list 111 ! !--- The redistribution rule is independent of peers. ! ip msdp redistribute list 111 ! !--- ACL to control SA-messages originated, forwarded. ! !--- Domain-local applications. access-list 111 deny ip any host 224.0.2.2 ! access-list 111 deny ip any host 224.0.1.3 ! Rwhod access-list 111 deny ip any host 224.0.1.24 ! Microsoft-ds access-list 111 deny ip any host 224.0.1.22 ! SVRLOC access-list 111 deny ip any host 224.0.1.2 ! SGI-Dogfight access-list 111 deny ip any host 224.0.1.35 ! SVRLOC-DA access-list 111 deny ip any host 224.0.1.60 ! hp-device-disc !--- Auto-RP groups. access-list 111 deny ip any host 224.0.1.39 access-list 111 deny ip any host 224.0.1.40 !--- Scoped groups. access-list 111 deny ip any 239.0.0.0 0.255.255.255 !--- Loopback, private addresses (RFC 6761). access-list 111 deny ip 10.0.0.0 0.255.255.255 any access-list 111 deny ip 127.0.0.0 0.255.255.255 any access-list 111 deny ip 172.16.0.0 0.15.255.255 any access-list 111 deny ip 192.168.0.0 0.0.255.255 any !--- Default SSM-range. Do not do MSDP in this range. access-list 111 deny ip any 232.0.0.0 0.255.255.255 access-list 111 permit ip any any !
可能な限り厳密に、インバウンドとアウトバウンドの両方向でフィルタリングすることを推奨します。
MSDP SAフィルタの推奨事項の詳細については、https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13717-49.htmlを参照してください。
2) MSDP状態の制限
複数の自律システム(AS)間でMSDPを有効にする場合は、ネイバーから「Source-Active」(SA)メッセージを受信するため、ルータに組み込まれる状態の量を制限することをお勧めします。ip msdp sa-limitコマンドを使用できます。
ip msdp sa-limit <peer> <limit>
図14:MSDPコントロールプレーン
ip msdp sa-limitコマンドを使用すると、MSDPピアから受け入れられたSAメッセージによって作成されたSA状態の数を制限できます。いくつかの簡単な経験則に基づく推奨事項を次に示します。
3) MSDP MD5ネイバー認証
MSDPピアでメッセージダイジェストアルゴリズム(MD5)パスワード認証を使用することをお勧めします。これは、BGPを保護するためのRFC 6691で説明されている使用と同等のTCP MD5シグニチャオプションを使用します。
図15:MSDP MD5ネイバー認証
次の3つのMSDPセキュリティの推奨事項は、異なる目標を追求しています。
送信側に起因するマルチキャストセキュリティの問題の多くは、適切なユニキャストセキュリティメカニズムによって軽減できます。推奨されるベストプラクティスは、次のユニキャストセキュリティメカニズムの数です。
このような対策は、コアへの標的型攻撃をブロックするために使用できます。これは、たとえば、RPへのPIMユニキャストパケットを使用した攻撃(ネットワークの「内部」であるためインフラストラクチャACLによって保護される)などの問題も解決します。
図16に示す例では、フィルタはファーストホップマルチキャストルータ(代表ルータ)のLANインターフェイス(E0)に設定されています。フィルタは、「source」と呼ばれる拡張アクセスコントロールリスト(ACL)によって定義されます。このACLは、送信元LANに接続されている代表ルータ(DR)の送信元インターフェイスに適用されます。実際、マルチキャストトラフィックの性質により、送信元がアクティブになる可能性のあるすべてのLAN側インターフェイスで同様のフィルタを設定する必要があります。送信元アクティビティが発生する場所を正確に把握することは不可能であるため、このようなフィルタをネットワークへのすべての入力ポイントに適用することを推奨します。
図16:制御ソース
このフィルタの目的は、特定の送信元アドレスまたは送信元アドレスの範囲から特定のグループまたはグループアドレスの範囲へのトラフィックを防止することです。このフィルタは、PIMがルートを作成する前に機能し、ステートの制限に役立ちます。
これは標準データプレーンACLです。これはハイエンドプラットフォームのASICに実装され、パフォーマンスの低下は発生しません。データプレーンACLは、不要なトラフィックによるコントロールプレーンへの影響を最小限に抑えるため、直接接続された送信元に対しては、コントロールプレーンよりも推奨されます。また、パケットの送信先となる宛先(IPマルチキャストグループアドレス)を制限することも非常に効果的です。これはルータコマンドであるため、スプーフィングされた送信元IPアドレスを克服することはできません(このセクションの前半を参照)。したがって、追加のレイヤ2(L2)メカニズムを提供するか、特定のローカルエリアネットワーク/仮想ローカルエリアネットワーク(LAN/VLAN)に接続できるすべてのデバイスに対して一貫したポリシーを提供することを推奨します。
注:ACLの「log」キーワードは、特定のACLエントリに対するヒットを理解するのに非常に便利です。ただし、このキーワードはCPUリソースを消費するため、慎重に処理する必要があります。また、ハードウェアベースのプラットフォームでは、ACLログメッセージはCPUによって生成されるため、CPUへの影響を考慮する必要があります。
?セキュリティの観点から見たASM/PIM-SMアーキテクチャの実際の利点の1つは、ランデブーポイント(RP)があらゆるグループ範囲のネットワーク内のすべての送信元に対して単一の制御ポイントを提供することです。これは、accept-register filterと呼ばれるデバイスで利用できます。このフィルタのコマンドは次のとおりです。
ip pim accept-register / ipv6 pim accept-register
図17:PIM-SMソース制御
PIM-SMネットワークでは、このコマンドで不要なトラフィックの送信元を制御できます。送信元トラフィックがファーストホップルータに到達すると、ファーストホップルータ(DR)は(S,G)状態を作成し、PIMソースレジスタメッセージをRPに送信します。送信元がaccept-registerフィルタリスト(RPで設定)にリストされていない場合、RPは登録を拒否し、即座にRegister-StopメッセージをDRに送り返します。
この例では、送信元アドレスだけをフィルタリングする単純なACLがRPに適用されています。RPで拡張ACLを使用して、送信元とグループをフィルタリングすることもできます。
送信元フィルタには欠点があります。これは、RPでpim accept-registerコマンドを使用した場合でも、送信元のファーストホップルータでPIM-SM(S,G)ステートが作成されるためです。その結果、送信元に対してローカルであり、送信元とRPの間に存在するレシーバでトラフィックが発生する可能性があります。さらに、pim accept-registerコマンドは、RPのコントロールプレーンで動作します。これは、偽の登録メッセージでRPをオーバーロードするために使用される可能性があり、DoS状態を引き起こす可能性があります。
pim accept-registerコマンドは、その他の方法(すべてのDR上での単純なデータプレーンACLの適用など)に加えて、ネットワークへのすべての入力点でRP上で適用することを推奨します。 完全に設定され運用されているネットワークではDRの入力ACLで十分ですが、エッジルータで設定ミスが発生した場合のセカンダリセキュリティメカニズムとして、RPでpim accept-registerコマンドを設定することを推奨いたします。同じ目標を持つ階層化されたセキュリティメカニズムは「多層防御」と呼ばれ、セキュリティの一般的な設計原則です。
ほとんどのレシーバの問題は、IGMP/MLDレシーバプロトコルの相互作用の領域に分類されます。
図18:制御IGMP
IGMPまたはMLDパケットがフィルタリングされる場合は、次の点に注意してください。
IGMPプロセスは、IPマルチキャストがイネーブルにされると同時に、デフォルトでイネーブルになります。IGMPパケットは次のプロトコルも伝送します。したがって、マルチキャストがイネーブルになっている場合は常に、次のプロトコルがすべてイネーブルになります。
詳細については、「IANAのインターネットグループ管理プロトコル(IGMP)タイプ番号」を参照してください。
Router> mtrace 172.16.0.0 172.16.0.10 239.254.254.254 Type escape sequence to abort. Mtrace from 172.16.0.0 to 172.16.0.10 via group 239.254.254.254 From source (?) to destination (?) Querying full reverse path... 0 172.16.0.10 -1 172.16.0.8 PIM thresh^ 0 0 ms -2 172.16.0.6 PIM thresh^ 0 2 ms -3 172.16.0.5 PIM thresh^ 0 894 ms -4 172.16.0.3 PIM thresh^ 0 893 ms -5 172.16.0.2 PIM thresh^ 0 894 ms -6 172.16.0.1 PIM thresh^ 0 893 ms
ユニキャストIGMPパケット(IGMP/UDLR用)は、攻撃パケットである可能性が高く、有効なIGMPプロトコルパケットではないため、フィルタリングできます。ユニキャストIGMPパケットは、単方向リンクおよびその他の例外条件をサポートするために、Cisco IOSでサポートされています。
偽造されたIGMP/MLDクエリーパケットは、予想よりも低いIGMPバージョンになる可能性があります。
特に、ホストはIGMPクエリを送信しないことが理想的です。これは、低いIGMPバージョンで送信されたクエリによって、このクエリを受信したすべてのホストが低いバージョンに戻る可能性があるためです。IGMPv3/SSMホストの存在下では、SSMストリームを「攻撃」できます。IGMPv2の場合は、この結果、長いリーブ遅延が発生する可能性があります。
単一のIGMPクエリアを持つ非冗長LANが存在する場合、ルータは受信したIGMPクエリをドロップする必要があります。
冗長または共通のパッシブLANが存在する場合は、IGMPスヌーピングが可能なスイッチが必要です。この場合に役立つ特定の機能が2つあります。
ルータガード
スイッチがそのポートでマルチキャストルータ制御パケット(IGMP一般クエリー、PIM Hello、またはCGMP Hello)を受信すると、すべてのスイッチポートがマルチキャストルータポートになる可能性があります。スイッチポートがマルチキャストルータポートになると、すべてのマルチキャストトラフィックがそのポートに送信されます。これは「ルータガード」で防ぐことができます。ルータガード機能では、IGMPスヌーピングをイネーブルにする必要はありません。
ルータガード機能を使用すると、指定したポートをマルチキャストホストポートに指定できます。マルチキャストルータ制御パケットを受信しても、ポートはルータポートになりません。
これらのパケットタイプは、ルータガードが有効になっているポートで受信されると廃棄されます。
これらのパケットが廃棄されると、ルータガードによってパケットが廃棄されたことを示す統計情報が更新されます。
IGMPの最小バージョン
許可するIGMPホストの最小バージョンを設定できます。たとえば、すべてのIGMPv1ホストまたはすべてのIGMPv1およびIGMPv2ホストを拒否できます。このフィルタは、メンバシップレポートにのみ適用されます。
ホストが共通の「パッシブ」LAN(IGMPスヌーピングをサポートしないスイッチや、そのスイッチ用に設定されていないスイッチなど)に接続されている場合、このような誤ったクエリに対してルータができることは、トリガーされる「古いバージョン」のメンバシップレポートを無視すること以外にありません。このメンバシップレポートは自分自身にフォールバックしません。
IGMPクエリはすべてのホストから可視である必要があるため、「有効なルータ」からのIGMPクエリを認証するために、スタティックキーIPSecなどの事前共有キーとハッシュベースのメッセージ認証(HMAC)メカニズムを使用することはできません。2つ以上のルータが共通のLANセグメントに接続されている場合、IGMPクエリアを選択する必要があります。この場合、使用できる唯一のフィルタは、クエリーを送信する他のIGMPルータの送信元IPアドレスに基づくip access-groupフィルタです。
「通常の」マルチキャストIGMPパケットが許可される必要があります。
このフィルタを受信側ポートで使用すると、「正常な」IGMPパケットだけを許可し、既知の「不良」IGMPパケットをフィルタリングできます。
ip access-list extended igmp-control <snip> deny igmp any any pim ! No PIMv1 deny igmp any any dvmrp ! No DVMRP packets deny igmp any any host-query ! Do not use this command with redundant routers. ! In that case this packet type is required ! permit igmp any host 224.0.0.22 ! IGMPv3 membership reports permit igmp any any 14 ! Mtrace responses permit igmp any any 15 ! Mtrace queries permit igmp any 224.0.0.0 10.255.255.255 host-query ! IGMPv1/v2/v3 queries permit igmp any 224.0.0.0 10.255.255.255 host-report ! IGMPv1/v2 reports permit igmp any 224.0.0.0 10.255.255.255 7 ! IGMPv2 leave messages deny igmp any any ! Implicitly deny unicast IGMP here!
<snip> permit ip any any ! Permit other packets interface ethernet 0 ip access-group igmp-control in
注:このタイプのIGMPフィルタは、受信ACLまたはCoPPで使用できます。どちらのアプリケーションでも、ルーティングや管理プレーンプロトコルなど、処理される他のトラフィックのフィルタと組み合わせる必要があります。
図19:ホスト受信側のアクセス制御
受信側へのトラフィックをフィルタリングするには、データプレーントラフィックではなく、コントロールプレーンプロトコルIGMPをフィルタリングします。IGMPはマルチキャストトラフィックを受信するために必要な前提条件であるため、データプレーンフィルタは必要ありません。
特に、受信側が参加できる(コマンドが設定されているインターフェイスに接続される)マルチキャストフローを制限できます。この場合は、ip igmp access-group / ipv6 mld access-group コマンドを使用します。
ip igmp access-group / ipv6 mld access-group
ASMグループの場合、このコマンドは宛先アドレスに基づいてのみフィルタします。その後、ACLの送信元IPアドレスは無視されます。IGMPv3/MLDv2を使用するSSMグループでは、送信元と宛先のIPでフィルタリングを行います。
次の例では、すべてのIGMPスピーカに対して特定のグループをフィルタリングします。
access-list 1 deny 226.1.0.0 0.0.255.255
access-list 1 permit any log
!
interface ethernet 1/3
ip igmp access-group 1
次の例では、特定のグループの特定のIGMPスピーカ(したがって、特定のマルチキャストレシーバ)をフィルタリングします。
ip access-list extended test5 deny igmp host 10.4.4.4 host 232.2.30.30 permit igmp any any ! interface Ethernet0/3 ip igmp access-group test5
注意: ASMグループの場合、ソースは無視されます。
?アクセスコントロールは、ネットワークの状態に関係なく、特定のフローに対してバイナリ、yes、またはnoのいずれかの応答を提供します。コントラストによるアドミッション制御は、送信者/受信者がアクセス制御メカニズムを通過したと仮定して、使用できるリソースの数を制限します。マルチキャスト環境でのアドミッション制御に役立つさまざまなデバイスが用意されています。
対象となるマルチキャスト受信側に最も近いルータでは、グローバルに、またはインターフェイスごとに、参加するIGMPグループの数を制限できます。ip igmp limit/ipv6 mld limitコマンドを使用できます。
ip igmp limit <n> [ except <ext-acl> ] ipv6 mld limit <n> [ except <ext-acl> ]
この制限は、常にインターフェイス単位で、またグローバルに設定することを推奨します。いずれの場合も、この制限はIGMPキャッシュ内のエントリ数を指します。
次の2つの例は、このコマンドを使用して、家庭用ブロードバンドネットワークのエッジでグループ数を制限する方法を示しています。
例1:受信したグループをSDRアナウンスと1つの受信チャネルだけに制限する
セッションディレクトリ(SDR)は、一部のマルチキャスト受信者に対するチャネルガイドとして機能します。詳細は、RFC 2327を参照してください。
一般的な要件として、SDグループと1つのチャネルを受信するようにレシーバを制限することが挙げられます。次の設定例を使用できます。
ip access-list extended channel-guides permit ip any host 239.255.255.254 ! SDR announcements deny ip any any ip igmp limit 1 except channel-guides interface ethernet 0 ip igmp limit 2 except channel-guides
この例のアクセスリストでは、チャネルガイドだけが指定されています。グローバルip igmp limitコマンドでは、各IGMPソースが単一の(1)チャネルに制限されますが、常に受信可能なチャネルガイドは含まれません。interfaceコマンドはグローバルコマンドを上書きし、このインターフェイスでチャネルガイドに加えて2つのチャネルの受信を許可します。
例2:アグリゲーションDSLAMリンクのアドミッション制御
このコマンドは、帯域幅アドミッション制御の形式を提供するためにも使用できます。たとえば、それぞれ4 Mbpsの300のSDTVチャネルを分散する必要があり、Digital-Subscriber-Line-Access-Multiplexer(DSLAM;デジタル加入者線アクセスマルチプレクサ)への1 Gbpsのリンクがある場合は、ポリシーを決定してTV帯域幅を500 Mbpsに制限し、残りはインターネット用などに残すことができます。この場合、IGMPの状態を500 Mbps/4 Mbps = 125 IGMPの状態に制限できます。
この設定は、次の場合に使用できます。
図20インターフェイスごとのIGMP制限の使用、Agg-DSLAMリンクでのアドミッション制御
ip multicast limit [ rpf | out | connected ] <ext-acl> <max>
状態は、入出力インターフェイスで個別に制限できます。直接接続された送信元の状態は、「connected」キーワードを使用して制限することもできます。次に、このコマンドの使用例を示します。
例1:Agg-DSLAMリンクでの出力アドミッション制御
この例では、300のSD TVチャネルがあります。各SDチャネルに4 Mbpsが必要で、合計が500 Mbps以下であると仮定します。最後に、Basic、Extended、およびPremiumバンドルのサポートが必要であると仮定します。帯域幅割り当ての例:
チャネルごとに4 Mbpsを使用し、DSLAMアップリンクを次のように制限します。
PEAggからDSLAMに面する発信インターフェイスの制限を設定します。
図21:インターフェイスごとのmroute制限の使用、Agg-DSLAMリンクでのアドミッション制御
例2:Agg-DSLAMリンクでの入力アドミッション制御
アップストリームデバイスの発信インターフェイスでの「out」制限の代わりに、ダウンストリームデバイスのRPFインターフェイスでRPF制限を使用できます。これは実質的に前の例と同じ結果になり、ダウンストリームデバイスがCisco IOSデバイスでない場合に役立つ可能性があります。
図22:インターフェイスごとのmroute制限の使用;入力アドミッション制御
例3 – 帯域幅ベースの制限
複数のコンテンツプロバイダー間のアクセス帯域幅をさらに分割し、各コンテンツプロバイダーにDSLAMへのアップリンクの帯域幅の公平な割り当てを提供できます。この場合は、ip multicast limit costコマンドを使用します。
ip multicast limit cost <ext-acl> <multiplier>
このコマンドを使用すると、ipマルチキャストの制限の拡張ACLに一致する任意の状態に「コスト」(「乗数」で指定した値を使用)を関連付けることができます。
このコマンドはグローバルコマンドで、複数の同時コストを設定できます。
この例では、3つの異なるコンテンツプロバイダーをサポートし、それぞれにネットワークへの公平なアクセスを提供する必要があります。さらに、この例では、さまざまなタイプのMoving Picture Experts Group(MPEG)ストリームをサポートする必要があります。
MPEG2 SDTV:4 Mbps
MPEG2 HDTV:18Mbps
MPEG4 SDTV:1.6Mbps
MPEG4 HDTV:6 Mbps
この場合、次の設定を使用して、各ストリームタイプに帯域幅コストを割り当て、残りの750Mbpsを3つのコンテンツプロバイダー間で共有できます。
ip multicast limit cost acl-MP2SD-channels 4000 ! from any provider ip multicast limit cost acl-MP2HD-channels 18000 ! from any provider ip multicast limit cost acl-MP4SD-channels 1600 ! from any provider ip multicast limit cost acl-MP4HD-channels 6000 ! from any provider ! interface Gig0/0 description --- Interface towards DSLAM --- <snip> ! CAC ip multicast limit out 250000 acl-CP1-channels ip multicast limit out 250000 acl-CP2-channels ip multicast limit out 250000 acl-CP3-channels
図23:インターフェイスごとのMroute状態制限のコスト要因
ユニキャストと同様に、マルチキャストトラフィックも、機密性や整合性を保護するために保護する必要がある場合があります。このようなサービスが必要になる可能性のある主な領域は、次の2つです。
プロトコルとしてのIPSec [RFC 6040、7619、4302、4303、5282]は、ユニキャストトラフィック(RFCによる)に限定されます。そこで、2つのユニキャストピア間で「セキュリティアソシエーション」(SA)が確立されます。マルチキャストトラフィックにIPSecを適用する1つのオプションは、GREトンネル内でマルチキャストトラフィックをカプセル化してから、IPSecをユニキャストであるGREトンネルに適用することです。新しいアプローチでは、グループのすべてのメンバー間で確立された単一のセキュリティアソシエーションを使用します。これを実現する方法は、Group Domain of Interpretation(GDOI)[RFC 6407]で定義されています。
GDOIに基づいて、シスコはGroup Encryption Transport(GET)VPNと呼ばれるテクノロジーを開発しました。このテクノロジーは、「draft-ietf-msec-ipsec-extensions」のドキュメントで定義されている「アドレス保護を使用したトンネルモード」を使用します。GET VPNでは、最初にグループのすべてのメンバー間でグループセキュリティアソシエーション(SA)が確立されます。その後、トラフィックはESP(カプセル化されたセキュリティペイロード)またはAH(認証ヘッダー)のいずれかで保護されます。AHでは、アドレスが保持されたトンネルモードが使用されます。
要約すると、GET VPNでは、元のヘッダーのアドレス情報を使用するマルチキャストパケットがカプセル化され、グループポリシーに関連して内部パケットがESPなどで保護されます。
GET VPNの利点は、マルチキャストトラフィックがセキュリティカプセル化メカニズムの影響を受けないことです。ルーテッドIPヘッダーアドレスは、元のIPヘッダーと同じままです。マルチキャストトラフィックは、GET VPNの有無にかかわらず同じ方法で保護できます。
GET VPNノードに適用されるポリシーは、Group Key Serverで一元的に定義され、すべてのグループノードに配布されます。したがって、すべてのグループノードが同じポリシーを持ち、同じセキュリティ設定がグループトラフィックに適用されます。暗号化ポリシーは、標準のIPSecと同様に、保護する必要があるトラフィックのタイプを定義します。これにより、GET VPNをさまざまな目的で使用できます。
ネットワーク全体の暗号化ポリシーがグループキーサーバに設定され、GET VPNエンドポイントに配布されます。このポリシーには、IPSecポリシー(IPSecモード – ここではヘッダーを保持したトンネルモード)と、使用するセキュリティアルゴリズム(AESなど)が含まれています。また、ACLで定義されているように、どのトラフィックを保護できるかについて記述したポリシーも含まれています。
GET VPNは、マルチキャストおよびユニキャストトラフィックに使用できます。ユニキャストトラフィックを保護するポリシーは、次のようにACLで定義できます。
permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
これにより、送信元IPが10/8で宛先IPが10/8のトラフィックがすべて暗号化されます。10/8から別のアドレスへのトラフィックなど、その他すべてのトラフィックは、GET VPNでは無視されます。
マルチキャストトラフィックに対するGET VPNの適用は、技術的には同じです。たとえば、次のアクセスコントロールエントリ(ACE)を使用して、任意の送信元から各マルチキャストグループへのトラフィックを保護できます。
permit ip any 239.192.0.0 0.0.255.255
このポリシーは、すべての送信元(「any」)と、239.192で始まるすべてのマルチキャストグループに一致します。他のマルチキャストグループへのトラフィックは保護されません。
注:暗号ACLの構築には細心の注意を払う必要があります。管理トラフィック、またはGET VPNドメイン外から発信され、内部で終端するトラフィック(つまり、1つの暗号化エンドポイントのみを通過するトラフィック)は、GDOIポリシーから除外する必要があります。
?一般的な間違いは次のとおりです。
一般に、メッセージが信頼できるピアから発信されるように、ルーティングプロトコルなどのコントロールプレーントラフィックを認証することがベストプラクティスです。これは、BGPなどのユニキャストを使用するコントロールプレーンプロトコルでは比較的簡単です。ただし、多くのコントロールプレーンプロトコルはマルチキャストトラフィックを使用します。例としては、OSPF、RIP、PIMなどがあります。完全なリストについては、IANAのIPv4 Multicast Address Space Registryを参照してください。
これらのプロトコルの中には、Routing Information Protocol(RIP;ルーティング情報プロトコル)やEnhanced Interior Group Routing Protocol(EIGRP)などの組み込み認証を備えているものもあれば、IPSecを使用してこの認証を提供しているもの(OSPFv3、PIMなど)もあります。後者の場合、GET VPNはこれらのプロトコルを保護するためのスケーラブルな方法を提供します。ほとんどの場合、この要件はプロトコルメッセージ認証、つまり信頼できるピアからメッセージが送信されたことの確認です。ただし、GET VPNではこのようなメッセージの暗号化も可能です。
このようなコントロールプレーントラフィックを保護(通常は認証のみ)するには、トラフィックをACLで記述し、GET VPNポリシーに含める必要があります。詳細は保護するプロトコルによって異なります。ここでは、ACLに入力GET VPNノード(カプセル化されている)のみを通過するトラフィックが含まれているか、出力ノードも含まれているかに注意する必要があります。
PIMプロトコルを保護する基本的な方法は2つあります。
注:コマンドは、概念の説明に役立つ例として提供されています。 たとえば、PIMのブートストラップに使用される特定のPIMプロトコル(BSRやAuto-RPなど)を除外する必要があります。導入に依存する特定の利点や不便な点がある方法はありません。詳細については、GET VPNでPIMを保護する方法に関する特定の資料を参照してください。
マルチキャストは、ネットワークでますます一般的になっているサービスです。家庭/ホームブロードバンドネットワークにおけるIPTVサービスの登場と、世界の金融市場の多くで電子取引アプリケーションに向かう動きは、マルチキャストを絶対的な要件にする要件の2つの例にすぎません。マルチキャストには、設定、運用、および管理に関するさまざまな課題が伴います。重要な課題の1つはセキュリティです。
このドキュメントでは、マルチキャストのセキュリティを確保するさまざまな方法について説明しました。
マルチキャストセキュリティを考慮して、ユニキャストとの違いを覚えておいてください。マルチキャスト送信はダイナミックステートの作成に基づいており、マルチキャストではダイナミックパケットレプリケーションが行われます。また、マルチキャストではPIM JOIN/PRUNEメッセージに応答して単方向ツリーが構築されます。この環境全体のセキュリティには、Cisco IOSコマンドの豊富なフレームワークの理解と導入が含まれます。これらのコマンドは、主に、CoPPなどのパケットに対して配置されるプロトコル操作、状態(マルチキャスト)、またはポリサーの保護に重点を置いています。 これらのコマンドを正しく使用することで、IPマルチキャストに対して堅牢な保護サービスを提供できます。
要約すると、このドキュメントでは、次のような複数のアプローチを推奨および説明しています。
IPマルチキャストは、さまざまなアプリケーションサービスを提供するためのエキサイティングでスケーラブルな手段です。ユニキャストと同様に、さまざまなエリアでセキュリティを確保する必要があります。このドキュメントでは、IPマルチキャストネットワークの保護に使用できる基本的な構成要素について説明します。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
14-Oct-2023 |
初版 |