RFC4609 日本語訳
4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) MulticastRouting Security Issues and Enhancements. P. Savola, R. Lehtonen, D.Meyer. October 2006. (Format: TXT=49812 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Savola
Request for Comments: 4609 CSC/FUNET
Category: Informational R. Lehtonen
TeliaSonera
D. Meyer
August 2006
Savolaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4609年のCSC/FUNETカテゴリ: 情報のR.レヒトネンTeliaSonera D.マイヤー2006年8月
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)インターネット協会(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.
このメモは、より大きい(イントラドメインか相互ドメイン)マルチキャストルーティングインフラストラクチャのための軍事的脅威について説明します。 プロトコル無党派Multicastだけ--まばらなMode(PIM-SM)は3つの主な操作上のモードで分析されます: 伝統的なAny-ソースMulticast(ASM)はモデル化します、(SSM)がモデル化して、ASMモデルがEmbedded Rendezvous Point(埋め込まれたRP)グループからRPへのマッピングメカニズムで高めたソース特有のマルチキャスト。 また、このメモは特定された脅威を緩和するプロトコル操作に増進について説明します。
Savola, et al. Informational [Page 1] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[1ページ]のRFC4609PIM-Smマルチキャスト
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
1. 序論…3 2. 用語…4 3. マルチキャストルート設定への脅威…4 3.1. 受信機ベースの攻撃…5 3.1.1. 異なったグループ(氾濫を接合する)につなぎます…5 3.2. ソースベースの攻撃…7 3.2.1. 空にする送付マルチキャストは(データ氾濫)を分類します…7 3.2.2. 存在を擾乱して、それ(グループ整合性違反)に発信することによって、分類してください…8 3.3. 要素を脅威にいらいらさせます…9 3.3.1. 遠方のRP/ソース問題…9 3.3.2. PIMの受信機情報は全く接合しません…10 4. 脅威分析…10 4.1. 脅威の概要…10 4.2. 脅威緩和のための増進…10 5. PIMセキュリティ増進…11 5.1. リモートRoutability合図…11 5.2. レートを制限するポシビリティーズ…12 5.3. 特定のレート制限提案…14 5.3.1. 集団経営はレートリミタについて議定書の中で述べます…14 5.3.2. ソース通信速度リミタ…14 5.3.3. PIM合図レートリミタ…15 5.3.4. ユニキャスト被膜剥離術レートリミタ…15 5.3.5. PIMはレートリミタを登録します…15 5.3.6. MSDPのソースアクティブなレートリミタ…16 5.4. PIMに、受け身のモード…16 6. セキュリティ問題…16 7. 承認…17 8. 参照…17 8.1. 標準の参照…17 8.2. 有益な参照…17 付録A.RPFは隣人ではなく、インタフェースを考えます…19付録B.は拡大をRoutabilityに返します…20 B.1。 PIM-プルーンのメッセージを木の下側に送ります…20 B.2。 マルチキャストを分析して、DRでトラフィックを分類してください…21 B.3。 上のアプローチの比較…21
Savola, et al. Informational [Page 2] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[2ページ]のRFC4609PIM-Smマルチキャスト
1. Introduction
1. 序論
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.
このドキュメントは、まばらなMode(PIM-SM)マルチキャストがインフラストラクチャを発送して、プロトコル無党派Multicastに軍事的脅威を説明して、これらのアーキテクチャを説明された脅威により抵抗力があるようにする方法を示します。
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.
ことによるとグループ管理プロトコルを使用して、ほかの場所で「リンク」に対するホストがリンクの上に明確にDesignated Router(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はReverse Path Forwarding(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.
私たちは、伝統的なAny Source Multicast(ASM)モデル(Multicast Sourceディスカバリープロトコル(MSDP)[2]のソース発見の使用を含んでいる)で作動しながら、PIM-SMが[1]であると考えます、Sourceの特定のMulticast[3](SSM)モデル、およびASMモデルのEmbedded-RP[4]グループからRPへのマッピングメカニズムで。 双方向のPIM[15]はイントラドメインだけで通常配布されて、ASMにもかかわらず、レジスタメッセージなしで同様です。 双方向のPIMはこの書くこと付けで終わっていません、そして、さらに本書では問題について議論しません。
Savola, et al. Informational [Page 3] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[3ページ]のRFC4609PIM-Smマルチキャスト
2. Terminology
2. 用語
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)がある伝統的なAny Source Multicastモデルについて言及するのに使用されます。
SSM
SSM
"SSM" [7] is used to refer to Source-Specific Multicast.
"SSM"[7]は、Source特有のMulticastについて言及するのに使用されます。
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」はEmbedded-RPマッピングメカニズムがグループに関してRendezvous Point(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).
「目標Router」がパケット(ASMかEmbedded-RP)を処理するRPについて言及するのに使用されるか、または受信しているDR(ソース、Group)(または、(S、G))は接合します(すべてのモデルで)。
3. Threats to Multicast Routing
3. マルチキャストルート設定への脅威
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 Router(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]で説明されるように。
Savola, et al. Informational [Page 4] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[4ページ]のRFC4609PIM-Smマルチキャスト
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.
インターネットGroup Managementプロトコル(IGMP)かMulticast Listenerディスカバリー(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.
RPFチェックが適切でない(特定スタッブLANネットワークにおける)場合でPIM-SMを誤用できます、リンクの上のトラフィックを偽造するのが非常に簡単であるときに。 例えば、ホストは、DRになるようにサブネットのために選出させますが、機能のいずれも実行できませんでした。 また、ホストは容易にPIM Assertを送るのによるリンク停止推進マルチキャストに関するPIMルータをメッセージにすることができます。 これは、意図的な攻撃者がDRで実行された潜在的レートを制限する機能の多くを回避できるのを含意します(1つがいつも自分でメッセージを送ることができるとき)。 しかしながら、PIM-SM仕様は、これらのメッセージが知られているPIM隣人から受け入れられるだけであるべきであると述べます。 これが実行されるなら、ホストは最初に、ルータでPIM隣接番組を確立しなければならないでしょう。 通常、隣接番組がリンクの上のだれと共にも形成されるので、意図的な攻撃者には、プロトコル隣接番組を形成することにおける、成功の高い確率があるでしょう。 これらは、[1]で何らかの長さで説明されますが、また、このメモの範囲から考えられます。
3.1. Receiver-Based Attacks
3.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.
これらの攻撃はしばしばコントロール飛行機攻撃と呼ばれます、そして、攻撃者の目的は通常、処理しやすいレベルを超えてルータにおける、マルチキャスト州の情報の量を増強することです。
3.1.1. Joins to Different Groups (Join Flooding)
3.1.1. 異なったグループにつなぎます。(氾濫を接合します)
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がTarget RouterにPIM Joinを生成すると、起こります。 グループ/SSMチャンネルかTarget Routerが存在するかもしれません。
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状態」と呼ばれる)、または過度の数のパケットがあるTarget Routerと共に経路でルータを積みすぎようとして。
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 Joinタイマが期限が切れるか、または状態がDRで変化した後に次のメッセージを送るだけです。
Savola, et al. Informational [Page 5] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[5ページ]のRFC4609PIM-Smマルチキャスト
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 Reports/葉が不在のときDRで活動的であることの時間デフォルトがどれであるか、) 複数のソースが同じメッセージがプロトコルで包含するときホストが多くの異なったASMグループかSSMチャンネルに1IGMPv3[11]かMLDv2[12]のレポートだけで加わることができることに注意してください、1つのIGMPv3/MLDv2メッセージからの複数のPIM Joinsをもたらして。
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 Reportsを送り続けることができます。 これは以下に結果として生じます。
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 Reportのホスト、aは接合します(S、G)。直接ソースのDR、以下のSSMのように、送ります。
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)は、RPがグループGに埋め込んだ間の/イントラドメインに向かって送られて、その経路の状態を引き起こしながら、接合します。 接合してください。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(単にEmbedded-RPの場合の)が存在していないなら、マルチキャストルーティング・プロトコルには、分配木を取り除くどんな手段もありません。 最悪の場合攻撃は多くの異なったグループにアクティブなままで残っているホストであるかもしれません(架空のソースかRPのどちらかを含んでいて)。 想像するRP問題がRPアドレスがグループアドレスから抜粋される唯一のEmbedded-RPに関連することに注意してください、Gをお願いします。
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.
例えば、それぞれ10のソースを運んで、ホストが100IGMPv3を生成することができるなら、(S、G)は2番目を接合します、それでも、260秒が260 000州エントリー、および100のパケットに1秒あたりなった後に状態の量がかなり容易に達成可能な数です。
Savola, et al. Informational [Page 6] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[6ページ]のRFC4609PIM-Smマルチキャスト
3.2. Source-Based Attacks
3.2. ソースベースの攻撃
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コントロール飛行機の脅威を含んでいます。
3.2.1. Sending Multicast to Empty Groups (Data Flooding)
3.2.1. グループを空にするためにマルチキャストを送ります。(データ氾濫)
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はソースにつないで、Register-停止を発行するかもしれませんが、データを得続けているイントラドメインRPへのRegisterメッセージのパケットをレジスタでカプセルに入れります。 活発なソースに関する通知をグローバルに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へのパケットをレジスタでカプセルに入れります。(RPはソースにつないで、Register-停止を発行するかもしれません)。 異なったグループが使用されているなら、データは、カプセル化され続けています。
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
o 空輸が生成したMSDPコントロールはかなりの量のコントロールとデータ通信量を引き起こす場合があります。(それは、それを受けながら、ルータを積みすぎるかもしれません)。 MSDP脆弱性の徹底的な分析は、[16]で見つけることができて、ASMに関連するだけです。 しかしながら、MSDPが浸水するので、現在、これは最も重大な脅威です。
Savola, et al. Informational [Page 7] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[7ページ]のRFC4609PIM-Smマルチキャスト
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.
マルチキャストパケットを含むインターネットのすべてのマルチキャストドメインへのマルチキャストグループ情報は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を実行する方法であるかもしれません。 以下に注意してください。 decapsulatorは、decapsulateにパケットを必要としないのを知るかもしれません(アクセス構成、レート限界、または他の何かに基づいています)、ボトルネックを避けて。 これらの脅威は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と共に、ソースはRPsを通して偽造トラフィックを注入できます。RPsはソース発見をグループに提供します。 RPsは受信機((*、G)状態があるルータ)に向かった共有された木の上にトラフィックを送ります。 次に、正統の受取人が求められていないソースを無視できないなら、DRは偽造トラフィックを受信機に送ります、例えば、使用Multicast Source Filters(MSF)API[8]。 これは、これらのプロトコルを使用しながら、アプリケーションで通常、使用もされませんし、サポートもされません。
Savola, et al. Informational [Page 8] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[8ページ]のRFC4609PIM-Smマルチキャスト
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は、1グループあたり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 decapsulatesに加えたレジスタパケットとマルチキャスト分配木の受信機にそれらを送って、整合性違反となるとして。
3.3. Aggravating Factors to the Threats
3.3. 要素を脅威にいらいらさせます。
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で説明された脅威をいらいらさせるいくつかの要素について説明します。 また、個々の脅威として一人でこれらを見なすことができました。
3.3.1. Distant RP/Source Problem
3.3.1. 遠方のRP/ソース問題
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)か(S、G)のGを使用するのをメッセージで合図をセットアップする保証する方法が全くありません、1つはアドレスに達することができませんが。
This will be analyzed at more length in Section 5.1.
これはセクション5.1で、より多くの長さで分析されるでしょう。
Savola, et al. Informational [Page 9] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[9ページ]のRFC4609PIM-Smマルチキャスト
3.3.2. No Receiver Information in PIM Joins
3.3.2. PIMの受信機情報は全く接合しません。
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はマルチキャスト分配木で、より遠くにその情報を転送しません。 したがって、個々のルータ(例えば、ドメイン縁のルータ)は分配木にだれを接続できるかに関する政策決定をすることができません。
4. Threat Analysis
4. 脅威分析
4.1. Summary of the Threats
4.1. 脅威の概要
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 |
+-------------+----------------+------------------+-----------------+
+----------------+------------------+-----------------+ | 鍛造されて、接合してください。| ソースです。| グループ保全| +-------------+----------------+------------------+-----------------+ | ASM| 悪い1) | 非常に悪いです。| 悪いか、または平凡です。| +-------------+----------------+------------------+-----------------+ | SSM| 悪い| 非常に良いです。| 非常に良いです。| +-------------+----------------+------------------+-----------------+ | 埋め込まれたRP| 悪い1) 2) | 良いか平凡な3) | 利益| +-------------+----------------+------------------+-----------------+
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レジスタ機械のいずれも実装しないで、ホストは攻撃を仕掛けることができます。
4.2. Enhancements for Threat Mitigation
4.2. 脅威緩和のための増進
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
o 相互ドメインMSDP(ASM)は攻撃を避けるために退職しているべきです。 または、これが妥当でないなら、DRsはレジスタカプセル化をレートで制限するはずです(ホストがこれを回避できることに注意してください)。 more
Savola, et al. Informational [Page 10] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[10ページ]のRFC4609PIM-Smマルチキャスト
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.
重要に、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 DRsがPIM JoinsとPrunesをレートで制限するはずである、どうにか。 これが考えられるべき(すなわち、どの変数が考慮に入れられるかによります)複数の方法があります。
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 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はおもしろくないパケットを拒絶するために良いインタフェースを提供するはずです。 例えば、Embedded-RPグループがRPに許容されるために構成されないなら、パケットであるとカプセル化されたレジスタはdecapsulatedされさえしないでしょう。
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チャンネルの数をレートで制限するはずです。
5. PIM Security Enhancements
5. PIMセキュリティ増進
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.
このセクションはレート制限のための上の言及された機能の、より徹底的な記述などを含んでいます、リモートroutability合図問題の記述と同様に。
5.1. Remote Routability Signalling
5.1. リモートRoutability合図
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がいくつかの問題を引き起こすかもしれません。 特に配備されて、レート制限が手広く思えないなら、これを緩和する2、3の異なるアプローチがあるように思えます。
Savola, et al. Informational [Page 11] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[11ページ]のRFC4609PIM-Smマルチキャスト
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の手の届かないメッセージ(どんな風味のも)を受け取るのはDRにRegisterパケットを止めさせるはずです、RPがとにかくそれらを受けないとき。 (しかしながら、そのような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から聞かれない場合、Registerメッセージの流れが止まるように。 (彼らがソースにつなぎたくないなら、現在、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) レジスタメッセージを始める前に、極端なケースは何らかの形式のリターンroutabilityチェックを実行する予定でしょう: まず最初に、パケットを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 Joins(そして、他のメッセージ)のためのある種の国家管理を持っているのは望ましいでしょう。 例えば、ソース/RPへの経路が実際に存在するのを保証するのに使用できた「Ackを接合してください。」 しかしながら、これは、現在の建築で非常に難しいか、または不可能です: ホップごとにPIMメッセージを送ります、そして、例えば、中央のルータが、対応する状態をリリースするか、または経路が存在しなかったことをDRに通知するように通知するために回答をたどって戻すことができるくらいの情報がありません。
Appendix B discusses this receiver-based remote routability signalling in more detail.
付録Bはさらに詳細にこの受信機ベースのリモートroutability合図について議論します。
5.2. Rate-Limiting Possibilities
5.2. レートを制限するポシビリティーズ
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 ホストがわがままにそう、悪意がある非制御(例えば、ウイルス/虫)か、またはa愛用者がただ不具合をします。
Savola, et al. Informational [Page 12] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[12ページ]のRFC4609PIM-Smマルチキャスト
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.
上記では、私たちが、レート制限が実行されると思う、-、きめ細かにより粒状のフィルタが使用されていないなら、連結してください(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にツールとして正統のマルチキャストユーザに対してレートを制限する機能のいくつかを使用できることに注意されるべきです。 したがって、レート制限のためのいくつかのパラメタが、そのような操作を防ぐのに使用されるべきです。
Savola, et al. Informational [Page 13] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[13ページ]のRFC4609PIM-Smマルチキャスト
5.3. Specific Rate-limiting Suggestions
5.3. 特定のレートを制限する提案
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.
これらの提案は2つの形を取ります: 第一に攻撃を防ぐか、または制限して、すべての縁のネットワークにおける走行になるように設計されたリミタ、および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個のリンク、1DR、または1RPだけに制限して、インターネットマルチキャスト構造への、よりグローバルな効果を避けることです。
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)は、これらに関連するパケットが限界に向かって数えられないように、レートリミタから対にされます。 これは例えば、すべての交通のための制限パラメタを変更しないで攻撃的な、しかし、正統のソースを扱うことの役に立ちます。
5.3.1. Group Management Protocol Rate-Limiter
5.3.1. 集団経営プロトコルレートリミタ
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.
Group Managementプロトコルレートリミタは特定のインタフェースの受け入れられたグループかソースの平均相場を制限するすべてのGroup Managementプロトコル(IGMP、MLD)への象徴バケツベースのレートリミタです、G_DEPTHの深さのバケツで、G_RATEで1秒あたりの象徴を詰め替えて。 例の値は、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.
これはホストからの州創造攻撃に対する一次ディフェンスでしょう。 しかしながら、すべてのルータが何かこのようなものを実行するのを保証できないので、また、他の種類の保護も役に立つでしょう。 これは攻撃者として同じリンクの上の正統の受信機に害を及ぼします。
5.3.2. Source Transmission Rate-Limiter
5.3.2. ソース通信速度リミタ
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であるかもしれません。
Savola, et al. Informational [Page 14] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[14ページ]のRFC4609PIM-Smマルチキャスト
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.
これはデータフラッディング攻撃に対する一次ディフェンスでしょう。 しかしながら、また、これ、複数の送付者からRP(SSMが使用されていないなら)は積み込むことができたのですべてのルータが何かを実行するのを保証できないように、追加保護が必要です。 これは攻撃者と同じリンクの上に正統の送付者に危害を加えます。 これは、ホストが多くの交通を同じグループに送るのを防ぎません--グループのDRとRPだけに害を及ぼして、1つのソースに対するユニキャストDoS攻撃と同様であり、総合的なセキュリティに重要であることは考えられない動作。
5.3.3. PIM Signalling Rate-Limiter
5.3.3. PIM合図レートリミタ
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を制限する象徴バケツベースのレートリミタです、PIM_DEPTHの深さのバケツで、PIM_RATEで1秒あたりの象徴を詰め替えて。 例の値は、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ドメインの境界にあるでしょう。 これはまた、正統の受信機に害を及ぼします。
5.3.4. Unicast-Decapsulation Rate-Limiter
5.3.4. ユニキャスト被膜剥離術レートリミタ
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消費の最悪を阻止するために被膜剥離術の前に使用されて、グループをチェックすることへの追加チェックであるかもしれません。 この限界は、かなり高いはずでなければならなく、また、既存の正統のセッションを妨げるでしょう。
5.3.5. PIM Register Rate-Limiter
5.3.5. PIMはレートリミタを登録します。
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 Registerレートリミタはレッジ_DEPTHの深さのバケツでPIM Registerメッセージのレジスタ被膜剥離術を制限する象徴バケツベースのレートリミタです、レッジ_RATEで1秒あたりの象徴を詰め替えて。 ルータが最近再開したなら、より大きい初期のバケツは使用されるべきです。 例の値は、レッジ_RATE=1とレッジ_DEPTH=10であるかもしれません(または、再開の後のレッジ_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
これはデータ氾濫に対する2番目のオーダーディフェンスでしょう: DRsが適切なリミタを実行しないだろうか、または水につかっているグループの総数があまり高く上昇するなら、RPは限界にできるべきです。
Savola, et al. Informational [Page 15] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[15ページ]のRFC4609PIM-Smマルチキャスト
rate with which new groups are created. This does not harm legitimate senders, as long as their groups have already been created.
どの新しいグループが創設されるかで、評価してください。 彼らのグループが既に創設された限り、これは正統の送付者に危害を加えません。
5.3.6. MSDP Source-Active Rate-Limiter
5.3.6. MSDPのソースアクティブなレートリミタ
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の深さのバケツで1ソースあたりの新しいグループを制限するでしょう、SAG_RATEで1秒あたりの象徴を詰め替えて。 例の値は、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.
これは2番目のオーダーディフェンスでしょう、両方のMSDP SA送受信サイトで、データ氾濫と特にMSDP脆弱性に対して。 ここに記述される特定の脅威は(例えば、ウイルスか虫)異なったマルチキャストアドレスを「調べようとする」ソース(または、複数のさまざまな原因)です。 [16]は十分異なったMSDP攻撃防止メカニズムについて議論します。
5.4. Passive Mode for PIM
5.4. PIMのための受け身の形態
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パケットを全く送りもしませんし、処理もしませんが(受け取るなら)、ホストは、そのインタフェースでまだマルチキャストを送って、受けることができます。
6. Security Considerations
6. セキュリティ問題
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は同様に適用されるかもしれない)の使用について説明します。(このメモのための範囲の外に集団経営があります)。 しかしながら、グループ会員資格を制御できるなら受信機ベースの攻撃が抑えられるかもしれないことに注意してください。
Savola, et al. Informational [Page 16] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[16ページ]のRFC4609PIM-Smマルチキャスト
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攻撃の形で。
7. Acknowledgements
7. 承認
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は十分「リターンroutability」問題について議論しました。 スティVenaasとバラトジョーシーは、ドキュメント品質を改良するためにフィードバックを提供しました。 ビル・フェナーとラスHousleyはIESG評価の間、役に立つコメントを提供しました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol
(MSDP)", RFC 3618, October 2003.
[2] フェナーとB.とD.マイヤー、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618 2003年10月。
[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006.
[3] ホルブルックとH.とB.カイン、「IPのためのソース特有のマルチキャスト」、RFC4607、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.ハーバーマン、「ランデブーポイント(RP)を埋め込んで、IPv6マルチキャストでアドレスを記述してください」、RFC3956、2004年11月。
[5] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, July 2006.
2006年7月の[5]BarbirとA.とマーフィー、S.とY.陽、「ルーティング・プロトコルへの一般的な脅威」RFC4593。
8.2. Informative References
8.2. 有益な参照
[6] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[6] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[7] Bhattacharyya, S., "An Overview of Source-Specific Multicast
(SSM)", RFC 3569, July 2003.
[7]Bhattacharyya、2003年7月のS.、「ソース特有のマルチキャスト(SSM)の概観」RFC3569。
[8] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678,
January 2004.
[8] ターレル、D.、フェナー、B.、およびB.クイン、「マルチキャストソースフィルタのためのソケットインタフェース拡大」、RFC3678、2004年1月。
Savola, et al. Informational [Page 17] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[17ページ]のRFC4609PIM-Smマルチキャスト
[9] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[9]HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、2004年3月。
[10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast
Listener Discovery", Work in Progress, July 2004.
[10] 「マルチキャストリスナー発見における信用モデルとセキュリティ」というデイリー、G.、およびG.クルップは進歩、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インチ、RFC3376、2002年10月。」
[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
そして、[12] ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[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を使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[14] ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[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、「マルチキャストソース発見に対するDoS攻撃の検出と偏向は議定書を作ります」、UCSB技術報告書、2003年5月。
Savola, et al. Informational [Page 18] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[18ページ]のRFC4609PIM-Smマルチキャスト
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つ以上のルータが特にイーサネットベースのインターネットExchangesに接続できるメディアで問題です。 したがって、合図に使用されるアドレスに合っているルートがインタフェースを通っている限り、そのようなリンクの上のどんな隣人もどんな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つの一見を必要とするでしょう。 すなわち、この照合は人が望むかもしれないほど可能ではありません。
Savola, et al. Informational [Page 19] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[19ページ]のRFC4609PIM-Smマルチキャスト
Appendix B. Return Routability Extensions
付録B.リターンRoutability拡張子
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は、そのような情報を提供するためにリターンroutability拡張子なしで状態を剪定できません。 また、そのグループに送られたマルチキャスト交通が全くないときいくつかの場合、状態を取り除く必要があるかもしれません。 このセクションはルータにおける未使用の州の情報を取り除く代替の方法を論じます、州のベースのDoS攻撃にそれを使用できないように。 レートを制限するPIM Joinsが州の攻撃に対する何らかの保護を与えることに注意してください。
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-プルーンのメッセージを作成して、それを返送できるか、創始者に加わってください。 しかしながら、そうしないのでユニキャストIPアドレスを知ってください、創始者DRを接合してください、直接そうすることができない、ユニキャスト、それ、そのルータに。
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-プルーンのメッセージを木の同じポイントからソースに向かって送ることによって、同じ効果を達成できます。 それで、提案されたメカニズムは本当に状況を悪化させません。
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-プルーンはネットワークで通信します。
Savola, et al. Informational [Page 20] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[20ページ]のRFC4609PIM-Smマルチキャスト
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 Joinsを制限するはずです。 1つの追加オプションはしばらくの間実在しないソース/RPにPIM Joinsを妨げることです。
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-プルーン)では、目標の一部は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ルータを変える必要性がない)と共に少しの関係も持っていません。
Savola, et al. Informational [Page 21] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[21ページ]のRFC4609PIM-Smマルチキャスト
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
RamiレヒトネンTeliaSonera Hataanpaan valtatie20タンペレ33100フィンランド
EMail: rami.lehtonen@teliasonera.com
メール: rami.lehtonen@teliasonera.com
David Meyer
デヴィッド・マイヤー
EMail: dmm@1-4-5.net
メール: dmm@1-4-5.net
Savola, et al. Informational [Page 22] RFC 4609 PIM-SM Multicast Routing Security August 2006
Savola、他 セキュリティ2006年8月に掘られる情報[22ページ]のRFC4609PIM-Smマルチキャスト
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Savola, et al. Informational [Page 23]
Savola、他 情報[23ページ]
一覧
スポンサーリンク
