Network Working Group P. Savola
Request for Comments: 4609 CSC/FUNET
Category: Informational R. Lehtonen
TeliaSonera
D. Meyer
August 2006
Protocol Independent Multicast - Sparse Mode (PIM-SM)
Multicast Routing Security Issues and Enhancements
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats.
このメモは、より大きな（ドメイン内またはドメイン間）マルチキャストルーティングインフラストラクチャのセキュリティ脅威について説明します。プロトコル独立マルチキャストのみ - 希薄モード（PIM-SM）は、その三つの主要な動作モードでは、分析されている：伝統的な任意-ソースマルチキャスト（ASM）モデル、ソース固有のマルチキャスト（SSM）モデル、およびによって強化ASMモデルを組み込みランデブーポイント（組み込み-RP）グループに-RPマッピングメカニズム。また、このメモは識別された脅威を緩和するためのプロトコル操作に機能強化について説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Threats to Multicast Routing ....................................4
3.1. Receiver-Based Attacks .....................................5
3.1.1. Joins to Different Groups (Join Flooding) ...........5
3.2. Source-Based Attacks .......................................7
3.2.1. Sending Multicast to Empty Groups (Data Flooding) ...7
3.2.2. Disturbing Existing Group by Sending to It
(Group Integrity Violation)..........................8
3.3. Aggravating Factors to the Threats .........................9
3.3.1. Distant RP/Source Problem ...........................9
3.3.2. No Receiver Information in PIM Joins ...............10
4. Threat Analysis ................................................10
4.1. Summary of the Threats ....................................10
4.2. Enhancements for Threat Mitigation ........................10
5. PIM Security Enhancements ......................................11
5.1. Remote Routability Signalling .............................11
5.2. Rate-Limiting Possibilities ...............................12
5.3. Specific Rate-limiting Suggestions ........................14
5.3.1. Group Management Protocol Rate-Limiter .............14
5.3.2. Source Transmission Rate-Limiter ...................14
5.3.3. PIM Signalling Rate-Limiter ........................15
5.3.4. Unicast-Decapsulation Rate-Limiter .................15
5.3.5. PIM Register Rate-Limiter ..........................15
5.3.6. MSDP Source-Active Rate-Limiter ....................16
5.4. Passive Mode for PIM ......................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
Appendix A. RPF Considers Interface, Not Neighbor ................19
Appendix B. Return Routability Extensions ........................20
B.1. Sending PIM-Prune Messages Down the Tree ..................20
B.2. Analysing Multicast Group Traffic at DR ...................21
B.3. Comparison of the Above Approaches ........................21
This document describes security threats to the Protocol Independent Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures and suggests ways to make these architectures more resistant to the described threats.
この文書では、プロトコル独立マルチキャストにセキュリティ上の脅威を説明 - 希薄モード（PIM-SM）マルチキャストルーティングインフラストラクチャと説明した脅威にこれらのアーキテクチャは、より耐性にする方法を提案します。
Only attacks that have an effect on the multicast routing infrastructures (whether intra- or inter-domain) are considered.
マルチキャストルーティングインフラストラクチャ（分子内またはドメイン間かどうか）に影響を与える攻撃のみが考慮されます。
"On-link" attacks where the hosts specifically target the Designated Router (DR) or other routers on the link, or where hosts disrupt other hosts on the same link, possibly using group management protocols, are discussed elsewhere (e.g., [10] and [12]). These attacks are not discussed further in this document.
ホストは、おそらくグループ管理プロトコルを使用して、同じリンク上の他のホストを破壊する場合、ホストは、具体的には、リンク上の指定ルータ（DR）または他のルータを標的とする「オンリンク」攻撃は、または、他の場所で議論されている（例えば、[10]及び[12]）。これらの攻撃は、この文書で詳しく説明されていません。
Similar to unicast, the multicast payloads may need end-to-end security. Security mechanisms to provide confidentiality, authentication, and integrity are described in other documents (e.g., [9]). Attacks that these security mechanisms protect against are not discussed further in this document.
ユニキャストと同様に、マルチキャストペイロードは、エンドツーエンドのセキュリティが必要な場合があります。機密性、認証、および完全性を提供するために、セキュリティメカニズムは、他の文献に記載されている（例えば、[9]）。これらのセキュリティメカニズムがから守るという攻撃は、この文書で詳しく説明されていません。
PIM builds on a model where Reverse Path Forwarding (RPF) checking is, among other things, used to ensure loop-free properties of the multicast distribution trees. As a side effect, this limits the impact of an attacker using a forged source address, which is often used as a component in unicast-based attacks. However, a host can still spoof an address within the same subnet, or spoof the source of a unicast-encapsulated PIM Register message, which a host may send on its own.
PIMは、リバースパス転送（RPF）チェックがマルチキャスト配信ツリーのループフリー性を確保するために使用され、とりわけ、あるモデルに基づいています。副作用として、これは、多くの場合、ユニキャストベースの攻撃の成分として使用される偽造ソースアドレスを使用して、攻撃の影響を制限します。しかし、ホストは同じサブネット内のアドレスをスプーフィング、またはホストが独自に送信することができるユニキャストカプセル化PIM Registerメッセージの送信元を偽装することができます。
We consider PIM-SM [1] operating in the traditional Any Source Multicast (ASM) model (including the use of Multicast Source Discovery Protocol (MSDP) [2] for source discovery), in Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] group-to-RP mapping mechanism in ASM model. Bidirectional-PIM [15] is typically deployed only in intra-domain and is similar to ASM but without register messages. Bidirectional-PIM is not finished as of this writing, and its considerations are not discussed further in this document.
私たちは、ソース固有のマルチキャスト[3]（SSM）で、PIM-SMは、[1]（[2]のソース発見のためのは、Multicast Source Discovery Protocol（MSDP）の使用を含む）は、従来の任意のソースマルチキャスト（ASM）モデルで動作して考えますモデル、およびEmbedded-RP ASMモデルにおける[4]グループとRPマッピングメカニズム。双方向PIM [15]典型的にのみドメイン内に配備し、ASMではなくレジスタメッセージなしで同様です。双方向PIM-は、これを書いているとして終了していない、とその考慮事項は、この文書で詳しく説明されていません。
ASM
ASM
"ASM" [6] is used to refer to the traditional Any Source Multicast model with multiple PIM domains and a signalling mechanism (MSDP) to exchange information about active sources between them.
「ASM」は、[6]複数のPIMドメインを有する従来の任意のソースマルチキャストモデルとそれらの間のアクティブソースに関する情報を交換するシグナリングメカニズム（MSDP）を指すために用いられます。
SSM
SSM
"SSM" [7] is used to refer to Source-Specific Multicast.
「SSM」は、[7]ソース固有マルチキャストを指すために使用されます。
SSM channel
SSMチャンネル
SSM channel (S, G) identifies the multicast delivery tree associated with a source address S and a SSM destination address G.
SSMチャネル（S、G）は、送信元アドレスSとSSM宛先アドレスG.関連付けられたマルチキャスト配信ツリーを識別する
Embedded-RP
組み込み-RP
"Embedded-RP" refers to the ASM model where the Embedded-RP mapping mechanism is used to find the Rendezvous Point (RP) for a group, and MSDP is not used.
「埋込み-RPは、」埋込み-RPマッピングメカニズムは、グループのためにランデブーポイント（RP）を見つけるために使用されるASMモデルを参照し、MSDPは使用されません。
Target Router
ターゲットルータ
"Target Router" is used to refer to either the RP processing a packet (ASM or Embedded-RP) or the DR that is receiving (Source, Group) (or (S,G)) joins (in all models).
「ターゲットルータは」RP処理パケット（ASMまたは内蔵-RP）または（ソース、グループ）を受信しているDR（または（S、G））のいずれかを指すために使用される（すべてのモデルにおいて）加入。
We make the broad assumption that the multicast routing networks are reasonably trusted. That is, we assume that the multicast routers themselves are well-behaved, in the same sense that unicast routers are expected to behave well. While this assumption is not entirely correct, it simplifies the analysis of threat models. The threats caused by misbehaving multicast routers (including fake multicast routers) are not considered in this memo; the generic threat model would be similar to [5]. RP discovery mechanisms like Bootstrap Router (BSR) and Auto-RP are also considered out of scope.
私たちは、マルチキャストルーティングネットワークが合理的に信頼されていることを、幅広い仮定を作ります。つまり、私たちは、ユニキャストルータがうまく動作するように期待されているのと同じ意味で、マルチキャストルータ自体は行儀であることを前提としています。この仮定が完全に正しいものではないが、それは脅威モデルの解析を簡素化します。 （偽のマルチキャストルータを含む）マルチキャストルータの動作不良に起因する脅威はこのメモでは考慮されません。一般的な脅威モデルは、[5]と同様です。ブートストラップルータ（BSR）とAuto-RPのようなRPディスカバリメカニズムは、適用範囲外と考えられています。
As the threats described in this memo are mainly Denial-of-Service (DoS) attacks, it may be useful to note that the attackers will try to find a scarce resource anywhere in the control or data plane, as described in [5].
このメモで説明した脅威は主にサービス拒否（DoS）攻撃をしているように説明したように、それは、攻撃者が任意の場所にコントロールやデータプレーンでの希少資源を見つけることを試みることに注意することが有用である[5]。
There are multiple threats relating to the use of host-to-router signalling protocols -- such as Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) -- but these are outside the scope of this memo.
こうしたインターネットグループ管理プロトコル（IGMP）またはマルチキャストリスナ発見（MLD）など - - そこホストとルータのシグナリングプロトコルの使用に関連する複数の脅威があるが、これらは、このメモの範囲外です。
PIM-SM can be abused in the cases where RPF checks are not applicable (in particular, in the stub LAN networks), as spoofing the on-link traffic is very simple. For example, a host could get elected to become DR for the subnet, but not perform any of its functions. A host can also easily make PIM routers on the link stop forwarding multicast by sending PIM Assert messages. This implies that a willful attacker will be able to circumvent many of the potential rate-limiting functions performed at the DR (as one can always send the messages himself). The PIM-SM specification, however, states that these messages should only be accepted from known PIM neighbors; if this is performed, the hosts would first have to establish a PIM adjacency with the router. Typically, adjacencies are formed with anyone on the link, so a willful attacker would have a high probability of success in forming a protocol adjacency. These are described at some length in [1], but are also considered out of the scope of this memo.
非常に簡単ですオンリンクトラフィックをスプーフィングとしてPIM-SMは、（スタブLANネットワークでは、特に）RPFチェックが適用されない場合に悪用される可能性が。例えば、ホストは、サブネットのDRになるために選出されたが、その機能のいずれかを実行しませ得ることができました。ホストも簡単にPIMアサートメッセージを送信することにより、リンク停止フォワーディングマルチキャスト上のPIMルータを作ることができます。 （1は常にメッセージ自分自身を送信することができますように）これは故意の攻撃者がDRで行われる可能性のある速度制限機能の多くを回避することができるようになりますことを意味します。 PIM-SM仕様は、しかし、これらのメッセージは、唯一知られているPIMネイバーから受け入れられるべきであると述べています。これが行われた場合、ホストは最初のルータとPIM隣接関係を確立する必要があります。一般的に、隣接は、リンク上の誰もが形成されているので、故意の攻撃者は、プロトコルの隣接関係を形成するのに成功する確率が高いでしょう。これらは、[1]の一部の長さに記載されているだけでなく、このメモの範囲外であると考えられます。
These attacks are often referred to as control plane attacks, and the aim of the attacker is usually to increase the amount of multicast state information in routers above a manageable level.
これらの攻撃は、多くの場合、制御プレーン攻撃と呼ばれ、攻撃者の目的は、管理可能なレベル以上のルータにマルチキャスト状態情報の量を増加させるために、通常れます。
Join flooding occurs when a host tries to join, once or a couple of times, to a group or an SSM channel, and the DR generates a PIM Join to the Target Router. The group/SSM channel or the Target Router may or may not exist.
ホストがグループかSSMチャンネルに、一回または数回、参加しようとし、DRは、PIMはターゲットルータに参加したときに発生し、洪水が発生した参加。グループ/ SSMチャネルまたはターゲットルータ、または存在してもしなくてもよいです。
An example of this is a host trying to join different, non-existent groups at a very rapid pace, trying to overload the routers on the path with an excessive amount of (*/S,G) state (also referred to as "PIM State"), or the Target Router with an excessive number of packets.
この例は、ホストが（* / S、G）ステートの過剰量と経路上のルータをオーバーロードしようとすると、非常に急速なペースで異なる、存在しないグループに参加しようとしている（また、PIM」と称しますパケットの数が多すぎると国家」）、またはターゲットルータ。
Note that even if a host joins to a group multiple times, the DR only sends one PIM Join message, without waiting for any acknowledgement; the next message is only sent after the PIM Join timer expires or the state changes at the DR.
ホストがグループに複数回参加していても、DRのみ確認応答を待たずに、1はPIM Joinメッセージを送信していることに注意してください。 PIMは、タイマーが切れるか、DRの状態変化に参加した後、次のメッセージにのみ送信されます。
This kind of joining causes PIM state to be created, but this state is relatively short-lived (260 seconds by default, which is the default time that the state is active at DR in the absence of IGMP/ MLD Reports/Leaves). Note that the host can join a number of different ASM groups or SSM channels with only one IGMPv3 [11] or MLDv2 [12] Report as the protocol allows multiple sources to be included in the same message, resulting in multiple PIM Joins from one IGMPv3/MLDv2 message.
（状態はIGMP / MLDレポート/葉のない状態でDRでアクティブであることをデフォルト時間で、デフォルトでは260秒、）このPIM状態を作成する原因に参加するようなものが、この状態は比較的短命です。ホストが一つだけのIGMPv3とASM基又はSSMチャネル別の数に参加できることに留意されたい[11]またはMLDv2の[12]を報告するプロトコルは、複数のソース一件のIGMPv3からジョイン複数のPIMをもたらす、同じメッセージに含まれることを可能にするように/ MLDv2のメッセージ。
However, even short-lived state may be harmful when the intent is to cause as much state as possible. The host can continue to send IGMP/MLD Reports to these groups to make the state attack more long-lived. This results in:
目的は、できるだけ多くの状態を引き起こすことがあるときしかし、短命の状態が有害である可能性があります。ホストは、IGMP / MLDは、状態の攻撃は、より長寿命にするために、これらのグループにレポートの送信を継続することができます。これは、その結果：
o ASM: An (*,G) join is sent to an intra-domain RP, causing state on that path; in turn, that RP joins to the DR of the source if the source is active. If the source address was specified by the host in the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly to the DR of the source, as with SSM, below.
O ASM：（*、G）参加は、そのパス上の状態を引き起こして、ドメイン内のRPに送信されます。今度は、そのRPは、ソースがアクティブである場合は、ソースのDRに結合します。ソースアドレスがのIGMPv3 / MLDv2のレポート内のホストによって指定された場合、（S、G）参加は、以下、SSMと同様に、ソースのDRに直接送られます。
o SSM: An (S,G) join is sent inter-domain to the DR of the source S, causing state on that path. If the source S does not exist, the join goes to the closest router using longest prefix matching on the path to S as possible.
O SSM：（S、G）に参加は、そのパス上の状態を引き起こし、ソースSのDRにドメイン間を送信されます。ソースはSが存在しない場合は、参加するには、可能な限りSへのパス上の最長プレフィックスマッチングを使用して、最も近いルータに行きます。
o Embedded-RP: An (*,G) join is sent towards an inter/intra-domain RP embedded in the group G, causing state on that path. If the RP does not exist, the join goes to the router that is closest to the RP address. Similarly, an explicit (S,G) join goes to the DR, as with SSM above.
埋め込み-RP（O）（*、G）が参加その経路上の状態を引き起こし、グループG内に埋め込まれたインター/イントラドメインRPに向けて送信されます。 RPが存在しない場合は、参加するには、RPアドレスに最も近いルータになります。同様に、明示的な（S、G）が参加上記SSMと同様に、DRに進みます。
That is, SSM and Embedded-RP always enable "inter-domain" state creation. ASM defaults to intra-domain, but can be used for inter-domain state creation as well.
それはSSMおよびEmbedded-RPは、常に「ドメイン間」状態の作成を可能にする、です。 ASMは、ドメイン内にデフォルトが、同様に、ドメイン間の状態を作成するために使用することができます。
If the source or RP (only in case of Embedded-RP) does not exist, the multicast routing protocol does not have any means to remove the distribution tree if the joining host remains active. The worst case attack could be a host remaining active to many different groups (containing either imaginary source or RP). Please note that the imaginary RP problem is related to only Embedded-RP, where the RP address is extracted from the group address, G.
（のみ埋め込み-RPの場合）ソースまたはRPが存在しない場合、マルチキャストルーティングプロトコルは、参加ホストがアクティブのままである場合、配信木を除去するための任意の手段を有していません。最悪の場合の攻撃は、（仮想ソースまたはRPのいずれかを含む）多くの異なるグループにアクティブ残りのホストとすることができます。架空のRPの問題は、RPアドレスがグループアドレス、G.から抽出された唯一の組み込み-RPに関連していることに注意してください
For example, if the host is able to generate 100 IGMPv3 (S,G) joins a second, each carrying 10 sources, the amount of state after 260 seconds would be 260 000 state entries -- and 100 packets per second is still a rather easily achievable number.
例えば、ホストにIGMPv3（S、G）は、260の000状態エントリであろう第二、各担持10の源、260秒後の状態量を接合100を生成することができる場合 - 毎秒100個のパケットがまだかなりあります容易に達成数。
These attacks are often referred to as "data plane" attacks; however, with traditional ASM and MSDP, these also include an MSDP control plane threat.
これらの攻撃は、多くの場合、「データプレーン」攻撃と呼ばれています。しかし、従来のASMとMSDPで、これらはまた、MSDPコントロールプレーンの脅威が含まれます。
Data flooding occurs when a host sends data packets to a multicast group or SSM channel for which there are no real subscribers.
ホストが本当の加入者が存在しないれるマルチキャストグループまたはSSMチャネルにデータパケットを送信するとき、データ、洪水が発生します。
Note that since register encapsulation is not subject to RPF checks, the hosts can also craft and send these packets themselves, also spoofing the source address of the register messages unless ingress filtering [13] has been deployed [14]. That is, as the initial data registering is not subject to the same RPF checks as many other multicast routing procedures, making control decisions based on that data leads to many potential threats.
[14]展開されている[13]レジスタカプセル化がRPFチェックを受けないので、ホストもまた、イングレスフィルタリングない限り、レジスタメッセージの送信元アドレスを偽装し、これらのパケット自身を作るし、送信することができることに留意されたいです。これは、そのデータに基づいて制御意思決定を行うことは、多くの潜在的な脅威につながり、初期データの登録は、他の多くのマルチキャストルーティング手順と同じRPFチェックを受けないように、です。
Examples of this threat are a virus/worm trying to propagate to multicast addresses, an attacker trying to crash routers with excessive MSDP state, or an attacker wishing to overload the RP with encapsulated packets of different groups. This results in:
この脅威の例としては、過度のMSDPの状態、または異なるグループのカプセル化されたパケットとRPをオーバーロードしたい攻撃者とルータをクラッシュしようとする攻撃者マルチキャストアドレスに伝播しようとしているウイルス/ワームです。これは、その結果：
o ASM: The DR register-encapsulates the packets in Register messages to the intra-domain RP, which may join to the source and issue a Register-Stop, but which continues to get the data. A notification about the active source is sent (unless the group or source is configured to be local) inter-domain with MSDP and propagated globally.
O ASMは：DRは、ソースに参加し、登録・停止を発行することができるドメイン内のRPへの登録メッセージ内のパケットを登録し、カプセル化しますが、データを取得するために続けています。 （グループまたはソースがローカルであるように構成されていない限り）MSDPを有するドメイン間及びグローバル伝播アクティブソースについての通知が送られます。
o SSM: The DR receives the data, but the data does not propagate from the DR unless someone joins the (S,G) channel.
O SSM：DRは、データを受信し、誰かが（S、G）チャネルに参加しない限り、データはDRから伝播しません。
o Embedded-RP: The DR register-encapsulates the packets to the intra/inter-domain RP, which may join to the source and issue a Register-Stop. Data continues to be encapsulated if different groups are used.
O組込み-RP：DRはソースに参加し、登録・停止を発行することができるイントラ/インター・ドメインのRPにパケットを登録し、カプセル化します。データは、異なるグループが使用されている場合は、カプセル化され続けています。
This yields many potential attacks, especially if at least parts of the multicast forwarding functions are implemented on a "slow" path or CPU in the routers:
：これは、マルチキャスト転送機能の少なくとも一部は、ルータで「遅い」パスまたはCPUに実装されている場合は特に、多くの潜在的な攻撃をもたらし
o The MSDP control plane traffic generated can cause a significant amount of control and data traffic, which may overload the routers receiving it. A thorough analysis of MSDP vulnerabilities can be found in [16] and is only related to the ASM. However, this is the most serious threat at the moment, because MSDP will flood the multicast group information to all multicast domains in Internet including the multicast packet encapsulated to MSDP source-active message. This creates a lot of data and state to be shared by all multicast-enabled routers, and if the source remains active, the flooding will be repeated every 60 seconds by default.
O生成MSDP制御プレーントラフィックはそれを受信ルータが過負荷にすることができる制御およびデータ・トラフィックのかなりの量を引き起こす可能性があります。 MSDP脆弱性の徹底的な分析は、[16]に見出すことができるのみASMに関連しています。 MSDPは、MSDPのソースアクティブメッセージにカプセル化されたマルチキャストパケットを含むインターネット上のすべてのマルチキャストドメインにマルチキャストグループ情報をフラッディングしますので、しかし、これは、現時点で最も深刻な脅威です。これは、すべてのマルチキャスト対応ルータで共有するデータや状態の多くを作成し、ソースがアクティブのままであれば、洪水は、デフォルトでは60秒ごとに繰り返されます。
o As a large amount of data is forwarded on the multicast tree, if multicast forwarding is performed on CPU, it may be a serious performance bottleneck, and a way to perform DoS on the path. Similarly, the DR must always be capable of processing (and discarding, if necessary) the multicast packets received from the source. These are potentially present in every model.
マルチキャスト転送は、CPU上で実行された場合に大量のデータがマルチキャストツリー上で転送されるように、O、それは深刻なパフォーマンスのボトルネック、およびパスにDoS攻撃を実行するための方法であってもよいです。同様に、DRは常にソースから受信したマルチキャストパケット（必要に応じて、および廃棄）処理できなければなりません。これらは、すべてのモデルに潜在的に存在しています。
o If the encapsulation is performed on software, it may be a performance bottleneck, and a way to perform DoS on the DR. Similarly, if the decapsulation is performed on software, it may be a performance bottleneck, and a way to perform DoS on the RP. Note: the decapsulator may know (based on access configuration, a rate limit, or something else) that it doesn't need to decapsulate the packet, avoiding bottlenecks. These threats are related to ASM and Embedded-RP.
カプセル化がソフトウェアで実行されている場合は、O、それがパフォーマンスのボトルネック、およびDRにDoS攻撃を実行するための方法かもしれません。カプセル化解除がソフトウェアで実行された場合も、それがパフォーマンスのボトルネック、およびRPにDoS攻撃を実行するための方法かもしれません。注意：カプセル化を解くには、それがボトルネックを回避、パケットをデカプセル化する必要がないこと（アクセス構成、レート制限、または何か他のものに基づいて）知っているかもしれません。これらの脅威は、ASMおよびEmbedded-RPに関連しています。
3.2.2. Disturbing Existing Group by Sending to It (Group Integrity Violation)
3.2.2. それに送信することにより、妨害既存のグループ（グループ整合性違反）
Group integrity violation occurs when a host sends packets to a group or SSM channel, which already exists, to disturb the users of the existing group/SSM channel.
ホストは既存のグループ/ SSMチャネルのユーザーを邪魔するために、すでに存在しているグループまたはSSMチャネルにパケットを送信するときに、グループの整合性違反が発生します。
The SSM service model prevents injection of packets to (S,G) channels, avoiding this problem. However, if the source address can be spoofed to be a topologically-correct address, it's possible to get the packet into the distribution tree. Typically only hosts that are on-link with the source are able to perform this, so it is not really relevant in the scope of this memo.
SSMサービスモデルは、この問題を回避する、（S、G）チャネルにパケットの注入を防止します。送信元アドレスがトポロジー的に、正しいアドレスであることを詐称することができますしかし、もし、それが配布ツリーにパケットを取得することが可能です。通常、ソースとにリンクされているホストだけが、これを実行することができますので、このメモの範囲に本当に関係ありません。
With ASM and Embedded-RP, sources can inject forged traffic through RPs, which provide the source discovery for the group. The RPs send the traffic over the shared tree towards receivers (routers with (*,G) state). DR then forwards the forged traffic to receivers unless the legitimate recipients are able to filter out unwanted sources, e.g., using Multicast Source Filters (MSF) API [8]. Typically this is not used or supported by the applications using these protocols.
ASMおよびEmbedded-RPでは、ソースはグループのためのソース発見を提供RPは、通過偽造トラフィックを注入することができます。 RPは受信機（（*、G）状態でルータ）への共有ツリー上のトラフィックを送信します。正規受信者は、例えば、不要なソースを除外することができない限り、DRは、マルチキャストソースフィルタ（MSF）APIを使用して、受信機に偽造トラフィックを転送する[8]。通常、これは使用されるか、または、これらのプロトコルを使用するアプリケーションでサポートされていません。
Note that with ASM and Embedded-RP, the RP may exert some form of control on who can send to a group, as the first packets are register-encapsulated in register packets to the RP. If the RP drops the packet based on an access list, a rate limit, or something else,
ASMおよびEmbedded-RPと、RPは最初のパケットをRPにレジスタパケットに登録カプセル化されているように、グループに送信できるユーザーのコントロールのいくつかのフォームを発揮し得ることに留意されたいです。 RPは、アクセスリスト、レート制限、または何か他のものに基づいてパケットをドロップした場合は、
it doesn't get injected to an existing group. However, if the DR has existing (*,G) state, the data will also be forwarded on those interfaces.
それは、既存のグループに注入されません。 DRは（*、G）ステートを既存している場合は、データはまた、それらのインタフェースに転送されます。
With ASM, this "source control" is distributed across all the PIM domains, which significantly decreases its applicability. Embedded-RP enables easier control because source discovery is done through a single RP per group.
ASMでは、この「ソースコントロールは、」大幅にその適用性を減少させ、すべてのPIMドメイン、分散されます。組み込み-RPソースの発見は、グループごとに単一のRPを介して行われますので、簡単に制御することができます。
As a result, in addition to possible local disturbance, the RP decapsulates the register packets and forwards them to the receivers in the multicast distribution tree, resulting in an integrity violation.
結果として、可能なローカル妨害に加えて、RPは、レジスタパケットをデカプセル化し、整合性違反をもたらす、マルチキャスト配信ツリー内の受信機に転送します。
This section describes a few factors that aggravate the threats described in Sections 3.1 and 3.2. These could also be viewed as individual threats on their own.
このセクションでは、セクション3.1と3.2で説明した脅威を悪化させるいくつかの要因を説明しています。これらは、独自の個々の脅威と見なすことができます。
In the shared tree model, if the RP or a source is distant (topologically), then joins will travel to the distant RP or source and keep the state information in the path active, even if the data is being delivered locally.
RPまたはソースが遠い（位相的）である場合、共有ツリーモデルでは、そのデータを局所的に送達されている場合でも、遠隔RPまたはソースに移動し、アクティブパスの状態情報を維持する参加。
Note that this problem will be exacerbated if the RP/source space is global; if a router is registering to a RP/source that is not in the local domain (say, fielded by the site's direct provider), then the routing domain is flat.
RP /ソース空間がグローバルであるならば、この問題は悪化することに注意してください。ルータが（たとえば、サイトの直接のプロバイダによって擁立）ローカルドメイン内にないRP /ソースに登録している場合は、ルーティングドメインは平坦です。
Also note that PIM assumes that the addresses used in PIM messages are valid. However, there is no way to ensure this, and using non-existent S or G in (*,G) or (S,G) messages will cause the signalling to be set up, even though one cannot reach the address.
また、PIMは、PIMメッセージで使用されるアドレスが有効であることを前提としています。しかし、これを確実にする方法はありませんし、（*、G）または（S、G）メッセージに存在しないSまたはGを使用して、1つのアドレスに到達できない場合でも、シグナリングが設定されます。
This will be analyzed at more length in Section 5.1.
これは、5.1節でより多くの長さで分析されます。
Only DRs, which are directly connected to receivers, know the exact receiver information (e.g., IP address). PIM does not forward that information further in the multicast distribution tree. Therefore, individual routers (e.g., domain edge routers) are not able to make policy decisions on who can be connected to the distribution tree.
のみ直接受信機に接続されているDRSは、正確な受信者情報（例えば、IPアドレス）を知っています。 PIMは、マルチキャスト配信ツリーに、さらにその情報を転送しません。したがって、個々のルータ（例えば、ドメインエッジルータ）は、配信ツリーに接続することができるユーザーにポリシー決定を行うことができません。
Trying to summarize the severity of the major classes of threats with respect to each multicast usage model, we have a matrix of resistance to different kinds of threats:
各マルチキャスト使用モデルに対する脅威の主なクラスの重症度を要約しようとすると、我々は脅威の種類に対する抵抗性のマトリックスを持っています：
+----------------+------------------+-----------------+
| Forged Join | Being a Source | Group Integrity |
+-------------+----------------+------------------+-----------------+
| ASM | bad 1) | very bad | bad/mediocre |
+-------------+----------------+------------------+-----------------+
| SSM | bad | very good | very good |
+-------------+----------------+------------------+-----------------+
| Embedded-RP | bad 1),2) | good/mediocre 3) | good |
+-------------+----------------+------------------+-----------------+
Notes:
ノート：
1) In ASM, the host can directly join also (S,G) groups with IGMPv3/MLDv2 and thus have the same characteristics as SSM (also allows inter-domain state to be created).
1）ASMでは、ホストは、直接（また、ドメイン間の状態を作成することを可能にする）のIGMPv3 / MLDv2のでも（S、G）のグループに参加し、従ってSSMと同じ特性を有することができます。
2) allows inter-domain shared state to be created.
2）ドメイン間の共有状態を作成することを可能にします。
3) Embedded-RP allows a host to determine the RP for a given group (or set of groups), which in turn allows that host to mount a PIM register attack. In this case, the host can mount the attack without implementing any of the PIM register machinery.
3）埋め込み-RPは、ホストが順番にそのホストがPIMレジスタ攻撃をマウントすることができ、所与のグループのためのRP（またはグループのセット）を、決定することができます。この場合、ホストは、PIMレジスタ機械のいずれかを実装せずに攻撃を仕掛けることができます。
There are several desirable actions ("requirements") that could be considered to mitigate these threats; these are listed below. A few more concrete suggestions are presented later in the section.
これらの脅威を軽減するために考えることができるいくつかの望ましい行動（「要件」）があります。これらは以下のとおりです。さらにいくつかの具体的な提案は、後のセクションで提示されています。
o Inter-domain MSDP (ASM) should be retired to avoid attacks; or, if this is not reasonable, the DRs should rate-limit the register encapsulation (note that the hosts can circumvent this). More importantly, the RPs should rate-limit the register decapsulation especially from different sources, or MSDP must rate-limit the MSDP data generation for new sources.
Oドメイン間MSDP（ASM）は、攻撃を避けるために引退しなければなりません。これは合理的でない場合や、DRSは、（ホストがこれを回避することができることに留意されたい）レジスタカプセル化制限を評価すべきです。さらに重要なのは、RPは異なるソースから特にレジスタカプセル化解除をレート制限すべきである、またはMSDPは、レートを制限しなければならないMSDPデータの生成を新しいソースのため。
o DRs should rate-limit PIM Joins and Prunes somehow; there are multiple ways this should be considered (i.e., depending on which variables are taken into consideration).
O DRSはレート制限すべきであるPIMは何とか参加し、プルーン。これは（すなわち、変数が考慮されているに応じて）考慮されるべき複数の方法があります。
o DRs could rate-limit register encapsulation somehow; there are multiple ways to perform this. Note that the hosts can avoid this by performing the register encapsulation themselves if so inclined.
O DRSはレート制限できレジスタカプセル化を何とか。これを実行する複数の方法があります。ホストがその気ならばレジスタのカプセル化自体を実行することにより、この問題を回避できることに注意してください。
o RPs could rate-limit register decapsulation somehow; there are multiple ways to perform this. Note that if the source of the unicast packets is spoofed by the host, this may have an effect on how (for example) rate-limiters behave.
O RPはレート制限できレジスタカプセル化解除を何とか。これを実行する複数の方法があります。ユニキャストパケットの送信元がホストによって偽装されている場合、これは（例えば）のレートリミッタの動作方法に影響を与えることができることに留意されたいです。
o RPs should rate-limit the MSDP SA messages coming from MSDP peers.
O RPはレートを制限すべきであるMSDPピアからのMSDP SAメッセージを。
o RPs could limit or even disable the SA cache size. However, this could have negative effects on normal operation.
O RPは制限したり、SAのキャッシュサイズを無効にすることができます。しかし、これは通常の動作に悪影響を与える可能性があります。
o RPs should provide good interfaces to reject packets that are not interesting; for example, if an Embedded-RP group is not configured to be allowed in the RP, the register encapsulated packets would not even be decapsulated.
O RPは面白くないですパケットを拒否するための良いインターフェースを提供する必要があります。埋め込み-RPグループがRPで許可されるように構成されていない場合、例えば、レジスタカプセル化されたパケットをデカプセル化もされないであろう。
o DRs could rate-limit the multicast traffic somehow to reduce the disturbing possibilities; there are multiple possibilities how exactly this should be considered.
O DRSはレート制限を可能性がマルチキャストトラフィックを何とか妨害の可能性を減らすために、これは、考慮すべきかを正確に複数の可能性があります。
o DRs should rate-limit the number of groups/SSM channels that can be created by a given source, S.
O DRSはレート制限所与のソース、S.によって作成することができるグループ/ SSMチャネルの数をすべきです
This section includes more in-depth description of the above-mentioned functions for rate-limiting, etc., as well as a description of the remote routability signalling issue.
このセクションでは、より詳細なレート制限、等のための上記の機能の説明、ならびに遠隔ルータビリティ・シグナリング問題の記述を含みます。
As described in Section 3.3.1, non-existent DRs or RPs may cause some problems when setting up multicast state. There seem to be a couple of different approaches to mitigate this, especially if rate-limiting is not extensively deployed.
セクション3.3.1で説明したように、マルチキャスト状態を設定するときに、存在しないのDRまたはRPはいくつかの問題を引き起こす可能性があります。レート制限が広範囲に展開されていない場合は特に、これを緩和するために異なるアプローチのカップルがあるように思われます。
With ASM and Embedded-RP, Register message delivery could be ensured somehow. For example:
ASMおよびEmbedded-RPでは、Registerメッセージの配信は何とか確保することができます。例えば：
1) At the very least, receiving an ICMP unreachable message (of any flavor) should cause the DR to stop the Register packets, as the RP will not be receiving them anyway. (However, one should note that easy spoofing of such ICMP messages could cause a DoS on legitimate traffic.)
1）少なくとも、どんな味のICMP到達不能メッセージを（）を受信すると、RPは、とにかくそれらを受けていないだろうとして、DRはRegisterパケットを停止させなければなりません。 （ただし、1は、ICMPメッセージを簡単になりすましが正当なトラフィックにDoS攻撃を引き起こす可能性があることに注意してください。）
2) An additional method could be implementing a timer on the DRs so that unless nothing is heard back from the RP within a defined time period, the flow of Register messages would stop. (Currently, the RPs are not required to answer back, unless they want to join to the source.)
何も定義された時間内に戻ってRPから聞いていないされていない限り、Registerメッセージの流れが停止するように、2）追加的な方法は、のDRにタイマーを実装することができます。 （現在、RPは、彼らがソースに参加する場合を除き、アンサーバックする必要はありません。）
3) An extreme case would be performing some form of return routability check prior to starting the register messages: first, a packet would be sent to the RP, testing its existence and willingness to serve, and also proving to the RP that the sender of the "bubble" and the sender of the registers are the same and the source address is not forged. (That is, the RP would insert a cookie in the bubble, and it would have to be present in the register message.)
3）極端な場合には、事前登録メッセージを開始するリターンルータビリティチェックのいくつかのフォームを実行することになります。最初、パケットはその存在と奉仕する意欲をテストし、RPに送信されるだろう、ともの差出人ことをRPに証明します「バブル」とレジスタの送信者が同じであり、送信元アドレスが偽造されていません。 （つまり、RPはバブルでクッキーを挿入する、そしてそれは、レジスタメッセージ内に存在でなければならないであろう。）
It would be desirable to have some kind of state management for PIM Joins (and other messages) as well; for example, a "Join Ack" that could be used to ensure that the path to the source/RP actually exists. However, this is very difficult, if not impossible, with the current architecture: PIM messages are sent hop-by-hop, and there is not enough information to trace back the replies, for example, to notify the routers in the middle to release the corresponding state or to notify the DR that the path did not exist.
それだけでなく、PIM参加（および他のメッセージ）のための国家管理のいくつかの種類を持っていることが望ましいであろう。例えば、ソース/ RPへのパスが実際に存在することを確認するために使用され得る「ACKに参加します」。しかし、これは現在のアーキテクチャと、非常に困難、不可能ではないです：PIMメッセージはホップバイホップを送った、と応答をトレースバックするのに十分な情報がないとされ、例えば、解放するために途中でルータに通知します状態対応またはパスが存在しなかったことをDRに通知します。
Appendix B discusses this receiver-based remote routability signalling in more detail.
付録Bは、より詳細にこの受信機ベースのリモートルータビリティ・シグナリングを論じています。
There seem to be many ways to implement rate-limiting (for signalling, data encapsulation, and multicast traffic) at the DRs or RPs. The best approach likely depends on the threat model; for example, factors in the evaluation may include:
DRかのRPにレート制限（シグナリング、データのカプセル化、およびマルチキャストトラフィック用）を実装する多くの方法があるように思われます。最善のアプローチは、おそらく脅威モデルによって異なります。例えば、評価中の要因が挙げられます。
o Whether the host is willfully malicious, uncontrolled (e.g., virus/worm), or a regular user just doing something wrong.
ホストが故意に悪意があるかどうか、制御されていない（例えば、ウイルス/ワーム）、または通常のユーザーはただ何か間違ったことをやって、O。
o Whether the threat is aimed towards a single group, a single RP handling the group, or the (multicast) routing infrastructure in general.
脅威が単一のグループ、グループを取り扱う単一RP、または一般に（マルチキャスト）ルーティングインフラストラクチャに向かって目的としているかどうか、O。
o Whether the host on a subnet is spoofing its address (but still as one that fulfills the RPF checks of the DR).
サブネット上のホストがそのアドレスをスプーフィングしているかどうかO（まだDRのRPFチェックを満たすものとして）。
o Whether the host may generate the PIM join (and similar) messages itself to avoid rate-limiters at the DR, if possible.
PIMを生成することができるホストが参加（および同様の）メッセージかどうか可能であれば自体は、DRにレートリミッタを避けるために、O。
o Whether unicast RPF checks are applied on the link (i.e., whether the host can send register-encapsulated register-messages on its own).
ユニキャストRPFチェックはリンク上に適用されるかどうかは、O（すなわち、ホストは、独自に登録封入レジスタメッセージを送信できるかどうか）。
o Whether blocking the misbehaving host on a subnet is allowed to also block other, legitimate hosts on the same subnet.
サブネット上の誤動作ホストをブロックするかどうかOが、同じサブネット上の他、正当なホストをブロックすることができます。
o Whether these mechanisms would cause false positives on links with only properly working hosts if many of them are receivers or senders.
それらの多くは、受信機や送信者であれば、これらのメカニズムにのみ正常に動作し、ホストとのリンク上の偽陽性の原因となるかどうかは、O。
As should be obvious, there are many different scenarios here that seem to call for different kinds of solutions.
明らかであるように、ソリューションのさまざまな種類のために呼び出すように見えるここに多くの異なるシナリオがあります。
For example, the rate-limiting could be performed based on:
例えば、レート制限は、に基づいて実行することができます。
3. the (source address, multicast address) pair (or the RP that maps to the multicast address)
3.（ソースアドレス、マルチキャストアドレス）ペア（またはマルチキャストアドレスにマップRP）
5. everything (multicast groups and sources would not be distinguished at all)
5.すべて（マルチキャストグループとソースがすべてでは区別されません）
In the above, we assume that rate-limiting would be performed per-interface (on DRs) if a more fine-grained filter is not being used.
上記では、我々は、よりきめの細かいフィルタが使用されていない場合に律速ごとのインターフェイス（DRS上で）実行されると仮定する。
It should be noted that some of the rate-limiting functions can be used as a tool for DoS against legitimate multicast users. Therefore, several parameters for rate-limiting should be used to prevent such operation.
レート制限機能のいくつかは、正当なマルチキャストユーザに対するDoS攻撃のためのツールとして使用することができることに留意すべきです。したがって、レート制限のためのいくつかのパラメータは、このような操作を防止するために使用されるべきです。
These suggestions take two forms: limiters designed to be run on all the edge networks, preventing or limiting an attack in the first place, and the limiters designed to be run at the border of PIM domains or at the RPs, which should provide protection in case edge-based limiting fails or was not implemented, or when additional control is required.
すべてのエッジネットワーク上で動作するように設計されたリミッター、最初の場所での攻撃を予防または制限、およびPIMドメインの境界にまたはのRPで実行されるように設計されたリミッター、中に保護を提供する必要があります。これらの提案は、次の2つの形式を取りますケースのエッジベースの制限が失敗するか、実装されなかった、または追加の制御が必要な場合。
Almost none of the suggested rate-limiters take legitimate users into account. That is, being able to allow some hosts on a link to transmit/receive, while disallowing others, is very challenging to do right, because the attackers can easily circumvent such systems. Therefore, the intent is to limit the damage to only one link, one DR, or one RP -- and avoid the more global effects on the Internet multicast architecture.
提案レートリミッターのほとんどどれも考慮に正当なユーザーを取りません。それは他の人を禁止しながら、攻撃者が簡単にこのようなシステムを回避することができますので、右行うことは非常に困難である、送信/受信するためのリンクをいくつかのホストを許可することができること、です。インターネットマルチキャストアーキテクチャで、よりグローバルな影響を避ける - したがって、目的は一つだけのリンク、1 DR、または1つのRPへの損傷を制限することです。
Also, it is possible to perform white-listing of groups, sources, or (S,G) pairs from the rate-limiters so that packets related to these are not counted towards the limits. This is useful for handling an aggressive but legitimate source without modifying the limiting parameters for all the traffic, for example.
また、これらに関連するパケットが限界に向かってカウントされないように、レートリミッタから基、源、または（S、G）ペアのホワイトリストを行うことが可能となります。これは、例えば、すべてのトラフィックを制限するパラメータを変更することなく、積極的なが、合法的なソースを処理するのに便利です。
A Group Management Protocol rate-limiter is a token-bucket-based rate-limiter to all Group Management Protocols (IGMP, MLD) that would limit the average rate of accepted groups or sources on the specific interface, with a bucket of depth of G_DEPTH, refilling at G_RATE tokens per second. Example values could be G_RATE=1 and G_DEPTH=20. Note that, e.g., an IGMPv3 join with two included sources for one group would count as two groups/sources.
グループ管理プロトコルのレートリミッタはG_DEPTHの深さのバケツと、受け付けたグループまたは特定のインターフェイス上のソースの平均速度を制限するすべてのグループ管理プロトコル（IGMP、MLD）にトークンバケットベースのレートリミッタであります毎秒G_RATEトークンで補充します。値の例はG_RATE = 1とG_DEPTH = 20とすることができます。例えば、IGMPv3の1つのグループが2つのグループ/ソースとしてカウントになるために2つのソースを含めると結合なお。
This would be the first-order defense against state-creation attacks from the hosts. However, as it cannot be guaranteed that all the routers would implement something like this, other kinds of protections would be useful as well. This harms legitimate receivers on the same link as an attacker.
これは、ホストからの状態創造攻撃に対する一次防衛になります。それはすべてのルータがこのような何かを実装することを保証することはできませんしかし、保護の他の種類も同様に有用であろう。これは、攻撃者と同じリンク上の正当な受信者に害を与えます。
A source transmission rate-limiter is a token-bucket-based rate-limiter that would limit the multicast data transmission (excluding link-local groups) on a specific interface with a bucket of depth of GSEND_DEPTH, refilling at GSEND_RATE tokens per second. Example values could be GSEND_RATE=10 and GSEND_DEPTH=20.
送信元送信レートリミッタは、毎秒GSEND_RATEトークンで補充、GSEND_DEPTHの深さのバケツと特定のインターフェイス上で（リンクローカルグループを除く）のマルチキャストデータの送信を制限するトークンバケットベースのレートリミッタです。値の例はGSEND_RATE = 10とGSEND_DEPTH = 20とすることができます。
This would be the first-order defense against data flooding attacks. However, as it cannot be guaranteed that all routers would implement something like this, and as the RP (if SSM is not used) could be loaded from multiple senders, additional protections are needed as well. This harms legitimate senders on the same link as an attacker. This does not prevent a host from sending a lot of traffic to the same group -- an action that would harm only the DR and the RP of the group, is similar to unicast DoS attacks against one source, and is not considered critical to the overall security.
これは、データの氾濫攻撃に対する一次防衛になります。しかし、（SSMが使用されていない場合）には、すべてのルータがこのような何かを実装することを保証し、RPとすることができないように、追加の保護が同様に必要とされ、複数の送信者からロードすることができました。これは、攻撃者と同じリンク上の正当な送信者に害を与えます。これは、同じグループに多くのトラフィックを送信してからホストを防ぐことはできません - だけでDRグループのRPを害する行為は、1つのソースに対してDoS攻撃をユニキャストに似ている、とするために重要と考えられていません全体的なセキュリティ。
A PIM signalling rate-limiter is a token-bucket-based rate-limiter that would limit all multicast PIM messaging, either through a specific interface or globally on the router, with a bucket of depth of PIM_DEPTH, refilling at PIM_RATE tokens per second. Example values could be PIM_RATE=1000 and PIM_DEPTH=10000.
レートリミッタシグナリングPIMは、毎秒PIM_RATEトークンで補充、PIM_DEPTHの深さのバケツと、特定のインターフェイスを介して、またはグローバルルータのいずれか、すべてのマルチキャストPIMメッセージングを制限するトークンバケットベースのレートリミッタです。値の例はPIM_RATE = 1000とPIM_DEPTH = 10000である可能性があります。
This would be second-order defense against PIM state attacks when IGMP/MLD rate-limiters haven't been implemented or haven't been effective. This limiter might not need to be active by default, as long as the values are configurable. The main applicability for this filter would be at a border of PIM domain in case PIM state attacks are detected. This harms legitimate receivers as well.
これは、IGMP / MLD率-リミッターが実装されていないか、有効でなかったPIM状態攻撃に対する二次防衛になります。このリミッタは限り値は設定されているように、デフォルトでアクティブである必要はないかもしれません。 PIM状態の攻撃が検出された場合には、このフィルタの主な適用は、PIMドメインの境界になります。これは、同様に正当な受信機に害を与えます。
A unicast-decapsulation rate-limiter is a simple decapsulation rate-limiter that would protect the CPU usage in the router by limiting the packets per second (depending on the router architecture) and disregarding the source of the registers. This could also be an additional check to be used before decapsulation and checking the group to throttle the worst of the decapsulation CPU consumption. This limit should have to be quite high, and would hamper the existing legitimate sessions as well.
ユニキャストデカプセル化レートリミッタは、（ルータアーキテクチャに応じて）秒あたりのパケットを制限し、レジスタのソースを無視することによって、ルータのCPU使用率を保護する単純なデカプセル化率リミッタです。これはまた、非カプセル化前とカプセル化解除のCPU消費量の最悪を絞るためにグループをチェックし、使用する追加のチェックである可能性があります。この制限は非常に高くなければなければならない、とだけでなく、既存の合法的なセッションを妨げるだろう。
A PIM Register rate-limiter is a token-bucket-based rate-limiter that would limit register decapsulation of PIM Register messages with a bucket of depth of REG_DEPTH, refilling at REG_RATE tokens per second. If the router has restarted recently, a larger initial bucket should be used. Example values could be REG_RATE=1 and REG_DEPTH=10 (or REG_DEPTH=500 after restart).
PIMレジスタレートリミッタは、毎秒REG_RATEトークンで詰め替え、REG_DEPTHの深さのバケツにPIM Registerメッセージのカプセル化解除を登録制限するトークンバケットベースのレートリミッタです。ルータが最近再起動した場合は、より大きな初期のバケットを使用する必要があります。値の例はREG_RATE = 1とREG_DEPTH = 10（又はREG_DEPTH = 500再起動後）であってもよいです。
This would be second-order defense against data flooding: if the DRs would not implement appropriate limiters, or if the total number of flooded groups rises too high, the RP should be able to limit the rate with which new groups are created. This does not harm legitimate senders, as long as their groups have already been created.
これは、データの洪水に対する二次防衛のようになります。DRSが適切なリミッターを実装していないだろう、あるいは浸水基の合計数が高すぎる上昇した場合、RPは、新しいグループが作成されるとのレートを制限することができる必要があります。これは、限り、彼らのグループがすでに作成されているとして、正当な送信者に悪影響を及ぼすことはありません。
A MSDP source-active rate-limiter is a token-bucket-based, source-based rate-limiter, that would limit new groups per source with a bucket of depth of SAG_DEPTH, refilling at SAG_RATE tokens per second. Example values could be SAG_RATE=1 and SAG_DEPTH=10.
MSDPのソースアクティブレートリミッタは、毎秒SAG_RATEトークンで補充、SAG_DEPTHの深さのバケツとソースごとに新しいグループを制限するトークンバケットベース、ソースベースのレートリミッタです。値の例はSAG_RATE = 1とSAG_DEPTH = 10とすることができます。
This would be second-order defense, at both the MSDP SA sending and receiving sites, against data flooding and MSDP vulnerabilities in particular. The specific threat being addressed here is a source (or multiple different sources) trying to "probe" (e.g., virus or worm) different multicast addresses. [16] discusses different MSDP attack prevention mechanisms at length.
これは、MSDP SAは、データの洪水、特にMSDPの脆弱性に対して、サイトを送信および受信の両方で、二次防衛になります。ここで扱われている特定の脅威は「プローブ」（例えば、ウイルスやワーム）異なるマルチキャストアドレスにしようと、ソース（または複数の異なるソース）です。 [16]の長さで異なるMSDP攻撃防止メカニズムを説明します。
As described in the last paragraph of Section 3, hosts are also able to form PIM adjacencies and send disrupting traffic unless great care is observed at the routers. This stems from the fact that most implementations require that stub LANs with only one PIM router must also have PIM enabled (to enable PIM processing of the sourced data, etc.) Such stub networks however do not require to actually run the PIM protocol on the link. 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.
第3節の最後の段落で説明したように、ホストはまた、PIMの隣接関係を形成し、細心の注意がルーターで観測されていない限り、トラフィックを中断送信することができます。これは、ほとんどの実装は唯一のPIMルータとスタブLANはまた、PIMは、このようなスタブネットワークは、しかし、実際にPIMプロトコルを実行する必要はありません（ソースデータなどのPIM処理を有効にする）が有効になっている必要があることを必要とするという事実から茎リンク。 （受信された場合）は、PIMパケットは送信されないか、または処理されるが、ホストはまだそのインターフェイス上でマルチキャストを送信および受信することができる。したがって、そのような実装は、インタフェースがPIMに関して「受動的」であることを指定するオプションを提供すべきです。
This memo analyzes the security of PIM routing infrastructures in some detail and proposes enhancements to mitigate the observed threats.
このメモは、いくつかの詳細にPIMルーティングインフラストラクチャのセキュリティを分析し、観測された脅威を軽減するための機能強化を提案しています。
This document does not discuss adding (strong) authentication to the multicast protocols. The PIM-SM specification [1] describes the application of IPsec for routing authentication; note that being able to authenticate the register messages and to prevent illegitimate users from establishing PIM adjacencies seem to be the two most important goals. The IGMPv3 specification [11] describes the use of IPsec for group management (IPsec for MLDv2 may be applied similarly), which is out of scope for this memo. However, note that being able to control the group memberships might reduce the receiver-based attacks.
この文書では、マルチキャストプロトコルに（強い）の認証を追加することについては説明しません。 PIM-SM仕様は、[1]認証をルーティングするためのIPsecの適用を記載します。登録メッセージを認証し、PIMの隣接関係を確立するから違法なユーザーを防ぐためにできることは、2つの最も重要な目標であると思われることに注意してください。 IGMPv3の仕様[11]は、このメモの範囲外であるグループ管理（MLDv2のためにIPsecを同様に適用することができる）、のためのIPsecの使用を記載しています。しかし、受信機ベースの攻撃を減らす可能性があるグループのメンバーシップを制御することができることに注意してください。
However, one should keep in mind two caveats: authentication alone might not be sufficient, especially if the user or the host stack (consider a worm propagation scenario) cannot be expected to "behave well"; and adding such authentication likely provides new attack vectors, e.g., in the form of a CPU DoS attack with an excessive amount of cryptographic operations.
しかし、人は心の中で2回の警告を維持する必要があります：認証のみで、ユーザまたはホストスタックは、（ワームの伝播のシナリオを考える）「行儀よく」と期待することができない場合は特に、十分ではないかもしれません。そしておそらくそのような認証を追加すると、暗号化操作の過剰量とCPU DoS攻撃の形で、例えば、新たな攻撃ベクターを提供します。
Kamil Sarac discussed "return routability" issues at length. Stig Venaas and Bharat Joshi provided feedback to improve the document quality. Bill Fenner and Russ Housley provided useful comments during the IESG evaluation.
カミルSaracは長さで、「リターン・ルータビリティ」の問題を議論しました。スティグVenaasとバーラトJoshi氏は、文書の品質を向上させるためにフィードバックを提供します。ビルフェナーとラスHousleyはIESG評価の中に有益なコメントを提供しました。
[1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[1]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月を。
[2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[2]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[3]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[4] Savola、P.とB.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。
[5] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, July 2006.
[5] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 4593、2006年7月を。
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[6]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[7] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[7]バッタチャリヤ、S.、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月を。
[8] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[8]ターラー、D.、フェナー、B.、およびB.クイン、 "マルチキャストソースフィルタのためのソケットインタフェース拡張"、RFC 3678、2004年1月。
[9] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[9] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、RFC 3740、2004年3月。
[10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", Work in Progress, July 2004.
[10]デイリー、G.とG. Kurup、「信頼モデルとマルチキャストリスナ発見のセキュリティ」、進歩、2004年7月に作業。
[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[11]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[12]ヴィーダ、R.とL.コスタ、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月。
[13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[13]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
[14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[14]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[15] Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Work in Progress, October 2005.
[15]ハンドレー、M.、 "双方向プロトコル独立マルチキャスト（BIDIR-PIM）"、進歩、2005年10月に働いています。
[16] Rajvaidya, P., Ramachandran, K., and K. Almeroth, "Detection and Deflection of DoS Attacks Against the Multicast Source Discovery Protocol", UCSB Technical Report, May 2003.
[16] Rajvaidya、P.、ラマチャンドラン、K.、およびK. Almeroth、UCSB技術報告書、2003年5月 "マルチキャストソース発見プロトコルに対するDoS攻撃の検出とたわみ"。
Appendix A. RPF Considers Interface, Not Neighbor
付録A. RPFは、インターフェイス、ない隣人を考慮します
In most current implementations, the RPF check considers only the incoming interface, and not the upstream neighbor (RPF neighbor).
ほとんどの現在の実装では、RPFチェックは、着信インターフェイスはなく、上流隣接（RPFネイバー）を考慮する。
This can result in accepting packets from the "wrong" RPF neighbor (the neighbor is "wrong" since, while the RPF check succeeds and the packet is forwarded, the unicast policy would not have forwarded the packet).
これは、「間違った」RPF隣人（隣人がRPFチェックが成功した一方で、以来、「間違った」で、パケットが転送され、ユニキャストポリシーがパケットを転送していないだろう）からのパケットを受け入れるにつながることができます。
This is a problem in the media where more than two routers can connect to, in particular, Ethernet-based Internet Exchanges. Therefore, any neighbor on such a link could inject any PIM signalling as long as a route matching the address used in the signalling is going through the interface.
これは、二つ以上のルータが特定の、イーサネットベースのインターネット取引所では、に接続できるメディアで問題となっています。したがって、そのようなリンク上のネイバーがシグナリングに使用されるアドレスと一致するルートがインタフェースを介して起こっている限り、シグナル伝達の任意のPIMを注入することができました。
Note that for PIM signalling to be accepted, a PIM adjacency must have been established. However, typically, this does not help much against willful attackers, as PIM adjacencies are usually formed with anyone on the link. Still, the requirement is that the neighbor has enabled PIM in the concerned interface. That is, in most cases, the threat is limited to attackers within the operators in the exchange, not third parties. On the other hand, data plane forwarding has no such checks -- and having such checks would require that one look at the link-layer addresses used. That is, this checking is not as feasible as one might hope.
PIMが受け入れられるために、シグナリングのために、PIMの隣接関係が確立されている必要があることに注意してください。 PIM隣接関係は通常、リンク上の誰もが形成されているようしかし、一般的に、これは、故意の攻撃に対してあまり役立ちません。それでも、要件は、隣人が心配インターフェイスでPIMを有効にしているということです。これは、ほとんどの場合、脅威は交換、ない第三者に事業者の中に、攻撃者に限定されています。一方、データプレーン転送は、そのようなチェックを持っていない - このようなチェックを有するリンク層アドレスに1つのルックを使用することを必要とするであろう。つまり、このチェックは1つが願うかもしれないほど現実的ではありません。
Appendix B. Return Routability Extensions
付録B.リターンルータビリティ拡張機能
The multicast state information is built from the receiver side, and it can be currently pruned only by the receiver-side DR. If the RP or the source for the group is non-existent, the state can't be pruned by the DR without return routability extensions to provide such information. There might also be a need to remove the state in some cases when there is no multicast traffic sent to that group. This section discusses the alternative ways to remove the unused state information in the routers, so that it can't be used in state-based DoS attacks. Note that rate-limiting PIM Joins gives some protection against the state attacks.
マルチキャスト状態情報は、受信側から構築され、それは現在だけ受信側DRによって剪定することができます。 RPまたはグループのソースが存在しない場合には、状態は、そのような情報を提供するために、リターン・ルータビリティ拡張せずにDRによって剪定することはできません。また、そのグループに送信されたマルチキャストトラフィックがない場合にいくつかのケースでは状態を除去する必要があるかもしれません。このセクションでは、状態ベースのDoS攻撃に使用することができないように、ルータに未使用の状態情報を削除する別の方法について説明します。レート制限PIMジョインことに注意してください状態攻撃に対する何らかの保護を提供します。
B.1. Sending PIM-Prune Messages Down the Tree
B.1。ツリーの下PIM-プルーンのメッセージの送信
When a router discovers the non-existence of the RP or the source, it can create a PIM-Prune message and send it back to the join originator. However, since it does not know the unicast IP address of join originator DR, it cannot directly unicast it to that router.
ルータがRPかソースの非存在を検出すると、PIM-Pruneメッセージを作成し、参加元に戻ってそれを送ることができます。それは参加創始DRのユニキャストIPアドレスを知らないので、それは直接そのルータにそれをユニキャストすることはできません。
A possible alternative is to use a link-local multicast group address (e.g., all-pim routers local multicast address) to pass this information back toward the joining DR. Since the routers from this current router all the way back to the joining DR have forwarding state entry for the group, they can use this state information to see how to forward the PIM-Prune message back.
可能な代替は、接合DR向かっバックこの情報を渡すためにリンクローカルマルチキャストグループアドレス（例えば、すべてのPIMルータのローカルマルチキャストアドレス）を使用することです。この現在のルータからルータが戻って参加するDRへのすべての方法は、グループの状態エントリを転送しているので、彼らは戻ってPIM-プルーンのメッセージを転送する方法を確認するには、この状態情報を使用することができます。
Each on-tree router, in addition to forwarding the PIM-Prune message, can also prune the state from its state tables. This way, the PIM-Prune message will go back to the DR by following the multicast forwarding state information created so far. In addition, if we use some sort of RPF checks during this process, we can also make it more difficult to inject such PIM-Prune messages maliciously.
各オンツリールータは、PIM-プルーンメッセージを転送することに加えて、また、その状態テーブルから状態を剪定することができます。この方法では、PIM-プルーンのメッセージは、これまでに作成したマルチキャスト転送状態の情報を、以下によりDRに戻ります。私たちはこのプロセス中にRPFチェックのいくつかの並べ替えを使用した場合に加えて、我々はまた、それはより困難悪意を持って、このようなPIM-プルーンのメッセージを注入することができます。
A potential abuse scenario may involve an attacker that has access to a router on the direct path and can send such PIM-Prune messages down the tree branch so as to prune the branch from the tree. But such an attacker can currently achieve the same effect by sending a PIM-Prune message toward the source from the same point on the tree. So, the proposed mechanism does not really aggravate the situation.
潜在的な虐待のシナリオは、直接経路上のルータへのアクセス権を持つ攻撃者を含むことができるし、木から枝を剪定するように木の枝の下、このようなPIM-プルーンメッセージを送信することができます。しかし、このような攻撃者は、現在のツリー上の同じ点からソースに向かってPIM-Pruneメッセージを送信することによって、同じ効果を得ることができます。だから、提案されたメカニズムは、実際に状況を悪化させていません。
One visible overhead in this new scenario might be that someone can send bogus join messages to create redundant PIM-Join and PIM-Prune messages in the network.
この新しいシナリオでは一つ目に見えるオーバーヘッドは、誰かがネットワーク内の冗長PIM-参加し、PIM-プルーンのメッセージを作成するために、偽のJoinメッセージを送信できることかもしれません。
B.2. Analyzing Multicast Group Traffic at DR
B.2。 DRでマルチキャストグループトラフィックの分析
Another possible way to remove the unused state information would be to analyze individual group traffic at the DR and if there is no multicast traffic for a certain group within a certain time limit, the state should be removed. In here, if the receiver is malicious and wants to create states in the network, then it can send joins to different groups and create states on routers for each of these different groups until the DR decides that the groups are inactive and initiates the prune process. In addition, during the prune process, the routers will again process all these prune messages and therefore will be spending time.
未使用状態情報を削除するための別の可能な方法は、DRで個々のグループのトラフィックを分析することであろうと、特定の期間内に特定のグループのためのマルチキャストトラフィックがない場合、状態は除去されるべきです。ここで、受信機が悪意のあるで、ネットワーク内の状態を作成したい場合は、それを送ることができます別のグループに参加し、DRは、グループが非アクティブであると判断し、プルーンプロセスを開始するまで、これらの異なるグループごとに、ルータ上での状態を作成します。また、プルーンプロセスの間に、ルータは再び時間を過ごすことになるので、これらすべてのプルーンのメッセージを処理します。
B.3. Comparison of the Above Approaches
B.3。上記のアプローチの比較
Both of these solutions have the same problem of renewing the multicast state information. The DR shouldn't permanently block the state building for that group, but should restrict the PIM Joins if it notices that the receiver is abusing the system. One additional option is to block the PIM Joins to the non-existent source/RP for a certain time.
これらのソリューションの両方がマルチキャスト状態情報を更新するのと同じ問題を抱えています。 DRは、恒久的にそのグループの状態の建物をブロックしてはならないが、それは、受信機がシステムを悪用していることに気付く場合PIMジョイン制限するべきです。一つの追加オプションは、PIMは、特定の時間のために、存在しないソース/ RPへの参加阻止することです。
In the first approach (sending PIM-Prunes down the tree), part of the goal was to prune the states in the routers much sooner than in the second approach. (That is, the goal is to make sure that the routers will not be keeping unnecessary states for long time.)
第1のアプローチでは、目標の一部（ツリーダウンPIM-プルーンを送信する）はるかに早く第二のアプローチに比べてルータ内の状態を整理することでした。 （それは目標はルータが長い時間のために不必要な状態を維持されないことを確認することです、です。）
The second approach works also for DoS attacks related to the existing source/RP addresses, could be more quickly implemented and deployed in the network, and does not have any relationship with the other deployments (no need to change all PIM routers).
第2のアプローチは、より迅速に実装し、ネットワークに展開することができ、既存のソース/ RPアドレスに関連するDoS攻撃のためにも動作し、他の展開で任意の関係（すべてのPIMルータを変更する必要はありません）がありません。
Authors' Addresses
著者のアドレス
Pekka Savola CSC/FUNET Espoo Finland
ペッカSavola CSC / FUNETエスポーフィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Rami Lehtonen TeliaSonera Hataanpaan valtatie 20 Tampere 33100 Finland
ラミLehtonenのテリアソネラHataanpaanハイウェイ20 33100タンペレフィンランド
EMail: rami.lehtonen@teliasonera.com
メールアドレス：rami.lehtonen@teliasonera.com
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
メールアドレス：dmm@1-4-5.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。