Network Working Group B. Weis
Request for Comments: 5374 Cisco Systems
Category: Standards Track G. Gross
Secure Multicast Networks LLC
D. Ignjatic
Polycom
November 2008
Network Working Group B. Weis
Request for Comments: 5374 Cisco Systems
Category: Standards Track G. Gross
Secure Multicast Networks LLC
D. Ignjatic
Polycom
November 2008
Multicast Extensions to the Security Architecture for the Internet Protocol
Internet协议安全体系结构的多播扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast.
Internet协议的安全体系结构描述了IP层流量的安全服务。该体系结构主要为Internet协议（IP）单播数据包定义服务。本文档描述如何将IPsec安全服务应用于IP多播数据包。这些扩展仅与支持多播的IPsec实现相关。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................4
2. Overview of IP Multicast Operation ..............................6
3. Security Association Modes ......................................7
3.1. Tunnel Mode with Address Preservation ......................7
4. Security Association ............................................8
4.1. Major IPsec Databases ......................................8
4.1.1. Group Security Policy Database (GSPD) ...............8
4.1.2. Security Association Database (SAD) ................12
4.1.3. Group Peer Authorization Database (GPAD) ...........12
4.2. Group Security Association (GSA) ..........................14
4.2.1. Concurrent IPsec SA Life Spans and Re-key Rollover .15
4.3. Data Origin Authentication ................................17
4.4. Group SA and Key Management ...............................18
4.4.1. Co-Existence of Multiple Key Management Protocols ..18
5. IP Traffic Processing ..........................................18
5.1. Outbound IP Traffic Processing ............................18
5.2. Inbound IP Traffic Processing .............................19
6. Security Considerations ........................................22
6.1. Security Issues Solved by IPsec Multicast Extensions ......22
6.2. Security Issues Not Solved by IPsec Multicast Extensions ..23
6.2.1. Outsider Attacks ...................................23
6.2.2. Insider Attacks ....................................23
6.3. Implementation or Deployment Issues that Impact Security ..24
6.3.1. Homogeneous Group Cryptographic Algorithm
Capabilities .......................................24
6.3.2. Groups that Span Two or More Security
Policy Domains .....................................24
6.3.3. Source-Specific Multicast Group Sender
Transient Locators .................................25
7. Acknowledgements ...............................................25
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................26
Appendix A - Multicast Application Service Models .................28
A.1 Unidirectional Multicast Applications ......................28
A.2 Bi-directional Reliable Multicast Applications .............28
A.3 Any-To-Any Multicast Applications ..........................30
Appendix B - ASN.1 for a GSPD Entry ...............................30
B.1 Fields Specific to a GSPD Entry ............................30
B.2 SPDModule ..................................................31
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................4
2. Overview of IP Multicast Operation ..............................6
3. Security Association Modes ......................................7
3.1. Tunnel Mode with Address Preservation ......................7
4. Security Association ............................................8
4.1. Major IPsec Databases ......................................8
4.1.1. Group Security Policy Database (GSPD) ...............8
4.1.2. Security Association Database (SAD) ................12
4.1.3. Group Peer Authorization Database (GPAD) ...........12
4.2. Group Security Association (GSA) ..........................14
4.2.1. Concurrent IPsec SA Life Spans and Re-key Rollover .15
4.3. Data Origin Authentication ................................17
4.4. Group SA and Key Management ...............................18
4.4.1. Co-Existence of Multiple Key Management Protocols ..18
5. IP Traffic Processing ..........................................18
5.1. Outbound IP Traffic Processing ............................18
5.2. Inbound IP Traffic Processing .............................19
6. Security Considerations ........................................22
6.1. Security Issues Solved by IPsec Multicast Extensions ......22
6.2. Security Issues Not Solved by IPsec Multicast Extensions ..23
6.2.1. Outsider Attacks ...................................23
6.2.2. Insider Attacks ....................................23
6.3. Implementation or Deployment Issues that Impact Security ..24
6.3.1. Homogeneous Group Cryptographic Algorithm
Capabilities .......................................24
6.3.2. Groups that Span Two or More Security
Policy Domains .....................................24
6.3.3. Source-Specific Multicast Group Sender
Transient Locators .................................25
7. Acknowledgements ...............................................25
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................26
Appendix A - Multicast Application Service Models .................28
A.1 Unidirectional Multicast Applications ......................28
A.2 Bi-directional Reliable Multicast Applications .............28
A.3 Any-To-Any Multicast Applications ..........................30
Appendix B - ASN.1 for a GSPD Entry ...............................30
B.1 Fields Specific to a GSPD Entry ............................30
B.2 SPDModule ..................................................31
The Security Architecture for the Internet Protocol [RFC4301] provides security services for traffic at the IP layer. It describes an architecture for IPsec-compliant systems and a set of security services for the IP layer. These security services primarily describe services and semantics for IPsec Security Associations (SAs) shared between two IPsec devices. Typically, this includes SAs with traffic selectors that include a unicast address in the IP destination field, and results in an IPsec packet with a unicast address in the IP destination field. The security services defined in RFC 4301 can also be used to tunnel IP multicast packets, where the tunnel is a pairwise association between two IPsec devices. RFC 4301 defined manually keyed transport mode IPsec SA support for IP packets with a multicast address in the IP destination address field. However, RFC 4301 did not define the interaction of an IPsec subsystem with a Group Key Management protocol or the semantics of a tunnel mode IPsec SA with an IP multicast address in the outer IP header.
互联网协议[RFC4301]的安全架构为IP层的流量提供安全服务。它描述了IPsec兼容系统的体系结构和IP层的一组安全服务。这些安全服务主要描述两个IPsec设备之间共享的IPsec安全关联（SA）的服务和语义。通常，这包括带有流量选择器的SAs，流量选择器在IP目的地字段中包含单播地址，并导致在IP目的地字段中包含单播地址的IPsec数据包。RFC 4301中定义的安全服务还可用于隧道IP多播分组，其中隧道是两个IPsec设备之间的成对关联。RFC 4301为IP目的地地址字段中具有多播地址的IP数据包定义了手动密钥传输模式IPsec SA支持。然而，RFC 4301没有定义IPsec子系统与组密钥管理协议的交互，也没有定义隧道模式IPsec SA与外部IP报头中的IP多播地址的语义。
This document describes OPTIONAL extensions to RFC 4301 that further define the IPsec security architecture in order for groups of IPsec devices to share SAs. In particular, it supports SAs with traffic selectors that include a multicast address in the IP destination field and that result in an IPsec packet with an IP multicast address in the IP destination field. It also describes additional semantics for IPsec Group Key Management (GKM) subsystems. Note that this document uses the term "GKM protocol" generically and therefore does not assume a particular GKM protocol.
本文档描述了RFC 4301的可选扩展，这些扩展进一步定义了IPsec安全体系结构，以便IPsec设备组共享SAs。特别是，它支持带有流量选择器的SAs，该流量选择器在IP目的地字段中包含多播地址，并导致在IP目的地字段中包含IP多播地址的IPsec数据包。它还描述了IPsec组密钥管理（GKM）子系统的附加语义。请注意，本文件一般使用术语“GKM协议”，因此不采用特定的GKM协议。
An IPsec implementation that does not support multicast is not required to support these extensions.
不支持多播的IPsec实现不需要支持这些扩展。
Throughout this document, RFC 4301 semantics remain unchanged by the presence of these multicast extensions unless specifically noted to the contrary.
在本文档中，RFC 4301语义因这些多播扩展的存在而保持不变，除非另有明确说明。
The IPsec extensions described in this document support IPsec Security Associations that result in IPsec packets with IPv4 or IPv6 multicast group addresses as the destination address. Both Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569] group addresses are supported. These extensions are used when management policy requires that IP multicast packets protected by IPsec remain IP multicast packets. When management policy
本文档中描述的IPsec扩展支持IPsec安全关联，这些关联导致IPsec数据包以IPv4或IPv6多播组地址作为目标地址。支持任何源多播（ASM）和源特定多播（SSM）[RFC3569]组地址。当管理策略要求受IPsec保护的IP多播数据包保持为IP多播数据包时，将使用这些扩展。当管理策略
requires that the IP multicast packets be encapsulated as IP unicast packets (e.g., because the network connected to the unprotected interface does not support IP multicast), the extensions in this document are not used.
要求将IP多播数据包封装为IP单播数据包（例如，由于连接到未受保护接口的网络不支持IP多播），因此不使用本文档中的扩展。
These extensions also support Security Associations with IPv4 Broadcast addresses that result in an IPv4 link-level Broadcast packet, and IPv6 Anycast addresses [RFC2526] that result in an IPv6 Anycast packet. These destination address types share many of the same characteristics of multicast addresses because there may be multiple candidate receivers of a packet protected by IPsec.
这些扩展还支持与IPv4广播地址（生成IPv4链路级广播数据包）和IPv6选播地址（生成IPv6选播数据包）的安全关联。这些目标地址类型共享多播地址的许多相同特征，因为可能有多个受IPsec保护的数据包的候选接收器。
The IPsec architecture does not make requirements upon entities not participating in IPsec (e.g., network devices between IPsec endpoints). As such, these multicast extensions do not require intermediate systems in a multicast-enabled network to participate in IPsec. In particular, no requirements are placed on the use of multicast routing protocols (e.g., Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]) or multicast admission protocols (e.g., Internet Group Management Protocol (IGMP) [RFC3376]).
IPsec体系结构不要求未参与IPsec的实体（例如，IPsec端点之间的网络设备）。因此，这些多播扩展不需要启用多播的网络中的中间系统来参与IPsec。特别是，对多播路由协议（例如，协议独立多播-稀疏模式（PIM-SM）[RFC4601]）或多播接入协议（例如，互联网组管理协议（IGMP）[RFC3376]）的使用没有任何要求。
All implementation models of IPsec (e.g., "bump-in-the-stack", "bump-in-the-wire") are supported.
支持IPsec的所有实现模型（例如，“堆栈中的凹凸”、“线路中的凹凸”）。
This version of the multicast IPsec extension specification requires that all IPsec devices participating in a Security Association be homogeneous. They MUST share a common set of cryptographic transform and protocol-handling capabilities. The semantics of an "IPsec composite group" [COMPGRP], a heterogeneous IPsec cryptographic group formed from the union of two or more sub-groups, is an area for future standardization.
此版本的多播IPsec扩展规范要求参与安全关联的所有IPsec设备都是同质的。它们必须共享一组通用的加密转换和协议处理功能。“IPsec复合组”[COMPGRP]是由两个或多个子组联合而成的异构IPsec加密组，其语义是未来标准化的一个领域。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following key terms are used throughout this document.
本文件中使用了以下关键术语。
Any-Source Multicast (ASM) The Internet Protocol (IP) multicast service model as defined in RFC 1112 [RFC1112]. In this model, one or more senders source packets to a single IP multicast address. When receivers join the group, they receive all packets sent to that IP multicast address. This is known as a (*,G) group.
任意源多播（ASM）指RFC 1112[RFC1112]中定义的互联网协议（IP）多播服务模型。在此模型中，一个或多个发送方将数据包发送到单个IP多播地址。当接收者加入组时，他们接收发送到该IP多播地址的所有数据包。这被称为（*，G）群。
Group A set of devices that work together to protect group communications.
组一起工作以保护组通信的一组设备。
Group Controller Key Server (GCKS) A Group Key Management (GKM) protocol server that manages IPsec state for a group. A GCKS authenticates and provides the IPsec SA policy and keying material to GKM Group Members.
组控制器密钥服务器（GCKS）组密钥管理（GKM）协议服务器，用于管理组的IPsec状态。GCKS验证IPsec SA策略并向GKM组成员提供密钥材料。
Group Key Management (GKM) Protocol A key management protocol used by a GCKS to distribute IPsec Security Association policy and keying material. A GKM protocol is used when a group of IPsec devices require the same SAs. For example, when an IPsec SA describes an IP multicast destination, the sender and all receivers need to have the group SA.
组密钥管理（GKM）协议GCKS用于分发IPsec安全关联策略和密钥材料的密钥管理协议。当一组IPsec设备需要相同的SAs时，使用GKM协议。例如，当IPsec SA描述IP多播目的地时，发送方和所有接收方都需要具有组SA。
Group Key Management Subsystem A subsystem in an IPsec device implementing a Group Key Management protocol. The GKM subsystem provides IPsec SAs to the IPsec subsystem on the IPsec device. Refer to RFC 3547 [RFC3547] and RFC 4535 [RFC4535] for additional information.
组密钥管理子系统IPsec设备中实现组密钥管理协议的子系统。GKM子系统向IPsec设备上的IPsec子系统提供IPsec SAs。有关更多信息，请参阅RFC 3547[RFC3547]和RFC 4535[RFC4535]。
Group Member An IPsec device that belongs to a group. A Group Member is authorized to be a Group Sender and/or a Group Receiver.
组成员属于组的IPsec设备。集团成员被授权为集团发送方和/或集团接收方。
Group Owner An administrative entity that chooses the policy for a group.
组所有者为组选择策略的管理实体。
Group Security Association (GSA) A collection of IPsec Security Associations (SAs) and GKM subsystem SAs necessary for a Group Member to receive key updates. A GSA describes the working policy for a group. Refer to RFC 4046 [RFC4046] for additional information.
组安全关联（GSA）组成员接收密钥更新所需的IPsec安全关联（SA）和GKM子系统SA的集合。GSA描述组的工作策略。有关更多信息，请参阅RFC 4046[RFC4046]。
Group Security Policy Database (GSPD) The GSPD is a multicast-capable security policy database, as mentioned in RFC 3740 and Section 4.4.1.1. of RFC 4301. Its semantics are a superset of the unicast Security Policy Database (SPD) defined by Section 4.4.1 of RFC 4301. Unlike a unicast SPD-S, in which point-to-point traffic selectors are inherently bi-directional, multicast security traffic selectors in the GSPD-S include a "sender only", "receiver only", or "symmetric" directional attribute. Refer to Section 4.1.1 for more details.
组安全策略数据库（GSPD）GSPD是一个支持多播的安全策略数据库，如RFC 3740和第4.4.1.1节所述。RFC 4301的一部分。其语义是RFC 4301第4.4.1节定义的单播安全策略数据库（SPD）的超集。与单播SPD-S不同，在单播SPD-S中，点到点流量选择器本质上是双向的，GSPD-S中的多播安全流量选择器包括“仅发送方”、“仅接收方”或“对称”方向属性。有关更多详细信息，请参阅第4.1.1节。
GSPD-S, GSPD-I, GSPD-O Group Security Policy Database (secure traffic), (inbound), and (outbound), respectively. See Section 4.4.1 of RFC 4301.
GSPD-S、GSPD-I、GSPD-O组安全策略数据库（安全流量），（入站）和（出站）。见RFC 4301第4.4.1节。
Group Receiver A Group Member that is authorized to receive packets sent to a group by a Group Sender.
组接收方授权接收由组发送方发送到组的数据包的组成员。
Group Sender A Group Member that is authorized to send packets to a group.
组发送者有权向组发送数据包的组成员。
Source-Specific Multicast (SSM) The Internet Protocol (IP) multicast service model as defined in RFC 3569 [RFC3569]. In this model, each combination of a sender and an IP multicast address is considered a group. This is known as an (S,G) group.
源特定多播（SSM）RFC 3569[RFC3569]中定义的互联网协议（IP）多播服务模型。在该模型中，发送方和IP多播地址的每个组合都被视为一个组。这被称为（S，G）群。
Tunnel Mode with Address Preservation A type of IPsec tunnel mode used by security gateway implementations when encapsulating IP multicast packets such that they remain IP multicast packets. This mode is necessary for IP multicast routing to correctly route IP multicast packets protected by IPsec.
具有地址保留的隧道模式安全网关实现在封装IP多播数据包时使用的一种IPsec隧道模式，使其保持IP多播数据包。此模式是IP多播路由正确路由受IPsec保护的IP多播数据包所必需的。
IP multicasting is a means of sending a single packet to a "host group", a set of zero or more hosts identified by a single IP destination address. IP multicast packets are delivered to all members of the group either with "best-efforts" reliability [RFC1112] or as part of a reliable stream (e.g., NACK-Oriented Reliable Multicast (NORM) [RFC3940]).
IP多播是一种将单个数据包发送到“主机组”的方法，主机组是由单个IP目标地址标识的一组零个或多个主机。IP多播分组以“最大努力”可靠性[RFC1112]或作为可靠流的一部分（例如，面向NACK的可靠多播（NORM）[RFC3940]）交付给组的所有成员。
A sender to an IP multicast group sets the destination of the packet to an IP address that has been allocated for IP multicast. Allocated IP multicast addresses are defined in [RFC3171], [RFC3306], and [RFC3307]. Potential receivers of the packet "join" the IP multicast group by registering with a network routing device ([RFC3376], [RFC3810]), signaling its intent to receive packets sent to a particular IP multicast group.
IP多播组的发送方将数据包的目的地设置为已分配给IP多播的IP地址。[RFC3171]、[RFC3306]和[RFC3307]中定义了分配的IP多播地址。数据包的潜在接收者通过向网络路由设备（[RFC3376]，[RFC3810]）注册来“加入”IP多播组，用信号表示其接收发送到特定IP多播组的数据包的意图。
Network routing devices configured to pass IP multicast packets participate in multicast routing protocols (e.g., PIM-SM) [RFC4601]. Multicast routing protocols maintain state regarding which devices have registered to receive packets for a particular IP multicast group. When a router receives an IP multicast packet, it forwards a copy of the packet out of each interface for which there are known receivers.
配置为传递IP多播分组的网络路由设备参与多播路由协议（例如，PIM-SM）[RFC4601]。多播路由协议维护关于哪些设备已注册以接收特定IP多播组的数据包的状态。当一个路由器接收到一个IP多播数据包时，它会将该数据包的一个副本从每个有已知接收器的接口转发出去。
IPsec supports two modes of use: transport mode and tunnel mode. In transport mode, IP Authentication Header (AH) [RFC4302] and IP Encapsulating Security Payload (ESP) [RFC4303] provide protection primarily for next layer protocols; in tunnel mode, AH and ESP are applied to tunneled IP packets.
IPsec支持两种使用模式：传输模式和隧道模式。在传输模式下，IP认证头（AH）[RFC4302]和IP封装安全负载（ESP）[RFC4303]主要为下一层协议提供保护；在隧道模式下，AH和ESP应用于隧道IP数据包。
A host implementation of IPsec using the multicast extensions MAY use either transport mode or tunnel mode to encapsulate an IP multicast packet. These processing rules are identical to the rules described in Section 4.1 of [RFC4301]. However, the destination address for the IPsec packet is an IP multicast address, rather than a unicast host address.
使用多播扩展的IPsec的主机实现可以使用传输模式或隧道模式来封装IP多播分组。这些处理规则与[RFC4301]第4.1节中描述的规则相同。但是，IPsec数据包的目标地址是IP多播地址，而不是单播主机地址。
A security gateway implementation of IPsec MUST use a tunnel mode SA, for the reasons described in Section 4.1 of [RFC4301]. In particular, the security gateway needs to use tunnel mode to encapsulate incoming fragments, since IPsec cannot directly operate on fragments.
出于[RFC4301]第4.1节所述原因，IPsec的安全网关实现必须使用隧道模式SA。特别是，安全网关需要使用隧道模式来封装传入的片段，因为IPsec不能直接对片段进行操作。
New (tunnel) header construction semantics are required when tunnel mode is used to encapsulate IP multicast packets that are to remain IP multicast packets. These semantics are due to the following unique requirements of IP multicast routing protocols (e.g., PIM-SM [RFC4601]). This document describes these new header construction semantics as "tunnel mode with address preservation", which is described as follows.
当使用隧道模式封装将保留IP多播数据包的IP多播数据包时，需要新的（隧道）报头构造语义。这些语义是由于IP多播路由协议（例如PIM-SM[RFC4601]）的以下独特要求造成的。本文将这些新的头结构语义描述为“具有地址保留的隧道模式”，描述如下。
- When an IP multicast packet is received by a host or router, the destination address of the packet is compared to the local IP multicast state. If the (outer) destination IP address of an IP multicast packet is set to another IP address, the host or router receiving the IP multicast packet will not process it properly. Therefore, an IPsec security gateway needs to populate the multicast IP destination address in the outer header using the destination address from the inner header after IPsec tunnel encapsulation.
- 当主机或路由器接收到IP多播数据包时，会将数据包的目标地址与本地IP多播状态进行比较。如果IP多播数据包的（外部）目标IP地址设置为另一个IP地址，则接收IP多播数据包的主机或路由器将无法正确处理该数据包。因此，在IPsec隧道封装之后，IPsec安全网关需要使用来自内部报头的目标地址在外部报头中填充多播IP目标地址。
- IP multicast routing protocols typically create multicast distribution trees based on the source address as well as the group address. If an IPsec security gateway populates the (outer) source address of an IP multicast packet (with its own IP address, as called for in RFC 4301), the resulting IPsec-protected packet may fail Reverse Path Forwarding (RPF) checks performed by other routers. A failed RPF check may result in the packet being
- IP多播路由协议通常根据源地址和组地址创建多播分发树。如果IPsec安全网关填充IP多播数据包的（外部）源地址（如RFC 4301中所述，使用其自己的IP地址），则产生的IPsec保护数据包可能会使其他路由器执行的反向路径转发（RPF）检查失败。RPF检查失败可能导致数据包丢失
dropped. To accommodate routing protocol RPF checks, the security gateway implementing the IPsec multicast extensions SHOULD populate the outer IP address from the original packet IP source address. However, it should be noted that a security gateway performing source address preservation will not receive ICMP Path MTU (PMTU) or other messages intended for the security gateway (triggered by packets that have had the outer IP source address set to that of the inner header). Security gateway applications not requiring source address preservation will be able to receive ICMP PMTU messages and process them as described in Section 6.1 of RFC 4301.
下降。为了适应路由协议RPF检查，实现IPsec多播扩展的安全网关应该从原始数据包IP源地址填充外部IP地址。但是，应注意，执行源地址保留的安全网关不会接收ICMP Path MTU（PMTU）或其他针对安全网关的消息（由外部IP源地址设置为内部报头地址的数据包触发）。不需要源地址保留的安全网关应用程序将能够接收ICMP PMTU消息，并按照RFC 4301第6.1节中的说明对其进行处理。
Because some applications of address preservation may require that only the destination address be preserved, specification of destination address preservation and source address preservation are separated in the above description. Destination address preservation and source address preservation attributes are described in the Group Security Policy Database (GSPD) (defined later in this document), and are copied into corresponding Security Association Database (SAD) entries.
由于地址保留的一些应用可能要求仅保留目的地地址，因此在上述描述中分离了目的地地址保留和源地址保留的规范。目标地址保留和源地址保留属性在集团安全策略数据库（GSPD）（本文档稍后定义）中进行了描述，并复制到相应的安全关联数据库（SAD）条目中。
Address preservation is applicable only for tunnel mode IPsec SAs that specify the IP version of the encapsulating header to be the same version as that of the inner header. When the IP versions are different, IP multicast packets can be encapsulated using a tunnel interface, for example as described in [RFC4891], where the tunnel is also treated as an interface by IP multicast routing protocols.
地址保留仅适用于隧道模式IPsec SA，该模式将封装头的IP版本指定为与内部头的IP版本相同。当IP版本不同时，可以使用隧道接口封装IP多播数据包，例如[RFC4891]中所述，其中隧道也被IP多播路由协议视为接口。
In summary, propagating both the IP source and destination addresses of the inner IP header into the outer (tunnel) header allows IP multicast routing protocols to route a packet properly when the packet is protected by IPsec. This result is necessary in order for the multicast extensions to allow a host or security gateway to provide IPsec services for IP multicast packets. This method of RFC 4301 tunnel mode is known as "tunnel mode with address preservation".
总之，将内部IP报头的IP源地址和目标地址传播到外部（隧道）报头允许IP多播路由协议在数据包受IPsec保护时正确路由数据包。为了使多播扩展允许主机或安全网关为IP多播数据包提供IPsec服务，此结果是必需的。RFC 4301隧道模式的这种方法被称为“具有地址保留的隧道模式”。
The following sections describe the GKM subsystem and IPsec extension interactions with the IPsec databases. The major IPsec databases need expanded semantics to fully support multicast.
以下各节描述了GKM子系统和IPsec扩展与IPsec数据库的交互。主要的IPsec数据库需要扩展语义以完全支持多播。
The Group Security Policy Database is a security policy database capable of supporting both unicast Security Associations as defined by RFC 4301 and the multicast extensions defined by this
组安全策略数据库是一个安全策略数据库，能够支持由RFC 4301定义的单播安全关联和由RFC 4301定义的多播扩展
specification. The GSPD is considered to be the SPD, with the addition of the semantics relating to the multicast extensions described in this section. Appendix B provides an example of an ASN.1 definition of a GSPD entry.
规格GSPD被认为是SPD，添加了与本节中描述的多播扩展相关的语义。附录B提供了GSPD条目的ASN.1定义示例。
This document describes a new "address preservation" (AP) flag indicating that tunnel mode with address preservation is to be applied to a GSPD entry. The AP flag has two attributes: AP-L, used in the processing of the local tunnel address, and AP-R, used in the processing of the remote tunnel process. This flag is added to the GSPD "Processing info" field of the GSPD. The following text reproduced from Section 4.4.1.2 of RFC 4301 is amended to include this additional processing. (Note: for brevity, only the "Processing info" text related to tunnel processing has been reproduced.)
本文档描述了一个新的“地址保留”（AP）标志，该标志指示具有地址保留的隧道模式将应用于GSPD条目。AP标志有两个属性：AP-L，用于处理本地隧道地址；AP-R，用于处理远程隧道进程。此标志添加到GSPD的GSPD“处理信息”字段中。对RFC 4301第4.4.1.2节中复制的以下文本进行了修订，以包括此附加处理。（注：为简洁起见，仅复制了与隧道处理相关的“处理信息”文本。）
o Processing info -- which action is required -- PROTECT, BYPASS, or DISCARD. There is just one action that goes with all the selector sets, not a separate action for each set. If the required processing is PROTECT, the entry contains the following information. - IPsec mode -- tunnel or transport - (if tunnel mode) local tunnel address -- For a non-mobile host, if there is just one interface, this is straightforward; if there are multiple interfaces, this must be statically configured. For a mobile host, the specification of the local address is handled externally to IPsec. If tunnel mode with address preservation is specified for the local tunnel address, the AP-L attribute is set to TRUE for the local tunnel address and the local tunnel address is unspecified. The presence of the AP-L attribute indicates that the inner IP header source address will be copied to the outer IP header source address during IP header construction for tunnel mode. - (if tunnel mode) remote tunnel address -- There is no standard way to determine this. See Section 4.5.3 of RFC 4301, "Locating a Security Gateway". If tunnel mode with address preservation is specified for the remote tunnel address, the AP-R attribute is set to TRUE for the remote tunnel address and the remote tunnel address is unspecified. The presence of the AP-R attribute indicates that the inner IP header destination address will be copied to the outer IP header destination address during IP header construction for tunnel mode.
o 处理信息—需要执行哪些操作—保护、绕过或放弃。所有选择器集只有一个操作，而不是每个选择器集都有一个单独的操作。如果所需处理为PROTECT，则条目包含以下信息。-IPsec模式——隧道或传输-（如果是隧道模式）本地隧道地址——对于非移动主机，如果只有一个接口，这很简单；如果有多个接口，则必须对其进行静态配置。对于移动主机，本地地址的指定在IPsec外部处理。如果为本地隧道地址指定了具有地址保留的隧道模式，则本地隧道地址的AP-L属性将设置为TRUE，并且未指定本地隧道地址。AP-L属性的存在表示内部IP报头源地址将在隧道模式的IP报头构造期间复制到外部IP报头源地址。-（如果是隧道模式）远程隧道地址——没有标准的方法来确定。参见RFC 4301第4.5.3节“定位安全网关”。如果为远程隧道地址指定了具有地址保留的隧道模式，则远程隧道地址的AP-R属性将设置为TRUE，并且未指定远程隧道地址。AP-R属性的存在表示内部IP报头目标地址将在隧道模式的IP报头构造期间复制到外部IP报头目标地址。
This document describes unique directionality processing for GSPD entries with a remote IP multicast address. Since an IP multicast address must not be sent as the source address of an IP packet
本文档描述了具有远程IP多播地址的GSPD条目的唯一方向性处理。因为IP多播地址不能作为IP数据包的源地址发送
[RFC1112], directionality of Local and Remote addresses and ports is maintained during incoming SPD-S and SPD-I checks rather than being swapped. Section 4.4.1 of RFC 4301 is amended as follows:
[RFC1112]，本地和远程地址和端口的方向性在输入SPD-S和SPD-I检查期间保持，而不是交换。RFC 4301第4.4.1节修订如下：
Representing Directionality in an SPD Entry
表示SPD条目中的方向性
For traffic protected by IPsec, the Local and Remote address and ports in an SPD entry are swapped to represent directionality, consistent with IKE conventions. In general, the protocols that IPsec deals with have the property of requiring symmetric SAs with flipped Local/Remote IP addresses. However, SPD entries with a remote IP multicast address do not have their Local and Remote addresses and ports in an SPD entry swapped during incoming SPD-S and SPD-I checks.
对于受IPsec保护的流量，SPD条目中的本地和远程地址和端口将交换以表示方向性，这与IKE约定一致。通常，IPsec所处理的协议具有要求具有翻转本地/远程IP地址的对称SA的特性。但是，具有远程IP多播地址的SPD条目在传入SPD-S和SPD-I检查期间，其本地和远程地址以及SPD条目中的端口没有交换。
A new Group Security Policy Database (GSPD) attribute is introduced: GSPD entry directionality. The following text is added to the bullet list of SPD fields described in Section 4.4.1.2 of RFC 4301.
引入了一个新的组安全策略数据库（GSPD）属性：GSPD条目方向性。以下文本添加到RFC 4301第4.4.1.2节所述SPD字段的项目符号列表中。
o Directionality -- can be one of three types: "symmetric", "sender only", or "receiver only". "Symmetric" indicates that a pair of SAs are to be created (one in each direction, as specified by RFC 4301). GSPD entries marked as "sender only" indicate that one SA is to be created in the outbound direction. GSPD entries marked as "receiver only" indicate that one SA is to be created in the inbound direction. GSPD entries marked as "sender only" or "receiver only" SHOULD support multicast IP addresses in their destination address selectors. If the processing requested is BYPASS or DISCARD and a "sender only" type is configured, the entry MUST be put in GSPD-O only. Reciprocally, if the type is "receiver only", the entry MUST go to GSPD-I only.
o 方向性——可以是三种类型之一：“对称”、“仅发送方”或“仅接收方”。“对称”表示要创建一对SA（按照RFC 4301的规定，每个方向一个）。标记为“仅发件人”的GSPD条目表示将在出站方向创建一个SA。标记为“仅接收器”的GSPD条目表示将在入站方向创建一个SA。标记为“仅发件人”或“仅收件人”的GSPD条目应在其目标地址选择器中支持多播IP地址。如果请求的处理是旁路或丢弃，并且配置了“仅发送方”类型，则条目必须仅放在GSPD-O中。反过来，如果类型为“receiver only”，则条目必须仅转到GSPD-I。
GSPD entries created by a GCKS may be assigned identical Security Parameter Indexes (SPIs) to SAD entries created by IKEv2 [RFC4306]. This is not a problem for the inbound traffic as the appropriate SAs can be matched using the algorithm described in Section 4.1 of RFC 4301. However, the outbound traffic needs to be matched against the GSPD selectors so that the appropriate SA can be created.
GCKS创建的GSPD条目可分配给IKEv2创建的SAD条目相同的安全参数索引（SPI）[RFC4306]。这对于入站流量不是问题，因为可以使用RFC 4301第4.1节中描述的算法匹配适当的SA。但是，出站流量需要与GSPD选择器匹配，以便创建适当的SA。
To facilitate dynamic group keying, the outbound GSPD MUST implement a policy action capability that triggers a GKM protocol registration exchange (as per Section 5.1 of [RFC4301]). For example, the Group Sender GSPD policy might trigger on a match with a specified multicast application packet that is entering the implementation via the protected interface or that is emitted by the implementation on the protected side of the boundary and directed toward the
为了促进动态组密钥，出站GSPD必须实现触发GKM协议注册交换的策略操作功能（根据[RFC4301]第5.1节）。例如，组发送方GSPD策略可能会在与指定的多播应用程序包匹配时触发，该多播应用程序包通过受保护接口进入实现，或由边界受保护侧的实现发出并指向目标
unprotected interface. The ensuing Group Sender registration exchange would set up the Group Sender's outbound SAD entry that encrypts the multicast application's data stream. In the inverse direction, group policy may also set up an inbound IPsec SA.
未受保护的接口。随后的组发送方注册交换将设置组发送方的出站SAD条目，该条目将加密多播应用程序的数据流。相反，组策略也可以设置入站IPsec SA。
At the Group Receiver endpoint(s), the IPsec subsystem MAY use GSPD policy mechanisms that initiate a GKM protocol registration exchange. One such policy mechanism might be on the detection of a device in the protected network joining a multicast group matching GSPD policy (e.g., by receiving a IGMP/MLD (Multicast Listener Discovery) join group message on a protected interface). The ensuing Group Receiver registration exchange would set up the Group Receiver's inbound SAD entry that decrypts the multicast application's data stream. In the inverse direction, the group policy may also set up an outbound IPsec SA (e.g., when supporting an ASM service model).
在组接收方端点，IPsec子系统可以使用GSPD策略机制来启动GKM协议注册交换。一种这样的策略机制可以是检测受保护网络中的设备加入与GSPD策略匹配的多播组（例如，通过在受保护接口上接收IGMP/MLD（多播侦听器发现）加入组消息）。随后的组接收方注册交换将设置组接收方的入站SAD条目，该条目将解密多播应用程序的数据流。相反，组策略还可以设置出站IPsec SA（例如，当支持ASM服务模型时）。
Note: A security gateway triggering on the receipt of unauthenticated messages arriving on a protected interface may result in early Group Receiver registration if the message is not the result of a device on the protected network actually wishing to join a multicast group. The unauthenticated messages will only cause the Group Receiver to register once; subsequent messages will have no effect on the Group Receiver.
注意：安全网关在收到到达受保护接口的未经验证的消息时触发，如果该消息不是受保护网络上实际希望加入多播组的设备的结果，则可能会导致组接收方提前注册。未经验证的消息只会导致组接收方注册一次；后续消息对组接收方没有影响。
The IPsec subsystem MAY provide GSPD policy mechanisms that automatically initiate a GKM protocol de-registration exchange. De-registration allows a GCKS to minimize exposure of the group's secret key by re-keying a group on a group membership change event. It also minimizes cost on a GCKS for those groups that maintain member state. One such policy mechanism could be the detection of IGMP/MLD leave group exchange. However, a security gateway Group Member would not initiate a GKM protocol de-registration exchange until it detects that there are no more receivers behind a protected interface.
IPsec子系统可以提供GSPD策略机制，自动启动GKM协议注销交换。取消注册允许GCKS通过在组成员身份更改事件中为组重新设置密钥来最小化组密钥的公开。它还将维护成员国的团体的GCKS成本降至最低。其中一种策略机制可能是检测IGMP/MLD休假组交换。但是，安全网关组成员在检测到受保护接口后面没有更多接收器之前，不会启动GKM协议注销交换。
Additionally, the GKM subsystem MAY set up the GSPD/SAD state information independent of the multicast application's state. In this scenario, the Group Owner issues management directives that tell the GKM subsystem when it should start GKM registration and de-registration protocol exchanges. Typically, the registration policy strives to make sure that the group's IPsec subsystem state is "always ready" in anticipation of the multicast application starting its execution.
此外，GKM子系统可以独立于多播应用程序的状态来设置GSPD/SAD状态信息。在此场景中，组所有者发出管理指令，告知GKM子系统何时应启动GKM注册和注销协议交换。通常，注册策略努力确保组的IPsec子系统状态在多播应用程序开始执行之前“始终准备就绪”。
The SAD contains an item describing whether tunnel or transport mode is applied to traffic on this SA. The text in RFC 4301 Section 4.4.2.1 is amended to describe address preservation.
SAD包含一个项目，描述是否将隧道模式或传输模式应用于此SA上的流量。对RFC 4301第4.4.2.1节中的文本进行了修订，以说明地址保存。
o IPsec protocol mode: tunnel or transport. Indicates which mode of AH or ESP is applied to traffic on this SA. When tunnel mode is specified, the data item also indicates whether or not address preservation is applied to the outer IP header. Address preservation MUST NOT be specified when the IP version of the encapsulating header and IP version of the inner header do not match. The local address, remote address, or both addresses MAY be marked as being preserved during tunnel encapsulation.
o IPsec协议模式：隧道或传输。指示将哪种AH或ESP模式应用于此SA上的流量。指定隧道模式时，数据项还指示是否将地址保留应用于外部IP头。当封装标头的IP版本与内部标头的IP版本不匹配时，不得指定地址保留。本地地址、远程地址或这两个地址可以标记为在隧道封装期间被保留。
The multicast IPsec extensions introduce a new data structure called the Group Peer Authorization Database (GPAD). The GPAD is analogous to the PAD defined in RFC 4301. It provides a link between the GSPD and a Group Key Management (GKM) Subsystem. The GPAD embodies the following critical functions:
多播IPsec扩展引入了一种称为组对等授权数据库（GPAD）的新数据结构。GPAD类似于RFC 4301中定义的PAD。它在GSPD和组密钥管理（GKM）子系统之间提供链接。GPAD包含以下关键功能：
o identifies a GCKS (or group of GCKS devices) that is authorized to communicate with this IPsec entity
o 标识授权与此IPsec实体通信的GCKS（或GCKS设备组）
o specifies the protocol and method used to authenticate each GCKS
o 指定用于验证每个GCK的协议和方法
o provides the authentication data for each GKCS
o 提供每个GKCS的身份验证数据
o constrains the traffic selectors that can be asserted by a GCKS with regard to SA creation
o 限制GCKS在SA创建方面可以断言的流量选择器
o constrains the types and values of Group Identifiers for which a GCKS is authorized to provide group policy
o 限制授权GCKS提供组策略的组标识符的类型和值
The GPAD provides these functions for a Group Key Management subsystem. The GPAD is not consulted by IKE or other authentication protocols that do not act as GKM protocols.
GPAD为组密钥管理子系统提供这些功能。IKE或其他不作为GKM协议的身份验证协议不咨询GPAD。
To provide these functions, the GPAD contains an entry for each GCKS that the IPsec entity is configured to contact. An entry contains one or more GCKS Identifiers, the authentication protocol (e.g., Group Domain of Interpretation (GDOI) or Group Secure Association Key Management Protocol (GSAKMP)), the authentication method used (e.g., certificates or pre-shared secrets), and the authentication data
为了提供这些功能，GPAD包含IPsec实体配置为联系的每个GCK的条目。条目包含一个或多个GCKS标识符、身份验证协议（例如，组解释域（GDOI）或组安全关联密钥管理协议（GSAKMP））、使用的身份验证方法（例如，证书或预共享机密）和身份验证数据
(e.g., the pre-shared secret or trust anchor relative to which the peer's certificate will be validated). For certificate-based authentication, the entry also may provide information to assist in verifying the revocation status of the peer, e.g., a pointer to a Certificate Revocation List (CRL) repository or the name of an Online Certificate Status Protocol (OCSP) server associated with either the peer or the trust anchor associated with the peer. The entry also contains constraints a Group Member applies to the policy received from the GKCS.
（例如，将验证对等方证书的预共享秘密或信任锚）。对于基于证书的认证，条目还可以提供有助于验证对等方的撤销状态的信息，例如，指向证书撤销列表（CRL）存储库的指针或与对等方或与对等方关联的信任锚关联的在线证书状态协议（OCSP）服务器的名称。该条目还包含一个组成员应用于从GKCS收到的策略的约束。
GCKS Identifiers are used to identify one or more devices that are authorized to act as a GCKS for this group. GCKS Identifiers are specified as PAD entry IDs in Section 4.4.3.1 of RFC 4301 and follow the matching rules described therein.
GCKS标识符用于标识一个或多个被授权作为该组GCKS的设备。GCKS标识符在RFC 4301第4.4.3.1节中指定为PAD条目ID，并遵循其中描述的匹配规则。
Once a GPAD entry is located, it is necessary to verify the asserted identity, i.e., to authenticate the asserted GCKS Identifier. PAD authentication data types and semantics specified in Section 4.4.3.2 of RFC 4301 are used to authenticate a GCKS.
一旦找到GPAD条目，就必须验证断言的标识，即验证断言的GCKS标识符。RFC 4301第4.4.3.2节中规定的PAD认证数据类型和语义用于对GCKS进行认证。
See GDOI [RFC3547] and GSAKMP [RFC4535] for details of how a GKM protocol performs peer authentication using certificates and pre-shared secrets.
有关GKM协议如何使用证书和预共享机密执行对等身份验证的详细信息，请参见GDOI[RFC3547]和GSAKMP[RFC4535]。
A Group Identifier is used by a GKM protocol to identify a particular group to a GCKS. A GPAD entry includes a Group Identifier to indicate that the GKCS Identifiers in the GPAD entry are authorized to act as a GCKS for the group.
GKM协议使用组标识符向GCKS标识特定组。GPAD条目包括组标识符，以指示GPAD条目中的GKCS标识符被授权作为该组的GCK。
The Group Identifier is an opaque byte string of IKE ID type Key ID that identifies a secure multicast group. The Group Identifier byte string MUST be at least four bytes long and less than 256 bytes long.
组标识符是标识安全多播组的IKE ID类型Key ID的不透明字节字符串。组标识符字节字符串的长度必须至少为4个字节，且小于256个字节。
IKE ID types other than Key ID MAY be supported.
可能支持密钥ID以外的IKE ID类型。
Once a GCKS is authenticated, the GCKS delivers IPsec SA policy to the Group Member. Before the Group Member accepts the IPsec SA Policy, the source and destination traffic selectors of the SA are compared to a set of authorized data flows. Each data flow includes a set of authorized source traffic selectors and a set of authorized
对GCKS进行身份验证后，GCKS将IPsec SA策略传递给组成员。在组成员接受IPsec SA策略之前，将SA的源和目标流量选择器与一组授权数据流进行比较。每个数据流包括一组授权源流量选择器和一组授权源流量选择器
destination traffic selectors. Traffic selectors are represented as a set of IPv4 and/or IPv6 address ranges. (A peer may be authorized for both address types, so there MUST be provision for both v4 and v6 address ranges.)
目的地流量选择器。流量选择器表示为一组IPv4和/或IPv6地址范围。（对等方可能被授权使用这两种地址类型，因此必须同时提供v4和v6地址范围。）
When a GKM protocol registration exchange is triggered, the Group Member and GCKS each assert their identity as a part of the exchange. Each GKM protocol registration exchange MUST use the asserted ID to locate an identity in the GPAD. The GPAD entry specifies the authentication method to be employed for the identified GCKS. The entry also specifies the authentication data that will be used to verify the asserted identity. This data is employed in conjunction with the specified method to authenticate the GCKS before accepting any group policy from the GCKS.
触发GKM协议注册交换时，组成员和GCK各自声明其身份作为交换的一部分。每个GKM协议注册交换必须使用断言的ID在GPAD中定位标识。GPAD条目指定要用于已识别GCK的身份验证方法。该条目还指定将用于验证断言标识的身份验证数据。在接受来自GCK的任何组策略之前，此数据与指定方法一起用于对GCK进行身份验证。
During the GKM protocol registration, a Group Member includes a Group Identifier. Before presenting that Group Identifier to the GCKS, a Group Member verifies that the GPAD entry for authenticated GCKS GPAD entry includes the Group Identifier. This ensures that the GCKS is authorized to provide policy for the Group.
在GKM协议注册期间，组成员包括组标识符。在将该组标识符呈现给GCKS之前，组成员验证已验证的GCKS GPAD条目的GPAD条目是否包含该组标识符。这确保GCK有权为集团提供政策。
When IPsec SA policy is received, each data flow is compared to the data flows in the GPAD entry. The Group Member accepts policy matching a data flow. Policy not matching a data flow is discarded, and the reason SHOULD be recorded in the audit log.
当接收到IPsec SA策略时，会将每个数据流与GPAD条目中的数据流进行比较。组成员接受与数据流匹配的策略。与数据流不匹配的策略将被丢弃，原因应记录在审核日志中。
A GKM protocol may distribute IPsec SA policy to IPsec devices that have previously registered with it. The method of distribution is part of the GKM protocol and is outside the scope of this memo. When the IPsec device receives this new policy, it compares the policy to the data flows in the GPAD entry as described above.
GKM协议可以将IPsec SA策略分发给先前已向其注册的IPsec设备。分发方法是GKM协议的一部分，不在本备忘录的范围内。当IPsec设备收到此新策略时，它会将该策略与GPAD条目中的数据流进行比较，如上所述。
An IPsec implementation supporting these extensions will support a number of Security Associations: one or more IPsec SAs plus one or more GKM SAs used to download the parameters that are used to create IPsec SAs. These SAs are collectively referred to as a Group Security Association (GSA) [RFC3740].
支持这些扩展的IPsec实现将支持许多安全关联：一个或多个IPsec SA加上一个或多个用于下载用于创建IPsec SA的参数的GKM SA。这些SA统称为集团安全协会（GSA）[RFC3740]。
During a secure multicast group's lifetime, multiple IPsec Group Security Associations can exist concurrently. This occurs principally due to two reasons:
在安全多播组的生存期内，可以同时存在多个IPsec组安全关联。出现这种情况主要有两个原因：
- There are multiple Group Senders authorized in the group, each with its own IPsec SA, which maintains anti-replay state. A group that does not rely on IP security anti-replay services can share one IPsec SA for all of its Group Senders.
- 组中有多个已授权的组发送方，每个都有自己的IPsec SA，该SA保持防重播状态。不依赖IP安全反重播服务的组可以为其所有组发送方共享一个IPsec SA。
- The life spans of a Group Sender's two (or more) IPsec SAs are allowed to overlap in time so that there is continuity in the multicast data stream across group re-key events. This capability is referred to as "re-key rollover continuity".
- 允许组发送方的两个（或更多）IPsec SA的生命周期在时间上重叠，以便跨组密钥重设事件的多播数据流具有连续性。这种能力被称为“重新设置翻滚连续性”。
The re-key continuity rollover algorithm depends on an IPsec SA management interface between the GKM subsystem and the IPsec subsystem. The IPsec subsystem MUST provide management interface mechanisms for the GKM subsystem to add IPsec SAs and to delete IPsec SAs. For illustrative purposes, this text defines the re-key rollover continuity algorithm in terms of two timer parameters that govern IPsec SA life spans relative to the start of a group re-key event. However, it should be emphasized that the GKM subsystem interprets the group's security policy to direct the correct timing of IPsec SA activation and deactivation. A given group policy may choose timer values that differ from those recommended by this text. The two re-key rollover continuity timer parameters are:
密钥连续性翻转算法取决于GKM子系统和IPsec子系统之间的IPsec SA管理接口。IPsec子系统必须为GKM子系统提供管理接口机制，以添加IPsec SAs和删除IPsec SAs。出于说明目的，本文根据两个定时器参数定义了密钥翻转连续性算法，这两个定时器参数控制IPsec SA相对于组密钥翻转事件开始的寿命。但是，应该强调的是，GKM子系统解释组的安全策略，以指导IPsec SA激活和停用的正确时间。给定的组策略可能会选择不同于本文推荐值的计时器值。两个关键点翻转连续性计时器参数为：
1. Activation Time Delay (ATD) - The ATD defines how long after the start of a re-key event to activate new IPsec SAs. The ATD parameter is expressed in units of seconds. Typically, the ATD parameter is set to the maximum time it takes to deliver a multicast message from the GCKS to all of the group's members. For a GCKS that relies on a Reliable Multicast Transport Protocol (RMTP), the ATD parameter could be set equal to the RTMP's maximum error recovery time. When an RMTP is not present, the ATD parameter might be set equal to the network's maximum multicast message delivery latency across all of the group's endpoints. The ATD is a GKM group policy parameter. This value SHOULD be configurable at the Group Owner management interface on a per group basis.
1. 激活时间延迟（ATD）-ATD定义重新设置密钥事件开始后多长时间激活新的IPsec SAs。ATD参数以秒为单位表示。通常，ATD参数设置为从GCK向组的所有成员发送多播消息所需的最长时间。对于依赖可靠多播传输协议（RMTP）的GCKS，可以将ATD参数设置为RTMP的最大错误恢复时间。当RMTP不存在时，ATD参数可以设置为网络在组的所有端点上的最大多播消息传递延迟。ATD是GKM组策略参数。该值应可在集团所有者管理界面上根据每个集团进行配置。
2. Deactivation Time Delay (DTD) - The DTD defines how long after the start of a re-key event to deactivate those IPsec SAs that are destroyed by the re-key event. The purpose of the DTD parameter is to minimize the residual exposure of a group's keying material after a re-key event has retired that keying material. The DTD is independent of, and should not to be confused with, the IPsec SA soft lifetime attribute. The DTD parameter is expressed in units of seconds. Typically, the DTD parameter would be set to the ADT plus the maximum time it takes to deliver a multicast message from the Group Sender to all of the group's members. For a Group Sender that relies on an RMTP, the DTD parameter could be set
2. 停用时间延迟（DTD）-DTD定义在重新设置密钥事件开始后多长时间内停用那些被重新设置密钥事件破坏的IPsec SA。DTD参数的目的是在重新设置密钥事件使密钥材料失效后，将组密钥材料的剩余暴露降至最低。DTD独立于IPsec SA soft lifetime属性，不应与之混淆。DTD参数以秒为单位表示。通常，DTD参数将设置为ADT加上从组发送方向组的所有成员传递多播消息所需的最长时间。对于依赖RMTP的组发送方，可以设置DTD参数
equal to ADT plus the RMTP's maximum error recovery time. When an RMTP is not present, the DTD parameter might be set equal to ADT plus the network's maximum multicast message delivery latency across all of the group's endpoints. A GKM subsystem MAY implement the DTD as a group security policy parameter. If a GKM subsystem does not implement the DTD parameter, then other group security policy mechanisms MUST determine when to deactivate an IPsec SA.
等于ADT加上RMTP的最大错误恢复时间。当RMTP不存在时，DTD参数可以设置为ADT加上网络在组的所有端点上的最大多播消息传递延迟。GKM子系统可以实现DTD作为组安全策略参数。如果GKM子系统未实现DTD参数，则其他组安全策略机制必须确定何时停用IPsec SA。
Each group re-key multicast message sent by a GCKS signals the start of a new Group Sender IPsec SA time epoch, with each such epoch having an associated set of two IPsec SAs. Note that this document refers to re-key mechanisms as being multicast because of the inherent scalability of IP multicast distribution. However, there is no particular reason that re-keying mechanisms must be multicast. For example, [ZLLY03] describes a method of re-key employing both unicast and multicast messages.
GCKS发送的每个组密钥重传多播消息表示新的组发送方IPsec SA时间历元的开始，每个历元具有两个IPsec SA的关联集。注意，由于IP多播分发的固有可伸缩性，本文档将重密钥机制称为多播。然而，并没有特别的理由认为重密钥机制必须是多播的。例如，[ZLLY03]描述了一种同时使用单播和多播消息的重新设置密钥的方法。
The group membership interacts with these IPsec SAs as follows:
组成员身份与这些IPsec SA交互如下：
- As a precursor to the Group Sender beginning its re-key rollover continuity processing, the GCKS periodically multicasts a Re-Key Event (RKE) message to the group. The RKE multicast MAY contain group policy directives, new IPsec SA policy, and group keying material. In the absence of an RMTP, the GCKS may re-transmit the RKE a policy-defined number of times to improve the availability of re-key information. The GKM subsystem starts the ATD and DTD timers after it receives the last RKE re-transmission.
- 作为组发送方开始其密钥更新连续性处理的前兆，GCKS定期向组多播密钥更新事件（RKE）消息。RKE多播可能包含组策略指令、新IPsec SA策略和组密钥材料。在没有RMTP的情况下，GCK可以将RKE重新发送策略定义的次数，以提高重新密钥信息的可用性。GKM子系统在接收到最后一次RKE重新传输后启动ATD和DTD定时器。
- The GKM subsystem interprets the RKE multicast to configure the group's GSPD/SAD with the new IPsec SAs. Each IPsec SA that replaces an existing SA is called a "leading edge" IPsec SA. The leading edge IPsec SA has a new Security Parameter Index (SPI) and its associated keying material, which keys it. For a time period of ATD seconds after the GCKS multicasts the RKE, a Group Sender does not yet transmit data using the leading edge IPsec SA. Meanwhile, other Group Members prepare to use this IPsec SA by installing the leading edge IPsec SAs to their respective GSPD/SAD.
- GKM子系统解释RKE多播以使用新的IPsec SAs配置组的GSPD/SAD。替换现有SA的每个IPsec SA称为“前沿”IPsec SA。领先的IPsec SA有一个新的安全参数索引（SPI）及其相关的键控材料，对其进行键控。在GCKS多播RKE后ATD秒的时间段内，组发送方尚未使用前沿IPsec SA传输数据。同时，其他组成员通过将前沿IPsec SA安装到各自的GSPD/SAD，准备使用此IPsec SA。
- After waiting for the ATD period, such that all of the Group Members have received and processed the RKE message, the GKM subsystem directs the Group Sender to begin to transmit using the leading edge IPsec SA with its data encrypted by the new keying material. Only authorized Group Members can decrypt these IPsec SA multicast transmissions.
- 在等待ATD时段之后，使得所有组成员都已接收并处理RKE消息，GKM子系统指示组发送方开始使用前沿IPsec SA进行传输，其数据由新的密钥材料加密。只有授权的组成员才能解密这些IPsec SA多播传输。
- The Group Sender's "trailing edge" SA is the oldest Security Association in use by the group for that sender. All authorized Group Members can receive and decrypt data for this SA, but the Group Sender does not transmit new data using the trailing edge IPsec SA after it has transitioned to the leading edge IPsec SA. The trailing edge IPsec SA is deleted by the group's GKM subsystems after the DTD time period has elapsed since the RKE transmission.
- 组发送方的“后缘”SA是组为该发送方使用的最早的安全关联。所有授权的组成员都可以接收和解密此SA的数据，但组发送方在后缘IPsec SA转换为前缘IPsec SA后不会使用后缘IPsec SA传输新数据。自RKE传输后DTD时间段结束后，集团的GKM子系统删除后缘IPsec SA。
This re-key rollover strategy allows the group to drain its in-transit datagrams from the network while transitioning to the leading edge IPsec SA. Staggering the roles of each respective IPsec SA as described above improves the group's synchronization even when there are high network propagation delays. Note that due to group membership joins and leaves, each Group Sender IPsec SA time epoch may have a different group membership set.
此密钥重传策略允许组在转换到前沿IPsec SA时从网络中排出其传输中的数据报。如上所述，错开每个各自IPsec SA的角色可以提高组的同步，即使在网络传播延迟很高的情况下也是如此。请注意，由于组成员资格的加入和离开，每个组发送方IPsec SA时间历元可能具有不同的组成员资格集。
It is a group policy decision whether the re-key event transition between epochs provides forward and backward secrecy. The group's re-key protocol keying material and algorithm (e.g., Logical Key Hierarchy; refer to [RFC2627] and Appendix A of [RFC4535]) enforces this policy. Implementations MAY offer a Group Owner management interface option to enable/disable re-key rollover continuity for a particular group. This specification requires that a GKM/IPsec implementation MUST support at least two concurrent IPsec SAs per Group Sender as well as this re-key rollover continuity algorithm.
是否在历代之间重新设置密钥的事件转换提供前向和后向保密性是一个组策略决定。集团的重设密钥协议密钥材料和算法（例如，逻辑密钥层次结构；参考[RFC2627]和[RFC4535]的附录A）强制执行该政策。实施可能提供组所有者管理界面选项，以启用/禁用特定组的密钥翻转连续性。此规范要求GKM/IPsec实现必须支持每个组发送方至少两个并发IPsec SA以及此密钥翻转连续性算法。
As defined in [RFC4301], data origin authentication is a security service that verifies the identity of the claimed source of data. A Message Authentication Code (MAC) is often used to achieve data origin authentication for connections shared between two parties. However, typical MAC authentication methods using a single shared secret are not sufficient to provide data origin authentication for groups with more than two parties. With a MAC algorithm, every Group Member can use the MAC key to create a valid MAC tag, whether or not they are the authentic originator of the group application's data.
如[RFC4301]中所定义，数据源身份验证是一种安全服务，用于验证声明的数据源的身份。消息身份验证码（MAC）通常用于实现双方共享连接的数据源身份验证。但是，使用单个共享密钥的典型MAC身份验证方法不足以为具有两个以上参与方的组提供数据源身份验证。使用MAC算法，每个组成员都可以使用MAC密钥创建有效的MAC标记，无论他们是否是组应用程序数据的真实发起人。
When the property of data origin authentication is required for an IPsec SA shared by more than two parties, an authentication transform where the receiver is assured that the sender generated that message should be used. Two possible algorithms are Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] or RSA digital signature [RFC4359].
当两方以上共享的IPsec SA需要数据源身份验证的属性时，一种身份验证转换，在这种转换中，接收方确信应该使用发送方生成的消息。两种可能的算法是定时高效流丢失容忍认证（TESLA）[RFC4082]或RSA数字签名[RFC4359]。
In some cases (e.g., digital signature authentication transforms), the processing cost of the algorithm is significantly greater than a Hashed Message Authentication Code (HMAC) authentication method. To
在某些情况下（例如，数字签名认证转换），该算法的处理成本明显高于哈希消息认证码（HMAC）认证方法。到
protect against denial-of-service attacks from a device that is not authorized to join the group, the IPsec SA using this algorithm may be encapsulated with an IPsec SA using a MAC authentication algorithm. However, doing so requires the packet to be sent across the IPsec boundary a second time for additional outbound processing on the Group Sender (see Section 5.1 of [RFC4301]) and a second time for inbound processing on Group Receivers (see Section 5.2 of [RFC4301]). This use of AH or ESP encapsulated within AH or ESP accommodates the constraint that AH and ESP define an Integrity Check Value (ICV) for only a single authenticator transform.
为了防止来自未被授权加入组的设备的拒绝服务攻击，使用此算法的IPsec SA可以使用使用MAC身份验证算法的IPsec SA进行封装。但是，这样做需要第二次跨IPsec边界发送数据包，以便在组发送方上进行额外的出站处理（参见[RFC4301]第5.1节），在组接收方上进行第二次入站处理（参见[RFC4301]第5.2节）。这种封装在AH或ESP中的AH或ESP的使用适应了这样的约束，即AH和ESP仅为单个验证器转换定义完整性检查值（ICV）。
Often, the GKM subsystem will be introduced to an existent IPsec subsystem as a companion key management protocol to IKEv2 [RFC4306]. A fundamental GKM protocol IP security subsystem requirement is that both the GKM protocol and IKEv2 can simultaneously share access to a common Group Security Policy Database and Security Association Database. The mechanisms that provide mutually exclusive access to the common GSPD/SAD data structures are a local matter. This includes the GSPD-O cache and the GSPD-I cache. However, implementers should note that IKEv2 SPI allocation is entirely independent from GKM SPI allocation because Group Security Associations are qualified by a destination multicast IP address and may optionally have a source IP address qualifier. See Section 2.1 of [RFC4303] for further explanation.
通常，GKM子系统将作为IKEv2[RFC4306]的配套密钥管理协议引入现有的IPsec子系统。GKM协议IP安全子系统的一个基本要求是，GKM协议和IKEv2可以同时共享对公共组安全策略数据库和安全关联数据库的访问。提供对通用GSPD/SAD数据结构互斥访问的机制是一个局部问题。这包括GSPD-O缓存和GSPD-I缓存。然而，实现者应该注意，IKEv2 SPI分配完全独立于GKM SPI分配，因为组安全关联由目标多播IP地址限定，并且可以选择具有源IP地址限定符。更多说明请参见[RFC4303]第2.1节。
The Peer Authorization Database does require explicit coordination between the GKM protocol and IKEv2. Section 4.1.3 describes these interactions.
对等授权数据库确实需要GKM协议和IKEv2之间的明确协调。第4.1.3节描述了这些相互作用。
Processing of traffic follows Section 5 of [RFC4301], with the additions described below when these IP multicast extensions are supported.
流量处理遵循[RFC4301]的第5节，当支持这些IP多播扩展时，将添加以下内容。
If an IPsec SA is marked as supporting tunnel mode with address preservation (as described in Section 3.1), either or both of the outer header source or destination addresses are marked as being preserved.
如果IPsec SA被标记为具有地址保留的支持隧道模式（如第3.1节所述），则外部报头源地址或目标地址中的一个或两个都被标记为保留。
Header construction for tunnel mode is described in Section 5.1.2 of RFC 4301. The first bullet of that section is amended as follows:
RFC 4301第5.1.2节描述了隧道模式的集管结构。该节的第一个项目符号修订如下：
o If address preservation is not marked in the SAD entry for either the outer IP header Source Address or Destination Address, the outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). If address preservation is marked for the IP header Source Address, it is copied from the inner IP header Source Address. If address preservation is marked for the IP header Destination Address, it is copied from the inner IP header Destination Address. The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram (from the perspective of this tunnel), respectively. Address preservation MUST NOT be marked when the IP version of the encapsulating header and IP version of the inner header do not match.
o 如果SAD条目中未标记外部IP头源地址或目标地址的地址保留，则外部IP头源地址和目标地址标识隧道的“端点”（封装器和解封装器）。如果为IP头源地址标记了地址保留，则会从内部IP头源地址复制该地址。如果为IP标头目标地址标记了地址保留，则会从内部IP标头目标地址复制该地址。内部IP报头源地址和目标地址分别标识数据报的原始发送方和接收方（从这个隧道的角度）。当封装标头的IP版本与内部标头的IP版本不匹配时，不得标记地址保留。
Note (3), regarding construction of tunnel addresses in Section 5.1.2.1 of RFC 4301, is amended as follows. (Note: for brevity, Note (3) of RFC 4301 is not reproduced in its entirety.)
关于RFC 4301第5.1.2.1节中隧道地址施工的注释（3）修订如下。（注：为简洁起见，RFC 4301的注（3）未全部复制。）
(3) Unless marked for address preservation, Local and Remote addresses depend on the SA, which is used to determine the Remote address, which in turn determines which Local address (net interface) is used to forward the packet. If address preservation is marked for the Local address, it is copied from the inner IP header. If address preservation is marked for the Remote address, that address is copied from the inner IP header.
(3) 除非标记为地址保留，否则本地和远程地址取决于SA，SA用于确定远程地址，而远程地址又决定使用哪个本地地址（网络接口）转发数据包。如果为本地地址标记了地址保留，则会从内部IP标头复制该地址。如果为远程地址标记了地址保留，则该地址将从内部IP头复制。
IPsec-protected packets generated by an IPsec device supporting these multicast extensions may (depending on its GSPD policy) populate an outer tunnel header with a destination address such that it is not addressed to an IPsec device. This requires an IPsec device supporting these multicast extensions to accept and process IP traffic that is not addressed to the IPsec device itself. The following additions to IPsec inbound IP traffic processing are necessary.
由支持这些多播扩展的IPsec设备生成的受IPsec保护的数据包可能（取决于其GSPD策略）使用目标地址填充外部隧道头，从而使其不寻址到IPsec设备。这需要一个支持这些多播扩展的IPsec设备来接受和处理未寻址到IPsec设备本身的IP通信。需要对IPsec入站IP流量处理添加以下内容。
For compatibility with RFC 4301, the phrase "addressed to this device" is taken to mean packets with a unicast destination address belonging to the system itself, and also multicast packets that are received by the system itself. However, multicast packets not received by the IPsec device are not considered addressed to this device.
为了与RFC 4301兼容，短语“寻址到此设备”被认为是指具有属于系统本身的单播目的地地址的分组，以及由系统本身接收的多播分组。但是，IPsec设备未接收到的多播数据包不被视为发往该设备。
The discussion of processing inbound IP Traffic described in Section 5.2 of RFC 4301 is amended as follows.
RFC 4301第5.2节中描述的处理入站IP流量的讨论修改如下。
The first dash in item 2 is amended as follows:
第2项中的第一个破折号修改如下：
- If the packet appears to be IPsec protected and it is addressed to this device, or appears to be IPsec protected and is addressed to a multicast group, an attempt is made to map it to an active SA via the SAD. Note that the device may have multiple IP addresses that may be used in the SAD lookup, e.g., in the case of protocols such as SCTP.
- 如果该数据包似乎受IPsec保护，并且地址是此设备，或者似乎受IPsec保护，并且地址是多播组，则会尝试通过SAD将其映射到活动SA。注意，设备可以具有多个IP地址，这些IP地址可以在SAD查找中使用，例如，在诸如SCTP的协议的情况下。
A new item is added to the list between items 3a and 3b to describe processing of IPsec packets with destination address preservation applied:
在项目3a和3b之间的列表中添加了一个新项目，以描述应用了目标地址保留的IPsec数据包的处理：
3aa. If the packet is addressed to a multicast group and AH or ESP is specified as the protocol, the packet is looked up in the SAD. Use the SPI plus the destination or SPI plus destination and source addresses, as specified in Section 4.1. If there is no match, the packet is directed to SPD-I lookup. Note that if the IPsec device is a security gateway, and the SPD-I policy is to BYPASS the packet, a subsequent security gateway along the routed path of the multicast packet may decrypt the packet.
3aa。如果数据包被发送到多播组，并且AH或ESP被指定为协议，则在SAD中查找数据包。按照第4.1节的规定，使用SPI加上目的地或SPI加上目的地和源地址。如果不匹配，则数据包被定向到SPD-I查找。注意，如果IPsec设备是安全网关，并且SPD-I策略是绕过该分组，则沿着多播分组的路由路径的后续安全网关可以解密该分组。
Figure 3 in RFC 4301 is updated to show the new processing path defined in item 3aa.
RFC 4301中的图3已更新，以显示项目3aa中定义的新处理路径。
Unprotected Interface
|
V
+-----+ IPsec protected
------------------->|Demux|--------------------+
| +-----+ |
| | |
| Not IPsec | |
| | IPsec protected, not |
| V addressed to device, |
| +-------+ +---------+ and not in SAD |
| |DISCARD|<---|SPD-I (*)|<------------+ |
| +-------+ +---------+ | |
| | | |
| |-----+ | |
| | | | |
| | V | |
| | +------+ | |
| | | ICMP | | |
| | +------+ | |
| | | V
+---------+ | +-----------+
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
+---------+ | | (AH/ESP) | Boundary
^ | +-----------+
| | +---+ |
| BYPASS | +-->|IKE| |
| | | +---+ |
| V | V
| +----------+ +---------+ +----+
|--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
nested SAs +----------+ | (***) | +----+
| +---------+
V
Protected Interface
Unprotected Interface
|
V
+-----+ IPsec protected
------------------->|Demux|--------------------+
| +-----+ |
| | |
| Not IPsec | |
| | IPsec protected, not |
| V addressed to device, |
| +-------+ +---------+ and not in SAD |
| |DISCARD|<---|SPD-I (*)|<------------+ |
| +-------+ +---------+ | |
| | | |
| |-----+ | |
| | | | |
| | V | |
| | +------+ | |
| | | ICMP | | |
| | +------+ | |
| | | V
+---------+ | +-----------+
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
+---------+ | | (AH/ESP) | Boundary
^ | +-----------+
| | +---+ |
| BYPASS | +-->|IKE| |
| | | +---+ |
| V | V
| +----------+ +---------+ +----+
|--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
nested SAs +----------+ | (***) | +----+
| +---------+
V
Protected Interface
Figure 1. Processing Model for Inbound Traffic (amending Figure 3 of RFC 4301)
图1。入站流量处理模型（修订RFC 4301图3）
The discussion of processing inbound IP traffic in Section 5.2 of RFC 4301 is amended to insert a new item 6 as follows.
RFC 4301第5.2节中关于处理入站IP流量的讨论进行了修改，以插入新的第6项，如下所示。
6. If an IPsec SA is marked as supporting tunnel mode with address preservation (as described in Section 3.1), the marked address(es) (i.e., source and/or destination address(es)) in the outer IP header MUST be verified to be the same value(s) as in the inner IP header. If the addresses are not consistent, the IPsec system MUST discard the packet and treat the inconsistency as an auditable event.
6. 如果IPsec SA标记为具有地址保留的支持隧道模式（如第3.1节所述），则必须验证外部IP报头中标记的地址（即源地址和/或目标地址）与内部IP报头中的值相同。如果地址不一致，IPsec系统必须丢弃数据包，并将不一致视为可审核事件。
The IP security multicast extensions defined by this specification build on the unicast-oriented IP security architecture [RFC4301]. Consequently, this specification inherits many of RFC 4301's security considerations, and the reader is advised to review it as companion guidance.
本规范定义的IP安全多播扩展基于面向单播的IP安全体系结构[RFC4301]。因此，本规范继承了RFC 4301的许多安全注意事项，建议读者将其作为配套指南进行审查。
The IP security multicast extension service provides the following network layer mechanisms for secure group communications:
IP安全多播扩展服务为安全组通信提供以下网络层机制：
- Confidentiality using a group shared encryption key.
- 使用组共享加密密钥的机密性。
- Group source authentication and integrity protection using a group shared authentication key.
- 使用组共享身份验证密钥进行组源身份验证和完整性保护。
- Group Sender data origin authentication using a digital signature, TESLA, or other mechanism.
- 使用数字签名、特斯拉或其他机制进行组发送方数据源身份验证。
- Anti-replay protection for a limited number of Group Senders using the ESP (or AH) sequence number facility.
- 使用ESP（或AH）序列号功能为有限数量的组发送方提供防重播保护。
- Filtering of multicast transmissions identified with a source address of systems that are not authorized by group policy to be Group Senders. This feature leverages the IPsec stateless firewall service (i.e., SPD-I and/or SDP-O entries with a packet disposition specified as DISCARD).
- 过滤由组策略未授权为组发送方的系统的源地址标识的多播传输。此功能利用IPsec无状态防火墙服务（即，将数据包处理指定为丢弃的SPD-i和/或SDP-O条目）。
In support of the above services, this specification enhances the definition of the SPD, PAD, and SAD databases to facilitate the automated group key management of large-scale cryptographic groups.
为了支持上述服务，本规范增强了SPD、PAD和SAD数据库的定义，以促进大规模加密组的自动组密钥管理。
As noted in Section 2.2. of RFC 4301, it is out of the scope of this architecture to defend the group's keys or its application data against attacks targeting vulnerabilities of the operating environment in which the IPsec implementation executes. However, it should be noted that the risk of attacks originating by an adversary in the network is magnified to the extent that the group keys are shared across a large number of systems.
如第2.2节所述。在RFC 4301中，保护组密钥或其应用程序数据不受针对IPsec实施所在操作环境漏洞的攻击超出了此体系结构的范围。然而，应该注意的是，网络中的对手发起攻击的风险被放大，以至于组密钥在大量系统中共享。
The security issues that are left unsolved by the IPsec multicast extension service divide into two broad categories: outsider attacks and insider attacks.
IPsec多播扩展服务未解决的安全问题分为两大类：外部攻击和内部攻击。
The IPsec multicast extension service does not defend against an adversary outside of the group who has:
IPsec多播扩展服务不会防御组外具有以下特征的对手：
- the capability to launch a multicast, flooding denial-of-service attack against the group, originating from a system whose IPsec subsystem does not filter the unauthorized multicast transmissions.
- 对组发起多播、泛洪拒绝服务攻击的能力，该攻击源自其IPsec子系统未过滤未经授权的多播传输的系统。
- compromised a multicast router, allowing the adversary to corrupt or delete all multicast packets destined for the group endpoints downstream from that router.
- 危害多播路由器，允许对手破坏或删除所有发送到该路由器下游的组端点的多播数据包。
- captured a copy of an earlier multicast packet transmission and then replayed it to a group that does not have the anti-replay service enabled. Note that for a large-scale, any-source multicast group, it is impractical for the Group Receivers to maintain an anti-replay state for every potential Group Sender. Group policies that require anti-replay protection for a large-scale, any-source multicast group should consider an application layer multicast protocol that can detect and reject replays.
- 捕获早期多播数据包传输的副本，然后将其重播到未启用反重播服务的组。请注意，对于大规模的任意源多播组，组接收方为每个潜在组发送方保持防重播状态是不切实际的。对于大规模的、任何源组播组都需要反重放保护的组策略应该考虑能够检测和拒绝重放的应用层多播协议。
For large-scale groups, the IP security multicast extensions are dependent on an automated Group Key Management protocol to correctly authenticate and authorize trustworthy members in compliance to the group's policies. Inherent in the concept of a cryptographic group is a set of one or more shared secrets entrusted to all of the Group Members. Consequently, the service's security guarantees are no stronger than the weakest member admitted to the group by the GKM system. The GKM system is responsible for responding to compromised Group Member detection by executing a re-key procedure. The GKM re-keying protocol will expel the compromised Group Members and
对于大型组，IP安全多播扩展依赖于自动组密钥管理协议，以根据组的策略正确验证和授权可信成员。加密组的概念中固有的是一组委托给所有组成员的一个或多个共享秘密。因此，服务的安全保障并不比GKM系统接纳的最脆弱成员强。GKM系统负责通过执行重设密钥程序响应受损的组成员检测。GKM重设密钥协议将驱逐受损的组成员和
distribute new group keying material to the trusted members. Alternatively, the group policy may require the GKM system to terminate the group.
将新的组密钥材料分发给受信任的成员。或者，集团政策可能要求GKM系统终止集团。
In the event that an adversary has been admitted into the group by the GKM system, the following attacks are possible and can not be solved by the IPsec multicast extension service:
如果GKM系统允许对手进入组，则可能发生以下攻击，并且IPsec多播扩展服务无法解决这些攻击：
- The adversary can disclose the secret group key or group data to an unauthorized party outside of the group. After a group key or data compromise, cryptographic methods such as traitor tracing or watermarking can assist in the forensics process. However, these methods are outside the scope of this specification.
- 对手可以将秘密组密钥或组数据披露给组外的未经授权方。在组密钥或数据泄露后，叛逆者跟踪或水印等加密方法可协助取证过程。但是，这些方法不在本规范的范围内。
- The insider adversary can forge packet transmissions that appear to be from a peer Group Member. To defend against this attack, for those Group Sender transmissions that merit the overhead, the group policy can require the Group Sender to multicast packets using the data origin authentication service.
- 内部对手可以伪造看似来自对等组成员的数据包传输。为了防御此攻击，对于那些值得开销的组发送方传输，组策略可以要求组发送方使用数据源身份验证服务多播数据包。
- If the group's data origin authentication service uses digital signatures, then the insider adversary can launch a computational resource denial-of-service attack by multicasting bogus signed packets.
- 如果该组的数据源身份验证服务使用数字签名，则内部对手可以通过多播假签名数据包发起计算资源拒绝服务攻击。
The IP security multicast extensions service can not defend against a poorly considered group security policy that allows a weaker cryptographic algorithm simply because all of the group's endpoints are known to support it. Unfortunately, large-scale groups can be difficult to upgrade to the current best-in-class cryptographic algorithms. One possible approach to solving many of these problems is the deployment of composite groups that can straddle heterogeneous groups [COMPGRP]. A standard solution for heterogeneous groups is an activity for future standardization. In the interim, synchronization of a group's cryptographic capabilities could be achieved using a secure and scalable software distribution management tool.
IP安全多播扩展服务无法抵御考虑不周的组安全策略，该策略只允许较弱的加密算法，因为已知组的所有端点都支持它。不幸的是，大型组很难升级到当前同类最佳的加密算法。解决其中许多问题的一种可能方法是部署跨异构组的复合组[COMPGRP]。异构组的标准解决方案是未来标准化的一项活动。在此期间，可以使用安全且可扩展的软件分发管理工具实现组加密功能的同步。
Large-scale groups may span multiple legal jurisdictions (e.g., countries) that enforce limits on cryptographic algorithms or key strengths. As currently defined, the IPsec multicast extension service requires a single group policy per group. As noted above, this problem remains an area for future standardization.
大型集团可能跨越多个法律管辖区（例如国家），对加密算法或密钥强度实施限制。按照当前的定义，IPsec多播扩展服务要求每个组使用一个组策略。如上所述，这个问题仍然是未来标准化的一个领域。
A Source Specific Multicast (SSM) Group Sender's source IP address can dynamically change during a secure multicast group's lifetime. Examples of the events that can cause the Group Sender's source address to change include but are not limited to NAT, a mobility-induced change in the care-of-address, and a multi-homed host using a new IP interface. The change in the Group Sender's source IP address will cause GSPD entries related to that multicast group to become out of date with respect to the group's multicast routing state. In the worst case, there is a risk that the Group Sender's data originating from a new source address will be BYPASS processed by a security gateway. If this scenario was not anticipated, then it could leak the group's data. Consequently, it is recommended that SSM secure multicast groups have a default DISCARD policy for all unauthorized Group Sender source IP addresses for the SSM group's destination IP address.
源特定多播（SSM）组发送方的源IP地址可以在安全多播组的生存期内动态更改。可导致组发送方的源地址改变的事件的示例包括但不限于NAT、移动性引起的转交地址改变以及使用新IP接口的多宿主机。组发送方的源IP地址的更改将导致与该多播组相关的GSPD条目相对于组的多播路由状态过期。在最坏的情况下，安全网关可能会绕过来自新源地址的组发送方数据。如果没有预料到这种情况，那么它可能会泄露集团的数据。因此，建议SSM安全多播组对SSM组的目标IP地址的所有未经授权的组发送方源IP地址使用默认丢弃策略。
The authors wish to thank Steven Kent, Russ Housley, Pasi Eronen, and Tero Kivinen for their helpful comments.
作者希望感谢史蒂文·肯特、罗斯·霍斯利、帕西·埃隆和泰罗·基维宁的有益评论。
The "Guidelines for Writing RFC Text on Security Considerations" [RFC3552] was consulted to develop the Security Considerations section of this memo.
参考“关于安全注意事项的RFC文本编写指南”[RFC3552]来制定本备忘录的安全注意事项部分。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security Composite Cryptographic Groups", Work in Progress, February 2007.
[COMPGRP]Gross G.和H.Cruickshank，“多播IP安全复合加密组”，正在进行的工作，2007年2月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999.
[RFC2627]Wallner，D.，Harder，E.，和R.Agee，“多播的密钥管理：问题和架构”，RFC 2627，1999年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171]Albanna，Z.，Almeroth，K.，Meyer，D.，和M.Schipper，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 3171，2001年8月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307]Haberman，B.，“IPv6多播地址的分配指南”，RFC3307，2002年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[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月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya，S.，编辑，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月。
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3940]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向否定确认（NACK）的可靠多播（NORM）协议”，RFC 39402004年11月。
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
[RFC4046]Baugher，M.，Canetti，R.，Dondeti，L.，和F.Lindholm，“多播安全（MSEC）组密钥管理体系结构”，RFC 4046，2005年4月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]Weis，B.“在封装安全有效载荷（ESP）和身份验证头（AH）中使用RSA/SHA-1签名”，RFC 4359，2006年1月。
[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月。
[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月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891]Graveman，R.，Parthasarathy，M.，Savola，P.，和H.Tschofenig，“使用IPsec保护IPv4隧道中的IPv6”，RFC 4891，2007年5月。
[ZLLY03] Zhang, X., et al., "Protocol Design for Scalable and Reliable Group Rekeying", IEEE/ACM Transactions on Networking (TON), Volume 11, Issue 6, December 2003.
[ZLLY03]Zhang，X.，等，“可扩展和可靠组密钥更新的协议设计”，IEEE/ACM网络事务（TON），第11卷，第6期，2003年12月。
The vast majority of secure multicast applications can be catalogued by their service model and accompanying intra-group communication patterns. Both the Group Key Management (GKM) subsystem and the IPsec subsystem MUST be able to configure the GSPD/SAD security policies to match these dominant usage scenarios. The GSPD/SAD policies MUST include the ability to configure both Any-Source Multicast groups and Source-Specific Multicast groups for each of these service models. The GKM subsystem management interface MAY include mechanisms to configure the security policies for service models not identified by this standard.
绝大多数安全多播应用程序都可以根据其服务模型和相应的组内通信模式进行分类。组密钥管理（GKM）子系统和IPsec子系统必须能够配置GSPD/SAD安全策略，以匹配这些主要使用场景。GSPD/SAD策略必须包括为每个服务模型配置任何源多播组和源特定多播组的能力。GKM子系统管理接口可能包括为本标准未确定的服务模型配置安全策略的机制。
Multimedia content-delivery multicast applications that do not have congestion notification or re-transmission error-recovery mechanisms are inherently unidirectional. RFC 4301 only defines bi-directional unicast traffic selectors (as per RFC 4301, Sections 4.4.1 and 5.1 with respect to traffic selector directionality). The GKM subsystem requires that the IPsec subsystem MUST support unidirectional SPD entries, which cause a Group Security Association (GSA) to be installed in only one direction. Multicast applications that have only one Group Member authorized to transmit can use this type of Group Security Association to enforce that group policy. In the inverse direction, the GSA does not have an SAD entry, and the GSPD configuration is optionally set up to discard unauthorized attempts to transmit unicast or multicast packets to the group.
没有拥塞通知或重新传输错误恢复机制的多媒体内容交付多播应用程序本质上是单向的。RFC 4301仅定义双向单播业务选择器（根据RFC 4301第4.4.1节和第5.1节关于业务选择器方向性的规定）。GKM子系统要求IPsec子系统必须支持单向SPD条目，这导致只能在一个方向上安装组安全关联（GSA）。只有一个组成员被授权传输的多播应用程序可以使用这种类型的组安全关联来强制执行该组策略。在相反方向上，GSA没有SAD条目，并且可选地设置GSPD配置以丢弃向组发送单播或多播分组的未经授权的尝试。
The GKM subsystem's management interface MUST have the ability to set up a GKM subsystem group having a unidirectional GSA security policy.
GKM子系统的管理接口必须能够设置具有单向GSA安全策略的GKM子系统组。
Some secure multicast applications are characterized as one Group Sender to many receivers but have inverse data flows required by a reliable multicast transport protocol (e.g., NORM). In such applications, the data flow from the sender is multicast and the inverse flow from the Group's Receivers is unicast to the sender. Typically, the inverse data flows carry error repair requests and congestion control status.
一些安全多播应用程序的特征是一组发送方到多个接收方，但具有可靠多播传输协议（例如NORM）所需的反向数据流。在这样的应用中，来自发送方的数据流是多播的，来自组的接收方的反向数据流是单播到发送方的。通常，反向数据流携带错误修复请求和拥塞控制状态。
For such applications, it is advantageous to use the same IPsec SA for protection of both unicast and multicast data flows. This does introduce one risk: the IKEv2 application may choose the same SPI for receiving unicast traffic as the GCKS chooses for a group IPsec SA covering unicast traffic. If both SAs are installed in the SAD, the SA lookup may return the wrong SPI as the result of an SA lookup. To
对于这样的应用，使用相同的IPsec SA来保护单播和多播数据流是有利的。这确实引入了一个风险：IKEv2应用程序可能会选择与GCKS为覆盖单播流量的组IPsec SA选择相同的SPI来接收单播流量。如果两个SA都安装在SAD中，SA查找可能会返回错误的SPI作为SA查找的结果。到
avoid this problem, IPsec SAs installed by the GKM SHOULD use the 2- tuple {destination IP address, SPI} to identify each IPsec SA. In addition, the GKM SHOULD use a unicast destination IP address that does not match any destination IP address in use by an IKEv2 unicast IPsec SA. For example, suppose a Group Member is using both IKEv2 and a GKM protocol, and the group security policy requires protecting the NORM inverse data flows as described above. In this case, group policy SHOULD allocate and use a unique unicast destination IP address representing the NORM Group Sender. This address would be configured in parallel to the Group Sender's existing IP addresses. The GKM subsystems at both the NORM Group Sender and Group Receiver endpoints would install the IPsec SA, protecting the NORM unicast messages such that the SA lookup uses the unicast destination address as well as the SPI.
为了避免这个问题，GKM安装的IPsec SA应该使用2元组{目的地IP地址，SPI}来标识每个IPsec SA。此外，GKM应使用与IKEv2单播IPsec SA使用的任何目标IP地址不匹配的单播目标IP地址。例如，假设一个组成员同时使用IKEv2和GKM协议，并且组安全策略要求如上所述保护范数反向数据流。在这种情况下，组策略应该分配并使用一个唯一的单播目标IP地址，该地址表示正常的组发送方。此地址将与组发送方的现有IP地址并行配置。NORM组发送方和组接收方端点处的GKM子系统将安装IPsec SA，保护NORM单播消息，以便SA查找使用单播目标地址以及SPI。
The GSA SHOULD use IPsec anti-replay protection service for the sender's multicast data flow to the group's Receivers. Because of the scalability problem described in the next section, it is not practical to use the IPsec anti-replay service for the unicast inverse flows. Consequently, in the inverse direction, the IPsec anti-replay protection MUST be disabled. However, the unicast inverse flows can use the group's IPsec group authentication mechanism. The Group Receiver's GSPD entry for this GSA SHOULD be configured to only allow a unicast transmission to the sender node rather than a multicast transmission to the whole group.
GSA应使用IPsec防重播保护服务来保护发送方到组接收方的多播数据流。由于下一节中描述的可伸缩性问题，将IPsec反重播服务用于单播反向流是不切实际的。因此，在相反的方向上，必须禁用IPsec防重播保护。但是，单播反向流可以使用组的IPsec组身份验证机制。此GSA的组接收方的GSPD条目应配置为仅允许到发送方节点的单播传输，而不允许到整个组的多播传输。
If an ESP digital signature authentication is available (e.g., RFC 4359), source authentication MAY be used to authenticate a receiver node's transmission to the sender. The GKM protocol MUST define a key management mechanism for the Group Sender to validate the asserted signature public key of any receiver node without requiring that the sender maintain state about every Group Receiver.
如果ESP数字签名认证可用（例如，RFC 4359），则源认证可用于认证接收器节点到发送器的传输。GKM协议必须为组发送方定义密钥管理机制，以验证任何接收方节点的断言签名公钥，而无需发送方维护每个组接收方的状态。
This multicast application service model is RECOMMENDED because it includes congestion control feedback capabilities. Refer to [RFC2914] for additional background information.
推荐使用此多播应用程序服务模型，因为它包含拥塞控制反馈功能。有关更多背景信息，请参阅[RFC2914]。
The GKM subsystem's Group Owner management interface MUST have the ability to set up a symmetric GSPD entry and one Group Sender. The management interface SHOULD be able to configure a group to have at least 16 concurrent authorized senders, each with their own GSA anti-replay state.
GKM子系统的组所有者管理界面必须能够设置对称GSPD条目和一个组发送方。管理界面应能够将组配置为至少有16个并发授权发件人，每个发件人都有自己的GSA防重播状态。
Another family of secure multicast applications exhibits an "any-to-many" communications pattern. A representative example of such an application is a videoconference combined with an electronic whiteboard.
另一系列安全多播应用程序展示了“任意对多”通信模式。这种应用的一个代表性示例是结合电子白板的视频会议。
For such applications, all (or a large subset) of the Group Members are authorized multicast senders. In such service models, creating a distinct IPsec SA with anti-replay state for every potential sender does not scale to large groups. The group SHOULD share one IPsec SA for all of its senders. The IPsec SA SHOULD NOT use the IPsec anti-replay protection service for the sender's multicast data flow to the Group Receivers.
对于此类应用程序，组成员的所有（或大部分）都是授权的多播发送者。在这样的服务模型中，为每个潜在发送方创建具有反重放状态的独特IPsec SA不会扩展到大型组。该组应为其所有发件人共享一个IPsec SA。IPsec SA不应将IPsec防重播保护服务用于发送方到组接收方的多播数据流。
The GKM subsystem's management interface MUST have the ability to set up a group having an Any-To-Many Multicast GSA security policy.
GKM子系统的管理接口必须能够设置具有任意多播GSA安全策略的组。
This appendix describes an additional way to describe GSPD entries, as defined in Section 4.1.1. It uses ASN.1 syntax that has been successfully compiled. This syntax is merely illustrative and need not be employed in an implementation to achieve compliance. The GSPD description in Section 4.1.1 is normative. As shown in Section 4.1.1, the GSPD updates the SPD and thus this appendix updates the SPD object identifier.
本附录描述了第4.1.1节中定义的GSPD条目的另一种描述方式。它使用已成功编译的ASN.1语法。此语法只是说明性的，不需要在实现中使用以实现法规遵从性。第4.1.1节中的GSPD描述是规范性的。如第4.1.1节所示，GSPD更新SPD，因此本附录更新SPD对象标识符。
The following fields summarize the fields of the GSPD that are not present in the SPD.
以下字段汇总了SPD中不存在的GSPD字段。
- direction (in IPsecEntry) - DirectionFlags - noswap (in SelectorList) - ap-l, ap-r (in TunnelOptions)
- 方向（在IPsecEntry中）-方向标志-noswap（在选择器列表中）-ap-l、ap-r（在隧道中）
SPDModule
单刀双掷模块
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) ipsec (8) asn1-modules (3) spd-module (1) }
{iso（1）组织（3）国防部（6）互联网（1）安全（5）机制（5）ipsec（8）asn1模块（3）spd模块（1）}
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
IMPORTS
RDNSequence FROM PKIX1Explicit88
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
IMPORTS
RDNSequence FROM PKIX1Explicit88
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- An SPD is a list of policies in decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry
-- An SPD is a list of policies in decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
IPsecEntry ::= SEQUENCE { -- Each entry consists of
name NameSets OPTIONAL,
pFPs PacketFlags, -- Populate from packet flags
-- Applies to ALL of the corresponding
-- traffic selectors in the SelectorLists
direction DirectionFlags, -- SA directionality
condition SelectorLists, -- Policy "condition"
processing Processing -- Policy "action"
}
IPsecEntry ::= SEQUENCE { -- Each entry consists of
name NameSets OPTIONAL,
pFPs PacketFlags, -- Populate from packet flags
-- Applies to ALL of the corresponding
-- traffic selectors in the SelectorLists
direction DirectionFlags, -- SA directionality
condition SelectorLists, -- Policy "condition"
processing Processing -- Policy "action"
}
BypassOrDiscardEntry ::= SEQUENCE {
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
condition InOutBound }
BypassOrDiscardEntry ::= SEQUENCE {
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
condition InOutBound }
InOutBound ::= CHOICE {
outbound [0] SelectorLists,
inbound [1] SelectorLists,
bothways [2] BothWays }
InOutBound ::= CHOICE {
outbound [0] SelectorLists,
inbound [1] SelectorLists,
bothways [2] BothWays }
BothWays ::= SEQUENCE {
inbound SelectorLists,
outbound SelectorLists }
BothWays ::= SEQUENCE {
inbound SelectorLists,
outbound SelectorLists }
NameSets ::= SEQUENCE {
passed SET OF Names-R, -- Matched to IKE ID by
-- responder
local SET OF Names-I } -- Used internally by IKE
-- initiator
NameSets ::= SEQUENCE {
passed SET OF Names-R, -- Matched to IKE ID by
-- responder
local SET OF Names-I } -- Used internally by IKE
-- initiator
Names-R ::= CHOICE { -- IKEv2 IDs
dName RDNSequence, -- ID_DER_ASN1_DN
fqdn FQDN, -- ID_FQDN
rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
keyID OCTET STRING } -- KEY_ID
Names-R ::= CHOICE { -- IKEv2 IDs
dName RDNSequence, -- ID_DER_ASN1_DN
fqdn FQDN, -- ID_FQDN
rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
keyID OCTET STRING } -- KEY_ID
Names-I ::= OCTET STRING -- Used internally by IKE
-- initiator
Names-I ::= OCTET STRING -- Used internally by IKE
-- initiator
FQDN ::= IA5String
FQDN ::= IA5String
RFC822Name ::= IA5String
RFC822Name ::= IA5String
PacketFlags ::= BIT STRING {
-- if set, take selector value from packet
-- establishing SA
-- else use value in SPD entry
localAddr (0),
remoteAddr (1),
protocol (2),
localPort (3),
remotePort (4) }
PacketFlags ::= BIT STRING {
-- if set, take selector value from packet
-- establishing SA
-- else use value in SPD entry
localAddr (0),
remoteAddr (1),
protocol (2),
localPort (3),
remotePort (4) }
DirectionFlags ::= BIT STRING {
-- if set, install SA in the specified
-- direction. symmetric policy is
-- represented by setting both bits
inbound (0),
outbound (1) }
DirectionFlags ::= BIT STRING {
-- if set, install SA in the specified
-- direction. symmetric policy is
-- represented by setting both bits
inbound (0),
outbound (1) }
SelectorLists ::= SET OF SelectorList
SelectorLists ::= SET OF SelectorList
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice,
noswap BOOLEAN } -- Do not swap local and remote
-- addresses and ports on incoming
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice,
noswap BOOLEAN } -- Do not swap local and remote
-- addresses and ports on incoming
-- SPD-S and SPD-I checks
--SPD-S和SPD-I检查
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL } -- if absent, use
-- transport mode
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL } -- if absent, use
-- transport mode
SALifetime ::= SEQUENCE {
seconds [0] INTEGER OPTIONAL,
bytes [1] INTEGER OPTIONAL }
SALifetime ::= SEQUENCE {
seconds [0] INTEGER OPTIONAL,
bytes [1] INTEGER OPTIONAL }
ManualSPI ::= SEQUENCE {
spi INTEGER,
keys KeyIDs }
ManualSPI ::= SEQUENCE {
spi INTEGER,
keys KeyIDs }
KeyIDs ::= SEQUENCE OF OCTET STRING
KeyIDs ::= SEQUENCE OF OCTET STRING
ProcessingAlgs ::= CHOICE {
ah [0] IntegrityAlgs, -- AH
esp [1] ESPAlgs} -- ESP
ProcessingAlgs ::= CHOICE {
ah [0] IntegrityAlgs, -- AH
esp [1] ESPAlgs} -- ESP
ESPAlgs ::= CHOICE {
integrity [0] IntegrityAlgs, -- integrity only
confidentiality [1] ConfidentialityAlgs, -- confidentiality
-- only
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
ESPAlgs ::= CHOICE {
integrity [0] IntegrityAlgs, -- integrity only
confidentiality [1] ConfidentialityAlgs, -- confidentiality
-- only
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- Integrity Algorithms
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-- Integrity Algorithms
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
IntegrityAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5)
-- tbd (6..65535)
}
IntegrityAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5)
-- tbd (6..65535)
}
-- Confidentiality Algorithms
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-- Confidentiality Algorithms
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
ConfidentialityAlgType ::= INTEGER {
encr-DES-IV64 (1),
encr-DES (2),
encr-3DES (3),
encr-RC5 (4),
encr-IDEA (5),
encr-CAST (6),
encr-BLOWFISH (7),
encr-3IDEA (8),
encr-DES-IV32 (9),
encr-RC4 (10),
encr-NULL (11),
encr-AES-CBC (12),
encr-AES-CTR (13)
-- tbd (14..65535)
}
ConfidentialityAlgType ::= INTEGER {
encr-DES-IV64 (1),
encr-DES (2),
encr-3DES (3),
encr-RC5 (4),
encr-IDEA (5),
encr-CAST (6),
encr-BLOWFISH (7),
encr-3IDEA (8),
encr-DES-IV32 (9),
encr-RC4 (10),
encr-NULL (11),
encr-AES-CBC (12),
encr-AES-CTR (13)
-- tbd (14..65535)
}
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlg ::= SEQUENCE {
algorithm CombinedModeType,
parameters ANY -- DEFINED BY algorithm -- }
-- defined outside
-- of this document for AES modes.
CombinedModeAlg ::= SEQUENCE {
algorithm CombinedModeType,
parameters ANY -- DEFINED BY algorithm -- }
-- defined outside
-- of this document for AES modes.
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE Copy CE to inner header
ap-l BOOLEAN, -- TRUE Copy inner IP header
-- source address to outer
-- IP header source address
ap-r BOOLEAN, -- TRUE Copy inner IP header
-- destination address to outer
-- IP header destination address
df DF,
addresses TunnelAddresses }
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE Copy CE to inner header
ap-l BOOLEAN, -- TRUE Copy inner IP header
-- source address to outer
-- IP header source address
ap-r BOOLEAN, -- TRUE Copy inner IP header
-- destination address to outer
-- IP header destination address
df DF,
addresses TunnelAddresses }
TunnelAddresses ::= CHOICE {
ipv4 IPv4Pair,
ipv6 [0] IPv6Pair }
TunnelAddresses ::= CHOICE {
ipv4 IPv4Pair,
ipv6 [0] IPv6Pair }
IPv4Pair ::= SEQUENCE {
local OCTET STRING (SIZE(4)),
remote OCTET STRING (SIZE(4)) }
IPv4Pair ::= SEQUENCE {
local OCTET STRING (SIZE(4)),
remote OCTET STRING (SIZE(4)) }
IPv6Pair ::= SEQUENCE {
local OCTET STRING (SIZE(16)),
remote OCTET STRING (SIZE(16)) }
IPv6Pair ::= SEQUENCE {
local OCTET STRING (SIZE(16)),
remote OCTET STRING (SIZE(16)) }
DSCP ::= SEQUENCE {
copy BOOLEAN, -- TRUE copy from inner header
-- FALSE do not copy
mapping OCTET STRING OPTIONAL} -- points to table
-- if no copy
DSCP ::= SEQUENCE {
copy BOOLEAN, -- TRUE copy from inner header
-- FALSE do not copy
mapping OCTET STRING OPTIONAL} -- points to table
-- if no copy
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- for ANY protocol
noNext [0] NoNextLayerProtocol, -- has no next layer
-- items
oneNext [1] OneNextLayerProtocol, -- has one next layer
-- item
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- for ANY protocol
noNext [0] NoNextLayerProtocol, -- has no next layer
-- items
oneNext [1] OneNextLayerProtocol, -- has one next layer
-- item
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- ANY protocol
nextLayer AnyNextLayers }
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- ANY protocol
nextLayer AnyNextLayers }
AnyNextLayers ::= SEQUENCE { -- with either
first AnyNextLayer, -- ANY next layer selector
second AnyNextLayer } -- ANY next layer selector
AnyNextLayers ::= SEQUENCE { -- with either
first AnyNextLayer, -- ANY next layer selector
second AnyNextLayer } -- ANY next layer selector
NoNextLayerProtocol ::= INTEGER (2..254)
NoNextLayerProtocol ::= INTEGER (2..254)
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- Protocol
local NextLayerChoice, -- Local and
remote NextLayerChoice } -- Remote ports
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- Protocol
local NextLayerChoice, -- Local and
remote NextLayerChoice } -- Remote ports
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
-- Representation of ANY in next layer field
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- Representation of ANY in next layer field
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- Representation of OPAQUE in next layer field.
-- Matches IKE convention
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- Representation of OPAQUE in next layer field.
-- Matches IKE convention
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- Range for a next layer field
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- Range for a next layer field
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- List of IP addresses
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- List of IP addresses
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- IPv4 address representations
IPv4List ::= SEQUENCE OF IPv4Range
-- IPv4 address representations
IPv4List ::= SEQUENCE OF IPv4Range
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
-- IPv6 address representations
IPv6List ::= SEQUENCE OF IPv6Range
-- IPv6 address representations
IPv6List ::= SEQUENCE OF IPv6Range
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
END
终止
Authors' Addresses
作者地址
Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706 USA
Brian Weis Cisco Systems美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134-1706
Phone: +1-408-526-4796
EMail: bew@cisco.com
Phone: +1-408-526-4796
EMail: bew@cisco.com
George Gross Secure Multicast Networks LLC 977 Bates Road Shoreham, VT 05770 USA
乔治·格罗斯安全多播网络有限责任公司，美国VT 05770州肖勒姆贝茨路977号
Phone: +1-802-897-5339
EMail: gmgross@securemulticast.net
Phone: +1-802-897-5339
EMail: gmgross@securemulticast.net
Dragan Ignjatic Polycom Suite 200 3605 Gilmore Way Burnaby, BC V5G 4X5 Canada
加拿大卑诗省本纳比市吉尔摩路200 3605号Dragan Ignjatic Polycom套房V5G 4X5
Phone: +1-604-453-9424
EMail: dignjatic@polycom.com
Phone: +1-604-453-9424
EMail: dignjatic@polycom.com