Network Working Group                                          P. Savola
Request for Comments: 4609                                     CSC/FUNET
Category: Informational                                      R. Lehtonen
                                                             TeliaSonera
                                                                D. Meyer
                                                             August 2006
        
Network Working Group                                          P. Savola
Request for Comments: 4609                                     CSC/FUNET
Category: Informational                                      R. Lehtonen
                                                             TeliaSonera
                                                                D. Meyer
                                                             August 2006
        

Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements

协议无关多播-稀疏模式(PIM-SM)多播路由安全问题与增强

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

Abstract

摘要

This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats.

本备忘录描述了较大(域内或域间)多播路由基础设施的安全威胁。本文仅分析了协议无关多播稀疏模式(PIM-SM)的三种主要运行模式:传统的任意源多播(ASM)模型、源特定多播(SSM)模型以及通过嵌入式集合点(Embedded RP)组到RP映射机制增强的ASM模型。本备忘录还描述了对协议操作的增强,以缓解已识别的威胁。

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. 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. 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.

本文档描述了与协议无关的多播-稀疏模式(PIM-SM)多播路由基础结构的安全威胁,并提出了使这些体系结构更能抵御所述威胁的方法。

Only attacks that have an effect on the multicast routing infrastructures (whether intra- or inter-domain) are considered.

只考虑对多播路由基础设施(域内或域间)有影响的攻击。

"On-link" attacks where the hosts specifically target the Designated Router (DR) or other routers on the link, or where hosts disrupt other hosts on the same link, possibly using group management protocols, are discussed elsewhere (e.g., [10] and [12]). These attacks are not discussed further in this document.

“链路上”攻击,其中主机专门针对指定路由器(DR)或链路上的其他路由器,或者主机中断同一链路上的其他主机(可能使用组管理协议),将在其他地方讨论(例如,[10]和[12])。本文档中不再进一步讨论这些攻击。

Similar to unicast, the multicast payloads may need end-to-end security. Security mechanisms to provide confidentiality, authentication, and integrity are described in other documents (e.g., [9]). Attacks that these security mechanisms protect against are not discussed further in this document.

与单播类似,多播有效负载可能需要端到端安全性。用于提供机密性、身份验证和完整性的安全机制在其他文档(例如[9])中进行了描述。这些安全机制所保护的攻击在本文档中不作进一步讨论。

PIM builds on a model where Reverse Path Forwarding (RPF) checking is, among other things, used to ensure loop-free properties of the multicast distribution trees. As a side effect, this limits the impact of an attacker using a forged source address, which is often used as a component in unicast-based attacks. However, a host can still spoof an address within the same subnet, or spoof the source of a unicast-encapsulated PIM Register message, which a host may send on its own.

PIM建立在一个模型之上,其中反向路径转发(RPF)检查用于确保多播分发树的无循环属性。作为副作用,这限制了攻击者使用伪造源地址的影响,伪造源地址通常用作基于单播的攻击的组件。但是,主机仍然可以伪造同一子网内的地址,或者伪造单播封装的PIM寄存器消息的源,主机可以自行发送该消息。

We consider PIM-SM [1] operating in the traditional Any Source Multicast (ASM) model (including the use of Multicast Source Discovery Protocol (MSDP) [2] for source discovery), in Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] group-to-RP mapping mechanism in ASM model. Bidirectional-PIM [15] is typically deployed only in intra-domain and is similar to ASM but without register messages. Bidirectional-PIM is not finished as of this writing, and its considerations are not discussed further in this document.

我们认为PIM-SM(1)在传统的任意源组播(ASM)模型中操作(包括在源特定组播(3)(SSM)模型中使用组播源发现协议(MSDP)[2),以及在ASM模型中嵌入RP[4 ]组到RP映射机制。双向PIM[15]通常仅部署在域内,与ASM类似,但没有注册消息。截至撰写本文时,双向PIM尚未完成,本文档中不再进一步讨论其考虑事项。

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),用于在它们之间交换有关活动源的信息。

SSM

SSM

"SSM" [7] is used to refer to Source-Specific Multicast.

“SSM”[7]用于指特定于源的多播。

SSM channel

SSM信道

SSM channel (S, G) identifies the multicast delivery tree associated with a source address S and a SSM destination address G.

SSM信道(S,G)标识与源地址S和SSM目标地址G关联的多播传递树。

Embedded-RP

嵌入式RP

"Embedded-RP" refers to the ASM model where the Embedded-RP mapping mechanism is used to find the Rendezvous Point (RP) for a group, and MSDP is not used.

“嵌入式RP”是指ASM模型,其中嵌入式RP映射机制用于查找组的集合点(RP),而不使用MSDP。

Target Router

目标路由器

"Target Router" is used to refer to either the RP processing a packet (ASM or Embedded-RP) or the DR that is receiving (Source, Group) (or (S,G)) joins (in all models).

“目标路由器”用于指处理数据包的RP(ASM或嵌入式RP)或接收(源、组)(或(S、G))连接的DR(在所有型号中)。

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]。引导路由器(BSR)和自动RP等RP发现机制也被认为超出了范围。

As the threats described in this memo are mainly Denial-of-Service (DoS) attacks, it may be useful to note that the attackers will try to find a scarce resource anywhere in the control or data plane, as described in [5].

由于本备忘录中描述的威胁主要是拒绝服务(DoS)攻击,请注意,攻击者可能会试图在控制或数据平面的任何位置找到稀缺资源,如[5]中所述。

There are multiple threats relating to the use of host-to-router signalling protocols -- such as Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) -- but these are outside the scope of this memo.

使用主机到路由器的信令协议(如Internet组管理协议(IGMP)或多播侦听器发现(MLD))存在多种威胁,但这些不在本备忘录的范围之内。

PIM-SM can be abused in the cases where RPF checks are not applicable (in particular, in the stub LAN networks), as spoofing the on-link traffic is very simple. For example, a host could get elected to become DR for the subnet, but not perform any of its functions. A host can also easily make PIM routers on the link stop forwarding multicast by sending PIM Assert messages. This implies that a willful attacker will be able to circumvent many of the potential rate-limiting functions performed at the DR (as one can always send the messages himself). The PIM-SM specification, however, states that these messages should only be accepted from known PIM neighbors; if this is performed, the hosts would first have to establish a PIM adjacency with the router. Typically, adjacencies are formed with anyone on the link, so a willful attacker would have a high probability of success in forming a protocol adjacency. These are described at some length in [1], but are also considered out of the scope of this memo.

在RPF检查不适用的情况下(特别是在存根LAN网络中),PIM-SM可能被滥用,因为欺骗链路流量非常简单。例如,主机可以被选为子网的灾难恢复,但不执行其任何功能。主机还可以通过发送PIM断言消息,轻松使链路上的PIM路由器停止转发多播。这意味着恶意攻击者将能够绕过DR上执行的许多潜在速率限制功能(因为人们总是可以自己发送消息)。然而,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生成到目标路由器的PIM加入时,会发生加入泛洪。组/SSM信道或目标路由器可能存在,也可能不存在。

An example of this is a host trying to join different, non-existent groups at a very rapid pace, trying to overload the routers on the path with an excessive amount of (*/S,G) state (also referred to as "PIM State"), or the Target Router with an excessive number of packets.

例如,主机试图以非常快的速度加入不同的、不存在的组,试图用过量的(*/S,G)状态(也称为“PIM状态”)使路径上的路由器过载,或者目标路由器用过量的数据包。

Note that even if a host joins to a group multiple times, the DR only sends one PIM Join message, without waiting for any acknowledgement; the next message is only sent after the PIM Join timer expires or the state changes at the DR.

注意,即使主机多次加入组,DR也只发送一条PIM加入消息,而不等待任何确认;下一条消息仅在PIM加入计时器过期或DR的状态更改后发送。

This kind of joining causes PIM state to be created, but this state is relatively short-lived (260 seconds by default, which is the default time that the state is active at DR in the absence of IGMP/ MLD Reports/Leaves). Note that the host can join a number of different ASM groups or SSM channels with only one IGMPv3 [11] or MLDv2 [12] Report as the protocol allows multiple sources to be included in the same message, resulting in multiple PIM Joins from one IGMPv3/MLDv2 message.

这种连接会导致创建PIM状态,但该状态相对较短(默认情况下为260秒,这是在没有IGMP/MLD报告/离开的情况下,状态在DR处于活动状态的默认时间)。请注意,由于协议允许在同一消息中包含多个源,因此主机可以仅使用一个IGMPv3[11]或MLDv2[12]报告来加入多个不同的ASM组或SSM通道,从而从一个IGMPv3/MLDv2消息中加入多个PIM。

However, even short-lived state may be harmful when the intent is to cause as much state as possible. The host can continue to send IGMP/MLD Reports to these groups to make the state attack more long-lived. This results in:

然而,当目的是引起尽可能多的状态时,即使是短暂的状态也可能是有害的。主机可以继续向这些组发送IGMP/MLD报告,以使状态攻击更持久。这导致:

o ASM: An (*,G) join is sent to an intra-domain RP, causing state on that path; in turn, that RP joins to the DR of the source if the source is active. If the source address was specified by the host in the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly to the DR of the source, as with SSM, below.

o ASM:(*,G)连接被发送到域内RP,导致该路径上的状态;反过来,如果源处于活动状态,则RP将连接到源的DR。如果源地址是由主机在IGMPv3/MLDv2报告中指定的,则(S,G)联接将直接发送到源的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)连接被发送到嵌入在组G中的域间/域内RP,导致该路径上的状态。如果RP不存在,则连接到最接近RP地址的路由器。类似地,一个显式(S,G)连接到DR,就像上面的SSM一样。

That is, SSM and Embedded-RP always enable "inter-domain" state creation. ASM defaults to intra-domain, but can be used for inter-domain state creation as well.

也就是说,SSM和嵌入式RP始终支持“域间”状态创建。ASM默认为域内,但也可用于域间状态创建。

If the source or RP (only in case of Embedded-RP) does not exist, the multicast routing protocol does not have any means to remove the distribution tree if the joining host remains active. The worst case attack could be a host remaining active to many different groups (containing either imaginary source or RP). Please note that the imaginary RP problem is related to only Embedded-RP, where the RP address is extracted from the group address, G.

如果源或RP(仅在嵌入RP的情况下)不存在,则如果加入主机保持活动状态,则多播路由协议没有任何方法删除分发树。最坏情况下的攻击可能是主机对许多不同的组保持活动状态(包含假想源或RP)。请注意,虚构的RP问题仅与嵌入式RP有关,其中RP地址从组地址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.

例如,如果主机能够每秒生成100个IGMPv3(S,G)连接,每个连接携带10个源,260秒后的状态量将是26万个状态条目——每秒100个数据包仍然是一个相当容易实现的数字。

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]。也就是说,由于初始数据注册不像许多其他多播路由过程那样受到相同的RPF检查,因此基于该数据做出控制决策会导致许多潜在威胁。

Examples of this threat are a virus/worm trying to propagate to multicast addresses, an attacker trying to crash routers with excessive MSDP state, or an attacker wishing to overload the RP with encapsulated packets of different groups. This results in:

此威胁的示例包括试图传播到多播地址的病毒/蠕虫、试图使MSDP状态过多的路由器崩溃的攻击者,或希望用不同组的封装数据包使RP过载的攻击者。这导致:

o ASM: The DR register-encapsulates the packets in Register messages to the intra-domain RP, which may join to the source and issue a Register-Stop, but which continues to get the data. A notification about the active source is sent (unless the group or source is configured to be local) inter-domain with MSDP and propagated globally.

o ASM:DR寄存器将寄存器消息中的数据包封装到域内RP,该RP可以加入源并发出寄存器停止,但会继续获取数据。有关活动源的通知通过MSDP在域间发送(除非组或源配置为本地),并全局传播。

o SSM: The DR receives the data, but the data does not propagate from the DR unless someone joins the (S,G) channel.

o SSM:DR接收数据,但数据不会从DR传播,除非有人加入(S,G)通道。

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可以加入源并发出寄存器停止。如果使用不同的组,数据将继续被封装。

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将淹没整个世界

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.

将多播组信息发送到Internet中的所有多播域,包括封装到MSDP源活动消息的多播数据包。这将创建大量数据和状态,供所有支持多播的路由器共享,如果源保持活动状态,则默认情况下每60秒重复一次泛洪。

o As a large amount of data is forwarded on the multicast tree, if multicast forwarding is performed on CPU, it may be a serious performance bottleneck, and a way to perform DoS on the path. Similarly, the DR must always be capable of processing (and discarding, if necessary) the multicast packets received from the source. These are potentially present in every model.

o 由于大量数据在多播树上转发,如果在CPU上执行多播转发,可能会造成严重的性能瓶颈,并且是在路径上执行DoS的一种方式。类似地,DR必须始终能够处理(并在必要时丢弃)从源接收的多播数据包。这些都可能存在于每个模型中。

o If the encapsulation is performed on software, it may be a performance bottleneck, and a way to perform DoS on the DR. Similarly, if the decapsulation is performed on software, it may be a performance bottleneck, and a way to perform DoS on the RP. Note: the decapsulator may know (based on access configuration, a rate limit, or something else) that it doesn't need to decapsulate the packet, avoiding bottlenecks. These threats are related to ASM and Embedded-RP.

o 如果在软件上执行封装,则可能是性能瓶颈,并且是在DR上执行DoS的一种方式。类似地,如果在软件上执行解除封装,则可能是性能瓶颈,并且是在RP上执行DoS的一种方式。注:解除封装器可能知道(基于访问配置、速率限制或其他内容)它不需要拆封数据包,从而避免了瓶颈。这些威胁与ASM和嵌入式RP有关。

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和嵌入式RP,源可以通过RPs注入伪造流量,从而为组提供源发现。RPs通过共享树向接收器(状态为(*,G)的路由器)发送流量。DR然后将伪造流量转发给接收方,除非合法接收方能够过滤掉不需要的源,例如使用多播源过滤器(MSF)API[8]。通常,使用这些协议的应用程序不使用或不支持此功能。

Note that with ASM and Embedded-RP, the RP may exert some form of control on who can send to a group, as the first packets are register-encapsulated in register packets to the RP. If the RP drops the packet based on an access list, a rate limit, or something else,

注意,对于ASM和嵌入式RP,RP可以对谁可以发送到组施加某种形式的控制,因为第一个数据包被注册封装在向RP发送的注册数据包中。如果RP基于访问列表、速率限制或其他内容丢弃数据包,

it doesn't get injected to an existing group. However, if the DR has existing (*,G) state, the data will also be forwarded on those interfaces.

它不会被注入到现有的组中。但是,如果DR具有现有(*,G)状态,数据也将在这些接口上转发。

With ASM, this "source control" is distributed across all the PIM domains, which significantly decreases its applicability. Embedded-RP enables easier control because source discovery is done through a single RP per group.

在ASM中,这种“源代码控制”分布在所有PIM域中,这大大降低了其适用性。嵌入式RP实现了更轻松的控制,因为源发现是通过每个组一个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解除对寄存器分组的封装并将其转发给多播分发树中的接收器,从而导致完整性冲突。

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消息中使用的地址是有效的。但是,无法确保这一点,使用(*,G)或(S,G)消息中不存在的S或G将导致建立信令,即使无法到达地址。

This will be analyzed at more length in Section 5.1.

第5.1节将对此进行更详细的分析。

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       |
   +-------------+----------------+------------------+-----------------+
        
                 +----------------+------------------+-----------------+
                 | Forged Join    |   Being a Source | Group Integrity |
   +-------------+----------------+------------------+-----------------+
   | ASM         |    bad 1)      |      very bad    |   bad/mediocre  |
   +-------------+----------------+------------------+-----------------+
   | SSM         |    bad         |     very good    |    very good    |
   +-------------+----------------+------------------+-----------------+
   | Embedded-RP |    bad 1),2)   | good/mediocre 3) |      good       |
   +-------------+----------------+------------------+-----------------+
        

Notes:

笔记:

1) In ASM, the host can directly join also (S,G) groups with IGMPv3/MLDv2 and thus have the same characteristics as SSM (also allows inter-domain state to be created).

1) 在ASM中,主机还可以使用IGMPv3/MLDv2直接加入(S,G)组,因此具有与SSM相同的特性(还允许创建域间状态)。

2) allows inter-domain shared state to be created.

2) 允许创建域间共享状态。

3) Embedded-RP allows a host to determine the RP for a given group (or set of groups), which in turn allows that host to mount a PIM register attack. In this case, the host can mount the attack without implementing any of the PIM register machinery.

3) 嵌入式RP允许主机确定给定组(或组集)的RP,从而允许主机装载PIM寄存器攻击。在这种情况下,主机可以在不实现任何PIM注册机制的情况下装载攻击。

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应该限制寄存器封装的速率(注意,主机可以绕过这一点)。更多

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连接和修剪;有多种方法可以考虑这一点(即,取决于考虑哪些变量)。

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应该提供良好的接口来拒绝不感兴趣的数据包;例如,如果嵌入式RP组未配置为允许在RP中使用,则寄存器封装的数据包甚至不会被解除封装。

o DRs could rate-limit the multicast traffic somehow to reduce the disturbing possibilities; there are multiple possibilities how exactly this should be considered.

o DRs可以对组播流量进行一定的速率限制,以减少干扰的可能性;如何准确地考虑这一点有多种可能性。

o DRs should rate-limit the number of groups/SSM channels that can be created by a given source, S.

o DRs应限制给定源S可以创建的组/SSM通道的数量。

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.

本节包括对上述速率限制等功能的更深入描述,以及对远程路由性信令问题的描述。

5.1. Remote Routability Signalling
5.1. 远程路由性信令

As described in Section 3.3.1, non-existent DRs or RPs may cause some problems when setting up multicast state. There seem to be a couple of different approaches to mitigate this, especially if rate-limiting is not extensively deployed.

如第3.3.1节所述,在设置多播状态时,不存在的DRs或RPs可能会导致一些问题。似乎有两种不同的方法来缓解这种情况,特别是在没有广泛部署速率限制的情况下。

With ASM and Embedded-RP, Register message delivery could be ensured somehow. For example:

使用ASM和嵌入式RP,可以以某种方式确保注册消息的传递。例如:

1) At the very least, receiving an ICMP unreachable message (of any flavor) should cause the DR to stop the Register packets, as the RP will not be receiving them anyway. (However, one should note that easy spoofing of such ICMP messages could cause a DoS on legitimate traffic.)

1) 至少,接收到ICMP不可访问的消息(任何类型)应该会导致DR停止注册数据包,因为RP无论如何都不会接收它们。(但是,应注意,此类ICMP消息的容易欺骗可能会导致对合法流量的拒绝服务。)

2) An additional method could be implementing a timer on the DRs so that unless nothing is heard back from the RP within a defined time period, the flow of Register messages would stop. (Currently, the RPs are not required to answer back, unless they want to join to the source.)

2) 另一种方法是在DRs上实现计时器,这样,除非在定义的时间段内没有从RP听到任何消息,否则寄存器消息流将停止。(目前,RPs不需要回复,除非他们想加入源。)

3) An extreme case would be performing some form of return routability check prior to starting the register messages: first, a packet would be sent to the RP, testing its existence and willingness to serve, and also proving to the RP that the sender of the "bubble" and the sender of the registers are the same and the source address is not forged. (That is, the RP would insert a cookie in the bubble, and it would have to be present in the register message.)

3) 一种极端情况是在启动寄存器消息之前执行某种形式的返回可路由性检查:首先,将数据包发送到RP,测试其存在性和服务意愿,并向RP证明“气泡”的发送方和寄存器的发送方是相同的,并且源地址不是伪造的。(也就是说,RP将在气泡中插入一个cookie,并且它必须出现在register消息中。)

It would be desirable to have some kind of state management for PIM Joins (and other messages) as well; for example, a "Join Ack" that could be used to ensure that the path to the source/RP actually exists. However, this is very difficult, if not impossible, with the current architecture: PIM messages are sent hop-by-hop, and there is not enough information to trace back the replies, for example, to notify the routers in the middle to release the corresponding state or to notify the DR that the path did not exist.

最好对PIM连接(和其他消息)进行某种状态管理;例如,可用于确保到源/RP的路径实际存在的“连接确认”。然而,在当前架构中,这是非常困难的(如果不是不可能的话):PIM消息是逐跳发送的,并且没有足够的信息来回溯答复,例如,通知中间路由器以释放相应的状态,或者通知DR该路径不存在。

Appendix B discusses this receiver-based remote routability signalling in more detail.

附录B更详细地讨论了这种基于接收器的远程路由性信令。

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 主机是否故意恶意、不受控制(如病毒/蠕虫),或者普通用户只是做错了什么。

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 join(和类似)消息以避免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工具。因此,应使用几个速率限制参数来防止此类操作。

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.

这些建议有两种形式:设计在所有边缘网络上运行的限制器,首先防止或限制攻击;设计在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.

几乎所有建议的费率限制都没有考虑合法用户。也就是说,允许链路上的某些主机发送/接收,而不允许其他主机发送/接收,这是非常具有挑战性的,因为攻击者可以轻松绕过此类系统。因此,目的是将损坏限制在一条链路、一个DR或一个RP上,并避免对Internet多播体系结构造成更大的全局影响。

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.

组管理协议速率限制器是一种基于令牌桶的速率限制器,适用于所有组管理协议(IGMP、MLD),它将限制特定接口上可接受组或源的平均速率,其桶深度为G_深度,以G_速率每秒重新填充令牌。示例值可以是G_RATE=1和G_DEPTH=20。请注意,例如,一个组中包含两个源的IGMPv3连接将计为两个组/源。

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_速率重新填充令牌。示例值可以是GSEND_RATE=10和GSEND_DEPTH=20。

This would be the first-order defense against data flooding attacks. However, as it cannot be guaranteed that all routers would implement something like this, and as the RP (if SSM is not used) could be loaded from multiple senders, additional protections are needed as well. This harms legitimate senders on the same link as an attacker. This does not prevent a host from sending a lot of traffic to the same group -- an action that would harm only the DR and the RP of the group, is similar to unicast DoS attacks against one source, and is not considered critical to the overall security.

这将是针对数据泛滥攻击的第一道防线。然而,由于不能保证所有路由器都会实现类似的功能,并且RP(如果未使用SSM)可以从多个发送方加载,因此还需要额外的保护。这会伤害与攻击者位于同一链接上的合法发件人。这不会阻止主机向同一组发送大量通信量——这一操作只会损害组的DR和RP,类似于针对一个源的单播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_深度,以每秒PIM_速率令牌重新填充。示例值可以是PIM_比率=1000和PIM_深度=10000。

This would be second-order defense against PIM state attacks when IGMP/MLD rate-limiters haven't been implemented or haven't been effective. This limiter might not need to be active by default, as long as the values are configurable. The main applicability for this filter would be at a border of PIM domain in case PIM state attacks are detected. This harms legitimate receivers as well.

这将是在IGMP/MLD速率限制器未实施或未生效时针对PIM状态攻击的二阶防御。默认情况下,此限制器可能不需要处于活动状态,只要这些值是可配置的。如果检测到PIM状态攻击,此过滤器的主要适用性将位于PIM域的边界。这也损害了合法的接收者。

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.

单播去封装速率限制器是一种简单的去封装速率限制器,它通过限制每秒的数据包(取决于路由器体系结构)和忽略寄存器的来源来保护路由器中的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寄存器速率限制器是一种基于令牌桶的速率限制器,用于限制深度为REG_depth的PIM寄存器消息的寄存器解除封装,以每秒REG_速率令牌重新填充。如果路由器最近重新启动,则应使用较大的初始存储桶。示例值可以是REG_RATE=1和REG_DEPTH=10(或重启后REG_DEPTH=500)。

This would be second-order defense against data flooding: if the DRs would not implement appropriate limiters, or if the total number of flooded groups rises too high, the RP should be able to limit the

这将是针对数据泛滥的二阶防御:如果DRs不实施适当的限制器,或者如果被淹没组的总数上升过多,RP应该能够限制数据泛滥

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. 源激活速率限制器

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_深度,以每秒SAG_速率令牌重新填充。示例值可以是凹陷率=1和凹陷深度=10。

This would be second-order defense, at both the MSDP SA sending and receiving sites, against data flooding and MSDP vulnerabilities in particular. The specific threat being addressed here is a source (or multiple different sources) trying to "probe" (e.g., virus or worm) different multicast addresses. [16] discusses different MSDP attack prevention mechanisms at length.

这将是MSDP SA发送和接收站点的二级防御,特别是针对数据泛滥和MSDP漏洞。这里要解决的特定威胁是一个源(或多个不同的源)试图“探测”(例如,病毒或蠕虫)不同的多播地址。[16] 详细讨论了不同的MSDP攻击预防机制。

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邻接并发送中断流量,除非在路由器上非常小心。这是因为大多数实现要求只有一个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邻接似乎是两个最重要的目标。IGMPv3规范[11]描述了IPsec在组管理中的使用(适用于MLDv2的IPsec也可以类似地应用),这超出了本备忘录的范围。但是,请注意,能够控制组成员身份可能会减少基于接收者的攻击。

However, one should keep in mind two caveats: authentication alone might not be sufficient, especially if the user or the host stack (consider a worm propagation scenario) cannot be expected to "behave well"; and adding such authentication likely provides new attack vectors, e.g., in the form of a CPU DoS attack with an excessive amount of cryptographic operations.

但是,应该记住两个注意事项:单独的身份验证可能是不够的,特别是当用户或主机堆栈(考虑蠕虫传播场景)不能被期望“表现良好”时;并且添加这样的认证可能会提供新的攻击向量,例如,以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.

Kamil Sarac详细讨论了“返回路由性”问题。Stig Venaas和Bharat Joshi提供了反馈,以提高文件质量。Bill Fenner和Russ 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] Fenner,B.,Handley,M.,Holbrook,H.,和I.Kouvelas,“协议独立多播-稀疏模式(PIM-SM):协议规范(修订版)”,RFC 4601,2006年8月。

[2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.

[2] Fenner,B.和D.Meyer,“多播源发现协议(MSDP)”,RFC3618,2003年10月。

[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[3] Holbrook,H.和B.Cain,“IP的源特定多播”,RFC 4607,2006年8月。

[4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.

[4] Savola,P.和B.Haberman,“将集合点(RP)地址嵌入IPv6多播地址”,RFC 3956,2004年11月。

[5] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, July 2006.

[5] Barbir,A.,Murphy,S.,和Y.Yang,“路由协议的一般威胁”,RFC4593,2006年7月。

8.2. Informative References
8.2. 资料性引用

[6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.

[6] Deering,S.,“IP多播的主机扩展”,STD 5,RFC 1112,1989年8月。

[7] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.

[7] Bhattacharyya,S.,“源特定多播(SSM)概述”,RFC 3569,2003年7月。

[8] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.

[8] Thaler,D.,Fenner,B.,和B.Quinn,“多播源过滤器的套接字接口扩展”,RFC 3678,2004年1月。

[9] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.

[9] Hardjono,T.和B.Weis,“多播组安全架构”,RFC 3740,2004年3月。

[10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", Work in Progress, July 2004.

[10] Daley,G.和G.Kurup,“多播侦听器发现中的信任模型和安全”,正在进行的工作,2004年7月。

[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.

[11] Cain,B.,Deering,S.,Kouvelas,I.,Fenner,B.,和A.Thyagarajan,“互联网组管理协议,第3版”,RFC 3376,2002年10月。

[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[12] Vida,R.和L.Costa,“IPv6多播侦听器发现版本2(MLDv2)”,RFC3810,2004年6月。

[13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[13] Ferguson,P.和D.Senie,“网络入口过滤:击败利用IP源地址欺骗的拒绝服务攻击”,BCP 38,RFC 2827,2000年5月。

[14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.

[14] Baker,F.和P.Savola,“多址网络的入口过滤”,BCP 84,RFC 37042004年3月。

[15] Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Work in Progress, October 2005.

[15] “双向协议独立多播(BIDIR-PIM)”,正在进行的工作,2005年10月。

[16] Rajvaidya, P., Ramachandran, K., and K. Almeroth, "Detection and Deflection of DoS Attacks Against the Multicast Source Discovery Protocol", UCSB Technical Report, May 2003.

[16] Rajvaidya,P.,Ramachandran,K.,和K.Almeroth,“针对多播源发现协议的DoS攻击的检测和偏转”,UCSB技术报告,2003年5月。

Appendix A. RPF Considers Interface, Not Neighbor

附录A.RPF考虑的是接口,而不是邻居

In most current implementations, the RPF check considers only the incoming interface, and not the upstream neighbor (RPF neighbor).

在大多数当前实现中,RPF检查只考虑传入接口,而不考虑上游邻居(RPF邻居)。

This can result in accepting packets from the "wrong" RPF neighbor (the neighbor is "wrong" since, while the RPF check succeeds and the packet is forwarded, the unicast policy would not have forwarded the packet).

这可能导致接受来自“错误”RPF邻居的数据包(该邻居是“错误”的,因为当RPF检查成功并转发数据包时,单播策略不会转发数据包)。

This is a problem in the media where more than two routers can connect to, in particular, Ethernet-based Internet Exchanges. Therefore, any neighbor on such a link could inject any PIM signalling as long as a route matching the address used in the signalling is going through the interface.

在两个以上路由器可以连接到基于以太网的互联网交换机的介质中,这是一个问题。因此,这种链路上的任何邻居都可以注入任何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。也就是说,在大多数情况下,威胁仅限于交易所运营商内部的攻击者,而不是第三方。另一方面,数据平面转发没有这样的检查——进行这样的检查需要查看所使用的链路层地址。也就是说,这种检查并不像人们希望的那样可行。

Appendix B. Return Routability Extensions
附录B.返回可路由性扩展

The multicast state information is built from the receiver side, and it can be currently pruned only by the receiver-side DR. If the RP or the source for the group is non-existent, the state can't be pruned by the DR without return routability extensions to provide such information. There might also be a need to remove the state in some cases when there is no multicast traffic sent to that group. This section discusses the alternative ways to remove the unused state information in the routers, so that it can't be used in state-based DoS attacks. Note that rate-limiting PIM Joins gives some protection against the state attacks.

多播状态信息是从接收方构建的,当前只能由接收方DR对其进行修剪。如果RP或组的源不存在,则在没有返回可路由性扩展来提供此类信息的情况下,DR无法对状态进行修剪。在某些情况下,当没有多播通信发送到该组时,可能还需要删除该状态。本节讨论删除路由器中未使用的状态信息的替代方法,以使其不能用于基于状态的DoS攻击。请注意,速率限制PIM连接提供了一些针对状态攻击的保护。

B.1. Sending PIM-Prune Messages Down the Tree
B.1. 在树下发送消息

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删减消息并将其发送回加入发起人。但是,由于它不知道加入发起人DR的单播IP地址,因此无法直接将其单播到该路由器。

A possible alternative is to use a link-local multicast group address (e.g., all-pim routers local multicast address) to pass this information back toward the joining DR. Since the routers from this current router all the way back to the joining DR have forwarding state entry for the group, they can use this state information to see how to forward the PIM-Prune message back.

一种可能的替代方法是使用链路本地多播组地址(例如,所有pim路由器本地多播地址)将该信息传回加入DR。因为从当前路由器一直传回加入DR的路由器具有该组的转发状态条目,他们可以使用此状态信息查看如何将PIM Prune消息转发回。

Each on-tree router, in addition to forwarding the PIM-Prune message, can also prune the state from its state tables. This way, the PIM-Prune message will go back to the DR by following the multicast forwarding state information created so far. In addition, if we use some sort of RPF checks during this process, we can also make it more difficult to inject such PIM-Prune messages maliciously.

每个树上路由器除了转发PIM Prune消息外,还可以从其状态表中修剪状态。这样,PIM Prune消息将通过跟踪到目前为止创建的多播转发状态信息返回到DR。此外,如果在此过程中使用某种RPF检查,也会使恶意注入此类PIM删减消息变得更加困难。

A potential abuse scenario may involve an attacker that has access to a router on the direct path and can send such PIM-Prune messages down the tree branch so as to prune the branch from the tree. But such an attacker can currently achieve the same effect by sending a PIM-Prune message toward the source from the same point on the tree. So, the proposed mechanism does not really aggravate the situation.

潜在的滥用场景可能涉及攻击者,该攻击者可以访问直接路径上的路由器,并可以沿树分支发送此类PIM修剪消息,以便从树中修剪该分支。但是这样的攻击者当前可以通过从树上的同一点向源发送PIM Prune消息来实现相同的效果。因此,拟议的机制并没有真正使情况恶化。

One visible overhead in this new scenario might be that someone can send bogus join messages to create redundant PIM-Join and PIM-Prune messages in the network.

在这个新场景中,一个明显的开销可能是有人可以发送虚假的连接消息来在网络中创建冗余的PIM连接和PIM删减消息。

B.2. Analyzing Multicast Group Traffic at DR
B.2. 在DR上分析多播组流量

Another possible way to remove the unused state information would be to analyze individual group traffic at the DR and if there is no multicast traffic for a certain group within a certain time limit, the state should be removed. In here, if the receiver is malicious and wants to create states in the network, then it can send joins to different groups and create states on routers for each of these different groups until the DR decides that the groups are inactive and initiates the prune process. In addition, during the prune process, the routers will again process all these prune messages and therefore will be spending time.

删除未使用状态信息的另一种可能方法是在DR分析单个组流量,如果在特定时间限制内某个组没有多播流量,则应删除该状态。在这里,如果接收者是恶意的,并且想要在网络中创建状态,那么它可以向不同的组发送加入,并在路由器上为每个不同的组创建状态,直到DR确定这些组处于非活动状态并启动修剪过程。此外,在修剪过程中,路由器将再次处理所有这些修剪消息,因此将花费时间。

B.3. Comparison of the Above Approaches
B.3. 上述方法的比较

Both of these solutions have the same problem of renewing the multicast state information. The DR shouldn't permanently block the state building for that group, but should restrict the PIM Joins if it notices that the receiver is abusing the system. One additional option is to block the PIM Joins to the non-existent source/RP for a certain time.

这两种解决方案都存在更新多播状态信息的相同问题。DR不应该永久性地阻止该组的状态建设,但是如果它注意到接收方滥用系统,应该限制PIM加入。另一个选项是在一定时间内阻止PIM连接到不存在的源/RP。

In the first approach (sending PIM-Prunes down the tree), part of the goal was to prune the states in the routers much sooner than in the second approach. (That is, the goal is to make sure that the routers will not be keeping unnecessary states for long time.)

在第一种方法中(将PIM修剪发送到树下),部分目标是比第二种方法更快地修剪路由器中的状态。(也就是说,目标是确保路由器不会长时间保持不必要的状态。)

The second approach works also for DoS attacks related to the existing source/RP addresses, could be more quickly implemented and deployed in the network, and does not have any relationship with the other deployments (no need to change all PIM routers).

第二种方法也适用于与现有源/RP地址相关的DoS攻击,可以更快地在网络中实施和部署,并且与其他部署没有任何关系(无需更改所有PIM路由器)。

Authors' Addresses

作者地址

Pekka Savola CSC/FUNET Espoo Finland

佩卡·萨沃拉CSC/芬兰福内·埃斯波

   EMail: psavola@funet.fi
        
   EMail: psavola@funet.fi
        

Rami Lehtonen TeliaSonera Hataanpaan valtatie 20 Tampere 33100 Finland

Rami Lehtonen TeliaSonera Hataanpan valtatie 20坦佩雷33100芬兰

   EMail: rami.lehtonen@teliasonera.com
        
   EMail: rami.lehtonen@teliasonera.com
        

David Meyer

大卫·梅耶尔

   EMail: dmm@1-4-5.net
        
   EMail: dmm@1-4-5.net
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

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.

Acknowledgement

确认

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFC编辑器功能的资金由IETF行政支持活动(IASA)提供。