[要約] 要約： RFC 4609は、PIM-SMマルチキャストルーティングのセキュリティ問題と改善策について説明しています。目的： このRFCの目的は、PIM-SMマルチキャストルーティングのセキュリティ上の問題を特定し、それに対する解決策を提案することです。
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
プロトコル独立マルチキャスト - スパースモード（PIM -SM）マルチキャストルーティングセキュリティの問題と拡張
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).
Copyright（c）The Internet Society（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）のみが分析され、3つの主要な運用モード：従来の任意のソースマルチキャスト（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レジスタメッセージのソースを押し付けることができます。
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.
PIM-SM [1]は、ソース固有のマルチキャスト[3]（SSM）で、従来の任意のソースマルチキャスト（ASM）モデル（ソース発見のためのマルチキャストソースディスカバリープロトコル（MSDP）[2]の使用を含む）で動作すると考えています。モデル、およびASMモデルの埋め込みRP [4]グループ間マッピングメカニズム。双方向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.
「Embedded-RP」とは、埋め込まれたRPマッピングメカニズムを使用してグループのランデブーポイント（RP）を見つけるために使用され、MSDPは使用されないASMモデルを指します。
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).
「ターゲットルーター」は、パケット（ASMまたは埋め込みRP）のRP処理または受信（ソース、グループ）（または（s、g））が結合する（すべてのモデル）（すべてのモデルで）（または（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]に似ています。Bootstrapルーター（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は、RPFチェックが適用されない場合（特に、スタブLANネットワークで）乱用する可能性があります。たとえば、ホストはサブネットのDRになることに選出される可能性がありますが、その機能を実行しません。ホストは、PIMアサートメッセージを送信して、リンク上のPIMルーターをマルチキャストの転送を停止することも簡単に作成できます。これは、故意の攻撃者が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チャネルに1回または数回参加しようとすると、ホストが1回または数回参加しようとすると、DRがPIM結合をターゲットルーターに生成すると、洪水が発生します。Group/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結合メッセージのみを送信することに注意してください。次のメッセージは、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.
この種の結合により、PIM状態が作成されますが、この状態は比較的短命です（デフォルトでは260秒です。これは、IGMP/ MLDレポート/葉がない場合に州がDRでアクティブであるデフォルトの時間です）。ホストは、1つのIGMPV3 [11]またはMLDV2 [12]レポートのみで多数の異なるASMグループまたはSSMチャネルに参加できることに注意してください。/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レポートのホストによって指定された場合、以下の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.
o 埋め込みRP：（*、g）結合は、グループGに埋め込まれたインター/ドメイン内RPに向けて送信され、そのパスに状態が発生します。RPが存在しない場合、結合はRPアドレスに最も近いルーターに移動します。同様に、上記のSSMと同様に、明示的な（s、g）結合は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と埋め込み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アドレスがグループアドレスから抽出される埋め込み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.
たとえば、ホストが100個のIgmpv3（s、g）を生成できる場合、それぞれ10個のソースを搭載し、260秒後の状態は260 000の州のエントリになり、秒あたり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.
レジスタカプセル化はRPFチェックの対象ではないため、ホストはこれらのパケットを作成および送信することもできます。また、イングレスフィルタリング[13]が展開されていない限り、レジスタメッセージのソースアドレスをスプーフィングすることもできます[14]。つまり、最初のデータ登録は他の多くのマルチキャストルーティング手順と同じ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.
o マルチキャストツリーに大量のデータが転送されるため、マルチキャスト転送がCPUで実行される場合、それは深刻なパフォーマンスボトルネックであり、パスで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と埋め込みRPに関連しています。
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と埋め込みRPを使用すると、ソースはRPSを介して偽造トラフィックを注入でき、グループのソース発見を提供します。RPSは、共有ツリーを介してトラフィックをレシーバー（（*、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および埋め込み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は、グループごとに1つの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メッセージで使用されるアドレスが有効であると想定していることに注意してください。ただし、これを確保する方法はなく、存在しないsまたはg in（*、g）または（s、g）メッセージを使用すると、アドレスに到達できなくてもシグナリングが設定されます。
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.
受信機に直接接続されているDRのみが、正確なレシーバー情報（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を使用すると、ホストは特定のグループ（またはグループのセット）のRPを決定することができ、ホストがPIMレジスタ攻撃を取り付けることができます。この場合、ホストは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はレジスタのカプセル化を評価する必要があります（ホストはこれを回避できることに注意してください）。さらに重要なことは、RPSは、特に異なるソースからのレジスタの脱カプセル化を評価する必要があるか、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 博士は、ピムが参加し、プルーンを何らかの形で評価する必要があります。これを考慮する必要がある複数の方法があります（つまり、どの変数が考慮されるかによって異なります）。
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 博士は、何らかの形でレジスタのカプセル化を評価することができます。これを実行するには複数の方法があります。ホストは、そのように傾いている場合、レジスタカプセル化自体を実行することでこれを回避できることに注意してください。
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 RPSは、何らかの形で登録崩壊を評価することができます。これを実行するには複数の方法があります。ユニキャストパケットのソースがホストによってスプーフィングされている場合、これは（たとえば）レート制限者の振る舞いに影響を与える可能性があることに注意してください。
o RPs should rate-limit the MSDP SA messages coming from MSDP peers.
o RPSは、MSDPピアからのMSDP SAメッセージを評価する必要があります。
o RPs could limit or even disable the SA cache size. However, this could have negative effects on normal operation.
o RPSは、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 RPSは、面白くないパケットを拒否するための適切なインターフェイスを提供する必要があります。たとえば、埋め込み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で説明したように、存在しないDRSまたはRPSは、マルチキャスト状態を設定する際にいくつかの問題を引き起こす可能性があります。特にレート制限が広範囲に展開されていない場合、これを軽減するためのいくつかの異なるアプローチがあるようです。
With ASM and Embedded-RP, Register message delivery could be ensured somehow. For example:
ASMと組み込みRPを使用すると、登録メッセージ配信をどうにか保証できます。例えば：
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) 少なくとも、RPがとにかく受信しないため、ICMPの到達不可能なメッセージ（任意のフレーバーの）を受信すると、DRがレジスタパケットを停止させるはずです。（ただし、このような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.)
2) 追加の方法は、DRSにタイマーを実装することで、定義された期間内にRPから何も聞かない限り、レジスタメッセージのフローが停止します。（現在、RPSは、ソースに参加したい場合を除き、返事をする必要はありません。）
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はバブルにCookieを挿入し、レジスタメッセージに存在する必要があります。）
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:
DRSまたはRPSにレート制限（シグナル伝達、データカプセル化、マルチキャストトラフィック）を実装する多くの方法があるようです。最良のアプローチは、おそらく脅威モデルに依存します。たとえば、評価の要因には以下が含まれます。
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.
o 脅威が単一のグループ、グループを処理する単一のRP、または一般的な（マルチキャスト）ルーティングインフラストラクチャを対象としているかどうか。
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.
o ホストがPIM結合（および同様の）メッセージ自体を生成して、可能であればDRの料金制限を避けることができるかどうか。
o Whether unicast RPF checks are applied on the link (i.e., whether the host can send register-encapsulated register-messages on its own).
o ユニキャストRPFチェックがリンクに適用されているかどうか（つまり、ホストがレジスタにカプセル化されたレジスタメッセージを単独で送信できるかどうか）。
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:
たとえば、レート制限は以下に基づいて実行できます。
1. multicast address, or the RP where the multicast address maps to
1. マルチキャストアドレス、またはマルチキャストアドレスがマップするRP
2. source address
2. ソースアドレス
3. the (source address, multicast address) pair (or the RP that maps to the multicast address)
3. （ソースアドレス、マルチキャストアドレス）ペア（またはマルチキャストアドレスにマップするRP）
4. data rate, in case of rate-limiting the source
4. ソースをレート制限する場合のデータレート
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.
上記では、より微細に粒のフィルターが使用されていない場合、interfaceごとにレート制限が実行されると想定しています。
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ドメインの境界またはRPSで実行されるように設計されたリミッターを使用します。ケースエッジベースの制限が失敗するか、実装されていない、または追加の制御が必要な場合。
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つのリンク、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.
グループ管理プロトコルレートリミッターは、すべてのグループ管理プロトコル（IGMP、MLD）に対するトークンバケットベースのレートリミッターであり、特定のインターフェイス上の受け入れられたグループまたはソースの平均レートを制限し、G_DEPTHの深さのバケツを制限します。、G_rateトークンで1秒間補充します。例の値は、g_rate = 1およびg_depth = 20です。たとえば、1つのグループの2つの含まれたソースと結合するIGMPV3は、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.
これは、ホストからの状態創造攻撃に対する1次防衛です。ただし、すべてのルーターがこのようなものを実装することを保証することはできないため、他の種類の保護も有用です。これは、攻撃者と同じリンク上の合法的なレシーバーに害を及ぼします。
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_DEPTHのバケツのバケツのバケツで特定のインターフェイスでマルチキャストデータ送信（リンクローカルグループを除く）を制限し、GSEND_RATEトークンで1秒あたりの補充を制限します。例の値は、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.
これは、データの洪水攻撃に対する1次防衛です。ただし、すべてのルーターがこのようなものを実装することを保証できないため、RP（SSMが使用されていない場合）を複数の送信者からロードできるため、追加の保護も必要です。これは、攻撃者と同じリンク上の合法的な送信者に害を及ぼします。これは、ホストが同じグループに多くのトラフィックを送信することを妨げるものではありません。これは、グループの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_DEPTHのバケツで、PIM_RATEトークンで補充されたルーター上のすべてのマルチキャスト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状態攻撃に対する2次防御となります。このリミッターは、値が構成可能である限り、デフォルトでアクティブである必要はない場合があります。このフィルターの主な適用性は、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.
ユニキャスト除去速度リミッターは、1秒あたりのパケットを制限し（ルーターアーキテクチャに応じて）、レジスタのソースを無視することにより、ルーターの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_depthの深さのバケツでPIMレジスタメッセージのレジスタの脱カプセル化を制限するトークンバケットベースのレートリミッターであり、reg_rateトークンで1秒あたりの深さで補充されます。ルーターが最近再起動した場合、より大きな初期バケットを使用する必要があります。例の値は、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_DEPTHの深さのバケツでソースごとに新しいグループを制限し、SAG_RateトークンあたりSAG_RATEトークンで補充します。例の値は、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の脆弱性に対して、サイトの送信および受信サイトの両方で2次防御となります。ここで対処されている特定の脅威は、さまざまなマルチキャストアドレスを「プローブ」（ウイルスやワームなど）にしようとするソース（または複数の異なるソース）です。[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の隣接を形成し、破壊するトラフィックを送信することもできます。これは、ほとんどの実装では、1つの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]は、グループ管理にIPSECの使用を説明しています（MLDV2の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.
Kamil Saracは、「Return rusidability」の問題について長々と議論しました。Stig VenaasとBharat Joshiは、ドキュメントの品質を向上させるためのフィードバックを提供しました。Bill FennerとRuss 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] Fenner、B.、Handley、M.、Holbrook、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] Fenner、B。およびD. Meyer、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[3] Holbrook、H。およびB. Cain、「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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（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.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年7月。
[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[6] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[7] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[7] Bhattacharyya、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] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルター用のソケットインターフェイス拡張」、RFC 3678、2004年1月。
[9] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[9] Hardjono、T。およびB. Weis、「マルチキャストグループセキュリティアーキテクチャ」、RFC 3740、2004年3月。
[10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", Work in Progress, July 2004.
[10] Daley、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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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] Vida、R。およびL. Costa、「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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[14] Baker、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] Handley、M。、「Bi-Directional Protocol Independent Multicast（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.、Ramachandran、K。、およびK. Almeroth、「マルチキャストソース発見プロトコルに対するDOS攻撃の検出とたわみ」、UCSBテクニカルレポート、2003年5月。
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.
これは、特にイーサネットベースのインターネット交換に2つ以上のルーターが接続できるメディアでの問題です。したがって、このようなリンクの隣人は、信号で使用されるアドレスに一致するルートがインターフェイスを通過している限り、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を有効にしたことです。つまり、ほとんどの場合、脅威は、第三者ではなく、交換のオペレーター内の攻撃者に限定されています。一方、データプレーンの転送にはそのようなチェックはありません。そのようなチェックを使用すると、使用されるリンク層アドレスを見る必要があります。つまり、このチェックは、期待するほど実行可能ではありません。
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結合は、州の攻撃に対するある程度の保護を与えることに注意してください。
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メッセージを作成してJoin Originatorに送信できます。ただし、Join Originator 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.
考えられる代替案は、Link-Local Multicast Groupアドレス（例：All-PIM Routersローカルマルチキャストアドレスなど）を使用して、この情報を参加DRに渡すことです。この現在のルーターからのルーターは、グループのフォワーディング状態エントリを搭載しているため、この状態情報を使用してPim-Pruneメッセージを転送する方法を確認することができます。
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-Pruneメッセージの転送に加えて、各オントリールーターは、状態テーブルから状態を剪定することもできます。このようにして、PIM-Pruneメッセージは、これまでに作成されたマルチキャスト転送状態情報に従ってDRに戻ります。さらに、このプロセス中にある種のRPFチェックを使用すると、このようなPIM-Pruneメッセージを悪意を持って挿入することをより困難にすることもできます。
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メッセージをツリーブランチに送信して、枝をツリーから剪定することができます。しかし、このような攻撃者は現在、ツリー上の同じポイントからソースに向かって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.
この新しいシナリオで目に見えるオーバーヘッドの1つは、誰かがBogus結合メッセージを送信して、ネットワークに冗長PIM結合とPIM-Pim-Pim-Pruneメッセージを作成できることです。
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がグループが非アクティブであると判断し、プルーンプロセスを開始するまで、これらの異なるグループの各グループに別のグループに結合を送信して作成できます。。さらに、プルーンプロセス中に、ルーターはこれらすべてのプルーンメッセージを再度処理するため、時間を費やします。
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結合を制限する必要があります。追加のオプションの1つは、特定の時間の間、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.)
最初のアプローチ（PIM-PIM-PRUNESをツリーに送信する）では、目標の一部は、2番目のアプローチよりもはるかに早くルーターの状態を剪定することでした。（つまり、目標は、ルーターが長期にわたって不必要な状態を維持しないことを確認することです。）
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
Pekka Savola CSC/Funet Espoo Finland
EMail: psavola@funet.fi
Rami Lehtonen TeliaSonera Hataanpaan valtatie 20 Tampere 33100 Finland
ラミ・レートンネン・テリアソネラ・ハタンパーン・ヴァルタティ20タンペレ33100フィンランド
EMail: rami.lehtonen@teliasonera.com
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。