Network Working Group P. Savola
Request for Comments: 5294 CSC/FUNET
Category: Informational J. Lingard
Arastra
August 2008
Network Working Group P. Savola
Request for Comments: 5294 CSC/FUNET
Category: Informational J. Lingard
Arastra
August 2008
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.
本备忘录通过描述特定于连接主机的路由器接口的协议独立多播（PIM）威胁，补充了多播基础设施安全威胁分析文档的列表。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Host-Interface PIM Vulnerabilities . . . . . . . . . . . . . . 2
2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 3
2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 3
2.3. Routers May Accept PIM Messages from Non-Neighbors . . . . 3
2.4. An Illegitimate Node May Be Elected as the PIM DR or DF . 3
2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 3
2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4
2.5. A Node May Become an Illegitimate PIM Asserted
Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 4
3. On-Link Threats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5
3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6
3.3. Confidentiality, Integrity, or Authorization Violations . 6
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8
4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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
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]中实现机密性、完整性和授权进行了一些工作，还对Internet组管理协议/多播侦听器发现（IGMP/MLD）[DALEY-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]的分析不在本文件范围内。
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信令的主要攻击，然后在下一节中介绍实际威胁和缓解方法。
The attacking node may be either a malicious host or an illegitimate router.
攻击节点可能是恶意主机或非法路由器。
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寄存器消息以单播方式发送，并包含封装的多播数据包。如[RFC4609]所述，恶意主机或路由器自身也可能发送注册消息，以绕过速率限制或干扰外部集合点（RPs）。
The Register message can be targeted to any IP address, whether in or out of the local PIM domain. The source address may be spoofed, unless spoofing has been prevented [RFC3704], to create arbitrary state at the RPs.
注册消息可以针对任何IP地址，无论是在本地PIM域内还是在本地PIM域外。源地址可能被欺骗，除非已阻止欺骗[RFC3704]，以在RPs处创建任意状态。
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消息，并可能使用这些消息攻击路由器。
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（稀疏模式）规范建议不接受Hellos以外的PIM消息，除非来自有效的PIM邻居。双向PIM（BIDIR-PIM）规范规定不应接受来自非邻居的数据包；见[RFC5015]第5.2节。但是，该规范并不强制要求这样做，因此一些实现可能容易受到非邻居发送的PIM消息的攻击。
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）上的指定路由器（DR）负责注册封装LAN上新来源的数据，并代表LAN上的组成员生成PIM加入/删除消息。
A node that can become a PIM neighbor can also cause itself to be elected DR, whether or not the DR Priority option is being used in PIM Hello messages on the LAN.
可以成为PIM邻居的节点也可以使自己被选为DR，无论LAN上的PIM Hello消息中是否使用DR优先级选项。
In BIDIR-PIM [RFC5015], a Designated Forwarder (DF) is elected per link. The DF is responsible for forwarding data downstream onto the link, and also for forwarding data from its link upstream.
在BIDIR-PIM[RFC5015]中，每个链路选择一个指定的转发器（DF）。DF负责将数据向下游转发到链路上，也负责将数据从其链路向上游转发。
A node that can become a BIDIR-PIM neighbor (this is just like becoming a PIM neighbor, except that the PIM Hello messages must include the Bidirectional Capable PIM-Hello option) can cause itself to be elected DF by sending DF Offer messages with a better metric than its neighbors.
可以成为BIDIR-PIM邻居的节点（这与成为PIM邻居类似，只是PIM Hello消息必须包含双向功能的PIM Hello选项）可以通过发送比其邻居具有更好度量的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要约和DF获胜者消息（例如，使用合法路由器的IP地址），使除模拟路由器外的所有路由器都相信路由器就是DF。此外，攻击者还可以通过发送无限序列的DF Offer消息来防止DF选择聚合。
For further discussion of BIDIR-PIM threats, we refer to the Security Considerations section in [RFC5015].
有关BIDIR-PIM威胁的进一步讨论，请参阅[RFC5015]中的安全注意事项部分。
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.
该规范指出，断言消息应该只接受来自已知PIM邻居的消息，否则“应该”被丢弃。因此，节点必须能够欺骗当前邻居的IP地址，首先形成PIM邻接，或者指望这些检查被禁用。
The Assert Timer, by default, is 3 minutes; the state must be refreshed or it will be removed automatically.
默认情况下，断言计时器为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.
如前所述，还可能伪造断言（例如，使用合法路由器的IP地址）以在LAN上造成临时中断。
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中）。另一方面，在存根主机接口上执行RPF检查。因为BIDIR-PIM中的所有转发都基于共享树原则，所以它不使用RPF检查来验证
forwarded packets are being received from a "topologically correct" direction. This has two immediately obvious implications:
从“拓扑正确”方向接收转发的数据包。这有两个显而易见的含义：
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. 节点可以通过将数据包从接口A传递到B来维持转发循环，直到生存时间（TTL）结束。这不会导致重大的新风险，因为类似的情况下，这样的节点可以生成原始数据包，将循环回其其他接口。
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地址。其他PIM协议在执行RPF检查时丢弃此类数据包。BIDIR-PIM接受此类数据包，从而更容易对多播传送树进行拒绝服务（DoS）攻击，并降低攻击者的可追踪性。
The previous section described some PIM vulnerabilities; this section gives an overview of the more concrete threats exploiting those vulnerabilities.
上一节描述了一些PIM漏洞；本节概述了利用这些漏洞的更具体的威胁。
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:
这些攻击可以通过多种方式进行：最典型的一种是通过与邻居打招呼并赢得DR选举而成为DR。在此之后，人们可以，例如：
o Not send any PIM Join/Prune messages based on the IGMP reports, or
o 不根据IGMP报告发送任何PIM加入/删减消息，或
o Not forward or register any sourced packets.
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剪枝消息攻击向量，因为即使路由器不是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邻接，则发送非欺骗消息。对于断言消息中的特定（S，G）或（*，G），这会产生与通过BIDIR-PIM当选为DR相同的结果。类似的攻击可以通过成为DF或防止DF选举收敛来完成。
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执行某种形式的速率限制，例如，对新的加入/删减消息执行速率限制，则成为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].
此外，任何主机都可以自己向任何RP发送PIM注册消息；此外，如果未应用单播RPF（反向路径转发）机制[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不能防止节点使用拓扑不正确的地址（源地址欺骗），从而使此类攻击更难跟踪。
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上源发送的任何数据流的完整性。
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的任何数据流的完整性。它将通过向LAN发送适当的断言消息来实现这一点，以防止真正的PIM路由器转发有效数据，通过其其他连接获取多播流量，并在将这些数据包转发到LAN之前修改这些数据包。
In either of the above two cases, the node could operate as normal for some traffic, while violating integrity for some other traffic.
在上述两种情况中的任何一种情况下，节点可以对某些流量正常运行，而对某些其他流量则违反完整性。
A more elaborate attack is on authorization. There are some very questionable models [HAYASHI] where the current multicast architecture is used to provide paid multicast service, and where the authorization/authentication is added to the group management protocols such as IGMP. Needless to say, if a host would be able to act as a router, it might be possible to perform all kinds of attacks: subscribe to multicast service without using IGMP (i.e., without having to pay for it), deny the service for the others on the same link, etc. In short, to be able to ensure authorization, a better architecture should be used instead (e.g., [RFC3740]).
更复杂的攻击是授权。有一些非常值得怀疑的模型[HAYASHI]，其中当前的多播架构用于提供付费多播服务，并且授权/认证被添加到组管理协议（如IGMP）中。不用说，如果主机能够充当路由器，则可能会执行各种攻击：订阅多播服务而不使用IGMP（即，不必付费），拒绝同一链路上其他主机的服务，等等。简言之，为了能够确保授权，应改为使用更好的体系结构（例如，[RFC3740]）。
This section lists some ways to mitigate the vulnerabilities and threats listed in previous sections.
本节列出了缓解前几节中列出的漏洞和威胁的一些方法。
The current PIM specification seems to mandate running the PIM Hello protocol on all PIM-enabled interfaces. Most implementations require PIM to be enabled on an interface in order to send PIM Register messages for data sent by sources on that interface or to do any other PIM processing.
当前的PIM规范似乎要求在所有启用PIM的接口上运行PIM Hello协议。大多数实现要求在接口上启用PIM，以便为该接口上的源发送的数据发送PIM注册消息或执行任何其他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]所述，对于那些只有一个路由器提供多播服务的存根网络，不需要运行完整的PIM以及Hello消息和all。因此，这样的实现应该提供一个选项来指定接口对于PIM是“被动的”：不发送或处理PIM数据包（如果接收到），但主机仍然可以在该接口上发送和接收多播。
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路由器时，也可以使用IPsec保护PIM消息传递，以防止任何人破坏它。实际程序已在[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安全关联（SA）可能是一个非常繁琐的过程，路由器甚至可能不支持IPsec；在这些场景中，进一步的自动密钥协商可能也不可行。组解释域（GDOI）[RFC3547]服务器可能能够缓解此协商。
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消息）。这比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，当链路上有多个PIM路由器时，这也是可以接受的（因为访问列表处理将有效的PIM消息视为IPsec AH/ESP数据包）。在这种情况下，单播寄存器消息还必须使用IPsec进行保护，或者路由拓扑必须确保该链路永远不会用于发起或传输单播寄存器消息。
When multiple routers exist on a link, IPsec is not required if it is possible to prevent hosts from sending PIM messages at the Ethernet switch (or equivalent) host ports. This could be accomplished in at least two ways:
当链路上存在多个路由器时，如果可以防止主机在以太网交换机（或等效）主机端口发送PIM消息，则不需要IPsec。这至少可以通过两种方式实现：
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.
这种方法的主要优点是多个存根路由器仍然可以在没有IPsec的情况下通过LAN进行通信，但主机不能干扰PIM协议。缺点是以太网交换机需要实现更细粒度的IP层过滤，仔细维护这些过滤器的操作要求可能非常高。
This section summarizes the vulnerabilities, and how well the mitigation methods are able to cope with them.
本节总结了漏洞，以及缓解方法能够如何应对这些漏洞。
Summary of vulnerabilities and mitigations:
漏洞和缓解措施概述：
+-----+---------------------+-----------------+-----------------+
| Sec | Vulnerability | One stub router | >1 stub routers |
| | | PASV|IPsec|Filt | PASV|IPsec|Filt |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
+-----+---------------------+-----------------+-----------------+
| Sec | Vulnerability | One stub router | >1 stub routers |
| | | PASV|IPsec|Filt | PASV|IPsec|Filt |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x |
+-----+---------------------+-----+-----+-----+-----+-----+-----+
Figure 1
图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”表示，对于BIDIR-PIM，需要在存根接口中应用IP访问列表或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.
总之，当存在多个存根路由器时，在实际存根路由器之间使用IPsec时，对所有PIM消息进行IP协议过滤似乎是最完整的解决方案。但是，如果对以太网交换机上的所有主机端口应用PIM消息过滤或某种IP欺骗预防，则不需要IPsec。如果执行注册的主机不被认为是一个严重的问题，那么IP协议过滤和被动模式PIM似乎是等效的方法。此外，如果使用BIDIR-PIM，则需要在多播数据包的存根接口以及单播中应用入口过滤，以防止主机使用错误的源地址。
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.
格雷格·戴利（Greg Daley）和戈皮·杜鲁普（Gopi Durup）对MLD安全问题[Daley-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.
Ayan Roy Chowdhury、Beau Williamson、Bharat Joshi、Dino Farinaci、John Zwiebel、Stig Venaas、Yiqun Cai和Eric Gray为这份备忘录提供了良好的反馈。
This memo analyzes the threats to the PIM multicast routing protocol on host interfaces and proposes some possible mitigation techniques.
本备忘录分析了主机接口上PIM多播路由协议面临的威胁，并提出了一些可能的缓解技术。
[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]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006.
[RFC4609]Savola，P.，Lehtonen，R.，和D.Meyer，“协议独立多播-稀疏模式（PIM-SM）多播路由安全问题和增强”，RFC 4609，2006年10月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[DALEY-MAGMA] Daley, G. and J. Combes, "Securing Neighbour Discovery Proxy Problem Statement", Work in Progress, February 2008.
[DALEY-MAGMA]DALEY，G.和J.Combes，“保护邻居发现代理问题声明”，正在进行的工作，2008年2月。
[HAYASHI] Hayashi, T., "Internet Group membership Authentication Protocol (IGAP)", Work in Progress, August 2003.
[HAYASHI]HAYASHI，T.，“互联网组成员身份验证协议（IGAP）”，正在进行的工作，2003年8月。
[LINKLOCAL] Atwood, J., Islam, S., and M. Siami, "Authentication and Confidentiality in PIM-SM Link-local Messages", Work in Progress, February 2008.
[LINKLOCAL]Atwood，J.，Islam，S.，和M.Siami，“PIM-SM链接本地消息中的身份验证和保密”，正在进行的工作，2008年2月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
Authors' Addresses
作者地址
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
Pekka Savola CSC-科学计算有限公司，芬兰埃斯波
EMail: psavola@funet.fi
EMail: psavola@funet.fi
James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA
James Lingard Arastra，Inc.美国加利福尼亚州帕洛阿尔托市邮政信箱10905，邮编94303
EMail: jchl@arastra.com
EMail: jchl@arastra.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.