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)
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.
このメモは、Protocol Independent Multicast（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）[デイリー-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 Registerメッセージは、ユニキャストを送信して、カプセル化されたマルチキャストデータパケットが含まれています。 [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.
Registerメッセージは、中かどうかローカルPIMドメインのうち、いずれかのIPアドレスを標的とすることができます。スプーフィングをRPのに任意の状態を作成するために、[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.
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（希薄モード）仕様はハローズ以外のPIMメッセージが有効なPIMネイバーから除き、受理してはならないことをお勧めします。双方向PIM-（BIDIR-PIM）仕様は、非隣人からのパケットが受け入れられる「NOTべきである」ことを指定します。 [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では、ローカル・エリア・ネットワーク上のDesignated Router（DR）（LAN）は、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ネイバーになることができるノードは、DR優先オプションは、LAN上のPIM Helloメッセージに使用されているかどうか、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 Helloメッセージが双方向できるPIM-こんにちはオプションを含まなければならないことを除いて、PIMネイバーになることのようである）になることができるノードはとDFオファーメッセージを送信することにより、DF選出すること自体を引き起こす可能性があります隣国よりも優れたメトリック。
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オファーとDF受賞メッセージを含むDF選定に関連するいくつかの他のBIDIR-PIM攻撃は、もあります（例えば、正当なルータのIPアドレスを使用して）、すべてを行うことが、偽装ルータがそのルータが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アサートメッセージで、ルータはLAN上の特定の（S、G）または（*、G）のすべてのトラフィックの転送を担当することを選択することができます。これは、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プロトコルは、リバースパス転送（RPF）を実行する（ローカル受信機へのRPからのPIM-SMで、例えば）共有ツリーにチェックしないでください。一方、RPFチェックは、スタブホストインターフェイスで、例えば、実行されます。 BIDIR-PIM内のすべての転送は共有ツリーの原理に基づいているので、転送されたパケットは、「位相幾何学的に正しい」方向から受信されていることを確認するためにRPFチェックを使用していません。これは、2つのすぐに明らかに影響があります。
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.
そのようなノードは、その元のパケットを生成することができる同様の容易さと同様に生存時間（TTL）は、これは重大な新たなリスクを引き起こすと考えられていないBに、インタフェースAからパケットを通過させることによってなくなるまで1ノードは、転送ループを維持することができますバックそのほかのインターフェイスにループだろう。
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アドレスを偽装してもよいです。 RPFチェックを実行するときに、他のPIMプロトコルは、このようなパケットをドロップします。 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:
これらの攻撃は、複数の方法で行うことができます。最も代表的なものは、Helloメッセージを隣人になることと、DR選挙の勝利を通じてDRになることでしょう。その後、1はできる、例えば：
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.
任意のソースパケットを転送したり、登録しないでください。
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プルーンメッセージを送信することもPIMプルーンメッセージは、ルータがDRでない場合でも、下流インタフェースから受け付けているので攻撃ノードが、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がのいくつかのフォームを実行する場合は速度制限、新しい参加/プルーンのメッセージに、例えば、DRになってきて、自分が1はこれらの制限を破壊することができますそれらのメッセージを送信します。 [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 Registerメッセージを送信することができます。さらに、もしユニキャスト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ネイバー隣接関係を形成するか、またはいくつかの他は、LAN以外の手段によって、それは外部の接続性を持って、その後場合は、現在のネイバーのIPアドレスを偽装することができた場合、ノードは、外部ソースから送信されたデータストリームの整合性に違反することができます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.
いくつかの他のトラフィックのための整合性に違反しながら、上記の二つの場合のいずれにおいて、ノードは、いくつかのトラフィックに対して通常通り動作することができます。
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などのグループ管理プロトコルに追加される場合があります。ホストがルータとして動作することができるならば、言うまでもなく、それは攻撃のすべての種類を行うことが可能かもしれません：、（すなわち、それを支払うことなく）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ハロープロトコルを実行している義務付けるようです。ほとんどの実装は、PIMは、そのインターフェイス上のソースによって送信されたデータのためのPIM Registerメッセージを送信したり、他の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メッセージとすべてで、完全な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ルータが単一のリンク上に存在する場合、1にも、それを破壊するから誰を防ぐために、PIMメッセージングを保護するためにIPsecを使用することができます。実際の手順は、[LINKLOCAL] [RFC4601]に記載されてきました。
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のAH / ESPパケットとして有効なPIMメッセージを見ているので）IPsecが使用されている場合は、リンク上に複数のPIMルータがある場合にも許容可能です。この場合は、ユニキャストRegisterメッセージはまた、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:
複数のルータがリンク上に存在する場合、IPsecは、イーサネットスイッチ（または同等の）ホストポートでPIMメッセージを送信ホストを防止することが可能である場合に必要とされません。これは、少なくとも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.
IPsecが加えて使用されるか、またはIPフィルタリングは、すべてのホストポート上のイーサネットスイッチで行われる場合、「YSWが」Yesを意味します。いいえそうでない場合はありません。
"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はのRPで使用しなければならないであろう。
"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プロトコルフィルタリングは、これらの2つ以上が存在する場合に、実際のスタブルータ間の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.
グレッグ・デイリーとGopi Durupは、オンリンクPIMの脅威の問題空間を探索中にインスピレーションを与えたMLDのセキュリティ問題[デイリー-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.
アヤンロイ・チョードリー、ボー・ウィリアムソン、バーラト・ジョシ、ディノファリナッチ、ジョンZwiebel、スティグVenaas、Yiqunカイ、そしてエリック・グレイは、このメモのために良いフィードバックを提供します。
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]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、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.マイヤー、 "プロトコル独立マルチキャスト - スパースモード（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]ハンドレー、M.、Kouvelas、I.、スピークマン、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.
[デイリー-MAGMA]デイリー、G.とJ. Combesの、進歩、2008年2月の作業「近隣探索プロキシの問題文の保護」。
[HAYASHI] Hayashi, T., "Internet Group membership Authentication Protocol (IGAP)", Work in Progress, August 2003.
[林]林、T.、 "インターネットグループメンバーシップ認証プロトコル（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]アトウッド、J.、イスラム教、S.、およびM. Siami、 "PIM-SMリンクローカルメッセージにおける認証および機密性"、進歩、2008年2月に働いています。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、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.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、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]アダムス、A.、ニコラス、J.、およびW. Siadak、 "プロトコル独立マルチキャスト - 稠密モード（PIM-DM）：プロトコル仕様（改訂）"、RFC 3973、2005年1月。
Authors' Addresses
著者のアドレス
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
ペッカSavola CSC - 科学計算株式会社エスポー、フィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA
ジェームズ・リンガードArastra、株式会社P. O.ボックス10905パロアルト、CA 94303 USA
EMail: jchl@arastra.com
メールアドレス：jchl@arastra.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。