[要約] RFC 5294は、プロトコルに依存しないマルチキャスト（PIM）へのホストの脅威に関する情報を提供するものです。このRFCの目的は、PIMを使用するネットワークでのホストのセキュリティリスクを理解し、適切な対策を講じるためのガイドラインを提供することです。
Network Working Group P. Savola
Request for Comments: 5294 CSC/FUNET
Category: Informational J. Lingard
Arastra
August 2008
Host Threats to Protocol Independent Multicast (PIM)
プロトコル独立マルチキャスト（PIM）に対するホストの脅威
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts.
このメモは、ホストを接続するルーターインターフェイスに固有のプロトコル独立マルチキャスト（PIM）の脅威を説明することにより、マルチキャストインフラストラクチャセキュリティ脅威分析ドキュメントのリストを補完します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Host-Interface PIM Vulnerabilities . . . . . . . . . . . . . . 2
2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 3
2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 3
2.3. Routers May Accept PIM Messages from Non-Neighbors . . . . 3
2.4. An Illegitimate Node May Be Elected as the PIM DR or DF . 3
2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 3
2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4
2.5. A Node May Become an Illegitimate PIM Asserted
Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 4
3. On-Link Threats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5
3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6
3.3. Confidentiality, Integrity, or Authorization Violations . 6
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8
4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
There has been some analysis of the security threats to the multicast routing infrastructures [RFC4609], some work on implementing confidentiality, integrity, and authorization in the multicast payload [RFC3740], and also some analysis of security threats in Internet Group Management Protocol/Multicast Listener Discovery (IGMP/MLD) [DALEY-MAGMA], but no comprehensive analysis of security threats to PIM at the host-connecting (typically "Local Area Network") links.
マルチキャストルーティングインフラストラクチャ[RFC4609]に対するセキュリティの脅威のいくつかの分析、マルチキャストペイロード[RFC3740]における機密性、整合性、認可の実装に関するいくつかの作業、およびインターネットグループ管理プロトコル/マルチキャストのセキュリティ脅威の分析もありました。リスナーディスカバリー（IGMP/MLD）[Daley-Magma]ですが、ホスト接続（通常は「ローカルエリアネットワーク」）リンクでのPIMに対するセキュリティの脅威の包括的な分析はありません。
We define these PIM host threats to include:
これらのPIMホストの脅威を含むように定義します。
o Nodes using PIM to attack or deny service to hosts on the same link,
o PIMを使用して、同じリンクのホストへのサービスを攻撃または拒否するノード、
o Nodes using PIM to attack or deny service to valid multicast routers on the link, or
o PIMを使用して、リンク上の有効なマルチキャストルーターへのサービスを攻撃または拒否するノード、または
o Nodes using PIM (Register messages) to bypass the controls of multicast routers on the link.
o PIM（登録メッセージ）を使用してノードを使用して、リンク上のマルチキャストルーターのコントロールをバイパスします。
The attacking node is typically a host or a host acting as an illegitimate router.
攻撃ノードは、通常、ホストまたはホストであり、非合法ルーターとして機能します。
A node originating multicast data can disturb existing receivers of the group on the same link, but this issue is not PIM-specific so it is out of scope. Subverting legitimate routers is out of scope. Security implications on multicast routing infrastructure are described in [RFC4609].
ノード発信マルチキャストデータは、同じリンク上のグループの既存の受信機を妨害する可能性がありますが、この問題はPIM固有ではないため、範囲外です。正当なルーターを破壊することは範囲外です。マルチキャストルーティングインフラストラクチャへのセキュリティへの影響については、[RFC4609]で説明されています。
This document analyzes the PIM host-interface vulnerabilities, formulates a few specific threats, proposes some potential ways to mitigate these problems, and analyzes how well those methods accomplish fixing the issues.
このドキュメントは、PIMホストインターフェイスの脆弱性を分析し、いくつかの特定の脅威を策定し、これらの問題を軽減する潜在的な方法を提案し、それらの方法が問題を修正することをどのように達成するかを分析します。
It is assumed that the reader is familiar with the basic concepts of PIM.
読者はPIMの基本概念に精通していると想定されています。
Analysis of PIM-DM [RFC3973] is out of scope of this document.
PIM-DM [RFC3973]の分析は、このドキュメントの範囲外です。
This section briefly describes the main attacks against host-interface PIM signaling, before we get to the actual threats and mitigation methods in the next sections.
このセクションでは、次のセクションの実際の脅威と緩和方法に到達する前に、ホストインターフェイスPIMシグナル伝達に対する主な攻撃について簡単に説明します。
The attacking node may be either a malicious host or an illegitimate router.
攻撃ノードは、悪意のあるホストまたは違法なルーターのいずれかです。
PIM Register messages are sent unicast, and contain encapsulated multicast data packets. Malicious hosts or routers could also send Register messages themselves, for example, to get around rate-limits or to interfere with foreign Rendezvous Points (RPs), as described in [RFC4609].
PIMレジスタメッセージにはユニキャストが送信され、カプセル化されたマルチキャストデータパケットが含まれています。悪意のあるホストまたはルーターは、たとえば、レート制限を回避したり、[RFC4609]に記載されているように、外国のランデブーポイント（RPS）を妨害するために、レジスタメッセージ自体を送信することもできます。
The Register message can be targeted to any IP address, whether in or out of the local PIM domain. The source address may be spoofed, unless spoofing has been prevented [RFC3704], to create arbitrary state at the RPs.
レジスタメッセージは、ローカルPIMドメイン内または外出するかどうかにかかわらず、任意のIPアドレスをターゲットにすることができます。RPSに任意の状態を作成するために、スプーフィングが防止されない限り[RFC3704]、ソースアドレスがスプーフィングされる場合があります。
When PIM has been enabled on a router's host interface, any node can also become a PIM neighbor using PIM Hello messages. Having become a PIM neighbor in this way, the node is able to send other PIM messages to the router and may use those messages to attack the router.
RouterのホストインターフェイスでPIMが有効になっている場合、どのノードもPIM Helloメッセージを使用してPIMネイバーになることもあります。この方法でPIMの隣人になったこのノードは、他のPIMメッセージをルーターに送信でき、それらのメッセージを使用してルーターを攻撃することができます。
The PIM-SM (Sparse Mode) specification recommends that PIM messages other than Hellos should not be accepted, except from valid PIM neighbors. The Bidirectional-PIM (BIDIR-PIM) specification specifies that packets from non-neighbors "SHOULD NOT" be accepted; see Section 5.2 of [RFC5015]. However, the specification does not mandate this, so some implementations may be susceptible to attack from PIM messages sent by non-neighbors.
PIM-SM（SPARSE MODE）仕様は、有効なPIMネイバーを除いて、Hellos以外のPIMメッセージを受け入れるべきではないことを推奨しています。双方向PIM（Bidir-PIM）仕様は、非相続からのパケットを「受け入れてはならない」ことを指定します。[RFC5015]のセクション5.2を参照してください。ただし、仕様にはこれが義務付けられていないため、一部の実装は、非希釈者から送信されたPIMメッセージから攻撃を受けやすい場合があります。
In PIM-SM, the Designated Router (DR) on a Local Area Network (LAN) is responsible for Register-encapsulating data from new sources on the LAN, and for generating PIM Join/Prune messages on behalf of group members on the LAN.
PIM-SMでは、ローカルエリアネットワーク（LAN）の指定されたルーター（DR）は、LANの新しいソースからのデータのカプセル化を登録し、LANのグループメンバーに代わってPIM結合/プルーンメッセージを生成する責任があります。
A node that can become a PIM neighbor can also cause itself to be elected DR, whether or not the DR Priority option is being used in PIM Hello messages on the LAN.
PIMの隣人になる可能性のあるノードは、LANのPIM HelloメッセージでDR優先オプションが使用されているかどうかにかかわらず、DRを選出することもできます。
In BIDIR-PIM [RFC5015], a Designated Forwarder (DF) is elected per link. The DF is responsible for forwarding data downstream onto the link, and also for forwarding data from its link upstream.
Bidir-PIM [RFC5015]では、リンクごとに指定されたフォワーダー（DF）が選出されます。DFは、下流のデータをリンクに転送し、上流のリンクからデータを転送する責任があります。
A node that can become a BIDIR-PIM neighbor (this is just like becoming a PIM neighbor, except that the PIM Hello messages must include the Bidirectional Capable PIM-Hello option) can cause itself to be elected DF by sending DF Offer messages with a better metric than its neighbors.
Bidir-PIMの隣人になる可能性のあるノード（これはPIMの隣人になるようなものですが、PIM Helloメッセージには双方向の対応PIM-Helloオプションを含める必要があることを除いて）隣人よりも優れたメトリック。
There are also some other BIDIR-PIM attacks related to DF election, including spoofing DF Offer and DF Winner messages (e.g., using a legitimate router's IP address), making all but the impersonated router believe that router is the DF. Also, an attacker might prevent the DF election from converging by sending an infinite sequence of DF Offer messages.
DF選挙に関連する他のいくつかのBidir-PIM攻撃もあります。これには、DFオファーやDF勝者メッセージ（たとえば、合法的なルーターのIPアドレスを使用するなど）など、froutorionatedルーターを除くすべてがルーターがDFであると信じています。また、攻撃者は、DFオファーメッセージの無限のシーケンスを送信することにより、DF選挙が収束するのを防ぐことができます。
For further discussion of BIDIR-PIM threats, we refer to the Security Considerations section in [RFC5015].
Bidir-PIMの脅威の詳細については、[RFC5015]のセキュリティ上の考慮事項セクションを参照してください。
With a PIM Assert message, a router can be elected to be in charge of forwarding all traffic for a particular (S,G) or (*,G) onto the LAN. This overrides DR behavior.
PIMアサートメッセージを使用すると、特定の（s、g）または（*、g）のすべてのトラフィックをLANに転送することを担当するようにルーターを選択できます。これはDRの動作を無効にします。
The specification says that Assert messages should only be accepted from known PIM neighbors, and "SHOULD" be discarded otherwise. So, either the node must be able to spoof an IP address of a current neighbor, form a PIM adjacency first, or count on these checks being disabled.
仕様では、アサートメッセージは既知のPIMネイバーからのみ受け入れられるべきであり、「それ以外の場合は「」廃棄されるべきであると述べています。したがって、ノードは、現在の隣人のIPアドレスをスプーフィングしたり、最初にPIM隣接を形成したり、これらのチェックを無効にしていることを期待している必要があります。
The Assert Timer, by default, is 3 minutes; the state must be refreshed or it will be removed automatically.
アサートタイマーは、デフォルトでは3分です。状態を更新する必要があります。そうしないと、自動的に削除されます。
As noted before, it is also possible to spoof an Assert (e.g., using a legitimate router's IP address) to cause a temporary disruption on the LAN.
前に述べたように、LANの一時的な混乱を引き起こすアサート（たとえば、合法的なルーターのIPアドレスを使用するなど）をスプーフィングすることも可能です。
PIM protocols do not perform Reverse Path Forwarding (RPF) check on the shared tree (e.g., in PIM-SM from the RP to local receivers). On the other hand, RPF check is performed, e.g., on stub host interfaces. Because all forwarding in BIDIR-PIM is based on the shared tree principle, it does not use RPF check to verify that the forwarded packets are being received from a "topologically correct" direction. This has two immediately obvious implications:
PIMプロトコルは、共有ツリー（たとえば、RPからローカルレシーバーまでのPIM-SM）をチェックする逆パス転送（RPF）を実行しません。一方、RPFチェックは、たとえば、スタブホストインターフェイスで実行されます。Bidir-PIMのすべての転送は共有ツリーの原則に基づいているため、RPFチェックを使用して、転送されたパケットが「トポロジカルで正しい」方向から受信されていることを確認しません。これにはすぐに明らかな意味があります。
1. A node may maintain a forwarding loop until the Time to Live (TTL) runs out by passing packets from interface A to B. This is not believed to cause significant new risk as with a similar ease such a node could generate original packets that would loop back to its other interface.
1. ノードは、インターフェイスAからBにパケットを渡すことでライブ時間（TTL）が実行されるまで転送ループを維持できます。他のインターフェイスに戻ります。
2. A node may spoof source IP addresses in multicast packets it sends. Other PIM protocols drop such packets when performing the RPF check. BIDIR-PIM accepts such packets, allowing easier Denial-of-Service (DoS) attacks on the multicast delivery tree and making the attacker less traceable.
2. ノードは、送信するマルチキャストパケットでソースIPアドレスを広げる場合があります。他のPIMプロトコルは、RPFチェックを実行するときにそのようなパケットをドロップします。Bidir-PIMはそのようなパケットを受け入れ、マルチキャスト配信ツリーでのサービス拒否（DOS）攻撃を容易にし、攻撃者の追跡を軽減します。
The previous section described some PIM vulnerabilities; this section gives an overview of the more concrete threats exploiting those vulnerabilities.
前のセクションでは、PIMの脆弱性について説明しました。このセクションでは、これらの脆弱性を利用するより具体的な脅威の概要を示します。
The easiest attack is to deny the multicast service on the link. This could mean either not forwarding all (or parts of) multicast traffic from upstream onto the link, or not registering or forwarding upstream the multicast transmissions originated on the link.
最も簡単な攻撃は、リンク上のマルチキャストサービスを拒否することです。これは、すべての（またはその一部）マルチキャストトラフィックを上流からリンクに転送しないこと、またはリンクで発生するマルチキャスト送信を上流に登録または転送しないことを意味します。
These attacks can be done in multiple ways: the most typical one would be becoming the DR through becoming a neighbor with Hello messages and winning the DR election. After that, one could, for example:
これらの攻撃は複数の方法で行うことができます。最も典型的な攻撃は、ハローメッセージを持って隣人になり、博士選挙に勝つことを通して博士になることです。その後、たとえば、できることができます。
o Not send any PIM Join/Prune messages based on the IGMP reports, or
o IGMPレポートに基づいてPIM結合/プルーンメッセージを送信しない、または
o Not forward or register any sourced packets.
o ソースのパケットを転送または登録しないでください。
Sending PIM Prune messages may also be an effective attack vector even if the attacking node is not elected DR, since PIM Prune messages are accepted from downstream interfaces even if the router is not a DR.
PIM PruneメッセージがDRでなくても下流インターフェイスから受け入れられるため、PIM Pruneメッセージの送信は、攻撃ノードがDRを選出されていない場合でも、効果的な攻撃ベクトルになる可能性があります。
An alternative mechanism is to send a PIM Assert message, spoofed to come from a valid PIM neighbor or non-spoofed if a PIM adjacency has already been formed. For the particular (S,G) or (*,G) from the Assert message, this creates the same result as getting elected as a DR. With BIDIR-PIM, similar attacks can be done by becoming the DF or by preventing the DF election from converging.
別のメカニズムは、PIMの隣接隣接から来るようにスプーフィングされたPIMアサートメッセージを送信するか、PIMの隣接がすでに形成されている場合は非スプーフィングされていることです。アサートメッセージから特定（s、g）または（*、g）の場合、これはDRとして選出されるのと同じ結果を作成します。Bidir-PIMでは、DFになるか、DF選挙が収束するのを防ぐことで、同様の攻撃を行うことができます。
It is also possible to perform Denial-of-Service attacks on nodes beyond the link, especially in environments where a multicast router and/or a DR is considered to be a trusted node.
また、特にマルチキャストルーターやDRが信頼できるノードと見なされる環境では、リンクを超えたノードに対してサービス拒否攻撃を実行することもできます。
In particular, if DRs perform some form of rate-limiting, for example, on new Join/Prune messages, becoming a DR and sending those messages yourself allows one to subvert these restrictions; therefore, rate-limiting functions need to be deployed at multiple layers, as described in [RFC4609].
特に、DRSが何らかの形のレート制限を実行する場合、たとえば新しいJoin/Pruneメッセージで、DRになり、それらのメッセージを自分で送信すると、これらの制限を破壊することができます。したがって、[RFC4609]で説明されているように、レート制限関数は複数の層に展開する必要があります。
In addition, any host can send PIM Register messages on their own, to whichever RP it wants; further, if unicast RPF (Reverse Path Forwarding) mechanisms [RFC3704] have not been applied, the packet may be spoofed. This can be done to get around rate-limits, and/or to attack remote RPs, and/or to interfere with the integrity of an ASM group. This attack is also described in [RFC4609].
さらに、ホストは、必要なRPにPIMレジスタメッセージを単独で送信できます。さらに、ユニキャストRPF（逆パス転送）メカニズム[RFC3704]が適用されていない場合、パケットがスプーフィングされる可能性があります。これは、レート制限を回避したり、リモートRPを攻撃したり、ASMグループの完全性を妨害するために行うことができます。この攻撃は[RFC4609]でも説明されています。
Also, BIDIR-PIM does not prevent nodes from using topologically incorrect addresses (source address spoofing) making such an attack more difficult to trace.
また、Bidir-PIMでは、ノードがトポロジカルに誤ったアドレス（ソースアドレスのスプーフィング）を使用することを妨げません。
Contrary to unicast, any node is able to legitimately receive all multicast transmission on the link by just adjusting the appropriate link-layer multicast filters. Confidentiality (if needed) must be obtained by cryptography.
ユニキャストとは反対に、どのノードも、適切なリンク層マルチキャストフィルターを調整するだけで、リンク上のすべてのマルチキャスト送信を正当に受信できます。機密性（必要に応じて）は、暗号化によって取得する必要があります。
If a node can become a DR, it is able to violate the integrity of any data streams sent by sources on the LAN, by modifying (possibly in subtle, unnoticeable ways) the packets sent by the sources before Register-encapsulating them.
ノードがDRになる可能性がある場合、登録済みのカプセル化の前にソースから送信されるパケットを変更する（おそらく微妙で目立たない方法で）LANのソースから送信されるデータストリームの整合性に違反することができます。
If a node can form a PIM neighbor adjacency or spoof the IP address of a current neighbor, then if it has external connectivity by some other means other than the LAN, the node is able to violate the integrity of any data streams sent by external sources onto the LAN. It would do this by sending an appropriate Assert message onto the LAN to prevent the genuine PIM routers forwarding the valid data, obtaining the multicast traffic via its other connection, and modifying those data packets before forwarding them onto the LAN.
ノードがPIM Neighborの隣接または現在の隣接のIPアドレスを形成できる場合、LAN以外の他の手段で外部接続がある場合、ノードは外部ソースによって送信されるデータストリームの整合性に違反することができますLANに。これは、有効なデータを転送する本物のPIMルーターを防ぎ、他の接続を介してマルチキャストトラフィックを取得し、それらをLANに転送する前にそれらのデータパケットを変更するのを防ぐために、適切なアサートメッセージをLANに送信することでこれを行います。
In either of the above two cases, the node could operate as normal for some traffic, while violating integrity for some other traffic.
上記の2つのケースのいずれかで、ノードは一部のトラフィックでは通常のように動作し、他のトラフィックの整合性に違反する可能性があります。
A more elaborate attack is on authorization. There are some very questionable models [HAYASHI] where the current multicast architecture is used to provide paid multicast service, and where the authorization/authentication is added to the group management protocols such as IGMP. Needless to say, if a host would be able to act as a router, it might be possible to perform all kinds of attacks: subscribe to multicast service without using IGMP (i.e., without having to pay for it), deny the service for the others on the same link, etc. In short, to be able to ensure authorization, a better architecture should be used instead (e.g., [RFC3740]).
より精巧な攻撃は認可にあります。現在のマルチキャストアーキテクチャを使用して有料マルチキャストサービスを提供し、IGMPなどのグループ管理プロトコルに承認/認証が追加される非常に疑わしいモデル[Hayashi]がいくつかあります。言うまでもなく、ホストがルーターとして機能することができる場合、あらゆる種類の攻撃を実行することが可能かもしれません：IGMPを使用せずにマルチキャストサービスに購読する（つまり、支払いをすることなく）、要するに、同じリンクなどの他の人は、より良いアーキテクチャを代わりに使用する必要があります（例：[RFC3740]）。
This section lists some ways to mitigate the vulnerabilities and threats listed in previous sections.
このセクションには、以前のセクションにリストされている脆弱性と脅威を軽減するいくつかの方法をリストします。
The current PIM specification seems to mandate running the PIM Hello protocol on all PIM-enabled interfaces. Most implementations require PIM to be enabled on an interface in order to send PIM Register messages for data sent by sources on that interface or to do any other PIM processing.
現在のPIM仕様は、すべてのPIM対応インターフェイスでPIM Helloプロトコルを実行することを義務付けているようです。ほとんどの実装では、そのインターフェイスのソースから送信されたデータのPIMレジスタメッセージを送信したり、他のPIM処理を行ったりするために、PIMをインターフェイスで有効にする必要があります。
As described in [RFC4609], running full PIM, with Hello messages and all, is unnecessary for those stub networks for which only one router is providing multicast service. Therefore, such implementations should provide an option to specify that the interface is "passive" with regard to PIM: no PIM packets are sent or processed (if received), but hosts can still send and receive multicast on that interface.
[RFC4609]で説明されているように、Hello Messagesなどを使用して、完全なPIMを実行することは、マルチキャストサービスを提供しているルーターが1つだけであるスタブネットワークにとっては不要です。したがって、このような実装は、インターフェイスがPIMに関して「パッシブ」であることを指定するオプションを提供する必要があります。PIMパケットは送信または処理されません（受信した場合）が、ホストはそのインターフェイスでマルチキャストを送信および受信できます。
Instead of passive mode, or when multiple PIM routers exist on a single link, one could also use IPsec to secure the PIM messaging, to prevent anyone from subverting it. The actual procedures have been described in [RFC4601] and [LINKLOCAL].
パッシブモードの代わりに、または単一のリンクに複数のPIMルーターが存在する場合、IPSECを使用してPIMメッセージングを固定して、誰もがそれを破壊するのを防ぐこともできます。実際の手順は[RFC4601]および[LinkLocal]で説明されています。
However, it is worth noting that setting up IPsec Security Associations (SAs) manually can be a very tedious process, and the routers might not even support IPsec; further automatic key negotiation may not be feasible in these scenarios either. A Group Domain of Interpretation (GDOI) [RFC3547] server might be able to mitigate this negotiation.
ただし、IPSECセキュリティアソシエーション（SA）を手動で設定することは非常に退屈なプロセスであり、ルーターがIPSECをサポートしない可能性があることは注目に値します。これらのシナリオでも、さらなる自動主要なネゴシエーションは実行可能ではない場合があります。解釈のグループドメイン（GDOI）[RFC3547]サーバーは、この交渉を軽減できる可能性があります。
To eliminate both the unicast and multicast PIM messages, in similar scenarios to those for which PIM passive mode is applicable, it might be possible to block IP protocol 103 (all PIM messages) in an input access list. This is more effective than PIM passive mode, as this also blocks Register messages.
ユニキャストとマルチキャストの両方のPIMメッセージを排除するために、PIMパッシブモードが適用されるシナリオと同様のシナリオで、入力アクセスリストのIPプロトコル103（すべてのPIMメッセージ）をブロックすることが可能かもしれません。これは、登録メッセージもブロックするため、PIMパッシブモードよりも効果的です。
This is also acceptable when there is more than one PIM router on the link if IPsec is used (because the access-list processing sees the valid PIM messages as IPsec AH/ESP packets). In this case, unicast Register messages must also be protected with IPsec or the routing topology must be such that the link is never used to originate, or transit unicast Register messages.
これは、IPSECを使用する場合（アクセスリスト処理が有効なPIMメッセージをIPSEC AH/ESPパケットと見なすため）、リンクに複数のPIMルーターがある場合にも許容されます。この場合、ユニキャストレジスタメッセージもIPSECで保護する必要があります。または、ルーティングトポロジは、リンクが発信またはトランジットユニキャストレジスタメッセージに使用されないようにする必要があります。
When multiple routers exist on a link, IPsec is not required if it is possible to prevent hosts from sending PIM messages at the Ethernet switch (or equivalent) host ports. This could be accomplished in at least two ways:
リンクに複数のルーターが存在する場合、ホストがイーサネットスイッチ（または同等の）ホストポートでPIMメッセージを送信できない場合、IPSECは必要ありません。これは、少なくとも2つの方法で達成できます。
1. Use IP access lists on the stub routers to allow PIM messages from the valid neighbor IP addresses only, and implement IP spoofing prevention at the Ethernet-switch-port level using proprietary mechanisms, or
1. スタブルーターのIPアクセスリストを使用して、有効な近隣IPアドレスからのPIMメッセージのみを許可し、独自のメカニズムを使用してイーサネットスイッチポートレベルでIPスプーフィング予防を実装するか、または
2. Filter out all PIM messages at configured host ports on Ethernet switches instead of doing it on the routers.
2. ルーターで行うのではなく、イーサネットスイッチで構成されたホストポートですべてのPIMメッセージを除外します。
The main benefit of this approach is that multiple stub routers can still communicate through the LAN without IPsec but hosts are not able to disturb the PIM protocol. The drawback is that Ethernet switches need to implement much finer-grained IP layer filtering, and the operational requirements of carefully maintaining these filters could be significant.
このアプローチの主な利点は、複数のスタブルーターがIPSECなしでLANを介して通信できるが、ホストはPIMプロトコルを乱すことができないことです。欠点は、イーサネットスイッチがより細かい粒度のIPレイヤーフィルタリングを実装する必要があり、これらのフィルターを慎重に維持するという運用要件が重要である可能性があることです。
This section summarizes the vulnerabilities, and how well the mitigation methods are able to cope with them.
このセクションでは、脆弱性と、緩和方法がそれらにどれだけうまく対処できるかを要約します。
Summary of vulnerabilities and mitigations:
脆弱性と緩和の概要：
+-----+---------------------+-----------------+-----------------+
| Sec | Vulnerability | One stub router | >1 stub routers |
| | | PASV|IPsec|Filt | PASV|IPsec|Filt |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
Figure 1
図1
"*" means Yes if IPsec is used in addition; No otherwise.
「*」は、ipsecがさらに使用されている場合はイエスを意味します。それ以外はありません。
"Ysw" means Yes if IPsec is used in addition or IP filtering is done on Ethernet switches on all host ports; No otherwise.
「YSW」とは、すべてのホストポートのイーサネットスイッチでIPSECが追加された場合、またはIPSECが使用されている場合、はいを意味します。それ以外はありません。
"N+" means that the use of IPsec between the on-link routers does not protect from this; IPsec would have to be used at RPs.
「N」とは、オンリンクルーター間でIPSECを使用してもこれから保護しないことを意味します。IPSECはRPSで使用する必要があります。
"x" means that, with BIDIR-PIM, IP access lists or RPF mechanisms need to be applied in stub interfaces to prevent originating packets with topologically incorrect source addresses. This needs to be done in addition to any other chosen approach.
「X」とは、Bidir-PIMでは、IPアクセスリストまたはRPFメカニズムをスタブインターフェイスに適用して、トポロジー的に誤ったソースアドレスを持つ発信パケットを防ぐ必要があることを意味します。これは、他の選択されたアプローチに加えて行う必要があります。
To summarize, IP protocol filtering for all PIM messages appears to be the most complete solution when coupled with the use of IPsec between the real stub routers when there are more than one of them. However, IPsec is not required if PIM message filtering or a certain kind of IP spoofing prevention is applied on all the host ports on Ethernet switches. If hosts performing registering is not considered a serious problem, IP protocol filtering and passive-mode PIM seem to be equivalent approaches. Additionally, if BIDIR-PIM is used, ingress filtering will need to be applied in stub interfaces to multicast packets, as well as unicast, to prevent hosts using wrong source addresses.
要約すると、すべてのPIMメッセージのIPプロトコルフィルタリングは、複数のPIMメッセージがある場合に、実際のスタブルーター間でIPSECを使用する場合、最も完全なソリューションであると思われます。ただし、PIMメッセージフィルタリングまたは特定の種類のIPスプーフィング予防がイーサネットスイッチのすべてのホストポートに適用される場合、IPSECは必要ありません。登録を実行するホストが深刻な問題とは見なされない場合、IPプロトコルフィルタリングとパッシブモードPIMは同等のアプローチのようです。さらに、Bidir-PIMを使用する場合、イングレスフィルタリングは、ホストが間違ったソースアドレスを使用するのを防ぐために、マルチキャストパケットとユニキャストにスタブインターフェイスに適用する必要があります。
Greg Daley and Gopi Durup wrote an excellent analysis of MLD security issues [DALEY-MAGMA], which gave inspiration in exploring the on-link PIM threats problem space.
Greg DaleyとGopi Durupは、MLDセキュリティ問題[Daley-Magma]の優れた分析を書きました。
Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci, John Zwiebel, Stig Venaas, Yiqun Cai, and Eric Gray provided good feedback for this memo.
Ayan Roy-Chowdhury、Beau Williamson、Bharat Joshi、Dino Farinacci、John Zwiebel、Stig Venaas、Yiqun Cai、およびEric Grayは、このメモに良いフィードバックを提供しました。
This memo analyzes the threats to the PIM multicast routing protocol on host interfaces and proposes some possible mitigation techniques.
このメモは、ホストインターフェイスのPIMマルチキャストルーティングプロトコルに対する脅威を分析し、いくつかの可能な緩和手法を提案します。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、 "Protocol Independent Multicast -Sparse Mode（PIM -SM）：Protocol Specification（改訂）、RFC 4601、2006年8月。
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006.
[RFC4609] Savola、P.、Lehtonen、R。、およびD. Meyer、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）マルチキャストルーティングセキュリティの問題と機能強化」、RFC 4609、2006年10月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、2007年10月。
[DALEY-MAGMA] Daley, G. and J. Combes, "Securing Neighbour Discovery Proxy Problem Statement", Work in Progress, February 2008.
[Daley-Magma] Daley、G。and J. Combes、「Securing Neighbor Discovery Proxy問題声明」、Work in Progress、2008年2月。
[HAYASHI] Hayashi, T., "Internet Group membership Authentication Protocol (IGAP)", Work in Progress, August 2003.
[Hayashi] Hayashi、T。、「Internet Group Membership Authentication Protocol（IGAP）」、2003年8月の作業。
[LINKLOCAL] Atwood, J., Islam, S., and M. Siami, "Authentication and Confidentiality in PIM-SM Link-local Messages", Work in Progress, February 2008.
[Linklocal] Atwood、J.、Islam、S。、およびM. Siami、「PIM-SM Link-Localメッセージの認証と機密性」、2008年2月、Work in Progress。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973] Adams、A.、Nicholas、J。、およびW. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM -DM）：プロトコル仕様（改訂）」、RFC 3973、2005年1月。
Authors' Addresses
著者のアドレス
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
Pekka Savola CSC -Scientific Computing Ltd. Espoo Finland
EMail: psavola@funet.fi
James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA
James Lingard Arastra、Inc。P.O.Box 10905 Palo Alto、CA 94303 USA
EMail: jchl@arastra.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。