Network Working Group                                          P. Savola
Request for Comments: 5294                                     CSC/FUNET
Category: Informational                                       J. Lingard
                                                             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.




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
1. Introduction
1. はじめに

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:


o Nodes using PIM to attack or deny service to hosts on the same link,


o Nodes using PIM to attack or deny service to valid multicast routers on the link, or


o Nodes using PIM (Register messages) to bypass the controls of multicast routers on the link.


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].


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.


It is assumed that the reader is familiar with the basic concepts of PIM.


Analysis of PIM-DM [RFC3973] is out of scope of this document.

PIM-DM [RFC3973]の分析は、この文書の範囲外です。

2. Host-Interface PIM Vulnerabilities

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.


The attacking node may be either a malicious host or an illegitimate router.


2.1. Nodes May Send Illegitimate PIM Register Messages
2.1. ノードは非嫡出PIM登録メッセージを送信することがあります

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.


2.2. Nodes May Become Illegitimate PIM Neighbors
2.2. ノードは非嫡出PIMネイバーになることがあり

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メッセージを送信することが可能であり、ルータを攻撃するためにそれらのメッセージを使用することができます。

2.3. Routers May Accept PIM Messages from Non-Neighbors
2.3. ルータは非隣人から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メッセージから攻撃を受けやすいかもしれません。

2.4. An Illegitimate Node May Be Elected as the PIM DR or DF
2.4. 非嫡出ノードは、PIM DRかDFとして選択できます
2.4.1. PIM-SM Designated Router Election
2.4.1. PIM-SMルータ選挙指定します

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選出すること自体を引き起こす可能性があります。

2.4.2. BIDIR-PIM Designated Forwarder Election
2.4.2. フォワーダー選挙指定BIDIR-PIM

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.


For further discussion of BIDIR-PIM threats, we refer to the Security Considerations section in [RFC5015].


2.5. A Node May Become an Illegitimate PIM Asserted Forwarder
2.5. ノードは、フォワーダーをアサート非嫡出PIMになることがあり

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.


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.


The Assert Timer, by default, is 3 minutes; the state must be refreshed or it will be removed automatically.


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.


2.6. BIDIR-PIM Does Not Use RPF Check
2.6. BIDIR-PIMはRPFチェックを使用しません

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.


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)攻撃を許すと、攻撃者が少ないトレーサブル作り、このようなパケットを受け入れます。

3. On-Link Threats

The previous section described some PIM vulnerabilities; this section gives an overview of the more concrete threats exploiting those vulnerabilities.


3.1. Denial-of-Service Attack on the Link
3.1. リンク上のサービス拒否攻撃

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.


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.


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選定を防止することにより行うことができます。

3.2. Denial-of-Service Attack on the Outside
3.2. 外側にDoS攻撃

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.


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.


3.3. Confidentiality, Integrity, or Authorization Violations
3.3. 機密性、完全性、または認可違反

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.


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.


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]).


4. Mitigation Methods

This section lists some ways to mitigate the vulnerabilities and threats listed in previous sections.


4.1. Passive Mode for PIM
4.1. PIMのためのパッシブモード

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に関して「受動的」であることを指定するオプションを提供すべきです。

4.2. Use of IPsec among PIM Routers
4.2. PIMルータ間のIPsecの使用

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.


4.3. IP Filtering PIM Messages
4.3. IPフィルタリングPIMメッセージ

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.


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:


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.


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.


4.4. Summary of Vulnerabilities and Mitigation Methods
4.4. 脆弱性と軽減方法の概要

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


"*" means Yes if IPsec is used in addition; No otherwise.


"Ysw" means Yes if IPsec is used in addition or IP filtering is done on Ethernet switches on all host ports; No otherwise.


"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.


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が使用される場合、さらに、イングレスフィルタリングは、間違ったソースアドレスを使用するホストを防止するために、マルチキャストパケット、並びにユニキャストにスタブ・インターフェースに適用する必要があります。

5. Acknowledgements

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.


6. Security Considerations

This memo analyzes the threats to the PIM multicast routing protocol on host interfaces and proposes some possible mitigation techniques.


7. References
7.1. Normative References
7.1. 引用規格

[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月。

7.2. Informative References
7.2. 参考文献

[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 - 科学計算株式会社エスポー、フィンランド



James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA

ジェームズ・リンガードArastra、株式会社P. O.ボックス10905パロアルト、CA 94303 USA



Full Copyright Statement


Copyright (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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎と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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。