Internet Engineering Task Force (IETF) W. Atwood
Request for Comments: 5796 Concordia University/CSE
Updates: 4601 S. Islam
Category: Standards Track IRS-EMT
ISSN: 2070-1721 M. Siami
Concordia University/CIISE
March 2010
Internet Engineering Task Force (IETF) W. Atwood
Request for Comments: 5796 Concordia University/CSE
Updates: 4601 S. Islam
Category: Standards Track IRS-EMT
ISSN: 2070-1721 M. Siami
Concordia University/CIISE
March 2010
Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages
协议无关多播稀疏模式（PIM-SM）链路本地消息中的身份验证和机密性
Abstract
摘要
RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601.
RFC 4601要求使用IPsec来确保独立于协议的多播稀疏模式（PIM-SM）路由协议中链路本地消息的身份验证。本文档指定了使用IP安全（IPsec）封装安全负载（ESP）或（可选）身份验证头（AH）对PIM-SM链路本地消息进行身份验证的机制。它指定了使用ESP提供机密性的可选机制。手动密钥指定为强制和默认组密钥管理解决方案。为了解决手动键控存在的可伸缩性和安全性问题，提供了对自动组密钥管理机制的可选支持。但是，实现自动组密钥管理的程序留给其他文档。本文件更新了RFC 4601。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5796.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5796.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Goals and Non-Goals ........................................4
2. Terminology .....................................................5
3. Transport Mode versus Tunnel Mode ...............................5
4. Authentication ..................................................5
5. Confidentiality .................................................6
6. IPsec Requirements ..............................................6
7. Key Management ..................................................8
7.1. Manual Key Management ......................................8
7.2. Automated Key Management ...................................8
7.3. Communications Patterns ....................................9
7.4. Neighbor Relationships ....................................10
8. Number of Security Associations ................................11
9. Rekeying .......................................................12
9.1. Manual Rekeying Procedure .................................13
9.2. KeyRolloverInterval .......................................14
9.3. Rekeying Interval .........................................14
10. IPsec Protection Barrier and SPD/GSPD .........................14
10.1. Manual Keying ............................................14
10.1.1. SAD Entries .......................................14
10.1.2. SPD Entries .......................................14
10.2. Automatic Keying .........................................15
10.2.1. SAD Entries .......................................15
10.2.2. GSPD Entries ......................................15
10.2.3. PAD Entries .......................................15
11. Security Association Lookup ...................................16
12. Activating the Anti-Replay Mechanism ..........................16
13. Implementing a Security Policy Database per Interface .........17
14. Extended Sequence Number ......................................17
15. Security Considerations .......................................18
16. Acknowledgements ..............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................19
1. Introduction ....................................................4
1.1. Goals and Non-Goals ........................................4
2. Terminology .....................................................5
3. Transport Mode versus Tunnel Mode ...............................5
4. Authentication ..................................................5
5. Confidentiality .................................................6
6. IPsec Requirements ..............................................6
7. Key Management ..................................................8
7.1. Manual Key Management ......................................8
7.2. Automated Key Management ...................................8
7.3. Communications Patterns ....................................9
7.4. Neighbor Relationships ....................................10
8. Number of Security Associations ................................11
9. Rekeying .......................................................12
9.1. Manual Rekeying Procedure .................................13
9.2. KeyRolloverInterval .......................................14
9.3. Rekeying Interval .........................................14
10. IPsec Protection Barrier and SPD/GSPD .........................14
10.1. Manual Keying ............................................14
10.1.1. SAD Entries .......................................14
10.1.2. SPD Entries .......................................14
10.2. Automatic Keying .........................................15
10.2.1. SAD Entries .......................................15
10.2.2. GSPD Entries ......................................15
10.2.3. PAD Entries .......................................15
11. Security Association Lookup ...................................16
12. Activating the Anti-Replay Mechanism ..........................16
13. Implementing a Security Policy Database per Interface .........17
14. Extended Sequence Number ......................................17
15. Security Considerations .......................................18
16. Acknowledgements ..............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................19
All the PIM-SM [RFC4601] control messages have IP protocol number 103. Some control messages are unicast; the rest are multicast with Time to Live (TTL) = 1. The source address used for unicast messages is a domain-wide reachable address. For the multicast messages, a link-local address of the interface on which the message is being sent is used as the source address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination address. These messages are called link-local messages. Hello, Join/Prune, and Assert messages are included in this category. A forged link-local message may be sent to the ALL_PIM_ROUTERS multicast address by an attacker. This type of message affects the construction of the distribution tree [RFC4601]. The effects of these forged messages are outlined in Section 6.1 of [RFC4601]. Some of the effects are very severe, whereas some are minor.
所有PIM-SM[RFC4601]控制消息的IP协议号均为103。一些控制消息是单播的；其余的是生存时间（TTL）=1的多播。用于单播消息的源地址是一个域范围的可访问地址。对于多播消息，发送消息的接口的链路本地地址用作源地址，特殊多播地址，所有_PIM_路由器（IPv4中为224.0.0.13，IPv6中为ff02:：d）用作目标地址。这些消息称为链接本地消息。Hello、Join/Prune和Assert消息都包含在此类别中。攻击者可能会将伪造的链路本地消息发送到所有PIM路由器的多播地址。此类消息会影响分发树[RFC4601]的构造。[RFC4601]第6.1节概述了这些伪造信息的影响。有些影响非常严重，而有些影响很小。
PIM-SM version 2 was originally specified in RFC 2117 [RFC2117], and revised in RFC 2362 [RFC2362] and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a number of deficiencies. The "Security Considerations" section of RFC 4601 is based primarily on the Authentication Header (AH) specification described in RFC 4302 [RFC4302].
PIM-SM版本2最初在RFC 2117[RFC2117]中规定，并在RFC 2362[RFC2362]和RFC 4601中修订。RFC 4601淘汰了RFC 2362，并纠正了许多缺陷。RFC 4601的“安全注意事项”部分主要基于RFC 4302[RFC4302]中描述的认证头（AH）规范。
Securing the unicast messages can be achieved by the use of a normal unicast IPsec Security Association (SA) between the two communicants.
通过在两个通信者之间使用正常的单播IPsec安全关联（SA），可以实现单播消息的安全。
This document focuses on the security issues for link-local messages. It provides some guidelines to take advantage of the new permitted AH functionality in RFC 4302 and the new permitted ESP functionality in RFC 4303 [RFC4303], and to bring the PIM-SM specification into alignment with the new AH and ESP specifications. In particular, in accordance with RFC 4301, the use of ESP is made mandatory and AH is specified as optional. This document specifies manual key management as mandatory to implement, i.e., that all implementations MUST support, and provides the necessary structure for an automated key management protocol that the PIM routers may use.
本文档重点介绍链接本地消息的安全问题。它提供了一些指南，以利用RFC 4302中新的许可AH功能和RFC 4303[RFC4303]中新的许可ESP功能，并使PIM-SM规范与新的AH和ESP规范保持一致。特别是，根据RFC 4301，ESP的使用是强制性的，AH是可选的。本文件规定必须实施手动密钥管理，即所有实施必须支持手动密钥管理，并为PIM路由器可能使用的自动密钥管理协议提供必要的结构。
The primary goal for link-local security is to provide data origin authentication for each link-local message. A secondary goal is to ensure that communication only happens between legitimate peers (i.e., adjacent routers). An optional goal is to provide data confidentiality for the link-local messages.
链路本地安全性的主要目标是为每个链路本地消息提供数据源身份验证。第二个目标是确保仅在合法对等方（即相邻路由器）之间进行通信。可选目标是为链接本地消息提供数据机密性。
The first goal implies that each router has a unique identity. It is possible (but not mandatory) that this identity will be based on the unicast identity of the router. (The unicast identity could be, for example, based on some individually configured property of the router, or be part of a region-wide public key infrastructure.) The existence of this unique identity is assumed in this specification, but procedures for establishing it are out of scope for this document.
第一个目标意味着每个路由器都有一个唯一的身份。此标识可能（但不是强制性的）基于路由器的单播标识。（例如，单播标识可以基于路由器的某些单独配置的属性，或者是区域范围公钥基础设施的一部分。）本规范假设存在此唯一标识，但建立此唯一标识的过程不在本文档的范围内。
The second goal implies that there is some form of "adjacency matrix" that controls the establishment of Security Associations among adjacent multicast routers. For manual keying, this control will be exercised by the Administrator of the router(s), through the setting of initialization parameters. For automated keying, the existence of this control will be reflected by the contents of the Peer Authorization Database (PAD) (see RFC 4301 [RFC4301]) or the Group Security Policy Database (GSPD) (see RFC 5374 [RFC5374]) in each router. Procedures for controlling the adjacency and building the associated PAD and GSPD are out of scope for this document.
第二个目标意味着存在某种形式的“邻接矩阵”，控制相邻多播路由器之间安全关联的建立。对于手动键控，该控制将由路由器管理员通过设置初始化参数来执行。对于自动键控，该控制的存在将通过每个路由器中的对等授权数据库（PAD）（参见RFC 4301[RFC4301]）或组安全策略数据库（GSPD）（参见RFC 5374[RFC5374]）的内容反映出来。控制邻接和建立相关PAD和GSPD的程序不在本文件范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. They indicate requirement levels for compliant PIM-SM implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。它们表示符合PIM-SM实施的需求级别。
All implementations conforming to this specification MUST support SA in transport mode to provide required IPsec security to PIM-SM link-local messages. They MAY also support SA in tunnel mode to provide required IPsec security to PIM-SM link-local messages. If tunnel mode is used, both destination address preservation and source address preservation MUST be used, as described in Section 3.1 of RFC 5374 [RFC5374].
符合本规范的所有实现必须在传输模式下支持SA，以向PIM-SM链路本地消息提供所需的IPsec安全性。它们还可以在隧道模式下支持SA，为PIM-SM链路本地消息提供所需的IPsec安全性。如果使用隧道模式，则必须同时使用目标地址保留和源地址保留，如RFC 5374[RFC5374]第3.1节所述。
Implementations conforming to this specification MUST support authentication for PIM-SM link-local messages. Implementations conforming to this specification MUST support HMAC-SHA1 [RFC2404].
符合本规范的实现必须支持PIM-SM链路本地消息的身份验证。符合本规范的实现必须支持HMAC-SHA1[RFC2404]。
In order to provide authentication of PIM-SM link-local messages, implementations MUST support ESP [RFC4303] and MAY support AH [RFC4302].
为了提供PIM-SM链路本地消息的身份验证，实现必须支持ESP[RFC4303]，并且可能支持AH[RFC4302]。
If ESP in transport mode is used, it will only provide authentication to PIM-SM protocol packets excluding the IP header, extension headers, and options.
如果使用传输模式下的ESP，它将仅为PIM-SM协议数据包提供身份验证，不包括IP报头、扩展报头和选项。
If AH in transport mode is used, it will provide authentication to PIM-SM protocol packets, selected portions of the IP header, extension headers and options.
如果使用传输模式下的AH，它将为PIM-SM协议包、IP报头的选定部分、扩展报头和选项提供身份验证。
Note: when authentication for PIM-SM link-local messages is enabled,
注意：启用PIM-SM链路本地消息的身份验证时，
o PIM-SM link-local packets that are not protected with AH or ESP will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets.
o 未受AH或ESP保护的PIM-SM链路本地数据包将被IPsec悄悄丢弃，尽管IPsec的实现可能会维护此类数据包的计数器。
o PIM-SM link-local packets that fail the authentication checks will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets.
o 未通过身份验证检查的PIM-SM链路本地数据包将被IPsec悄悄丢弃，尽管IPsec的实现可能会维护此类数据包的计数器。
Implementations conforming to this specification SHOULD support confidentiality for PIM-SM. Implementations supporting confidentiality MUST support AES-CBC [RFC3602] with a 128-bit key.
符合本规范的实现应支持PIM-SM的保密性。支持保密性的实现必须支持具有128位密钥的AES-CBC[RFC3602]。
If confidentiality is provided, ESP MUST be used.
如果提供了保密性，则必须使用ESP。
Since authentication MUST be supported by a conforming implementation, an implementation MUST NOT generate the combination of NON-NULL Encryption and NULL Authentication.
由于身份验证必须由一致性实现支持，因此实现不能生成非空加密和空身份验证的组合。
Note: when confidentiality for PIM-SM link-local packets is enabled,
注意：启用PIM-SM链路本地数据包的保密性时，
o PIM-SM packets that are not protected with ESP will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets.
o 未受ESP保护的PIM-SM数据包将被IPsec悄悄丢弃，尽管IPsec的实现可能会维护此类数据包的计数器。
In order to implement this specification, the following IPsec capabilities are required.
为了实现此规范，需要以下IPsec功能。
Transport mode IPsec in transport mode MUST be supported.
必须支持传输模式中的传输模式IPsec。
Multiple Security Policy Databases (SPDs) The implementation MUST support multiple SPDs with an SPD selection function that provides an ability to choose a specific SPD based on interface.
多个安全策略数据库（SPD）实施必须支持多个SPD，并具有SPD选择功能，该功能提供基于接口选择特定SPD的能力。
Selectors The implementation MUST be able to use source address, destination address, protocol, and direction as selectors in the SPD.
选择器实现必须能够使用源地址、目标地址、协议和方向作为SPD中的选择器。
Interface ID tagging The implementation MUST be able to tag the inbound packets with the ID of the interface (physical or virtual) on which they arrived.
接口ID标记实现必须能够使用入站数据包到达的接口（物理或虚拟）的ID标记入站数据包。
Manual key support It MUST be possible to use manually configured keys to secure the specified traffic.
手动密钥支持必须能够使用手动配置的密钥来保护指定的通信量。
Encryption and authentication algorithms Encryption and authentication algorithm requirements described in RFC 4835 [RFC4835] apply when ESP and AH are used to protect PIM-SM. Implementations MUST support ESP-NULL, and if providing confidentiality, MUST support the ESP transforms providing confidentiality required by [RFC4835]. However, in any case, implementations MUST NOT allow the user to choose a stream cipher or block mode cipher in counter mode for use with manual keys.
加密和认证算法当ESP和AH用于保护PIM-SM时，RFC 4835[RFC4835]中描述的加密和认证算法要求适用。实现必须支持ESP-NULL，如果提供机密性，则必须支持提供[RFC4835]要求的机密性的ESP转换。但是，在任何情况下，实现都不能允许用户在计数器模式下选择流密码或块模式密码用于手动密钥。
Encapsulation of ESP packets IP encapsulation of ESP packets MUST be supported. For simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
ESP数据包的封装必须支持ESP数据包的IP封装。为简单起见，不应使用ESP数据包的UDP封装。
If the automatic keying features of this specification are implemented, the following additional IPsec capabilities are required:
如果实现了本规范的自动密钥功能，则需要以下附加IPsec功能：
Group Security Policy Database (GSPD) The implementation MUST support the GSPD that is described in RFC 5374 [RFC5374].
组安全策略数据库（GSPD）实现必须支持RFC 5374[RFC5374]中描述的GSPD。
Multiple Group Security Policy Databases The implementation MUST support multiple GSPDs with a GSPD selection function that provides an ability to choose a specific GSPD based on interface.
多组安全策略数据库实施必须支持多个GSPD，并具有GSPD选择功能，该功能提供基于接口选择特定GSPD的能力。
Selectors The implementation MUST be able to use source address, destination address, protocol and direction as selectors in the GSPD.
选择器实现必须能够使用源地址、目标地址、协议和方向作为GSPD中的选择器。
All the implementations MUST support manual configuration of the Security Associations (SAs) that will be used to authenticate PIM-SM link-local messages. This does not preclude the use of a negotiation protocol such as the Group Domain Of Interpretation (GDOI) [RFC3547] or Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] to establish these SAs.
所有实现都必须支持安全关联（SA）的手动配置，这些安全关联将用于验证PIM-SM链路本地消息。这并不排除使用协商协议，例如组解释域（GDOI）[RFC3547]或组安全关联密钥管理协议（GSAKMP）[RFC4535]来建立这些SA。
To establish the SAs at PIM-SM routers, manual key configuration will be feasible when the number of peers (directly connected routers) is small. The Network Administrator will configure a router manually. At that time, the authentication method and the choice of keys SHOULD be configured. The parameters for the Security Association Database (SAD) will be entered. The Network Administrator will also configure the Security Policy Database of a router to ensure the use of the associated SA while sending a link-local message.
为了在PIM-SM路由器上建立SAs，当对等点（直接连接的路由器）数量较少时，手动密钥配置是可行的。网络管理员将手动配置路由器。此时，应配置身份验证方法和密钥选择。将输入安全关联数据库（SAD）的参数。网络管理员还将配置路由器的安全策略数据库，以确保在发送链路本地消息时使用相关SA。
All the link-local messages of the PIM-SM protocol are sent to the destination address, ALL_PIM_ROUTERS, which is a multicast address. By using the sender address in conjunction with the destination address for Security Association lookup, link-local communication turns into a Source-Specific Multicast (SSM) or "one-to-many" communication.
PIM-SM协议的所有链路本地消息都发送到目标地址，即所有PIM路由器，这是一个多播地址。通过将发送方地址与安全关联查找的目标地址结合使用，链路本地通信将转变为源特定多播（SSM）或“一对多”通信。
The procedures for automated key management are not specified in this document.
本文档中未指定自动密钥管理程序。
One option is to use Group Domain Of Interpretation (GDOI) [RFC3547], which enables a group of users or devices to exchange encrypted data using IPsec data encryption. GDOI has been developed to be used in multicast applications, where the number of end users or devices may be large and the end users or devices can dynamically join/leave a multicast group. However, a PIM router is not expected to join/leave very frequently, and the number of routers is small when compared to the possible number of users of a multicast application. Moreover, most of the PIM routers will be located inside the same administrative domain and are considered to be trusted parties. It is possible that a subset of GDOI functionalities will be sufficient.
一种选择是使用组解释域（GDOI）[RFC3547]，它允许一组用户或设备使用IPsec数据加密交换加密数据。GDOI已开发用于多播应用，其中最终用户或设备的数量可能很大，并且最终用户或设备可以动态加入/离开多播组。然而，PIM路由器并不期望非常频繁地加入/离开，并且与多播应用程序的可能用户数量相比，路由器的数量很小。此外，大多数PIM路由器将位于同一管理域内，并被视为受信任方。GDOI功能的子集可能就足够了。
Another option is to use the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535].
另一种选择是使用组安全关联密钥管理协议（GSAKMP）[RFC4535]。
Before discussing the set of Security Associations that are required to properly manage a multicast region that is under the control of a single administration, it is necessary to understand the communications patterns that will exist among the routers in this region. From the perspective of a speaking router, the information from that router is sent (multicast) to all of its neighbors. From the perspective of a listening router, the information coming from each of its neighbors is distinct from the information coming from every other router to which it is directly connected. Thus, an administrative region contains many (small) distinct groups, all of which happen to be using the same multicast destination address (e.g., ALL_PIM_ROUTERS, see Section 11), and each of which is centered on the associated speaking router.
在讨论正确管理由单一管理控制的多播区域所需的一组安全关联之前，有必要了解该区域中路由器之间存在的通信模式。从说话的路由器的角度来看，来自该路由器的信息被发送（多播）到其所有邻居。从侦听路由器的角度来看，来自其每个邻居的信息与来自其直接连接的每个其他路由器的信息是不同的。因此，一个行政区域包含许多（小的）不同的组，所有这些组恰好使用相同的多播目的地地址（例如，所有的PIM路由器，参见第11节），并且每个组都以相关的语音路由器为中心。
Consider the example configuration as shown in Figure 1.
考虑示例配置，如图1所示。
R2 R3 R4 R5 R6
| | | | |
| | | | |
--------- ---------------
| |
| |
\ /
R1
/ \
| |
| |
--------- --------------------
| | | | |
| | | | |
R7 R8 R9 R10 R11
| | | | |
|
|
-------------
| | |
| | |
R12 R13 R14
R2 R3 R4 R5 R6
| | | | |
| | | | |
--------- ---------------
| |
| |
\ /
R1
/ \
| |
| |
--------- --------------------
| | | | |
| | | | |
R7 R8 R9 R10 R11
| | | | |
|
|
-------------
| | |
| | |
R12 R13 R14
Figure 1: Set of router interconnections
图1：路由器互连集
In this configuration, router R1 has four interfaces, and is the speaking router for a group whose listening routers are routers R2 through R11. Router R9 is the speaking router for a group whose listening routers are routers R1, R8, and R10-R14.
在这种配置中，路由器R1有四个接口，是一个组的语音路由器，该组的监听路由器是路由器R2到R11。路由器R9是一个组的语音路由器，该组的监听路由器为路由器R1、R8和R10-R14。
From the perspective of R1 as a speaking router, if a Security Association SA1 is assigned to protect outgoing packets from R1, then it is necessary to distribute the key for this association to each of the routers R2 through R11. Similarly, from the perspective of R9 as a speaking router, if a Security Association is assigned to protect the outgoing packets from R9, then it is necessary to distribute the key for this association to each of the routers R1, R8, and R10 through R14.
从R1作为语音路由器的角度来看，如果分配了安全关联SA1以保护来自R1的传出分组，则有必要将该关联的密钥分发到路由器R2到R11中的每一个。类似地，从作为语音路由器的R9的角度来看，如果分配了安全关联以保护来自R9的传出分组，则有必要将该关联的密钥分发到路由器R1、R8和R10到R14中的每一个。
From the perspective of R1 as a listening router, all packets arriving from R2 through R11 need to be distinguished from each other, to permit selecting the correct Security Association in the SAD. (Packets from each of the peer routers (R2 through R11) represent communication from a different speaker, with a separate sequence-number space, even though they are sent using the same destination address.) For a multicast Security Association, RFC 4301 permits using the source address in the selection function. If the source addresses used by routers R2 through R11 are globally unique, then the source addresses of the peer routers are sufficient to achieve the differentiation. If the sending routers use link-local addresses, then these addresses are unique only on a per-interface basis, and it is necessary to use the Interface ID tag as an additional selector, i.e., either the selection function has to have the Interface ID tag as one of its inputs or separate SADs have to be maintained for each interface.
从R1作为侦听路由器的角度来看，从R2到R11到达的所有数据包都需要相互区分，以允许在SAD中选择正确的安全关联。（来自每个对等路由器（R2到R11）的分组表示来自不同扬声器的通信，具有单独的序列号空间，即使它们使用相同的目的地地址发送。）对于多播安全关联，RFC 4301允许在选择功能中使用源地址。如果路由器R2到R11使用的源地址是全局唯一的，则对等路由器的源地址足以实现区分。如果发送路由器使用链路本地地址，则这些地址仅在每个接口上是唯一的，并且有必要使用接口ID标签作为附加选择器，即选择功能必须将接口ID标签作为其输入之一，或者必须为每个接口维护单独的SAD。
If the assumption of connectivity to the key server can be made (which is true in the PIM-SM case), then the Group Controller/Key Server (GC/KS) that is used for the management of the keys can be centrally located (and duplicated for reliability). If this assumption cannot be made (i.e., in the case of adjacencies for a unicast router), then some form of "local" key server must be available for each group. Given that the listening routers are never more than one hop away from the speaking router, the speaking router is the obvious place to locate the "local" key server. As such, this may be a useful approach even in the PIM-SM case. This approach has the additional advantage that there is no need to duplicate the local key server for reliability, since if the key server is down, it is very likely that the speaking router is also down.
如果可以假设连接到密钥服务器（在PIM-SM案例中是如此），则用于密钥管理的组控制器/密钥服务器（GC/KS）可以位于中心位置（并复制以确保可靠性）。如果无法做出此假设（即，在单播路由器的邻接情况下），则必须为每个组提供某种形式的“本地”密钥服务器。考虑到侦听路由器与说话者路由器的距离不会超过一跳，说话者路由器显然是定位“本地”密钥服务器的地方。因此，即使在PIM-SM情况下，这也可能是一种有用的方法。这种方法还有一个额外的优点，即不需要复制本地密钥服务器以提高可靠性，因为如果密钥服务器关闭，很可能是语音路由器也关闭了。
Each distinct group consists of one speaker, and the set of directly connected listeners. If the decision is made to maintain one Security Association per speaker (see Section 8), then the key server will need to be aware of the adjacencies of each speaker. Procedures for managing and distributing these adjacencies are out of scope for this document.
每个不同的组由一个演讲者和一组直接连接的听众组成。如果决定为每个说话人维护一个安全关联（参见第8节），那么密钥服务器将需要知道每个说话人的邻接情况。管理和分发这些邻接的程序超出了本文档的范围。
The number of Security Associations to be maintained by a PIM router depends on the required security level and available key management.
PIM路由器要维护的安全关联的数量取决于所需的安全级别和可用的密钥管理。
This SHOULD be decided by the Network Administrator. Two different ways are shown in Figures 2 and 3. It is assumed that A, B, and C are three PIM routers, where B and C are directly connected with A, and there is no direct link between B and C.
这应由网络管理员决定。图2和图3显示了两种不同的方式。假设A、B和C是三个PIM路由器，其中B和C直接与A连接，B和C之间没有直接链路。
|
+++++ |
+ B + SAb ------------>|
+ + SAa <------------|
+++++ |
|
+++++ SAb <------------|
+ + ---->|
+ + /
+ A + SAa -------
+ + \
+ + ---->|
+++++ SAc <------------|
|
+++++ |
+ C + SAc ------------>|
+ + SAa <------------|
+++++ |
|
Directly connected network
|
+++++ |
+ B + SAb ------------>|
+ + SAa <------------|
+++++ |
|
+++++ SAb <------------|
+ + ---->|
+ + /
+ A + SAa -------
+ + \
+ + ---->|
+++++ SAc <------------|
|
+++++ |
+ C + SAc ------------>|
+ + SAa <------------|
+++++ |
|
Directly connected network
Figure 2: Activate unique Security Association for each peer
图2：为每个对等方激活唯一的安全关联
The first method, shown in Figure 2, SHOULD be supported by every implementation. In this method, each node will use a unique SA for its outbound traffic. A, B, and C will use SAa, SAb, and SAc, respectively, for sending any traffic. Each node will include the source address when searching the SAD for a match. Router A will use SAb and SAc for packets received from B and C, respectively. The number of SAs to be activated and maintained by a PIM router will be equal to the number of directly connected routers, plus one for sending its own traffic. Also, the addition of a PIM router in the network will require the addition of another SA on every directly connected PIM router. This solution will be scalable and practically feasible with an automated key management protocol. However, it MAY be used with manual key management, if the number of directly connected routers is small.
第一种方法，如图2所示，应该得到每个实现的支持。在这种方法中，每个节点将为其出站流量使用唯一的SA。A、 B和C将分别使用SAa、SAb和SAc发送任何流量。在搜索SAD以查找匹配项时，每个节点都将包含源地址。路由器A将分别对从B和C接收的数据包使用SAb和SAc。PIM路由器要激活和维护的SA数量将等于直接连接的路由器数量，加上一个用于发送自身流量的路由器数量。此外，在网络中添加PIM路由器需要在每个直接连接的PIM路由器上添加另一个SA。该解决方案将具有可扩展性，并且在自动密钥管理协议的支持下切实可行。但是，如果直接连接的路由器数量较少，则可以将其与手动密钥管理一起使用。
|
+++++ |
+ B + SAo ------------>|
+ + SAi <------------|
+++++ |
|
+++++ SAi <------------|
+ + ---->|
+ + /
+ A + SAo -------
+ + \
+ + ---->|
+++++ SAi <------------|
|
+++++ |
+ C + SAo ------------>|
+ + SAi <------------|
+++++ |
|
Directly connected network
|
+++++ |
+ B + SAo ------------>|
+ + SAi <------------|
+++++ |
|
+++++ SAi <------------|
+ + ---->|
+ + /
+ A + SAo -------
+ + \
+ + ---->|
+++++ SAi <------------|
|
+++++ |
+ C + SAo ------------>|
+ + SAi <------------|
+++++ |
|
Directly connected network
Figure 3: Activate two Security Associations
图3：激活两个安全关联
The second method, shown in Figure 3, MUST be supported by every implementation. In this simple method, all the nodes will use two SAs, one for sending (SAo) and the other for receiving (SAi) traffic. Thus, the number of SAs is always two and will not be affected by addition of a PIM router. Although two different SAs (i.e., SAo and SAi) are used in this method, the SA parameters (keys, Security Parameter Index (SPI), etc.) for the two SAs are identical, i.e., the same information is shared among all the routers in an administrative region. This document RECOMMENDS this second method for manual key configuration. However, it MAY also be used with automated key configuration.
第二种方法（如图3所示）必须得到每个实现的支持。在这个简单的方法中，所有节点将使用两个SA，一个用于发送（SAo），另一个用于接收（SAi）流量。因此，SA的数量始终为两个，并且不会受到添加PIM路由器的影响。尽管在该方法中使用了两个不同的SA（即SAo和SAi），但两个SA的SA参数（密钥、安全参数索引（SPI）等）是相同的，即，在管理区域中的所有路由器之间共享相同的信息。本文档推荐第二种手动钥匙配置方法。但是，它也可以与自动密钥配置一起使用。
An analysis of the considerations for key management is provided in RFC 4107 [RFC4107].
RFC 4107[RFC4107]中提供了密钥管理注意事项的分析。
In PIM-SM deployments it is expected that secure sessions will be relatively long-lived, and it is not expected that keys will be significantly exposed through normal operational activity. Manual keying is judged acceptable in the light of the relatively low rate of change that is required.
在PIM-SM部署中，预计安全会话将相对长寿命，并且预计密钥不会通过正常操作活动显著公开。根据所需的相对较低的变化率，判断手动键控是可接受的。
To maintain the security of a link, the authentication and encryption key values SHOULD be changed periodically, to limit the risk of undetected key disclosure. Keys SHOULD also be changed when there is a change of trusted personnel.
为了维护链路的安全性，应定期更改身份验证和加密密钥值，以限制未检测到的密钥泄露风险。当可信人员发生变化时，也应更换密钥。
Manual keying offers the ability to change keys in a coordinated way, but it has several drawbacks in PIM-SM systems. Some of these are listed in Section 15 ("Security Considerations") of this document.
手动键控提供了以协调方式更改键的能力，但在PIM-SM系统中有几个缺点。其中一些在本文件第15节（“安全考虑”）中列出。
According to an analysis in line with RFC 4107 [RFC4107], PIM-SM would benefit from automated key management and roll over because all the disadvantages of manual keys listed in Section 15 would be eliminated. However, suitable techniques for automated key management do not currently exist. Work is in hand in the IETF to develop suitable solutions. In the meantime, implementations MUST support manual rekeying as described below. Implementers and deployers need to be aware of the requirement to upgrade to support automated key management as soon as suitable techniques are available.
根据RFC 4107[RFC4107]的分析，PIM-SM将受益于自动钥匙管理和翻滚，因为第15节中列出的手动钥匙的所有缺点将被消除。然而，目前还不存在适用于自动密钥管理的技术。IETF正在着手开发合适的解决方案。同时，实现必须支持如下所述的手动密钥更新。实施者和部署者需要了解升级的需求，以便在适当的技术可用时支持自动密钥管理。
In accordance with the requirements of RFC 4107 [RFC4107], the following three-step procedure provides a possible mechanism to rekey the routers on a link without dropping PIM-SM protocol packets or disrupting the adjacency, while ensuring that it is always clear which key is being used.
根据RFC 4107[RFC4107]的要求，以下三步程序提供了一种可能的机制，在不丢弃PIM-SM协议包或中断邻接的情况下，在链路上为路由器重新设置密钥，同时确保始终清楚使用的密钥。
1. For every router on the link, create an additional inbound SA for the interface being rekeyed using a new SPI and the new key.
1. 对于链路上的每个路由器，为使用新SPI和新密钥重新设置密钥的接口创建一个额外的入站SA。
2. For every router on the link, replace the original outbound SA with one using the new SPI and key values. The SA replacement operation MUST be atomic with respect to sending PIM-SM packets on the link, so that no PIM-SM packets are sent without authentication/encryption
2. 对于链路上的每个路由器，使用新的SPI和键值替换原始出站SA。SA替换操作在链路上发送PIM-SM数据包时必须是原子操作，以便在没有身份验证/加密的情况下不会发送PIM-SM数据包
3. For every router on the link, remove the original inbound SA.
3. 对于链路上的每个路由器，删除原始入站SA。
Note that all routers on the link MUST complete step 1 before any begin step 2. Likewise, all the routers on the link MUST complete step 2 before any begin step 3.
请注意，链路上的所有路由器必须在开始任何步骤2之前完成步骤1。同样，链路上的所有路由器必须在任何开始步骤3之前完成步骤2。
One way to control the progression from one step to another is for each router to have a configurable time constant KeyRolloverInterval. After the router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3.
控制从一个步骤到另一个步骤的过程的一种方法是，每个路由器都有一个可配置的时间常数KeyRolloverInterval。路由器在给定链路上开始步骤1后，等待该间隔，然后移动到步骤2。同样，在移动到步骤2之后，它等待该间隔，然后移动到步骤3。
In order to achieve smooth key transition, all routers on a link MUST use the same value for KeyRolloverInterval and MUST initiate the key rollover process within this time period.
为了实现平稳的密钥转换，链路上的所有路由器必须使用相同的KeyRolloverInterval值，并且必须在此时间段内启动密钥翻转过程。
At the end of this time period, all the routers on the link will have a single inbound and outbound SA for PIM-SM with the new SPI and key values.
在此时间段结束时，链路上的所有路由器都将为PIM-SM提供一个具有新SPI和键值的入站和出站SA。
The configured value of KeyRolloverInterval needs to be long enough to allow the Administrator to change keys on all the PIM-SM routers. As this value can vary significantly depending on the implementation and the deployment, it is left to the Administrator to choose an appropriate value.
KeyRolloverInterval的配置值需要足够长，以允许管理员更改所有PIM-SM路由器上的密钥。由于此值可能因实施和部署的不同而有很大差异，因此由管理员选择适当的值。
In keeping with the goal of reducing key exposure, the encryption and authentication keys SHOULD be changed at least every 90 days.
为了实现减少密钥暴露的目标，加密和身份验证密钥至少应每90天更改一次。
The Administrator must configure the necessary Security Associations. Each SA entry has the source address of an authorized peer, and a Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the manually configured SAs MUST be assigned by the Administrator to ensure that the SPI does not conflict with existing SPI values in the SAD.
管理员必须配置必要的安全关联。每个SA条目都有授权对等方的源地址和所有\u PIM\u路由器的目标地址。管理员必须为手动配置的SAs分配唯一的SPI值，以确保SPI不会与SAD中的现有SPI值冲突。
The Administrator must configure the necessary SPD entries. The SPD entry must ensure that any outbound IP traffic packet traversing the IPsec boundary, with PIM as its next layer protocol and sent to the Destination Address of ALL_PIM_ROUTERS, is protected by ESP or AH. Note that this characterization includes all the link-local messages (Hello, Join/Prune, Bootstrap, Assert).
管理员必须配置必要的SPD条目。SPD条目必须确保通过IPsec边界的任何出站IP流量数据包（PIM作为其下一层协议并发送到所有_-PIM_路由器的目标地址）受到ESP或AH的保护。注意，此特征化包括所有链接本地消息（Hello、Join/Prune、Bootstrap、Assert）。
When automatic keying is used, the SA creation is done dynamically using a group key management protocol. The GSPD and PAD tables are configured by the Administrator. The PAD table provides the link between the IPsec subsystem and the group key management protocol.
当使用自动密钥时，SA创建是使用组密钥管理协议动态完成的。GSPD和PAD表由管理员配置。PAD表提供IPsec子系统和组密钥管理协议之间的链接。
For automatic keying, the implementation MUST support the multicast extensions described in [RFC5374].
对于自动键控，实现必须支持[RFC5374]中描述的多播扩展。
All PIM routers participate in an authentication scheme that identifies permitted neighbors and achieves peer authentication during SA negotiation, leading to child SAs being established and saved in the SAD.
所有PIM路由器都参与身份验证方案，该方案识别允许的邻居，并在SA协商期间实现对等身份验证，从而建立子SA并将其保存在SAD中。
The Administrator must configure the necessary GSPD entries for "sender only" directionality. This rule MUST trigger the group key management protocol for a registration exchange. This exchange will set up the outbound SAD entry that encrypts the multicast PIM control message. Considering that this rule is "sender only", no inbound SA is created in the reverse direction.
管理员必须为“仅发件人”方向性配置必要的GSPD条目。此规则必须触发注册交换的组密钥管理协议。此交换将设置对多播PIM控制消息进行加密的出站SAD条目。考虑到此规则为“仅发件人”，因此不会以相反方向创建入站SA。
In addition, the registration exchange will trigger the installation of the GSPD entries corresponding to each legitimate peer router, with direction "receiver only". Procedures for achieving the registration exchange are out of scope for this document.
此外，注册交换将触发对应于每个合法对等路由器的GSPD条目的安装，方向为“仅接收器”。实现注册交换的程序不在本文件的范围内。
A router SHOULD NOT dynamically detect new neighbors as the result of receiving an unauthenticated PIM-SM link-local message or an IPsec packet that fails an SAD lookup. An automated key management protocol SHOULD provide a means of notifying a router of new, legitimate neighbors.
路由器不应在收到未经验证的PIM-SM链路本地消息或未通过SAD查找的IPsec数据包时动态检测新邻居。自动密钥管理协议应提供一种通知路由器新的合法邻居的方法。
The PAD will be configured with information to permit identification of legitimate group members and senders (i.e., to control the adjacency). Procedures for doing this are out of scope for this document.
PAD将配置信息，以允许识别合法的组成员和发送者（即，控制邻接）。执行此操作的程序超出了本文档的范围。
For an SA that carries unicast traffic, three parameters (SPI, destination address, and security protocol type (AH or ESP)) are used in the Security Association lookup process for inbound packets. The SPI is sufficient to specify an SA. However, an implementation may use the SPI in conjunction with the IPsec protocol type (AH or ESP) for the SA lookup process. According to RFC 4301 [RFC4301], for multicast SAs, in conjunction with the SPI, the destination address or the destination address plus the sender address may also be used in the SA lookup. This applies to both ESP and AH. The security protocol field is not employed for a multicast SA lookup.
对于承载单播通信量的SA，在入站数据包的安全关联查找过程中使用三个参数（SPI、目标地址和安全协议类型（AH或ESP））。SPI足以指定SA。然而，对于SA查找过程，实现可以将SPI与IPsec协议类型（AH或ESP）结合使用。根据RFC 4301[RFC4301]，对于多播SA，结合SPI，也可以在SA查找中使用目的地地址或目的地地址加上发送方地址。这适用于ESP和AH。安全协议字段不用于多播SA查找。
Given that, from the prospective of a receiving router, each peer router is an independent sender and given that the destination address will be the same for all senders, the receiving router MUST use SPI plus destination address plus sender address when performing the SA lookup. In effect, link-local communication is an SSM communication that happens to use an Any-Source Multicast (ASM) address (which is shared among all the routers).
从接收路由器的角度来看，每个对等路由器都是独立的发送方，并且所有发送方的目标地址都相同，因此，在执行SA查找时，接收路由器必须使用SPI加目标地址加发送方地址。实际上，链路本地通信是一种SSM通信，它恰好使用任意源多播（ASM）地址（在所有路由器之间共享）。
Given that it is always possible to distinguish a connection using IPsec from a connection not using IPsec, it is recommended that the address ALL_PIM_ROUTERS be used, to maintain consistency with present practice.
考虑到始终可以区分使用IPsec的连接和不使用IPsec的连接，建议使用地址ALL_PIM_路由器，以保持与当前实践的一致性。
Given that the sender address of an incoming packet may be only locally unique (because of the use of link-local addresses), it is necessary for a receiver to use the interface ID tag to determine the associated SA for that sender. Therefore, this document mandates that the interface ID tag, the SPI, and the sender address MUST be used in the SA lookup process.
假设传入分组的发送方地址可能仅在本地唯一（因为使用链路本地地址），则接收方有必要使用接口ID标签来确定该发送方的关联SA。因此，本文档要求在SA查找过程中必须使用接口ID标记、SPI和发送方地址。
Although link-level messages on a link constitute a multiple-sender, multiple-receiver group, the use of the interface ID tag and sender address for SA lookup essentially resolves the communication into a separate SA for each sender/destination pair, even for the case where only two SAs (with identical SA parameters) are used for the entire administrative region. Therefore, the statement in the AH RFC (Section 2.5 of [RFC4302]) that "for a multi-sender SA, the anti-replay features are not available" becomes irrelevant to the PIM-SM link-local message exchange.
尽管链路上的链路级消息构成了多个发送方、多个接收方组，但使用接口ID标记和发送方地址进行SA查找基本上将通信解析为每个发送方/目的地对的单独SA，即使在只有两个SA（具有相同SA参数）的情况下也是如此适用于整个行政区域。因此，AH RFC（RFC4302）中“对于多发送方SA，防重放功能不可用”的声明（第2.5节）与PIM-SM链路本地消息交换无关。
To activate the anti-replay mechanism in a unicast communication, the receiver uses the sliding window protocol and it maintains a sequence number for this protocol. This sequence number starts from zero.
为了激活单播通信中的防重播机制，接收器使用滑动窗口协议，并维护该协议的序列号。这个序列号从零开始。
Each time the sender sends a new packet, it increments this number by one. In a multi-sender multicast group communication, a single sequence number for the entire group would not be enough.
每次发送方发送一个新数据包时，它都会将这个数字增加一。在多发送方多播组通信中，整个组只有一个序列号是不够的。
The whole scenario is different for PIM link-local messages. These messages are sent to local links with TTL = 1. A link-local message never propagates through one router to another. The use of the sender address and the interface ID tag for SA lookup converts the relationship from a multiple-sender group to multiple single-sender associations. This specification RECOMMENDS activation of the anti-replay mechanism only if the SAs are assigned using an automated key management procedure. If manual key management is used, the anti-replay SHOULD NOT be activated.
对于PIM链接本地消息，整个场景是不同的。这些消息被发送到TTL=1的本地链接。链路本地消息从不通过一个路由器传播到另一个路由器。使用发送方地址和接口ID标记进行SA查找将关系从多个发送方组转换为多个单发送方关联。本规范建议仅当使用自动密钥管理程序分配SAs时才激活防重播机制。如果使用手动密钥管理，则不应激活防重放。
If an existing router has to restart, in accordance with RFC 4303 [RFC4303], the sequence-number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced.
根据RFC 4303[RFC4303]，如果现有路由器必须重新启动，则必须在本地重新启动等过程中正确维护发送方的序列号计数器，直到更换密钥。
RFC 4601 suggests that it may be desirable to implement a separate Security Policy Database (SPD) for each router interface. The use of link-local addresses in certain circumstances implies that differentiation of ambiguous speaker addresses requires the use of the interface ID tag in the SA lookup. One way to do this is through the use of multiple SPDs. Alternatively, the interface ID tag may be a specific component of the selector algorithm. This is in conformance with RFC 4301, which explicitly removes the requirement for separate SPDs that was present in RFC 2401 [RFC2401].
RFC 4601建议，可能需要为每个路由器接口实现单独的安全策略数据库（SPD）。在某些情况下使用链接本地地址意味着区分不明确的说话人地址需要在SA查找中使用接口ID标记。一种方法是使用多个SPD。或者，接口ID标签可以是选择器算法的特定组件。这与RFC 4301一致，RFC 4301明确删除了RFC 2401[RFC2401]中存在的单独SPD的要求。
In the [RFC4302], there is a provision for a 64-bit Extended Sequence Number (ESN) as the counter of the sliding window used in the anti-replay protocol. Both the sender and the receiver maintain a 64-bit counter for the sequence number, although only the lower order 32 bits are sent in the transmission. In other words, it will not affect the present header format of AH. If ESN is used, a sender router can send 2^64 -1 packets without any intervention. This number is very large, and from a PIM router's point of view, a PIM router can never exceed this number in its lifetime. This makes it reasonable to permit manual configuration for a small number of PIM routers, since the sequence number will never roll over. For this reason, when manual configuration is used, ESN SHOULD be deployed as the sequence number for the sliding window protocol. In addition,
[RFC4302]中规定了64位扩展序列号（ESN）作为反重放协议中使用的滑动窗口计数器。发送方和接收方都为序列号保留一个64位计数器，尽管在传输中只发送低阶32位。换句话说，它不会影响AH当前的头格式。如果使用ESN，发送方路由器可以在没有任何干预的情况下发送2^64-1个数据包。这个数字非常大，从PIM路由器的角度来看，PIM路由器在其生命周期内永远不会超过这个数字。这使得允许对少量PIM路由器进行手动配置是合理的，因为序列号永远不会滚动。因此，当使用手动配置时，应将ESN部署为滑动窗口协议的序列号。此外
when an ESN is used with a manually keyed SA, it MUST be saved over a reboot, along with an indication of which sequence numbers have been used.
当ESN与手动键控SA一起使用时，必须在重新启动时将其保存，并指示使用了哪些序列号。
The whole document considers the security issues of PIM link-local messages and proposes a mechanism to protect them.
整个文档考虑了PIM链路本地消息的安全问题，并提出了一种保护机制。
Limitations of manual keys:
手动钥匙的限制：
The following are some of the known limitations of the usage of manual keys.
以下是一些已知的手动钥匙使用限制。
o If replay protection cannot be provided, the PIM routers will not be secured against all the attacks that can be performed by replaying PIM packets.
o 如果无法提供重播保护，PIM路由器将无法抵御重播PIM数据包所能执行的所有攻击。
o Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
o 手动钥匙通常寿命很长（经常更换它们是一项乏味的任务）。这使攻击者有足够的时间发现密钥。
o As the Administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least).
o 由于管理员正在手动配置密钥，因此配置的密钥可能很弱（至少存在已知的DES/3DES弱密钥）。
Impersonation attacks:
模拟攻击：
The usage of the same key on all the PIM routers connected to a link leaves them all insecure against impersonation attacks if any one of the PIM routers is compromised, malfunctioning, or misconfigured.
在连接到链路的所有PIM路由器上使用相同的密钥会使它们在任何一个PIM路由器受损、出现故障或配置错误时都不安全，无法抵御模拟攻击。
Detailed analysis of various vulnerabilities of routing protocols is provided in RFC 4593 [RFC4593]. For further discussion of PIM-SM and multicast security, the reader is referred to RFC 5294 [RFC5294], RFC 4609 [RFC4609], and the Security Considerations section of RFC 4601 [RFC4601].
RFC 4593[RFC4593]中提供了路由协议各种漏洞的详细分析。对于PIM-SM和多播安全性的进一步讨论，读者参考RFC 5294[RFC5294]、RFC 4609[RFC4609]和RFC 4601[RFC4601]的安全注意事项部分。
The structure and text of this document draw heavily from RFC 4552 [RFC4552]. The authors of this document thank M. Gupta and N. Melam for permission to do this.
本文件的结构和文本主要来自RFC 4552[RFC4552]。本文件的作者感谢M.Gupta和N.Melam的许可。
The quality of this document was substantially improved after SECDIR pre-review by Brian Weis, and after AD review by Adrian Farrel.
经过Brian Weis的SECDIR预审查和Adrian Farrel的AD审查，本文件的质量得到了显著提高。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，2008年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC2117] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2117, June 1997.
[RFC2117]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.，和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 21171997年6月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，和V.Jacobson，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[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月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, August 2008.
[RFC5294]Savola，P.和J.Lingard，“协议独立多播（PIM）的主机威胁”，RFC 52942008年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月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，2006年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
Authors' Addresses
作者地址
J. William Atwood Concordia University/CSE 1455 de Maisonneuve Blvd. West Montreal, QC H3G 1M8 Canada
J.威廉·阿特伍德·康科迪亚大学/CSE 1455德梅森纽韦大道。加拿大西蒙特利尔QC H3G 1M8
Phone: +1(514)848-2424 ext3046
EMail: bill@cse.concordia.ca
URI: http://users.encs.concordia.ca/~bill
Phone: +1(514)848-2424 ext3046
EMail: bill@cse.concordia.ca
URI: http://users.encs.concordia.ca/~bill
Salekul Islam INRS Energie, Materiaux et Telecommunications 800 de La Gauchetiere, Suite 800 Montreal, QC H5A 1K6 Canada
Salekul Islam INRS Energie，Materialux et Telecommunications 800 de La Gauchetiere，800套房，加拿大蒙特利尔QC H5A 1K6
EMail: Salekul.Islam@emt.inrs.ca
URI: http://users.encs.concordia.ca/~salek_is
EMail: Salekul.Islam@emt.inrs.ca
URI: http://users.encs.concordia.ca/~salek_is
Maziar Siami Concordia University/CIISE 1455 de Maisonneuve Blvd. West Montreal, QC H3G 1M8 Canada
Maziar Siami Concordia大学/CIISE 1455 de Maisonneuve大道。加拿大西蒙特利尔QC H3G 1M8
EMail: mzrsm@yahoo.ca
EMail: mzrsm@yahoo.ca