RFC5294 日本語訳
5294 Host Threats to Protocol Independent Multicast (PIM). P. Savola,J. Lingard. August 2008. (Format: TXT=26525 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Savola
Request for Comments: 5294 CSC/FUNET
Category: Informational J. Lingard
Arastra
August 2008
Savolaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5294年のCSC/FUNETカテゴリ: 情報のJ.リンガードArastra2008年8月
Host Threats to Protocol Independent Multicast (PIM)
独立しているマルチキャストについて議定書の中で述べるホストの脅威(PIM)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts.
このメモは、ホストに接するルータインタフェースに特定のプロトコル無党派Multicast(PIM)の脅威について説明することによって、マルチキャストインフラストラクチャ軍事的脅威解析書のリストの補足となります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Host-Interface PIM Vulnerabilities . . . . . . . . . . . . . . 2
2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 3
2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 3
2.3. Routers May Accept PIM Messages from Non-Neighbors . . . . 3
2.4. An Illegitimate Node May Be Elected as the PIM DR or DF . 3
2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 3
2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4
2.5. A Node May Become an Illegitimate PIM Asserted
Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 4
3. On-Link Threats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5
3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6
3.3. Confidentiality, Integrity, or Authorization Violations . 6
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8
4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ホスト・インターフェースPIM脆弱性. . . . . . . . . . . . . . 2 2.1。 ノードは違法なPIMレジスタメッセージ. . . . 3 2.2を送るかもしれません。 ノードは違法なPIMネイバーズ. . . . . . . 3 2.3になるかもしれません。 ルータは非ネイバーズ.32.4からPIMメッセージを受け入れるかもしれません。 違法なノードはPIM DRかDF. 3 2.4.1として選出されるかもしれません。 PIM-Smはルータ選挙. . . . . . . . . . 3 2.4を.2に指定しました。 BIDIR-PIMは混載業者Election. . . . . . . 4 2.5を指定しました。 ノードは混載業者. . . . . . . . . . . . . . . . . . . . . . . . 4 2.6であると断言された違法なPIMになるかもしれません。 BIDIR-PIMはRPFチェック. . . . . . . . . . . . . 4 3を使用しません。 リンクにおける脅威. . . . . . . . . . . . . . . . . . . . . . . 5 3.1。 リンク. . . . . . . . . . . 5 3.2におけるサービス不能攻撃。 外部. . . . . . . . . 6 3.3におけるサービス不能攻撃。 秘密性、保全、または承認違反. 6 4。 緩和メソッド. . . . . . . . . . . . . . . . . . . . . . 7 4.1。 PIM. . . . . . . . . . . . . . . . . . . 7 4.2のための受け身の形態。 PIMルータ. . . . . . . . . . . . . . 7 4.3の中のIPsecの使用。 PIMメッセージ. . . . . . . . . . . . . . . . 8 4.4をフィルターにかけるIP。 脆弱性と緩和メソッド. . . . 8 5の概要。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 10
Savola & Lingard Informational [Page 1] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[1ページ]のRFC5294ホストの脅威
1. Introduction
1. 序論
There has been some analysis of the security threats to the multicast routing infrastructures [RFC4609], some work on implementing confidentiality, integrity, and authorization in the multicast payload [RFC3740], and also some analysis of security threats in Internet Group Management Protocol/Multicast Listener Discovery (IGMP/MLD) [DALEY-MAGMA], but no comprehensive analysis of security threats to PIM at the host-connecting (typically "Local Area Network") links.
マルチキャストルーティングインフラストラクチャ[RFC4609](ホストに接する(通常「ローカル・エリア・ネットワーク」)リンクでペイロード[RFC3740]にもかかわらず、インターネットGroup Managementプロトコル/マルチキャストListenerディスカバリー(IGMP/MLD)[デイリー-MAGMA]における、軍事的脅威の何らかの分析にもかかわらずも、マルチキャストにおける秘密性、保全、および承認がPIMへの軍事的脅威の包括的な分析でないと実装することに対するいくらかの仕事)への軍事的脅威の何らかの分析がありました。
We define these PIM host threats to include:
私たちは含んでいるこれらのPIMホストの脅威を定義します:
o Nodes using PIM to attack or deny service to hosts on the same
link,
o 同じくらいでホストに対するサービスを攻撃するか、または否定するのにPIMを使用するノードがリンクします。
o Nodes using PIM to attack or deny service to valid multicast
routers on the link, or
o またはリンクの上に有効なマルチキャストルータに対するサービスを攻撃するか、または否定するのにPIMを使用するノード。
o Nodes using PIM (Register messages) to bypass the controls of
multicast routers on the link.
o リンクにおけるマルチキャストルータのコントロールを迂回させるのに、PIM(メッセージを登録する)を使用するノード。
The attacking node is typically a host or a host acting as an illegitimate router.
攻撃ノードは、違法なルータとして務めている通常ホストかホストです。
A node originating multicast data can disturb existing receivers of the group on the same link, but this issue is not PIM-specific so it is out of scope. Subverting legitimate routers is out of scope. Security implications on multicast routing infrastructure are described in [RFC4609].
マルチキャストデータを溯源するノードはグループの既存の受信機を同じリンクに擾乱できますが、この問題がPIM特有でないので、範囲の外にそれはあります。 範囲の外に正統のルータを打倒するのがあります。 マルチキャストルーティングインフラストラクチャに関するセキュリティ含意は[RFC4609]で説明されます。
This document analyzes the PIM host-interface vulnerabilities, formulates a few specific threats, proposes some potential ways to mitigate these problems, and analyzes how well those methods accomplish fixing the issues.
このドキュメントは、よくPIMホスト・インターフェース脆弱性を分析して、いくつかの特定の脅威を定式化して、これらの問題を緩和するいくつかの潜在的方法を提案して、どのようにを分析するか。それらのメソッドは、問題を修理しながら、達成します。
It is assumed that the reader is familiar with the basic concepts of PIM.
読者がPIMに関する基本概念に詳しいと思われます。
Analysis of PIM-DM [RFC3973] is out of scope of this document.
このドキュメントの範囲の外にPIM-DM[RFC3973]の分析があります。
2. Host-Interface PIM Vulnerabilities
2. ホスト・インターフェースPIM脆弱性
This section briefly describes the main attacks against host- interface PIM signaling, before we get to the actual threats and mitigation methods in the next sections.
このセクションは簡潔にホストインタフェースPIMシグナリングに対して主な攻撃について説明します、私たちが次のセクションの実際の脅威と緩和メソッドを始める前に。
Savola & Lingard Informational [Page 2] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[2ページ]のRFC5294ホストの脅威
The attacking node may be either a malicious host or an illegitimate router.
攻撃ノードは、悪意があるホストか違法なルータのどちらかであるかもしれません。
2.1. Nodes May Send Illegitimate PIM Register Messages
2.1. ノードは違法なPIMレジスタメッセージを送るかもしれません。
PIM Register messages are sent unicast, and contain encapsulated multicast data packets. Malicious hosts or routers could also send Register messages themselves, for example, to get around rate-limits or to interfere with foreign Rendezvous Points (RPs), as described in [RFC4609].
PIM Registerメッセージは、ユニキャストを送って、カプセル化されたマルチキャストデータ・パケットを含んでいます。 また、例えば、悪意があるホストかルータがレート限界を逃れるか、または外国Rendezvous Points(RPs)を妨げるためにメッセージ自体をRegisterに送るかもしれません、[RFC4609]で説明されるように。
The Register message can be targeted to any IP address, whether in or out of the local PIM domain. The source address may be spoofed, unless spoofing has been prevented [RFC3704], to create arbitrary state at the RPs.
ドメイン、または、地方のPIMドメインにかかわらず外へRegisterメッセージはどんなIPアドレスにも狙うことができます。 スプーフィングが任意の状態をRPsに創設するために防がれていない場合[RFC3704]、ソースアドレスは偽造されるかもしれません。
2.2. Nodes May Become Illegitimate PIM Neighbors
2.2. ノードは違法なPIMネイバーズになるかもしれません。
When PIM has been enabled on a router's host interface, any node can also become a PIM neighbor using PIM Hello messages. Having become a PIM neighbor in this way, the node is able to send other PIM messages to the router and may use those messages to attack the router.
また、PIMがルータのホスト・インターフェースで有効にされたとき、どんなノードも、PIM Helloメッセージを使用することでPIM隣人になることができます。 このようにPIM隣人になって、ノードは、他のPIMメッセージをルータに送ることができて、ルータを攻撃するそれらのメッセージを使用するかもしれません。
2.3. Routers May Accept PIM Messages from Non-Neighbors
2.3. ルータは非ネイバーズからPIMメッセージを受け入れるかもしれません。
The PIM-SM (Sparse Mode) specification recommends that PIM messages other than Hellos should not be accepted, except from valid PIM neighbors. The Bidirectional-PIM (BIDIR-PIM) specification specifies that packets from non-neighbors "SHOULD NOT" be accepted; see Section 5.2 of [RFC5015]. However, the specification does not mandate this, so some implementations may be susceptible to attack from PIM messages sent by non-neighbors.
PIM-SM(まばらなMode)仕様は、ハローズ以外のPIMメッセージが受け入れられるべきでないことを勧めます、有効なPIM隣人を除いて。 Bidirectional-PIM(BIDIR-PIM)仕様が非隣人からそのパケットを指定する、「」 受け入れてください;であるべきです [RFC5015]のセクション5.2を見てください。 しかしながら、仕様がこれを強制しないので、いくつかの実装が非隣人によって送られたPIMメッセージから攻撃するのにおいて影響されやすいかもしれません。
2.4. An Illegitimate Node May Be Elected as the PIM DR or DF
2.4. 違法なノードはPIM DRかDFとして選出されるかもしれません。
2.4.1. PIM-SM Designated Router Election
2.4.1. ルータ選挙に指定されたPIM-Sm
In PIM-SM, the Designated Router (DR) on a Local Area Network (LAN) is responsible for Register-encapsulating data from new sources on the LAN, and for generating PIM Join/Prune messages on behalf of group members on the LAN.
PIM-SMでは、ローカル・エリア・ネットワーク(LAN)のDesignated Router(DR)はLANの新しいソースからのRegister-要約データと、LANのグループのメンバーを代表してPIM Join/プルーンにメッセージを生成するのに責任があります。
A node that can become a PIM neighbor can also cause itself to be elected DR, whether or not the DR Priority option is being used in PIM Hello messages on the LAN.
また、PIM隣人になることができるノードで、それ自体をDRに選出できます、DR PriorityオプションがLANに関するPIM Helloメッセージで使用されているか否かに関係なく。
Savola & Lingard Informational [Page 3] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[3ページ]のRFC5294ホストの脅威
2.4.2. BIDIR-PIM Designated Forwarder Election
2.4.2. 混載業者Electionに指定されたBIDIR-PIM
In BIDIR-PIM [RFC5015], a Designated Forwarder (DF) is elected per link. The DF is responsible for forwarding data downstream onto the link, and also for forwarding data from its link upstream.
BIDIR-PIM[RFC5015]では、Designated Forwarder(DF)はリンク単位で選出されます。 DFはリンクと、また、リンク上流からデータを転送するためにデータを川下に転送するのに責任があります。
A node that can become a BIDIR-PIM neighbor (this is just like becoming a PIM neighbor, except that the PIM Hello messages must include the Bidirectional Capable PIM-Hello option) can cause itself to be elected DF by sending DF Offer messages with a better metric than its neighbors.
BIDIR-PIM隣人になることができるノード、(これがまさしくa PIMを近所付き合いさせて、PIM Helloメッセージが含まなければならないなるのに似ている、Bidirectional Capable PIM、-、こんにちは、オプション) それ自体がaが隣人よりよくメートル法でメッセージをDF Offerに送ることによってDFに選出されることを引き起こす場合があります。
There are also some other BIDIR-PIM attacks related to DF election, including spoofing DF Offer and DF Winner messages (e.g., using a legitimate router's IP address), making all but the impersonated router believe that router is the DF. Also, an attacker might prevent the DF election from converging by sending an infinite sequence of DF Offer messages.
また、DF選挙に関連するある他のBIDIR-PIM攻撃があります、DF OfferとDF Winnerがメッセージ(例えば、正統のルータのIPアドレスを使用する)であると偽造するのを含んでいて、まねられたルータ以外のすべてにルータがDFであると信じさせて。 また、攻撃者は、DF選挙が一点に集まるのをDF Offerメッセージの無限の系列を送ることによって、防ぐかもしれません。
For further discussion of BIDIR-PIM threats, we refer to the Security Considerations section in [RFC5015].
BIDIR-PIMの脅威のさらなる議論について、私たちは[RFC5015]のSecurity Considerations部について言及します。
2.5. A Node May Become an Illegitimate PIM Asserted Forwarder
2.5. ノードは混載業者であると断言された違法なPIMになるかもしれません。
With a PIM Assert message, a router can be elected to be in charge of forwarding all traffic for a particular (S,G) or (*,G) onto the LAN. This overrides DR behavior.
PIM Assertメッセージで、すべてが事項(S、G)か(*、G)のためにLANに取引する推進を担当してあるようにルータを選出できます。 これはDRの振舞いをくつがえします。
The specification says that Assert messages should only be accepted from known PIM neighbors, and "SHOULD" be discarded otherwise. So, either the node must be able to spoof an IP address of a current neighbor, form a PIM adjacency first, or count on these checks being disabled.
仕様は、Assertメッセージが知られているPIM隣人、および“SHOULD"から受け入れられるだけであるべきであると言います。別の方法で捨てられます。 現在の隣人のIPアドレスを偽造しなければならない、最初にPIM隣接番組を形成しなければならない、それで、さもなければ、さもなければ、ノードはこれらのチェックが無効にされるのを頼りにすることができなければなりません。
The Assert Timer, by default, is 3 minutes; the state must be refreshed or it will be removed automatically.
Assert Timerはデフォルトで3分です。 状態をリフレッシュしなければならない、さもなければ、自動的にそれを取り除くでしょう。
As noted before, it is also possible to spoof an Assert (e.g., using a legitimate router's IP address) to cause a temporary disruption on the LAN.
また、以前注意されるように、LANで一時的な分裂を引き起こすために、Assert(例えば、正統のルータのIPアドレスを使用する)を偽造するのも可能です。
2.6. BIDIR-PIM Does Not Use RPF Check
2.6. BIDIR-PIMはRPFチェックを使用しません。
PIM protocols do not perform Reverse Path Forwarding (RPF) check on the shared tree (e.g., in PIM-SM from the RP to local receivers). On the other hand, RPF check is performed, e.g., on stub host interfaces. Because all forwarding in BIDIR-PIM is based on the shared tree principle, it does not use RPF check to verify that the
PIMプロトコルは(RPF)が共有された木(例えば、RPから地方の受信機までのPIM-SMの)の上でチェックするReverse Path Forwardingを実行しません。 他方では、RPFチェックは例えば、スタッブホスト・インターフェースに実行されます。 BIDIR-PIMでのすべての推進が共有された木の原則に基づいているので、それはそれについて確かめるのにRPFチェックを使用しません。
Savola & Lingard Informational [Page 4] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[4ページ]のRFC5294ホストの脅威
forwarded packets are being received from a "topologically correct" direction. This has two immediately obvious implications:
パケットを進めて、受け取られていることはaから方向を「位相的に修正します」。 これには、2つのすぐに明白な意味があります:
1. A node may maintain a forwarding loop until the Time to Live
(TTL) runs out by passing packets from interface A to B. This is
not believed to cause significant new risk as with a similar ease
such a node could generate original packets that would loop back
to its other interface.
1. ノードは、Live(TTL)へのTimeがインタフェースAからB.Thisまでパケットを通過することによってなくなるまで推進輪がそのようなノードが他のインタフェースに輪にして戻られるオリジナルのパケットを生成することができた同様の容易さのように重要な新しい危険を引き起こすと信じられていないと主張するかもしれません。
2. A node may spoof source IP addresses in multicast packets it
sends. Other PIM protocols drop such packets when performing the
RPF check. BIDIR-PIM accepts such packets, allowing easier
Denial-of-Service (DoS) attacks on the multicast delivery tree
and making the attacker less traceable.
2. ノードはそれが送るマルチキャストパケットでソースIPにアドレスを偽造するかもしれません。 RPFチェックを実行するとき、他のPIMプロトコルはそのようなパケットを下げます。 マルチキャスト配送木に対する、より簡単なサービス妨害(DoS)攻撃を許して、攻撃者をより起因しないようにして、BIDIR-PIMはそのようなパケットを受け入れます。
3. On-Link Threats
3. リンクにおける脅威
The previous section described some PIM vulnerabilities; this section gives an overview of the more concrete threats exploiting those vulnerabilities.
前項はいくつかのPIM脆弱性について説明しました。 このセクションはそれらの脆弱性を利用するより具体的な脅威の概要を与えます。
3.1. Denial-of-Service Attack on the Link
3.1. リンクにおけるサービス不能攻撃
The easiest attack is to deny the multicast service on the link. This could mean either not forwarding all (or parts of) multicast traffic from upstream onto the link, or not registering or forwarding upstream the multicast transmissions originated on the link.
最も簡単な攻撃はリンクの上にマルチキャストサービスを否定することです。 または、これが、すべてを進めることを意味できなかった、(離れている、)、登録か上流へトランスミッションをマルチキャストに送るのではなく、リンクへの上流からのマルチキャストトラフィックはリンクの上に起因しました。
These attacks can be done in multiple ways: the most typical one would be becoming the DR through becoming a neighbor with Hello messages and winning the DR election. After that, one could, for example:
複数の方法でこれらの攻撃ができます: 最も典型的な1つは、Helloメッセージで隣人になって、DR選挙に勝つことでDRになっているでしょう。 その後に1がそうすることができた、例えば:
o Not send any PIM Join/Prune messages based on the IGMP reports, or
o またはIGMPレポートに基づくあらゆるPIM Join/プルーンのメッセージを送ってください。
o Not forward or register any sourced packets.
o あらゆる出典を明示されたパケットを進めるか、または登録してください。
Sending PIM Prune messages may also be an effective attack vector even if the attacking node is not elected DR, since PIM Prune messages are accepted from downstream interfaces even if the router is not a DR.
また、攻撃ノードがDRに選出されないでも、送付PIM Pruneメッセージは有効な攻撃ベクトルであるかもしれません、ルータがDRでなくても川下のインタフェースからPIM Pruneメッセージを受け入れるので。
An alternative mechanism is to send a PIM Assert message, spoofed to come from a valid PIM neighbor or non-spoofed if a PIM adjacency has already been formed. For the particular (S,G) or (*,G) from the Assert message, this creates the same result as getting elected as a DR. With BIDIR-PIM, similar attacks can be done by becoming the DF or by preventing the DF election from converging.
代替のメカニズムは既にPIM隣接番組を形成してあるなら有効なPIM隣人か非偽造されるのから来るために偽造されたPIM Assertメッセージを送ることです。 Assertメッセージからの事項(S、G)か(*、G)に関しては、これはDRとして選出されるのと同じ結果を作成します。BIDIR-PIMと共に、DFになるか、またはDF選挙が一点に集まるのを防ぐことによって、同様の攻撃ができます。
Savola & Lingard Informational [Page 5] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[5ページ]のRFC5294ホストの脅威
3.2. Denial-of-Service Attack on the Outside
3.2. 外部におけるサービス不能攻撃
It is also possible to perform Denial-of-Service attacks on nodes beyond the link, especially in environments where a multicast router and/or a DR is considered to be a trusted node.
また、リンクを超えてノードにサービス不能攻撃を実行するのも可能です、特にマルチキャストルータ、そして/または、DRが信じられたノードであると考えられる環境で。
In particular, if DRs perform some form of rate-limiting, for example, on new Join/Prune messages, becoming a DR and sending those messages yourself allows one to subvert these restrictions; therefore, rate-limiting functions need to be deployed at multiple layers, as described in [RFC4609].
例えば、DRsが新しいJoin/プルーンのメッセージに何らかのフォームのレート制限を実行するなら、特に、人はDRになって、自分でそれらのメッセージを送るのにこれらの制限を打倒できます。 したがって、レートを制限する機能は、[RFC4609]で説明されるように複数の層で配布される必要があります。
In addition, any host can send PIM Register messages on their own, to whichever RP it wants; further, if unicast RPF (Reverse Path Forwarding) mechanisms [RFC3704] have not been applied, the packet may be spoofed. This can be done to get around rate-limits, and/or to attack remote RPs, and/or to interfere with the integrity of an ASM group. This attack is also described in [RFC4609].
さらに、どんなホストもそれら自身のに関するPIM Registerメッセージをそれが欲しいRPに送ることができます。 さらに、ユニキャストRPF(Path Forwardingを逆にする)メカニズム[RFC3704]が適用されていないなら、パケットは偽造されるかもしれません。 レート限界を逃れて、リモートRPsを攻撃して、ASMグループの保全を妨げるためにこれができます。 また、この攻撃は[RFC4609]で説明されます。
Also, BIDIR-PIM does not prevent nodes from using topologically incorrect addresses (source address spoofing) making such an attack more difficult to trace.
また、BIDIR-PIMは、そのような攻撃をたどるのをより難しくしながらノードが不正確なアドレス(ソースアドレススプーフィング)を位相的に使用するのを防ぎません。
3.3. Confidentiality, Integrity, or Authorization Violations
3.3. 秘密性、保全、または承認違反
Contrary to unicast, any node is able to legitimately receive all multicast transmission on the link by just adjusting the appropriate link-layer multicast filters. Confidentiality (if needed) must be obtained by cryptography.
ユニキャストとは逆に、どんなノードも、リンクの上にただ適切なリンクレイヤマルチキャストフィルタを調整することによって、合法的にすべてのマルチキャスト送信を受けることができます。 暗号は秘密性(必要であるなら)を得なければなりません。
If a node can become a DR, it is able to violate the integrity of any data streams sent by sources on the LAN, by modifying (possibly in subtle, unnoticeable ways) the packets sent by the sources before Register-encapsulating them.
ノードがDRになることができるなら、LANのソースによって送られたどんなデータ・ストリームの保全にも違反できます、彼らをRegisterカプセル化する前にソースによって送られたパケットを変更することによって(ことによると微妙で、「非-めぼし」な方法で)。
If a node can form a PIM neighbor adjacency or spoof the IP address of a current neighbor, then if it has external connectivity by some other means other than the LAN, the node is able to violate the integrity of any data streams sent by external sources onto the LAN. It would do this by sending an appropriate Assert message onto the LAN to prevent the genuine PIM routers forwarding the valid data, obtaining the multicast traffic via its other connection, and modifying those data packets before forwarding them onto the LAN.
ノードがPIM隣人隣接番組を形成するか、または現在の隣人のIPアドレスを偽造することができるなら、それに外部の接続性がLAN以外のある他の手段であるなら、ノードは外部電源によってLANに送られたどんなデータ・ストリームの保全にも違反できます。 本物のPIMルータが有効データを転送するのを防ぐのが適切なAssertメッセージをLANに送ることによって、これをするでしょう、他の接続でマルチキャストトラフィックを得て、それらをLANに送る前にそれらのデータ・パケットを変更して。
In either of the above two cases, the node could operate as normal for some traffic, while violating integrity for some other traffic.
上の2つのケースのどちらかでは、ノードはある他のトラフィックのために保全に違反している間、何らかのトラフィックのための標準として作動するかもしれません。
Savola & Lingard Informational [Page 6] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[6ページ]のRFC5294ホストの脅威
A more elaborate attack is on authorization. There are some very questionable models [HAYASHI] where the current multicast architecture is used to provide paid multicast service, and where the authorization/authentication is added to the group management protocols such as IGMP. Needless to say, if a host would be able to act as a router, it might be possible to perform all kinds of attacks: subscribe to multicast service without using IGMP (i.e., without having to pay for it), deny the service for the others on the same link, etc. In short, to be able to ensure authorization, a better architecture should be used instead (e.g., [RFC3740]).
より入念な攻撃が承認にあります。 現在のマルチキャストアーキテクチャが支払われたマルチキャストサービスを提供するのに使用されて、承認/認証がIGMPなどのグループ管理プロトコルに追加される何人かの非常に疑わしいモデル[林]があります。 言うまでもなく、ホストがルータとして機能できるなら、すべての種類の攻撃を実行するのは可能であるかもしれません: IGMP(すなわち、それの代価を払う必要はなくて)を使用しないで、マルチキャストサービスに加入してください、そして、同じリンクなどの他のもののためにサービスを否定してください。 要するに、承認を確実にすることができるように、より良いアーキテクチャは代わりに(例えば[RFC3740])使用されるべきです。
4. Mitigation Methods
4. 緩和メソッド
This section lists some ways to mitigate the vulnerabilities and threats listed in previous sections.
このセクションは脆弱性を緩和するいくつかの方法と前項で記載された脅威を記載します。
4.1. Passive Mode for PIM
4.1. PIMのための受け身の形態
The current PIM specification seems to mandate running the PIM Hello protocol on all PIM-enabled interfaces. Most implementations require PIM to be enabled on an interface in order to send PIM Register messages for data sent by sources on that interface or to do any other PIM processing.
PIM Helloを実行する仕様が強制するように思える現在のPIMはすべてのPIMによって可能にされたインタフェースで議定書を作ります。 ほとんどの実装が、そのインタフェースのソースによって送られたデータかいかなる他のPIM処理もするメッセージをPIM Registerに送るためにPIMがインタフェースで有効にされるのを必要とします。
As described in [RFC4609], running full PIM, with Hello messages and all, is unnecessary for those stub networks for which only one router is providing multicast service. Therefore, such implementations should provide an option to specify that the interface is "passive" with regard to PIM: no PIM packets are sent or processed (if received), but hosts can still send and receive multicast on that interface.
[RFC4609]で説明されるように、Helloメッセージとすべてでは、1つのルータだけがマルチキャストサービスを提供しているそれらのスタッブネットワークに、実行している完全なPIMは不要です。 したがって、そのような実装はインタフェースがPIMに関して「受け身である」と指定するためにオプションを提供するべきです: PIMパケットを全く送りもしませんし、処理もしませんが(受け取るなら)、ホストは、そのインタフェースでまだマルチキャストを送って、受けることができます。
4.2. Use of IPsec among PIM Routers
4.2. PIMルータの中のIPsecの使用
Instead of passive mode, or when multiple PIM routers exist on a single link, one could also use IPsec to secure the PIM messaging, to prevent anyone from subverting it. The actual procedures have been described in [RFC4601] and [LINKLOCAL].
受け身の形態か複数のPIMルータがいつに関して存在しているかの代わりに単一のリンク、また、1つはだれでもそれを打倒するのを防ぐために通信するPIMを固定するのにIPsecを使用するかもしれません。 実際の手順は[RFC4601]と[LINKLOCAL]で説明されます。
However, it is worth noting that setting up IPsec Security Associations (SAs) manually can be a very tedious process, and the routers might not even support IPsec; further automatic key negotiation may not be feasible in these scenarios either. A Group Domain of Interpretation (GDOI) [RFC3547] server might be able to mitigate this negotiation.
しかしながら、手動で、IPsec Security Associations(SAs)をセットアップするのが、非常に退屈なプロセスであるかもしれなく、ルータがIPsecをサポートさえしないかもしれないことに注意する価値があります。 さらなる自動主要な交渉はこれらのシナリオで可能でないかもしれません。 Interpretation(GDOI)[RFC3547]サーバのGroup Domainはこの交渉を緩和できるかもしれません。
Savola & Lingard Informational [Page 7] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[7ページ]のRFC5294ホストの脅威
4.3. IP Filtering PIM Messages
4.3. PIMメッセージをフィルターにかけるIP
To eliminate both the unicast and multicast PIM messages, in similar scenarios to those for which PIM passive mode is applicable, it might be possible to block IP protocol 103 (all PIM messages) in an input access list. This is more effective than PIM passive mode, as this also blocks Register messages.
同様のシナリオのユニキャストとマルチキャストPIMメッセージの両方をPIM受け身の形態が適切であるそれらに排除するために、入力アクセスリストのIPプロトコル103(すべてのPIMメッセージ)を妨げるのは可能であるかもしれません。 また、Registerメッセージを妨げるとき、これはPIM受け身の形態より効果的です。
This is also acceptable when there is more than one PIM router on the link if IPsec is used (because the access-list processing sees the valid PIM messages as IPsec AH/ESP packets). In this case, unicast Register messages must also be protected with IPsec or the routing topology must be such that the link is never used to originate, or transit unicast Register messages.
また、IPsecが使用されているなら(アクセスリスト処理がIPsec AH/超能力パケットであると有効なPIMメッセージをみなすので)リンクの上に1つ以上のPIMルータがあるとき、これも許容できます。 また、この場合IPsecと共にユニキャストRegisterメッセージを保護しなければならない、ルーティングトポロジーは、リンクが起因するのに決して使用されないようなもの、またはさもなければ、トランジットユニキャストRegisterメッセージであるに違いありません。
When multiple routers exist on a link, IPsec is not required if it is possible to prevent hosts from sending PIM messages at the Ethernet switch (or equivalent) host ports. This could be accomplished in at least two ways:
複数のルータがリンクの上に存在するとき、IPsecはそれがホストがイーサネットスイッチでメッセージをPIMに送るのを防ぐのにおいて可能で(同等)のホストポートであるなら必要ではありません。 少なくとも2つの方法でこれを達成できました:
1. Use IP access lists on the stub routers to allow PIM messages
from the valid neighbor IP addresses only, and implement IP
spoofing prevention at the Ethernet-switch-port level using
proprietary mechanisms, or
1. またはスタッブルータのIPアクセスリストを使用して、有効な隣人IPアドレスだけからのメッセージをPIMに許容してくださいといって、イーサネットスイッチポートレベルで独占メカニズムを使用することでIPスプーフィング防止を実装してください。
2. Filter out all PIM messages at configured host ports on Ethernet
switches instead of doing it on the routers.
2. ルータでそれをすることの代わりにイーサネットスイッチの上の構成されたホストポートのすべてのPIMメッセージを無視してください。
The main benefit of this approach is that multiple stub routers can still communicate through the LAN without IPsec but hosts are not able to disturb the PIM protocol. The drawback is that Ethernet switches need to implement much finer-grained IP layer filtering, and the operational requirements of carefully maintaining these filters could be significant.
このアプローチの主な恩恵は複数のスタッブルータがLANを通ってIPsecなしでまだ交信できますが、ホストがPIMプロトコルを擾乱できないということです。 欠点はイーサネットスイッチが、多くの、よりきめ細かに粒状のIP層のフィルタリングを実装する必要があるということです、そして、慎重にこれらのフィルタを維持する操作上の要件は重要であるかもしれません。
4.4. Summary of Vulnerabilities and Mitigation Methods
4.4. 脆弱性と緩和メソッドの概要
This section summarizes the vulnerabilities, and how well the mitigation methods are able to cope with them.
このセクションは脆弱性であって、緩和メソッドがどうそれらによく、対処できるかをまとめます。
Savola & Lingard Informational [Page 8] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[8ページ]のRFC5294ホストの脅威
Summary of vulnerabilities and mitigations:
脆弱性と緩和の概要:
+-----+---------------------+-----------------+-----------------+
| Sec | Vulnerability | One stub router | >1 stub routers |
| | | PASV|IPsec|Filt | PASV|IPsec|Filt |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
+-----+---------------------+-----------------+-----------------+ | 秒| 脆弱性| 1つのスタッブルータ| >1スタッブルータ| | | | PASV|IPsec|Filt| PASV|IPsec|Filt| +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.1 | 登録を接待します。| N| N+| Y| N| N+| Ysw| +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.2 | 無効の隣人| Y| Y| Y| * | Y| Ysw| +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.3 | 隣接番組Reqdでない| Y| Y| Y| * | Y| Ysw| +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.4 | 無効のDR /DF| Y| Y| Y| * | Y| Ysw| +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.5 | 無効の混載業者| Y| Y| Y| * | Y| Ysw| +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.6 | どんなRPFも(BIDIR)をチェックしません。| x| x| x| x| x| x| +-----+---------------------+-----+-----+-----+-----+-----+-----+
Figure 1
図1
"*" means Yes if IPsec is used in addition; No otherwise.
IPsecがさらに、使用されるなら、「*」は、はいを意味します。 そうでなければ、いいえ。
"Ysw" means Yes if IPsec is used in addition or IP filtering is done on Ethernet switches on all host ports; No otherwise.
さらに、IPsecを使用するか、またはすべてのホストポートでイーサネットスイッチでIPフィルタリングをするなら、"Ysw"は、はいを意味します。 そうでなければ、いいえ。
"N+" means that the use of IPsec between the on-link routers does not protect from this; IPsec would have to be used at RPs.
「N+」は、リンクの上のルータの間のIPsecの使用がこれから保護されないことを意味します。 IPsecはRPsで使用されなければならないでしょう。
"x" means that, with BIDIR-PIM, IP access lists or RPF mechanisms need to be applied in stub interfaces to prevent originating packets with topologically incorrect source addresses. This needs to be done in addition to any other chosen approach.
「x」はそれを意味して、メカニズムがスタッブで適用される必要があるIPアクセスのBIDIR-PIM、リストまたはRPFに、不正確なソースアドレスは、パケットを位相的に溯源するのを防ぐために連結します。 これは、アプローチが選ばれたいかなる他のもに加えてする必要があります。
To summarize, IP protocol filtering for all PIM messages appears to be the most complete solution when coupled with the use of IPsec between the real stub routers when there are more than one of them. However, IPsec is not required if PIM message filtering or a certain kind of IP spoofing prevention is applied on all the host ports on Ethernet switches. If hosts performing registering is not considered a serious problem, IP protocol filtering and passive-mode PIM seem to be equivalent approaches. Additionally, if BIDIR-PIM is used, ingress filtering will need to be applied in stub interfaces to multicast packets, as well as unicast, to prevent hosts using wrong source addresses.
IPプロトコルが大部分が完全解であったならそれらの1つ以上があるとき、本当のスタッブルータの間のIPsecの使用に結びつけられるとPIMメッセージが見えるすべてのためにフィルターにかけられて、まとめるために。 しかしながら、PIMメッセージフィルタリングかIPスプーフィング防止のある種類がイーサネットスイッチの上のすべてのホストポートに適用されるなら、IPsecは必要ではありません。 ホストであるなら、登録を実行するのは深刻な問題であると考えられません、とIPプロトコルフィルタリングと受け身の形態PIMは同等なアプローチになるように思えます。 さらに、BIDIR-PIMが使用されていると、イングレスフィルタリングは、間違ったソースアドレスを使用することでホストを防ぐためにスタッブインタフェースでマルチキャストパケット、およびユニキャストに適用される必要があるでしょう。
Savola & Lingard Informational [Page 9] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[9ページ]のRFC5294ホストの脅威
5. Acknowledgements
5. 承認
Greg Daley and Gopi Durup wrote an excellent analysis of MLD security issues [DALEY-MAGMA], which gave inspiration in exploring the on-link PIM threats problem space.
グレッグ・デイリーとGopi DurupはMLD安全保障問題[デイリー-MAGMA]の素晴らしい分析を書きました。(安全保障問題はリンクのPIM脅威問題スペースを探検する際にインスピレーションを与えました)。
Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci, John Zwiebel, Stig Venaas, Yiqun Cai, and Eric Gray provided good feedback for this memo.
アヤンロイ-チョードリ、Beauウィリアムソン、バラトジョーシー、ディーノ・ファリナッチ、ジョンZwiebel、スティVenaas、Yiqun Cai、およびエリック・グレーは良いフィードバックをこのメモに供給しました。
6. Security Considerations
6. セキュリティ問題
This memo analyzes the threats to the PIM multicast routing protocol on host interfaces and proposes some possible mitigation techniques.
このメモは、ホスト・インターフェースのPIMマルチキャストルーティング・プロトコルへの脅威を分析して、いくつかの可能な緩和のテクニックを提案します。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I.
Kouvelas, "Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised)",
RFC 4601, August 2006.
[RFC4601] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609,
October 2006.
[RFC4609] Savola、P.、レヒトネン、R.、およびD.マイヤー、「独立しているマルチキャストについて議定書の中で述べてください--まばらなモード(PIM-Sm)マルチキャストルート設定安全保障問題と増進」、RFC4609、2006年10月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L.
Vicisano, "Bidirectional Protocol Independent
Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] ハンドレー、M.、Kouvelas、I.、Speakman、T.、およびL.Vicisano、「双方向のプロトコル独立しているマルチキャスト(BIDIR-PIM)」、RFC5015、2007年10月。
7.2. Informative References
7.2. 有益な参照
[DALEY-MAGMA] Daley, G. and J. Combes, "Securing Neighbour Discovery
Proxy Problem Statement", Work in Progress,
February 2008.
[デイリー-マグマ] 「隣人発見がプロキシ問題声明であると機密保護し」て、デイリー、G.、およびJ.コンブは進歩、2008年2月に働いています。
[HAYASHI] Hayashi, T., "Internet Group membership Authentication
Protocol (IGAP)", Work in Progress, August 2003.
[林]林、T.、「インターネットGroup会員資格Authenticationプロトコル(IGAP)」、Progress、2003年8月のWork。
[LINKLOCAL] Atwood, J., Islam, S., and M. Siami, "Authentication
and Confidentiality in PIM-SM Link-local Messages",
Work in Progress, February 2008.
[LINKLOCAL] アトウッド、J.、イスラム教、S.、およびM.Siami、「PIM-Smのリンクローカルのメッセージの認証と秘密性」は進歩、2008年2月に働いています。
Savola & Lingard Informational [Page 10] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[10ページ]のRFC5294ホストの脅威
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547,
July 2003.
2003年7月の[RFC3547]BaugherとM.とウィスとB.とHardjono、T.とH.ハーニー、「解釈のグループドメイン」RFC3547。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group
Security Architecture", RFC 3740, March 2004.
[RFC3740] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、2004年3月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC3973] アダムス、A.、ニコラス、J.、およびW.Siadak、「プロトコルの独立しているマルチキャスト--濃いモード(PIM-DM):、」 「プロトコル仕様(改訂される)」、RFC3973、2005年1月。
Authors' Addresses
作者のアドレス
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
ペッカSavola CSC--科学計算株式会社エスポーフィンランド
EMail: psavola@funet.fi
メール: psavola@funet.fi
James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA
パロアルト、ジェームスリンガードArastra Inc.P.O. Box10905カリフォルニア94303米国
EMail: jchl@arastra.com
メール: jchl@arastra.com
Savola & Lingard Informational [Page 11] RFC 5294 Host Threats to PIM August 2008
SavolaとPIM2008年8月へのリンガードの情報[11ページ]のRFC5294ホストの脅威
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Savola & Lingard Informational [Page 12]
SavolaとリンガードInformationalです。[12ページ]
一覧
スポンサーリンク
