Network Working Group S. Kent
Request for Comments: 4301 K. Seo
Obsoletes: 2401 BBN Technologies
Category: Standards Track December 2005
Network Working Group S. Kent
Request for Comments: 4301 K. Seo
Obsoletes: 2401 BBN Technologies
Category: Standards Track December 2005
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) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998).
本文档描述了“IP安全体系结构”的更新版本，旨在为IP层的流量提供安全服务。本文件废除RFC 2401（1998年11月）。
Dedication
奉献
This document is dedicated to the memory of Charlie Lynn, a long-time senior colleague at BBN, who made very significant contributions to the IPsec documents.
本文档旨在纪念BBN的长期资深同事Charlie Lynn，他对IPsec文档做出了重大贡献。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Summary of Contents of Document ............................4
1.2. Audience ...................................................4
1.3. Related Documents ..........................................5
2. Design Objectives ...............................................5
2.1. Goals/Objectives/Requirements/Problem Description ..........5
2.2. Caveats and Assumptions ....................................6
3. System Overview .................................................7
3.1. What IPsec Does ............................................7
3.2. How IPsec Works ............................................9
3.3. Where IPsec Can Be Implemented ............................10
4. Security Associations ..........................................11
4.1. Definition and Scope ......................................12
4.2. SA Functionality ..........................................16
4.3. Combining SAs .............................................17
4.4. Major IPsec Databases .....................................18
4.4.1. The Security Policy Database (SPD) .................19
4.4.1.1. Selectors .................................26
4.4.1.2. Structure of an SPD Entry .................30
4.4.1.3. More Regarding Fields Associated
with Next Layer Protocols .................32
4.4.2. Security Association Database (SAD) ................34
4.4.2.1. Data Items in the SAD .....................36
4.4.2.2. Relationship between SPD, PFP
flag, packet, and SAD .....................38
4.4.3. Peer Authorization Database (PAD) ..................43
4.4.3.1. PAD Entry IDs and Matching Rules ..........44
4.4.3.2. IKE Peer Authentication Data ..............45
4.4.3.3. Child SA Authorization Data ...............46
4.4.3.4. How the PAD Is Used .......................46
4.5. SA and Key Management .....................................47
4.5.1. Manual Techniques ..................................48
4.5.2. Automated SA and Key Management ....................48
4.5.3. Locating a Security Gateway ........................49
4.6. SAs and Multicast .........................................50
5. IP Traffic Processing ..........................................50
5.1. Outbound IP Traffic Processing
(protected-to-unprotected) ................................52
5.1.1. Handling an Outbound Packet That Must Be
Discarded ..........................................54
5.1.2. Header Construction for Tunnel Mode ................55
5.1.2.1. IPv4: Header Construction for
Tunnel Mode ...............................57
5.1.2.2. IPv6: Header Construction for
Tunnel Mode ...............................59
5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59
1. Introduction ....................................................4
1.1. Summary of Contents of Document ............................4
1.2. Audience ...................................................4
1.3. Related Documents ..........................................5
2. Design Objectives ...............................................5
2.1. Goals/Objectives/Requirements/Problem Description ..........5
2.2. Caveats and Assumptions ....................................6
3. System Overview .................................................7
3.1. What IPsec Does ............................................7
3.2. How IPsec Works ............................................9
3.3. Where IPsec Can Be Implemented ............................10
4. Security Associations ..........................................11
4.1. Definition and Scope ......................................12
4.2. SA Functionality ..........................................16
4.3. Combining SAs .............................................17
4.4. Major IPsec Databases .....................................18
4.4.1. The Security Policy Database (SPD) .................19
4.4.1.1. Selectors .................................26
4.4.1.2. Structure of an SPD Entry .................30
4.4.1.3. More Regarding Fields Associated
with Next Layer Protocols .................32
4.4.2. Security Association Database (SAD) ................34
4.4.2.1. Data Items in the SAD .....................36
4.4.2.2. Relationship between SPD, PFP
flag, packet, and SAD .....................38
4.4.3. Peer Authorization Database (PAD) ..................43
4.4.3.1. PAD Entry IDs and Matching Rules ..........44
4.4.3.2. IKE Peer Authentication Data ..............45
4.4.3.3. Child SA Authorization Data ...............46
4.4.3.4. How the PAD Is Used .......................46
4.5. SA and Key Management .....................................47
4.5.1. Manual Techniques ..................................48
4.5.2. Automated SA and Key Management ....................48
4.5.3. Locating a Security Gateway ........................49
4.6. SAs and Multicast .........................................50
5. IP Traffic Processing ..........................................50
5.1. Outbound IP Traffic Processing
(protected-to-unprotected) ................................52
5.1.1. Handling an Outbound Packet That Must Be
Discarded ..........................................54
5.1.2. Header Construction for Tunnel Mode ................55
5.1.2.1. IPv4: Header Construction for
Tunnel Mode ...............................57
5.1.2.2. IPv6: Header Construction for
Tunnel Mode ...............................59
5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59
6. ICMP Processing ................................................63
6.1. Processing ICMP Error Messages Directed to an
IPsec Implementation ......................................63
6.1.1. ICMP Error Messages Received on the
Unprotected Side of the Boundary ...................63
6.1.2. ICMP Error Messages Received on the
Protected Side of the Boundary .....................64
6.2. Processing Protected, Transit ICMP Error Messages .........64
7. Handling Fragments (on the protected side of the IPsec
boundary) ......................................................66
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
Fragments .................................................67
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
7.3. Stateful Fragment Checking ................................68
7.4. BYPASS/DISCARD Traffic ....................................69
8. Path MTU/DF Processing .........................................69
8.1. DF Bit ....................................................69
8.2. Path MTU (PMTU) Discovery .................................70
8.2.1. Propagation of PMTU ................................70
8.2.2. PMTU Aging .........................................71
9. Auditing .......................................................71
10. Conformance Requirements ......................................71
11. Security Considerations .......................................72
12. IANA Considerations ...........................................72
13. Differences from RFC 2401 .....................................72
14. Acknowledgements ..............................................75
Appendix A: Glossary ..............................................76
Appendix B: Decorrelation .........................................79
B.1. Decorrelation Algorithm ...................................79
Appendix C: ASN.1 for an SPD Entry ................................82
Appendix D: Fragment Handling Rationale ...........................88
D.1. Transport Mode and Fragments ..............................88
D.2. Tunnel Mode and Fragments .................................89
D.3. The Problem of Non-Initial Fragments ......................90
D.4. BYPASS/DISCARD Traffic ....................................93
D.5. Just say no to ports? .....................................94
D.6. Other Suggested Solutions..................................94
D.7. Consistency................................................95
D.8. Conclusions................................................95
Appendix E: Example of Supporting Nested SAs via SPD and
Forwarding Table Entries...............................96
References.........................................................98
Normative References............................................98
Informative References..........................................99
6. ICMP Processing ................................................63
6.1. Processing ICMP Error Messages Directed to an
IPsec Implementation ......................................63
6.1.1. ICMP Error Messages Received on the
Unprotected Side of the Boundary ...................63
6.1.2. ICMP Error Messages Received on the
Protected Side of the Boundary .....................64
6.2. Processing Protected, Transit ICMP Error Messages .........64
7. Handling Fragments (on the protected side of the IPsec
boundary) ......................................................66
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
Fragments .................................................67
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
7.3. Stateful Fragment Checking ................................68
7.4. BYPASS/DISCARD Traffic ....................................69
8. Path MTU/DF Processing .........................................69
8.1. DF Bit ....................................................69
8.2. Path MTU (PMTU) Discovery .................................70
8.2.1. Propagation of PMTU ................................70
8.2.2. PMTU Aging .........................................71
9. Auditing .......................................................71
10. Conformance Requirements ......................................71
11. Security Considerations .......................................72
12. IANA Considerations ...........................................72
13. Differences from RFC 2401 .....................................72
14. Acknowledgements ..............................................75
Appendix A: Glossary ..............................................76
Appendix B: Decorrelation .........................................79
B.1. Decorrelation Algorithm ...................................79
Appendix C: ASN.1 for an SPD Entry ................................82
Appendix D: Fragment Handling Rationale ...........................88
D.1. Transport Mode and Fragments ..............................88
D.2. Tunnel Mode and Fragments .................................89
D.3. The Problem of Non-Initial Fragments ......................90
D.4. BYPASS/DISCARD Traffic ....................................93
D.5. Just say no to ports? .....................................94
D.6. Other Suggested Solutions..................................94
D.7. Consistency................................................95
D.8. Conclusions................................................95
Appendix E: Example of Supporting Nested SAs via SPD and
Forwarding Table Entries...............................96
References.........................................................98
Normative References............................................98
Informative References..........................................99
This document specifies the base architecture for IPsec-compliant systems. It describes how to provide a set of security services for traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] environments. This document describes the requirements for systems that implement IPsec, the fundamental elements of such systems, and how the elements fit together and fit into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of the IPsec architecture. Other documents address additional architectural details in specialized environments, e.g., use of IPsec in Network Address Translation (NAT) environments and more comprehensive support for IP multicast. The fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d).
本文档指定了IPsec兼容系统的基本体系结构。它描述了如何在IPv4[Pos81a]和IPv6[DH98]环境中为IP层的流量提供一组安全服务。本文档描述了实现IPsec的系统的要求、此类系统的基本元素，以及这些元素如何组合在一起并适应IP环境。它还描述了IPsec协议提供的安全服务，以及如何在IP环境中使用这些服务。本文档不涉及IPsec体系结构的所有方面。其他文档介绍了专用环境中的其他体系结构细节，例如，在网络地址转换（NAT）环境中使用IPsec以及对IP多播的更全面支持。IPsec安全体系结构的基本组件将根据其底层、所需的功能进行讨论。其他RFC（参见第1.3节，了解指向其他文件的指针）定义了（a）、（c）和（d）中的协议。
a. Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP) b. Security Associations -- what they are and how they work, how they are managed, associated processing c. Key Management -- manual and automated (The Internet Key Exchange (IKE)) d. Cryptographic algorithms for authentication and encryption
a. Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP) b. Security Associations -- what they are and how they work, how they are managed, associated processing c. Key Management -- manual and automated (The Internet Key Exchange (IKE)) d. Cryptographic algorithms for authentication and encryptiontranslate error, please retry
This document is not a Security Architecture for the Internet; it addresses security only at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms.
本文件不是互联网的安全体系结构；它仅在IP层解决安全问题，通过使用密码和协议安全机制的组合提供。
The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of the sequence of letters "IPsec" should be understood to refer to the IPsec protocols.
首选拼写“IPsec”，并在本标准和所有相关IPsec标准中使用。不推荐使用IPsec的所有其他大写形式（例如IPsec、IPsec、IPsec）。然而，字母“IPsec”序列的任何大写字母都应理解为指IPsec协议。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、可和可选时，应按照RFC 2119[Bra97]中的说明进行解释。
The target audience for this document is primarily individuals who implement this IP security technology or who architect systems that will use this technology. Technically adept users of this technology
本文档的目标受众主要是实施此IP安全技术的个人或将使用此技术的系统架构师。这项技术的技术熟练用户
(end users or system administrators) also are part of the target audience. A glossary is provided in Appendix A to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol (IP), related networking technology, and general information system security terms and concepts.
（最终用户或系统管理员）也是目标受众的一部分。附录A中提供了词汇表，以帮助填补背景/词汇方面的空白。本文档假定读者熟悉互联网协议（IP）、相关网络技术以及一般信息系统安全术语和概念。
As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their interrelationship. They include RFCs on the following topics:
如上所述，其他文档提供了IPsec的一些组件及其相互关系的详细定义。它们包括以下主题的RFC：
a. security protocols -- RFCs describing the Authentication Header (AH) [Ken05b] and Encapsulating Security Payload (ESP) [Ken05a] protocols. b. cryptographic algorithms for integrity and encryption -- one RFC that defines the mandatory, default algorithms for use with AH and ESP [Eas05], a similar RFC that defines the mandatory algorithms for use with IKEv2 [Sch05] plus a separate RFC for each cryptographic algorithm. c. automatic key management -- RFCs on "The Internet Key Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)" [Sch05].
a. 安全协议——描述身份验证头（AH）[Ken05b]和封装安全有效负载（ESP）[Ken05a]协议的RFC。B完整性和加密的加密算法——一个RFC定义用于AH和ESP[Eas05]的强制默认算法，一个类似的RFC定义用于IKEv2[Sch05]的强制算法，以及每个加密算法的单独RFC。C自动密钥管理——关于“互联网密钥交换（IKEv2）协议”[Kau05]和“互联网密钥交换版本2（IKEv2）中使用的加密算法”[Sch05]的RFC。
IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself).
IPsec旨在为IPv4和IPv6提供可互操作、高质量、基于加密的安全性。提供的一组安全服务包括访问控制、无连接完整性、数据源身份验证、检测和拒绝重播（部分序列完整性的一种形式）、机密性（通过加密）和有限流量机密性。这些服务在IP层提供，以标准方式为可能通过IP承载的所有协议（包括IP本身）提供保护。
IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer. Implementations are free to provide more sophisticated firewall mechanisms, and to implement the IPsec-mandated functionality using those more sophisticated mechanisms. (Note that interoperability may suffer if additional firewall constraints on traffic flows are imposed by an IPsec implementation but cannot be negotiated based on the traffic selector features defined in this document and negotiated
IPsec包含一个最小防火墙功能的规范，因为这是IP层访问控制的一个基本方面。实现可以免费提供更复杂的防火墙机制，并使用这些更复杂的机制实现IPsec授权的功能。（请注意，如果IPsec实现对流量施加了额外的防火墙限制，但无法根据本文档中定义的流量选择器功能进行协商，并且协商一致，则互操作性可能会受到影响。）
via IKEv2.) The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection.
通过IKEv2。）IPsec防火墙功能利用为所有IPsec流量提供的加密强制身份验证和完整性，提供比使用防火墙（不了解IPsec内部参数的防火墙）加上单独的加密保护更好的访问控制。
Most of the security services are provided through use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in a context, and the ways in which they are employed, will be determined by the users/administrators in that context. It is the goal of the IPsec architecture to ensure that compliant implementations include the services and management interfaces needed to meet the security requirements of a broad user population.
大多数安全服务都是通过使用两个流量安全协议（身份验证头（AH）和封装安全负载（ESP）以及通过使用加密密钥管理过程和协议提供的。上下文中使用的IPsec协议集及其使用方式将由该上下文中的用户/管理员确定。IPsec体系结构的目标是确保兼容的实现包括满足广泛用户群的安全需求所需的服务和管理接口。
When IPsec is correctly implemented and deployed, it ought not adversely affect users, hosts, and other Internet components that do not employ IPsec for traffic protection. IPsec security protocols (AH and ESP, and to a lesser extent, IKE) are designed to be cryptographic algorithm independent. This modularity permits selection of different sets of cryptographic algorithms as appropriate, without affecting the other parts of the implementation. For example, different user communities may select different sets of cryptographic algorithms (creating cryptographically-enforced cliques) if required.
正确实施和部署IPsec后，不会对未使用IPsec进行流量保护的用户、主机和其他Internet组件产生不利影响。IPsec安全协议（AH和ESP，以及在较小程度上的IKE）设计为独立于加密算法。这种模块化允许根据需要选择不同的密码算法集，而不会影响实现的其他部分。例如，如果需要，不同的用户社区可能会选择不同的加密算法集（创建加密强制集团）。
To facilitate interoperability in the global Internet, a set of default cryptographic algorithms for use with AH and ESP is specified in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2 is specified in [Sch05]. [Eas05] and [Sch05] will be periodically updated to keep pace with computational and cryptologic advances. By specifying these algorithms in documents that are separate from the AH, ESP, and IKEv2 specifications, these algorithms can be updated or replaced without affecting the standardization progress of the rest of the IPsec document suite. The use of these cryptographic algorithms, in conjunction with IPsec traffic protection and key management protocols, is intended to permit system and application developers to deploy high quality, Internet-layer, cryptographic security technology.
为了促进全球互联网的互操作性，[Eas05]中规定了一组用于AH和ESP的默认加密算法，而[Sch05]中规定了一组用于实现IKEv2算法的强制性算法。[Eas05]和[Sch05]将定期更新，以跟上计算和密码学的发展。通过在独立于AH、ESP和IKEv2规范的文档中指定这些算法，可以更新或替换这些算法，而不会影响IPsec文档套件其余部分的标准化进度。这些加密算法与IPsec流量保护和密钥管理协议结合使用，旨在允许系统和应用程序开发人员部署高质量的Internet层加密安全技术。
The suite of IPsec protocols and associated default cryptographic algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of their implementation, which is
IPsec协议套件和相关的默认加密算法旨在为Internet流量提供高质量的安全性。然而，使用这些协议所提供的安全性最终取决于它们的实现质量，这是非常重要的
outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus, IPsec is only one part of an overall system security architecture.
在这套标准的范围之外。此外，计算机系统或网络的安全是许多因素的函数，包括人员、物理、程序、泄漏和计算机安全实践。因此，IPsec只是整个系统安全体系结构的一部分。
Finally, the security afforded by the use of IPsec is critically dependent on many aspects of the operating environment in which the IPsec implementation executes. For example, defects in OS security, poor quality of random number sources, sloppy system management protocols and practices, etc., can all degrade the security provided by IPsec. As above, none of these environmental attributes are within the scope of this or other IPsec standards.
最后，使用IPsec提供的安全性在很大程度上取决于执行IPsec实现的操作环境的许多方面。例如，操作系统安全性缺陷、随机数源质量差、系统管理协议和实践松散等都会降低IPsec提供的安全性。如上所述，这些环境属性都不在本标准或其他IPsec标准的范围内。
This section provides a high level description of how IPsec works, the components of the system, and how they fit together to provide the security services noted above. The goal of this description is to enable the reader to "picture" the overall process/system, see how it fits into the IP environment, and to provide context for later sections of this document, which describe each of the components in more detail.
本节对IPsec的工作原理、系统组件以及它们如何组合在一起以提供上述安全服务进行了详细描述。本说明的目的是使读者能够“描绘”整个流程/系统，了解其如何适应IP环境，并为本文档后面的章节提供上下文，这些章节将更详细地描述每个组件。
An IPsec implementation operates in a host, as a security gateway (SG), or as an independent device, affording protection to IP traffic. (A security gateway is an intermediate system implementing IPsec, e.g., a firewall or router that has been IPsec-enabled.) More detail on these classes of implementations is provided later, in Section 3.3. The protection offered by IPsec is based on requirements defined by a Security Policy Database (SPD) established and maintained by a user or system administrator, or by an application operating within constraints established by either of the above. In general, packets are selected for one of three processing actions based on IP and next layer header information ("Selectors", Section 4.4.1.1) matched against entries in the SPD. Each packet is either PROTECTed using IPsec security services, DISCARDed, or allowed to BYPASS IPsec protection, based on the applicable SPD policies identified by the Selectors.
IPsec实现在主机中作为安全网关（SG）或独立设备运行，为IP通信提供保护。（安全网关是实现IPsec的中间系统，例如启用了IPsec的防火墙或路由器。）关于这些实现类别的更多详细信息将在后面的第3.3节中提供。IPsec提供的保护基于由用户或系统管理员建立和维护的安全策略数据库（SPD）定义的要求，或由在上述任一约束条件下运行的应用程序定义的要求。通常，根据与SPD中的条目匹配的IP和下一层报头信息（“选择器”，第4.4.1.1节），为三个处理操作中的一个选择数据包。根据选择器确定的适用SPD策略，每个数据包要么使用IPsec安全服务进行保护，要么被丢弃，要么被允许绕过IPsec保护。
IPsec creates a boundary between unprotected and protected interfaces, for a host or a network (see Figure 1 below). Traffic traversing the boundary is subject to the access controls specified by the user or administrator responsible for the IPsec configuration. These controls indicate whether packets cross the boundary unimpeded, are afforded security services via AH or ESP, or are discarded.
IPsec为主机或网络在未受保护接口和受保护接口之间创建边界（请参见下面的图1）。通过边界的流量受负责IPsec配置的用户或管理员指定的访问控制。这些控件指示数据包是否畅通无阻地跨越边界，是否通过AH或ESP提供安全服务，或者是否被丢弃。
IPsec security services are offered at the IP layer through selection of appropriate security protocols, cryptographic algorithms, and cryptographic keys. IPsec can be used to protect one or more "paths" (a) between a pair of hosts, (b) between a pair of security gateways, or (c) between a security gateway and a host. A compliant host implementation MUST support (a) and (c) and a compliant security gateway must support all three of these forms of connectivity, since under certain circumstances a security gateway acts as a host.
IPsec安全服务通过选择适当的安全协议、加密算法和加密密钥在IP层提供。IPsec可用于保护一个或多个“路径”（a）在一对主机之间，（b）在一对安全网关之间，或（c）在安全网关和主机之间。兼容的主机实现必须支持（A）和（c），而兼容的安全网关必须支持这三种连接形式，因为在某些情况下，安全网关充当主机。
Unprotected
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| |Discard|<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec Boundary
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| |Discard|<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
Protected
Unprotected
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| |Discard|<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec Boundary
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| |Discard|<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
Protected
Figure 1. Top Level IPsec Processing Model
图1。顶级IPsec处理模型
In this diagram, "unprotected" refers to an interface that might also be described as "black" or "ciphertext". Here, "protected" refers to an interface that might also be described as "red" or "plaintext". The protected interface noted above may be internal, e.g., in a host implementation of IPsec, the protected interface may link to a socket layer interface presented by the OS. In this document, the term "inbound" refers to traffic entering an IPsec implementation via the unprotected interface or emitted by the implementation on the unprotected side of the boundary and directed towards the protected interface. The term "outbound" refers to traffic entering the implementation via the protected interface, or emitted by the implementation on the protected side of the boundary and directed toward the unprotected interface. An IPsec implementation may support more than one interface on either or both sides of the boundary.
在这个图中，“未保护”指的是一个接口，它也可以被描述为“黑色”或“密文”。这里，“受保护”指的是一个接口，它也可以被描述为“红色”或“纯文本”。上面提到的受保护接口可以是内部的，例如，在IPsec的主机实现中，受保护接口可以链接到OS提供的套接字层接口。在本文档中，术语“入站”是指通过未受保护的接口进入IPsec实现或由边界未受保护一侧的实现发出并指向受保护接口的通信量。术语“出站”是指通过受保护接口进入实现的通信量，或由边界受保护侧的实现发出并指向未受保护接口的通信量。IPsec实现可以在边界的一侧或两侧支持多个接口。
Note the facilities for discarding traffic on either side of the IPsec boundary, the BYPASS facility that allows traffic to transit the boundary without cryptographic protection, and the reference to IKE as a protected-side key and security management function.
请注意，用于丢弃IPsec边界两侧的流量的设施、允许流量在没有加密保护的情况下通过边界的旁路设施，以及将IKE作为受保护侧密钥和安全管理功能的引用。
IPsec optionally supports negotiation of IP compression [SMPT01], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers.
IPsec可选地支持IP压缩协商[SMPT01]，部分原因是观察到当IPsec中使用加密时，它会阻止较低协议层的有效压缩。
IPsec uses two protocols to provide traffic security services -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in detail in their respective RFCs [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. Note that ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.)
IPsec使用两种协议来提供流量安全服务——身份验证头（AH）和封装安全负载（ESP）。这两个协议在各自的RFC[Ken05b，Ken05a]中有详细描述。IPsec实现必须支持ESP，并且可能支持AH。（对AH的支持已降级至5月，因为经验表明，很少有环境中ESP无法提供必要的安全服务。请注意，ESP只能提供完整性，没有保密性，使其在大多数环境中与AH相当。）
o The IP Authentication Header (AH) [Ken05b] offers integrity and data origin authentication, with optional (at the discretion of the receiver) anti-replay features.
o IP认证头（AH）[Ken05b]提供完整性和数据源认证，并具有可选（由接收方自行决定）防重放功能。
o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers the same set of services, and also offers confidentiality. Use of ESP to provide confidentiality without integrity is NOT RECOMMENDED. When ESP is used with confidentiality enabled, there are provisions for limited traffic flow confidentiality, i.e., provisions for concealing packet length, and for facilitating efficient generation and discard of dummy packets. This capability is likely to be effective primarily in virtual private network (VPN) and overlay network contexts.
o 封装安全有效负载（ESP）协议[Ken05a]提供了相同的服务集，并且还提供了保密性。不建议使用ESP提供不完整的机密性。当ESP在启用机密性的情况下使用时，有限制流量机密性的规定，即隐藏数据包长度的规定，以及促进有效生成和丢弃虚拟数据包的规定。此功能可能主要在虚拟专用网络（VPN）和覆盖网络环境中有效。
o Both AH and ESP offer access control, enforced through the distribution of cryptographic keys and the management of traffic flows as dictated by the Security Policy Database (SPD, Section 4.4.1).
o AH和ESP都提供访问控制，通过分发加密密钥和管理安全策略数据库（SPD，第4.4.1节）规定的流量来实施。
These protocols may be applied individually or in combination with each other to provide IPv4 and IPv6 security services. However, most security requirements can be met through the use of ESP by itself. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode, AH and ESP provide protection primarily for
这些协议可以单独应用，也可以相互结合应用，以提供IPv4和IPv6安全服务。然而，大多数安全要求可以通过ESP本身的使用来满足。每个协议支持两种使用模式：传输模式和隧道模式。在运输模式下，AH和ESP主要为以下设备提供保护：
next layer protocols; in tunnel mode, AH and ESP are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4.1.
下一层协议；在隧道模式下，AH和ESP应用于隧道IP数据包。第4.1节讨论了两种模式之间的差异。
IPsec allows the user (or system administrator) to control the granularity at which a security service is offered. For example, one can create a single encrypted tunnel to carry all the traffic between two security gateways, or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec, through the SPD management paradigm, incorporates facilities for specifying:
IPsec允许用户（或系统管理员）控制提供安全服务的粒度。例如，可以创建一个加密隧道来承载两个安全网关之间的所有流量，或者可以为通过这些网关通信的每对主机之间的每个TCP连接创建一个单独的加密隧道。IPsec通过SPD管理模式，包含用于指定以下各项的功能：
o which security protocol (AH or ESP) to employ, the mode (transport or tunnel), security service options, what cryptographic algorithms to use, and in what combinations to use the specified protocols and services, and
o 使用哪种安全协议（AH或ESP）、模式（传输或隧道）、安全服务选项、使用何种加密算法，以及以何种组合使用指定的协议和服务，以及
o the granularity at which protection should be applied.
o 应用保护的粒度。
Because most of the security services provided by IPsec require the use of cryptographic keys, IPsec relies on a separate set of mechanisms for putting these keys in place. This document requires support for both manual and automated distribution of keys. It specifies a specific public-key based approach (IKEv2 [Kau05]) for automated key management, but other automated key distribution techniques MAY be used.
由于IPsec提供的大多数安全服务都需要使用加密密钥，IPsec依赖于一组单独的机制来放置这些密钥。本文档要求支持手动和自动分发密钥。它为自动密钥管理指定了一种特定的基于公钥的方法（IKEv2[Kau05]），但也可以使用其他自动密钥分发技术。
Note: This document mandates support for several features for which support is available in IKEv2 but not in IKEv1, e.g., negotiation of an SA representing ranges of local and remote ports or negotiation of multiple SAs with the same selectors. Therefore, this document assumes use of IKEv2 or a key and security association management system with comparable features.
注意：本文档要求支持若干功能，这些功能在IKEv2中可用，但在IKEv1中不可用，例如，代表本地和远程端口范围的SA协商或使用相同选择器协商多个SA。因此，本文件假设使用IKEv2或具有类似功能的密钥和安全关联管理系统。
There are many ways in which IPsec may be implemented in a host, or in conjunction with a router or firewall to create a security gateway, or as an independent security device.
IPsec可以通过多种方式在主机中实现，或者与路由器或防火墙结合来创建安全网关，或者作为独立的安全设备。
a. IPsec may be integrated into the native IP stack. This requires access to the IP source code and is applicable to both hosts and security gateways, although native host implementations benefit the most from this strategy, as explained later (Section 4.4.1, paragraph 6; Section 4.4.1.1, last paragraph).
a. IPsec可以集成到本机IP堆栈中。这需要访问IP源代码，并且适用于主机和安全网关，尽管本机主机实现从该策略中受益最大，如下文所述（第4.4.1节，第6段；第4.4.1.1节，最后一段）。
b. In a "bump-in-the-stack" (BITS) implementation, IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Source code access for the IP stack is not required in this context, making this implementation approach appropriate for use with legacy systems. This approach, when it is adopted, is usually employed in hosts.
b. 在“bump-In-the-stack”（BITS）实现中，IPsec在本地IP和本地网络驱动程序之间的现有IP协议栈实现的“下面”实现。在这种情况下，不需要对IP堆栈进行源代码访问，因此这种实现方法适用于遗留系统。当采用这种方法时，通常在主机中使用。
c. The use of a dedicated, inline security protocol processor is a common design feature of systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway. Usually, the BITW device is itself IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but in supporting a router or firewall, it must operate like a security gateway.
c. 专用内联安全协议处理器的使用是军用系统以及一些商用系统的常见设计特征。它有时被称为“线内凹凸”（BITW）实现。此类实现可设计为服务于主机或网关。通常，BITW设备本身是IP可寻址的。当支持单个主机时，它可能非常类似于BITS实现，但在支持路由器或防火墙时，它必须像安全网关一样运行。
This document often talks in terms of use of IPsec by a host or a security gateway, without regard to whether the implementation is native, BITS, or BITW. When the distinctions among these implementation options are significant, the document makes reference to specific implementation approaches.
本文档通常讨论主机或安全网关对IPsec的使用，而不考虑实现是本机、BITS还是BITW。当这些实施方案之间的差别很大时，本文件提到具体的实施办法。
A host implementation of IPsec may appear in devices that might not be viewed as "hosts". For example, a router might employ IPsec to protect routing protocols (e.g., BGP) and management functions (e.g., Telnet), without affecting subscriber traffic traversing the router. A security gateway might employ separate IPsec implementations to protect its management traffic and subscriber traffic. The architecture described in this document is very flexible. For example, a computer with a full-featured, compliant, native OS IPsec implementation should be capable of being configured to protect resident (host) applications and to provide security gateway protection for traffic traversing the computer. Such configuration would make use of the forwarding tables and the SPD selection function described in Sections 5.1 and 5.2.
IPsec的主机实现可能出现在不被视为“主机”的设备中。例如，路由器可以使用IPsec来保护路由协议（例如BGP）和管理功能（例如Telnet），而不影响通过路由器的订户流量。安全网关可以使用单独的IPsec实现来保护其管理流量和订户流量。本文档中描述的体系结构非常灵活。例如，具有全功能、兼容的本机OS IPsec实现的计算机应能够配置为保护驻留（主机）应用程序，并为通过计算机的流量提供安全网关保护。这种配置将利用转发表和第5.1节和第5.2节中描述的SPD选择功能。
This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both AH and ESP. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs, and a major function of IKE is the establishment and maintenance of SAs. All implementations of AH or ESP MUST support the concept of an SA as described below. The remainder of this
本节定义了所有IPv6实现以及实现AH、ESP或AH和ESP的IPv4实现的安全关联管理要求。“安全关联”（SA）的概念是IPsec的基础。AH和ESP都使用SAs，IKE的主要功能是建立和维护SAs。AH或ESP的所有实现必须支持SA的概念，如下所述。剩下的部分
section describes various aspects of SA management, defining required characteristics for SA policy management and SA management techniques.
第节描述了SA管理的各个方面，定义了SA策略管理和SA管理技术所需的特征。
An SA is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection are applied to a traffic stream, then two SAs must be created and coordinated to effect protection through iterated application of the security protocols. To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement.
SA是一个单一的“连接”，为其承载的流量提供安全服务。通过使用AH或ESP向SA提供安全服务，但不能同时使用两者。如果AH和ESP保护都应用于流量流，则必须创建并协调两个SA，以通过安全协议的迭代应用实现保护。为了确保两个启用IPsec的系统之间的典型双向通信安全，需要一对SAs（每个方向一个）。IKE显式地创建SA对，以识别这种常见的使用需求。
For an SA used to carry unicast traffic, the Security Parameters Index (SPI) by itself suffices to specify an SA. (For information on the SPI, see Appendix A and the AH and ESP specifications [Ken05b, Ken05a].) However, as a local matter, an implementation may choose to use the SPI in conjunction with the IPsec protocol type (AH or ESP) for SA identification. If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
对于用于承载单播流量的SA，安全参数索引（SPI）本身足以指定SA。（有关SPI的信息，请参阅附录A以及AH和ESP规范[Ken05b，Ken05a]）但是，作为本地事项，实现可以选择将SPI与IPsec协议类型（AH或ESP）结合使用，以识别SA。如果IPsec实现支持多播，则必须使用以下算法支持多播SAs，以便将入站IPsec数据报映射到SAs。仅支持单播通信的实现不需要实现此解复用算法。
In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that constitute the group. Consequently, it is possible that a GSA and a unicast SA can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
在许多安全多播体系结构中，例如[RFC3740]，中央组控制器/密钥服务器单方面分配组安全关联（GSA）的SPI。该SPI分配不与组成该组的各个终端系统中的密钥管理（如IKE）子系统协商或协调。因此，GSA和单播SA可能同时使用相同的SPI。支持多播的IPsec实现必须正确地解复用入站流量，即使在SPI冲突的情况下也是如此。
Each entry in the SA Database (SAD) (Section 4.4.2) must indicate whether the SA lookup makes use of the destination IP address, or the destination and source IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination address, or destination and source address (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
SA数据库（SAD）（第4.4.2节）中的每个条目必须指明SA查找是使用目标IP地址，还是使用SPI之外的目标和源IP地址。对于多播SA，协议字段不用于SA查找。对于每个受IPsec保护的入站数据包，实现必须对SAD进行搜索，以便找到与“最长”SA标识符匹配的条目。在此上下文中，如果两个或多个SAD条目基于SPI值匹配，则也基于目标地址或目标和源地址（如SAD条目中所示）匹配的条目是“最长”匹配。这意味着SAD搜索的逻辑顺序如下：
1. Search the SAD for a match on the combination of SPI, destination address, and source address. If an SAD entry matches, then process the inbound packet with that matching SAD entry. Otherwise, proceed to step 2.
1. 在SAD中搜索SPI、目标地址和源地址组合的匹配项。如果SAD条目匹配，则使用匹配的SAD条目处理入站数据包。否则，继续执行步骤2。
2. Search the SAD for a match on both SPI and destination address. If the SAD entry matches, then process the inbound packet with that matching SAD entry. Otherwise, proceed to step 3.
2. 在SAD中搜索SPI和目标地址的匹配项。如果SAD条目匹配，则使用匹配的SAD条目处理入站数据包。否则，继续执行步骤3。
3. Search the SAD for a match on only SPI if the receiver has chosen to maintain a single SPI space for AH and ESP, and on both SPI and protocol, otherwise. If an SAD entry matches, then process the inbound packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event.
3. 如果接收器选择为AH和ESP保留单个SPI空间，则仅在SPI上搜索SAD，否则在SPI和协议上搜索SAD。如果SAD条目匹配，则使用匹配的SAD条目处理入站数据包。否则，丢弃数据包并记录可审核事件。
In practice, an implementation may choose any method (or none at all) to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list could be kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers could be sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.
在实践中，实现可以选择任何方法（或根本不选择任何方法）来加速此搜索，尽管其外部可见的行为在功能上必须等同于按上述顺序搜索SAD。例如，基于软件的实现可以通过SPI索引到哈希表中。可以对每个哈希表bucket的链接列表中的SAD条目进行排序，以使那些SA标识符最长的SAD条目首先出现在该链接列表中。可以对具有最短SA标识符的SAD条目进行排序，以便它们是链接列表中的最后一个条目。基于硬件的实现可能能够使用常用的三值内容寻址存储器（TCAM）功能，从本质上实现最长匹配搜索。
The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.
将入站IPsec通信映射到SAs时是否需要源地址和目标地址匹配的指示必须设置为手动SA配置的副作用，或使用SA管理协议（例如IKE或组解释域（GDOI））通过协商进行设置[RFC3547]。通常，源特定多播（SSM）[HC03]组使用由SPI、目标多播地址和源地址组成的三元组SA标识符。任何源多播组SA只需要SPI和目标多播地址作为标识符。
If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver,
如果在同一SA上发送不同类别的流量（通过区分服务码点（DSCP）位[NIBLBAB98]、[Gro02]来区分），并且如果接收器采用AH和ESP中可用的可选反重放功能，由于此功能使用的窗口机制，这可能导致不适当地丢弃低优先级数据包。因此，发送方应该将不同类别但具有相同选择器值的流量放在不同的SA上，以适当地支持服务质量（QoS）。为此，IPsec实现必须允许在给定发送方和接收方之间建立和维护多个SA，
with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism.
使用相同的选择器。这些并行SA之间支持QoS的流量分布由发送方在本地确定，而不是由IKE协商。接收器必须处理来自不同SA的数据包，不得有任何影响。这些要求适用于运输和隧道模式SAs。对于隧道模式SAs，相关DSCP值出现在内部IP报头中。在传输模式下，DSCP值可能会在路由过程中更改，但这不会导致IPsec处理方面的问题，因为该值不用于SA选择，并且不得作为SA/数据包验证的一部分进行检查。然而，如果在SA中发生显著的分组重新排序，例如，由于路由中DSCP值的改变，这可能触发由于应用了反重放机制而被接收机丢弃的分组。
DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", as that term in used in this architecture, the sender will need a mechanism to direct packets with a given (set of) DSCP values to the appropriate SA. This mechanism might be termed a "classifier".
讨论：尽管DSCP[NIBLBAB98，Gro02]和显式拥塞通知（ECN）[RaFlBl01]字段不是“选择器”，正如该体系结构中使用的术语一样，发送方将需要一种机制将具有给定（一组）DSCP值的数据包定向到适当的SA。这种机制可以称为“分类器”。
As noted above, two types of SAs are defined: transport mode and tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose to require that both SAs in a pair be of the same mode, transport or tunnel.
如上所述，定义了两种类型的SA：传输模式和隧道模式。IKE创建SA对，因此为了简单起见，我们选择要求一对中的两个SA具有相同的模式、传输或隧道。
A transport mode SA is an SA typically employed between a pair of hosts to provide end-to-end security services. When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host. In the case where transport mode is used between security gateways or between a security gateway and a host, transport mode may be used to support in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing [ToEgWa04]) over transport mode SAs. To clarify, the use of transport mode by an intermediate system (e.g., a security gateway) is permitted only when applied to packets whose source address (for outbound packets) or destination address (for inbound packets) is an address belonging to the intermediate system itself. The access control functions that are an important part of IPsec are significantly limited in this context, as they cannot be applied to the end-to-end headers of the packets that traverse a transport mode SA used in this fashion. Thus, this way of using transport mode should be evaluated carefully before being employed in a specific context.
传输模式SA是通常在一对主机之间用于提供端到端安全服务的SA。当需要沿路径的两个中间系统之间的安全性时（相对于IPsec的端到端使用），可以在安全网关之间或安全网关与主机之间使用传输模式。在安全网关之间或安全网关与主机之间使用传输模式的情况下，传输模式可用于支持传输模式SAs上的IP内隧道（例如，IP-In-IP[Per96]或通用路由封装（GRE）隧道[FaLiHaMeTr00]或动态路由[ToEgWa04]）。为了澄清，只有当源地址（对于出站数据包）或目的地址（对于入站数据包）是属于中间系统本身的地址时，才允许中间系统（例如，安全网关）使用传输模式。在此上下文中，作为IPsec重要部分的访问控制功能受到很大限制，因为它们不能应用于以这种方式使用的传输模式SA中的数据包的端到端头。因此，这种使用运输方式的方式在用于特定环境之前应仔细评估。
In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any next layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and selected extension headers, but may appear before or after destination options; it MUST appear before next layer protocols (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)). In the case of ESP, a transport mode SA provides security services only for these next layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header preceding it, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification [Ken05b].
在IPv4中，传输模式安全协议头立即出现在IP头和任何选项之后，并出现在任何下一层协议（如TCP或UDP）之前。在IPv6中，安全协议头显示在基本IP头和所选扩展头之后，但可能出现在目标选项之前或之后；它必须出现在下一层协议（例如TCP、UDP、流控制传输协议（SCTP））之前。对于ESP，传输模式SA仅为这些下一层协议提供安全服务，而不为IP头或ESP头之前的任何扩展头提供安全服务。在AH的情况下，保护还扩展到它前面的IP报头的选定部分、扩展报头的选定部分和选定选项（包含在IPv4报头、IPv6逐跳扩展报头或IPv6目标扩展报头中）。有关AH提供的覆盖范围的更多详细信息，请参阅AH规范[Ken05b]。
A tunnel mode SA is essentially an SA applied to an IP tunnel, with the access controls applied to the headers of the traffic inside the tunnel. Two hosts MAY establish a tunnel mode SA between themselves. Aside from the two exceptions below, whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus, an SA between two security gateways is typically a tunnel mode SA, as is an SA between a host and a security gateway. The two exceptions are as follows.
隧道模式SA本质上是应用于IP隧道的SA，访问控制应用于隧道内流量的报头。两台主机可以在它们之间建立隧道模式SA。除了下面的两个例外，只要安全关联的任意一端是安全网关，SA都必须是隧道模式。因此，两个安全网关之间的SA通常是隧道模式SA，主机和安全网关之间的SA也是如此。这两个例外情况如下。
o Where traffic is destined for a security gateway, e.g., Simple Network Management Protocol (SNMP) commands, the security gateway is acting as a host and transport mode is allowed. In this case, the SA terminates at a host (management) function within a security gateway and thus merits different treatment.
o 当通信量发送至安全网关（例如，简单网络管理协议（SNMP）命令）时，安全网关充当主机，允许使用传输模式。在这种情况下，SA在安全网关内的主机（管理）功能处终止，因此需要不同的处理。
o As noted above, security gateways MAY support a transport mode SA to provide security for IP traffic between two intermediate systems along a path, e.g., between a host and a security gateway or between two security gateways.
o 如上所述，安全网关可支持传输模式SA，以便为沿路径的两个中间系统之间（例如，主机和安全网关之间或两个安全网关之间）的IP流量提供安全性。
Several concerns motivate the use of tunnel mode for an SA involving a security gateway. For example, if there are multiple paths (e.g., via different security gateways) to the same destination behind a security gateway, it is important that an IPsec packet be sent to the security gateway with which the SA was negotiated. Similarly, a packet that might be fragmented en route must have all the fragments delivered to the same IPsec instance for reassembly prior to cryptographic processing. Also, when a fragment is processed by IPsec and transmitted, then fragmented en route, it is critical that there be inner and outer headers to retain the fragmentation state data for the pre- and post-IPsec packet formats. Hence there are several reasons for employing tunnel mode when either end of an SA is
有几个问题促使对涉及安全网关的SA使用隧道模式。例如，如果有多条路径（例如，通过不同的安全网关）到达安全网关后面的同一目的地，则必须将IPsec数据包发送到与SA协商的安全网关。类似地，可能在路由中被分段的数据包必须在加密处理之前将所有片段交付给同一IPsec实例进行重新组装。此外，当一个片段由IPsec处理并传输，然后在路由中分段时，关键是要有内部和外部报头来保留IPsec前后数据包格式的分段状态数据。因此，当SA的任意一端被激活时，采用隧道模式有几个原因
a security gateway. (Use of an IP-in-IP tunnel in conjunction with transport mode can also address these fragmentation issues. However, this configuration limits the ability of IPsec to enforce access control policies on traffic.)
安全网关。（将IP-in-IP隧道与传输模式结合使用也可以解决这些碎片问题。但是，此配置限制了IPsec对流量实施访问控制策略的能力。）
Note: AH and ESP cannot be applied using transport mode to IPv4 packets that are fragments. Only tunnel mode can be employed in such cases. For IPv6, it would be feasible to carry a plaintext fragment on a transport mode SA; however, for simplicity, this restriction also applies to IPv6 packets. See Section 7 for more details on handling plaintext fragments on the protected side of the IPsec barrier.
注意：AH和ESP不能使用传输模式应用于作为片段的IPv4数据包。在这种情况下，只能采用隧道模式。对于IPv6，在传输模式SA上携带明文片段是可行的；然而，为简单起见，此限制也适用于IPv6数据包。有关在IPsec屏障的受保护端处理明文片段的更多详细信息，请参见第7节。
For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing source and destination, plus an "inner" IP header that specifies the (apparently) ultimate source and destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as next layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header.
对于隧道模式SA，有一个指定IPsec处理源和目标的“外部”IP头，还有一个指定（显然）数据包的最终源和目标的“内部”IP头。安全协议头显示在外部IP头之后，内部IP头之前。如果在隧道模式中使用AH，则外部IP报头的部分被提供保护（如上所述），以及所有隧道IP分组（即，所有内部IP报头被保护，以及下一层协议）。如果使用ESP，则仅对隧道数据包提供保护，而不对外部报头提供保护。
In summary,
总之，
a) A host implementation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts.
a) IPsec的主机实现必须同时支持传输和隧道模式。对于主机的本机、BITS和BITW实现来说，这是正确的。
b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path.
b) 安全网关必须支持隧道模式，并且可以支持传输模式。如果它支持传输模式，则仅当安全网关充当主机时才应使用该模式，例如，用于网络管理，或在路径上的两个中间系统之间提供安全性。
The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and the election of optional services within the protocol.
SA提供的安全服务集取决于选择的安全协议、SA模式、SA的端点以及协议中可选服务的选择。
For example, both AH and ESP offer integrity and authentication services, but the coverage differs for each protocol and differs for transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6 extension header must be protected en route between sender and receiver, AH can provide this service, except for IP or extension headers that may change in a fashion not predictable by the sender.
例如，AH和ESP都提供完整性和身份验证服务，但每个协议的覆盖范围不同，传输模式和隧道模式也不同。如果在发送方和接收方之间的路由中必须保护IPv4选项或IPv6扩展头的完整性，AH可以提供此服务，但IP或扩展头可能以发送方无法预测的方式更改的情况除外。
However, the same security may be achieved in some contexts by applying ESP to a tunnel carrying a packet.
然而，在某些情况下，通过将ESP应用于承载数据包的隧道，可以实现相同的安全性。
The granularity of access control provided is determined by the choice of the selectors that define each SA. Moreover, the authentication means employed by IPsec peers, e.g., during creation of an IKE (vs. child) SA also affects the granularity of the access control afforded.
提供的访问控制粒度由定义每个SA的选择器的选择决定。此外，IPsec对等方使用的认证手段（例如，在创建IKE（vs.child）SA期间）也影响所提供的访问控制的粒度。
If confidentiality is selected, then an ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination. Moreover, ESP payload padding also can be invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Note that fine-granularity SAs generally are more vulnerable to traffic analysis than coarse-granularity ones that are carrying traffic from many subscribers.
如果选择了机密性，则两个安全网关之间的ESP（隧道模式）SA可以提供部分流量机密性。隧道模式的使用允许对内部IP报头进行加密，从而隐藏（最终）流量源和目的地的身份。此外，还可以调用ESP有效负载填充来隐藏数据包的大小，从而进一步隐藏流量的外部特征。当在拨号上下文中为移动用户分配动态IP地址，并建立（隧道模式）ESP SA到公司防火墙（充当安全网关）时，可以提供类似的流量保密服务。请注意，细粒度SA通常比承载来自多个订户的流量的粗粒度SA更容易受到流量分析的影响。
Note: A compliant implementation MUST NOT allow instantiation of an ESP SA that employs both NULL encryption and no integrity algorithm. An attempt to negotiate such an SA is an auditable event by both initiator and responder. The audit log entry for this event SHOULD include the current date/time, local IKE IP address, and remote IKE IP address. The initiator SHOULD record the relevant SPD entry.
注意：兼容的实现不得允许实例化同时使用空加密和无完整性算法的ESP SA。协商此类SA的尝试是发起者和响应者都可审核的事件。此事件的审核日志项应包括当前日期/时间、本地IKE IP地址和远程IKE IP地址。发起人应记录相关SPD条目。
This document does not require support for nested security associations or for what RFC 2401 [RFC2401] called "SA bundles". These features still can be effected by appropriate configuration of both the SPD and the local forwarding functions (for inbound and outbound traffic), but this capability is outside of the IPsec module and thus the scope of this specification. As a result, management of nested/bundled SAs is potentially more complex and less assured than under the model implied by RFC 2401 [RFC2401]. An implementation that provides support for nested SAs SHOULD provide a management interface that enables a user or administrator to express the nesting requirement, and then create the appropriate SPD entries and forwarding table entries to effect the requisite processing. (See Appendix E for an example of how to configure nested SAs.)
本文档不需要支持嵌套安全关联或RFC 2401[RFC2401]所称的“SA捆绑包”。这些功能仍然可以通过适当配置SPD和本地转发功能（用于入站和出站流量）来实现，但此功能不在IPsec模块的范围内，因此不在本规范的范围内。因此，与RFC 2401[RFC2401]所暗示的模型相比，嵌套/捆绑SA的管理可能更复杂，也更不可靠。支持嵌套SA的实现应提供一个管理界面，使用户或管理员能够表达嵌套需求，然后创建适当的SPD条目和转发表条目以实现必要的处理。（有关如何配置嵌套SAs的示例，请参见附录E。）
Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to IPsec functionality, in support of these interoperability and functionality goals. The model described below is nominal; implementations need not match details of this model as presented, but the external behavior of implementations MUST correspond to the externally observable characteristics of this model in order to be compliant.
IPsec实现中与处理IP流量相关的许多细节主要是本地事务，不受标准化的约束。但是，必须对处理的某些外部方面进行标准化，以确保互操作性，并提供对IPsec的生产性使用至关重要的最低管理能力。本节描述了处理与IPsec功能相关的IP流量的通用模型，以支持这些互操作性和功能目标。以下描述的模型为标称模型；实现不需要与所呈现的该模型的细节相匹配，但实现的外部行为必须与该模型的外部可观察特征相对应，以符合要求。
There are three nominal databases in this model: the Security Policy Database (SPD), the Security Association Database (SAD), and the Peer Authorization Database (PAD). The first specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host or security gateway (Section 4.4.1). The second database contains parameters that are associated with each established (keyed) SA (Section 4.4.2). The third database, the PAD, provides a link between an SA management protocol (such as IKE) and the SPD (Section 4.4.3).
该模型中有三个标称数据库：安全策略数据库（SPD）、安全关联数据库（SAD）和对等授权数据库（PAD）。第一个指定用于确定主机或安全网关所有入站或出站IP流量的处置的策略（第4.4.1节）。第二个数据库包含与每个已建立（键控）SA相关的参数（第4.4.2节）。第三个数据库PAD提供SA管理协议（如IKE）和SPD（第4.4.3节）之间的链接。
Multiple Separate IPsec Contexts
多个独立的IPsec上下文
If an IPsec implementation acts as a security gateway for multiple subscribers, it MAY implement multiple separate IPsec contexts. Each context MAY have and MAY use completely independent identities, policies, key management SAs, and/or IPsec SAs. This is for the most part a local implementation matter. However, a means for associating inbound (SA) proposals with local contexts is required. To this end, if supported by the key management protocol in use, context identifiers MAY be conveyed from initiator to responder in the signaling messages, with the result that IPsec SAs are created with a binding to a particular context. For example, a security gateway that provides VPN service to multiple customers will be able to associate each customer's traffic with the correct VPN.
如果IPsec实现充当多个订阅者的安全网关，则它可以实现多个单独的IPsec上下文。每个上下文可能具有并可能使用完全独立的标识、策略、密钥管理SA和/或IPsec SA。这在很大程度上是一个地方实施问题。但是，需要一种将入站（SA）方案与本地上下文关联的方法。为此，如果使用中的密钥管理协议支持，则可以在信令消息中将上下文标识符从发起方传送到响应方，从而使用与特定上下文的绑定创建IPsec sa。例如，向多个客户提供VPN服务的安全网关将能够将每个客户的流量与正确的VPN相关联。
Forwarding vs Security Decisions
转发与安全决策
The IPsec model described here embodies a clear separation between forwarding (routing) and security decisions, to accommodate a wide range of contexts where IPsec may be employed. Forwarding may be trivial, in the case where there are only two interfaces, or it may be complex, e.g., if the context in which IPsec is implemented
这里描述的IPsec模型体现了转发（路由）和安全决策之间的明确分离，以适应可能使用IPsec的广泛上下文。在只有两个接口的情况下，转发可能是微不足道的，也可能是复杂的，例如，如果在其中实现IPsec的上下文中
employs a sophisticated forwarding function. IPsec assumes only that outbound and inbound traffic that has passed through IPsec processing is forwarded in a fashion consistent with the context in which IPsec is implemented. Support for nested SAs is optional; if required, it requires coordination between forwarding tables and SPD entries to cause a packet to traverse the IPsec boundary more than once.
采用先进的转发功能。IPsec仅假设通过IPsec处理的出站和入站流量以与实现IPsec的上下文一致的方式转发。支持嵌套SAs是可选的；如果需要，它需要转发表和SPD条目之间的协调，以使数据包多次穿越IPsec边界。
"Local" vs "Remote"
“本地”与“远程”
In this document, with respect to IP addresses and ports, the terms "Local" and "Remote" are used for policy rules. "Local" refers to the entity being protected by an IPsec implementation, i.e., the "source" address/port of outbound packets or the "destination" address/port of inbound packets. "Remote" refers to a peer entity or peer entities. The terms "source" and "destination" are used for packet header fields.
在本文档中，关于IP地址和端口，术语“本地”和“远程”用于策略规则。“本地”是指受IPsec实现保护的实体，即出站数据包的“源”地址/端口或入站数据包的“目的”地址/端口。“远程”指对等实体或对等实体。术语“源”和“目的地”用于数据包头字段。
"Non-initial" vs "Initial" Fragments
“非初始”与“初始”片段
Throughout this document, the phrase "non-initial fragments" is used to mean fragments that do not contain all of the selector values that may be needed for access control (e.g., they might not contain Next Layer Protocol, source and destination ports, ICMP message type/code, Mobility Header type). And the phrase "initial fragment" is used to mean a fragment that contains all the selector values needed for access control. However, it should be noted that for IPv6, which fragment contains the Next Layer Protocol and ports (or ICMP message type/code or Mobility Header type [Mobip]) will depend on the kind and number of extension headers present. The "initial fragment" might not be the first fragment, in this context.
在本文档中，短语“非初始片段”用于表示不包含访问控制可能需要的所有选择器值的片段（例如，它们可能不包含下一层协议、源端口和目标端口、ICMP消息类型/代码、移动头类型）。短语“initialfragment”用于表示包含访问控制所需的所有选择器值的片段。但是，应该注意，对于IPv6，哪个片段包含下一层协议和端口（或ICMP消息类型/代码或移动头类型[Mobip]）将取决于存在的扩展头的种类和数量。在此上下文中，“初始片段”可能不是第一个片段。
An SA is a management construct used to enforce security policy for traffic crossing the IPsec boundary. Thus, an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section specifies minimum management functionality that must be provided, to allow a user or system administrator to control whether and how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. The SPD, or relevant caches, must be consulted during the processing of all traffic (inbound and outbound), including traffic not protected by IPsec, that traverses the IPsec boundary. This includes IPsec management traffic such as IKE. An IPsec
SA是一种管理结构，用于对跨越IPsec边界的流量强制执行安全策略。因此，SA处理的一个基本元素是一个底层安全策略数据库（SPD），它指定要向IP数据报提供哪些服务以及以何种方式提供。数据库的形式及其接口不在本规范的范围内。但是，本节规定了必须提供的最低管理功能，以允许用户或系统管理员控制是否以及如何将IPsec应用于主机传输或接收的流量或传输安全网关。在处理所有通过IPsec边界的流量（入站和出站），包括未受IPsec保护的流量时，必须咨询SPD或相关缓存。这包括IPsec管理流量，如IKE。IPsec协议
implementation MUST have at least one SPD, and it MAY support multiple SPDs, if appropriate for the context in which the IPsec implementation operates. There is no requirement to maintain SPDs on a per-interface basis, as was specified in RFC 2401 [RFC2401]. However, if an implementation supports multiple SPDs, then it MUST include an explicit SPD selection function that is invoked to select the appropriate SPD for outbound traffic processing. The inputs to this function are the outbound packet and any local metadata (e.g., the interface via which the packet arrived) required to effect the SPD selection function. The output of the function is an SPD identifier (SPD-ID).
实施必须至少有一个SPD，并且它可以支持多个SPD（如果适用于IPsec实施操作的上下文）。按照RFC 2401[RFC2401]的规定，无需按照每个接口维护SPD。但是，如果一个实现支持多个SPD，那么它必须包含一个显式SPD选择函数，该函数被调用以选择出站流量处理的适当SPD。此功能的输入是出站数据包和实现SPD选择功能所需的任何本地元数据（例如，数据包到达的接口）。该函数的输出是一个SPD标识符（SPD-ID）。
The SPD is an ordered database, consistent with the use of Access Control Lists (ACLs) or packet filters in firewalls, routers, etc. The ordering requirement arises because entries often will overlap due to the presence of (non-trivial) ranges as values for selectors. Thus, a user or administrator MUST be able to order the entries to express a desired access control policy. There is no way to impose a general, canonical order on SPD entries, because of the allowed use of wildcards for selector values and because the different types of selectors are not hierarchically related.
SPD是一个有序的数据库，与防火墙、路由器等中访问控制列表（ACL）或数据包过滤器的使用相一致。之所以需要排序，是因为存在（非平凡）范围作为选择器的值，条目通常会重叠。因此，用户或管理员必须能够对条目进行排序，以表示所需的访问控制策略。由于允许对选择器值使用通配符，并且由于不同类型的选择器没有层次关系，因此无法对SPD条目施加常规的规范顺序。
Processing Choices: DISCARD, BYPASS, PROTECT
处理选项：丢弃、绕过、保护
An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The first choice refers to traffic that is not allowed to traverse the IPsec boundary (in the specified direction). The second choice refers to traffic that is allowed to cross the IPsec boundary without IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security protocols to be employed, their mode, security service options, and the cryptographic algorithms to be used.
SPD必须区分提供IPsec保护的流量和允许绕过IPsec的流量。这适用于发送方应用的IPsec保护和接收方必须存在的IPsec保护。对于任何出站或入站数据报，有三种处理选择：放弃、绕过IPsec或使用IPsec进行保护。第一个选项是指不允许（在指定方向）穿越IPsec边界的流量。第二种选择是指允许在没有IPsec保护的情况下跨越IPsec边界的流量。第三种选择是指提供IPsec保护的流量，对于此类流量，SPD必须指定要使用的安全协议、模式、安全服务选项以及要使用的加密算法。
SPD-S, SPD-I, SPD-O
SPD-S，SPD-I，SPD-O
An SPD is logically divided into three pieces. The SPD-S (secure traffic) contains entries for all traffic subject to IPsec protection. SPD-O (outbound) contains entries for all outbound traffic that is to be bypassed or discarded. SPD-I (inbound) is applied to inbound traffic that will be bypassed or discarded. All three of these can be decorrelated (with the exception noted above for native host implementations) to facilitate caching. If
SPD在逻辑上分为三部分。SPD-S（安全流量）包含受IPsec保护的所有流量的条目。SPD-O（出站）包含所有要绕过或丢弃的出站流量的条目。SPD-I（入站）应用于将被绕过或丢弃的入站流量。这三者都可以解相关（上面提到的本机主机实现的例外情况除外），以便于缓存。如果
an IPsec implementation supports only one SPD, then the SPD consists of all three parts. If multiple SPDs are supported, some of them may be partial, e.g., some SPDs might contain only SPD-I entries, to control inbound bypassed traffic on a per-interface basis. The split allows SPD-I to be consulted without having to consult SPD-S, for such traffic. Since the SPD-I is just a part of the SPD, if a packet that is looked up in the SPD-I cannot be matched to an entry there, then the packet MUST be discarded. Note that for outbound traffic, if a match is not found in SPD-S, then SPD-O must be checked to see if the traffic should be bypassed. Similarly, if SPD-O is checked first and no match is found, then SPD-S must be checked. In an ordered, non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O are interleaved. So there is one lookup in the SPD.
IPsec实现只支持一个SPD，然后SPD由所有三部分组成。如果支持多个SPD，其中一些SPD可能是部分的，例如，一些SPD可能只包含SPD-I条目，以控制每个接口的入站旁路流量。拆分允许针对此类流量咨询SPD-I，而无需咨询SPD-S。由于SPD-I只是SPD的一部分，如果在SPD-I中查找的数据包无法与其中的条目匹配，则必须丢弃该数据包。请注意，对于出站流量，如果在SPD-S中未找到匹配项，则必须检查SPD-O以查看是否应绕过该流量。同样，如果先检查SPD-O，但未找到匹配项，则必须检查SPD-S。在有序、不相关的SPD中，SPD-S、SPD-I和SPD-O的条目是交错的。因此，在SPD中有一个查找。
SPD Entries
SPD条目
Each SPD entry specifies packet disposition as BYPASS, DISCARD, or PROTECT. The entry is keyed by a list of one or more selectors. The SPD contains an ordered list of these entries. The required selector types are defined in Section 4.4.1.1. These selectors are used to define the granularity of the SAs that are created in response to an outbound packet or in response to a proposal from a peer. The detailed structure of an SPD entry is described in Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that matches anything that is otherwise unmatched, and discards it.
每个SPD条目将数据包处理指定为旁路、丢弃或保护。该条目由一个或多个选择器的列表键入。SPD包含这些条目的有序列表。第4.4.1.1节定义了所需的选择器类型。这些选择器用于定义为响应出站数据包或响应来自对等方的建议而创建的SA的粒度。第4.4.1.2节描述了SPD入口的详细结构。每一个SPD都应该有一个名义上的最终条目，该条目匹配任何其他不匹配的条目，并将其丢弃。
The SPD MUST permit a user or administrator to specify policy entries as follows:
SPD必须允许用户或管理员指定策略条目，如下所示：
- SPD-I: For inbound traffic that is to be bypassed or discarded, the entry consists of the values of the selectors that apply to the traffic to be bypassed or discarded.
- SPD-I：对于要绕过或丢弃的入站流量，条目由应用于要绕过或丢弃的流量的选择器的值组成。
- SPD-O: For outbound traffic that is to be bypassed or discarded, the entry consists of the values of the selectors that apply to the traffic to be bypassed or discarded.
- SPD-O：对于要绕过或丢弃的出站流量，条目由应用于要绕过或丢弃的流量的选择器的值组成。
- SPD-S: For traffic that is to be protected using IPsec, the entry consists of the values of the selectors that apply to the traffic to be protected via AH or ESP, controls on how to create SAs based on these selectors, and the parameters needed to effect this protection (e.g., algorithms, modes, etc.). Note that an SPD-S entry also contains information such as "populate from packet" (PFP) flag (see paragraphs below on "How To Derive the Values for an SAD entry") and bits indicating whether the
- SPD-S：对于要使用IPsec进行保护的流量，该条目包括通过AH或ESP应用于要保护的流量的选择器的值、关于如何基于这些选择器创建SA的控制以及实现该保护所需的参数（例如，算法、模式等）。请注意，SPD-S条目还包含诸如“从数据包填充”（PFP）标志（请参阅下面关于“如何导出SAD条目的值”的段落）和指示
SA lookup makes use of the local and remote IP addresses in addition to the SPI (see AH [Ken05b] or ESP [Ken05a] specifications).
SA查找除使用SPI外，还使用本地和远程IP地址（请参阅AH[Ken05b]或ESP[Ken05a]规范）。
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, for ICMP, there is often no such bi-directional authorization requirement. Nonetheless, for the sake of uniformity and simplicity, SPD entries for ICMP are specified in the same way as for other protocols. Note also that for ICMP, Mobility Header, and non-initial fragments, there are no port fields in these packets. ICMP has message type and code and Mobility Header has mobility header type. Thus, SPD entries have provisions for expressing access controls appropriate for these protocols, in lieu of the normal port field controls. For bypassed or discarded traffic, separate inbound and outbound entries are supported, e.g., to permit unidirectional flows if required.
对于受IPsec保护的流量，SPD条目中的本地和远程地址和端口将交换以表示方向性，这与IKE约定一致。通常，IPsec所处理的协议具有要求具有翻转本地/远程IP地址的对称SA的特性。然而，对于ICMP，通常没有这种双向授权要求。尽管如此，为了统一性和简单性，ICMP的SPD条目的指定方式与其他协议相同。还请注意，对于ICMP、Mobility Header和非初始片段，这些数据包中没有端口字段。ICMP具有消息类型和代码，而Mobility Header具有Mobility Header类型。因此，SPD条目具有表示适用于这些协议的访问控制的规定，以代替正常的端口字段控制。对于绕过或丢弃的流量，支持单独的入站和出站入口，例如，如果需要，允许单向流量。
OPAQUE and ANY
不透明和任何
For each selector in an SPD entry, in addition to the literal values that define a match, there are two special values: ANY and OPAQUE. ANY is a wildcard that matches any value in the corresponding field of the packet, or that matches packets where that field is not present or is obscured. OPAQUE indicates that the corresponding selector field is not available for examination because it may not be present in a fragment, it does not exist for the given Next Layer Protocol, or prior application of IPsec may have encrypted the value. The ANY value encompasses the OPAQUE value. Thus, OPAQUE need be used only when it is necessary to distinguish between the case of any allowed value for a field, vs. the absence or unavailability (e.g., due to encryption) of the field.
对于SPD条目中的每个选择器，除了定义匹配的文字值外，还有两个特殊值：ANY和不透明。ANY是一个通配符，它匹配数据包相应字段中的任何值，或者匹配该字段不存在或不清晰的数据包。不透明表示相应的选择器字段不可用于检查，因为它可能不存在于片段中，对于给定的下一层协议，它不存在，或者先前的IPsec应用程序可能已加密该值。“任意”值包含不透明值。因此，只有在需要区分字段的任何允许值与字段的不存在或不可用（例如，由于加密）的情况时，才需要使用不透明。
How to Derive the Values for an SAD Entry
如何导出SAD条目的值
For each selector in an SPD entry, the entry specifies how to derive the corresponding values for a new SA Database (SAD, see Section 4.4.2) entry from those in the SPD and the packet. The goal is to allow an SAD entry and an SPD cache entry to be created based on specific selector values from the packet, or from the matching SPD entry. For outbound traffic, there are SPD-S cache entries and SPD-O cache entries. For inbound traffic not
对于SPD条目中的每个选择器，该条目指定如何从SPD和数据包中的值导出新SA数据库（SAD，见第4.4.2节）条目的相应值。目标是允许基于数据包或匹配的SPD条目中的特定选择器值创建SAD条目和SPD缓存条目。对于出站流量，有SPD-S缓存项和SPD-O缓存项。不适用于入站流量
protected by IPsec, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (see Section 4.4.2). If IPsec processing is specified for an entry, a "populate from packet" (PFP) flag may be asserted for one or more of the selectors in the SPD entry (Local IP address; Remote IP address; Next Layer Protocol; and, depending on Next Layer Protocol, Local port and Remote port, or ICMP type/code, or Mobility Header type). If asserted for a given selector X, the flag indicates that the SA to be created should take its value for X from the value in the packet. Otherwise, the SA should take its value(s) for X from the value(s) in the SPD entry. Note: In the non-PFP case, the selector values negotiated by the SA management protocol (e.g., IKEv2) may be a subset of those in the SPD entry, depending on the SPD policy of the peer. Also, whether a single flag is used for, e.g., source port, ICMP type/code, and Mobility Header (MH) type, or a separate flag is used for each, is a local matter.
受IPsec保护，有SPD-I缓存条目，还有SAD，它表示入站IPsec保护流量的缓存（见第4.4.2节）。如果为条目指定了IPsec处理，则可以为SPD条目中的一个或多个选择器（本地IP地址；远程IP地址；下一层协议；以及，取决于下一层协议、本地端口和远程端口、或ICMP类型/代码或移动头类型）断言“从数据包填充”（PFP）标志。如果为给定选择器X断言，则该标志指示要创建的SA应从数据包中的值中获取其X值。否则，SA应从SPD条目中的值中获取X的值。注意：在非PFP情况下，SA管理协议（例如IKEv2）协商的选择器值可能是SPD条目中的选择器值的子集，具体取决于对等方的SPD策略。此外，是否对源端口、ICMP类型/代码和移动报头（MH）类型使用单个标志，或对每个类型使用单独的标志，是本地问题。
The following example illustrates the use of the PFP flag in the context of a security gateway or a BITS/BITW implementation. Consider an SPD entry where the allowed value for Remote address is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an outbound packet arrives with a destination address of 192.0.2.3, and there is no extant SA to carry this packet. The value used for the SA created to transmit this packet could be either of the two values shown below, depending on what the SPD entry for this selector says is the source of the selector value:
以下示例说明在安全网关或BITS/BITW实现的上下文中使用PFP标志。考虑一个SPD条目，其中远程地址的允许值是IPv4地址的范围：192.0.2.1到192.0.2.10。假设一个出站数据包到达的目的地地址为192.0.2.3，并且没有现存的SA来承载这个数据包。为传输此数据包而创建的SA使用的值可以是以下两个值中的任意一个，具体取决于此选择器的SPD条目所述的选择器值的来源：
PFP flag value example of new
for the Remote SAD dest. address
addr. selector selector value
--------------- ------------
a. PFP TRUE 192.0.2.3 (one host)
b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts)
PFP flag value example of new
for the Remote SAD dest. address
addr. selector selector value
--------------- ------------
a. PFP TRUE 192.0.2.3 (one host)
b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts)
Note that if the SPD entry above had a value of ANY for the Remote address, then the SAD selector value would have to be ANY for case (b), but would still be as illustrated for case (a). Thus, the PFP flag can be used to prohibit sharing of an SA, even among packets that match the same SPD entry.
请注意，如果上面的SPD条目对于远程地址的值为ANY，那么对于情况（b），SAD选择器值必须为ANY，但仍然如情况（a）所示。因此，PFP标志可用于禁止共享SA，即使在匹配相同SPD条目的分组之间也是如此。
Management Interface
管理界面
For every IPsec implementation, there MUST be a management interface that allows a user or system administrator to manage the SPD. The interface must allow the user (or administrator) to specify the security processing to be applied to every packet that traverses the IPsec boundary. (In a native host IPsec
对于每个IPsec实现，都必须有一个允许用户或系统管理员管理SPD的管理界面。接口必须允许用户（或管理员）指定要应用于穿过IPsec边界的每个数据包的安全处理。（在本机主机中）
implementation making use of a socket interface, the SPD may not need to be consulted on a per-packet basis, as noted at the end of Section 4.4.1.1 and in Section 5.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.1.1, and MUST support (total) ordering of these entries, as seen via this interface. The SPD entries' selectors are analogous to the ACL or packet filters commonly found in a stateless firewall or packet filtering router and which are currently managed this way.
通过使用套接字接口实现，可能不需要按照每个数据包咨询SPD，如第4.4.1.1节末尾和第5节所述。）SPD的管理接口必须允许创建与第4.4.1.1节中定义的选择器一致的条目，并且必须支持这些条目的（总）排序，通过这个界面可以看到。SPD条目的选择器类似于无状态防火墙或包过滤路由器中常见的ACL或包过滤器，目前以这种方式进行管理。
In host systems, applications MAY be allowed to create SPD entries. (The means of signaling such requests to the IPsec implementation are outside the scope of this standard.) However, the system administrator MUST be able to specify whether or not a user or application can override (default) system policies. The form of the management interface is not specified by this document and may differ for hosts vs. security gateways, and within hosts the interface may differ for socket-based vs. BITS implementations. However, this document does specify a standard set of SPD elements that all IPsec implementations MUST support.
在主机系统中，可能允许应用程序创建SPD条目。（向IPsec实现发送此类请求的方式不在本标准的范围内。）但是，系统管理员必须能够指定用户或应用程序是否可以覆盖（默认）系统策略。本文档未指定管理接口的形式，主机与安全网关可能不同，主机内基于套接字与BITS实现的接口可能不同。但是，本文档确实指定了所有IPsec实现都必须支持的一组标准SPD元素。
Decorrelation
去相关
The processing model described in this document assumes the ability to decorrelate overlapping SPD entries to permit caching, which enables more efficient processing of outbound traffic in security gateways and BITS/BITW implementations. Decorrelation [CoSa04] is only a means of improving performance and simplifying the processing description. This RFC does not require a compliant implementation to make use of decorrelation. For example, native host implementations typically make use of caching implicitly because they bind SAs to socket interfaces, and thus there is no requirement to be able to decorrelate SPD entries in these implementations.
本文档中描述的处理模型假设能够解相关重叠的SPD条目以允许缓存，从而能够在安全网关和BITS/BITW实现中更高效地处理出站流量。解相关[CoSa04]只是提高性能和简化处理描述的一种手段。此RFC不需要兼容的实现来使用去相关。例如，本机主机实现通常隐式地使用缓存，因为它们将SAs绑定到套接字接口，因此在这些实现中不需要能够解相关SPD条目。
Note: Unless otherwise qualified, the use of "SPD" refers to the body of policy information in both ordered or decorrelated (unordered) state. Appendix B provides an algorithm that can be used to decorrelate SPD entries, but any algorithm that produces equivalent output may be used. Note that when an SPD entry is decorrelated all the resulting entries MUST be linked together, so that all members of the group derived from an individual, SPD entry (prior to decorrelation) can all be placed into caches and into the SAD at the same time. For example, suppose one starts with an entry A (from an ordered SPD) that when decorrelated, yields entries A1, A2, and A3. When a packet comes along that matches, say A2, and triggers the creation of an SA, the SA management protocol (e.g., IKEv2) negotiates A. And all 3
注：除非另有限定，“SPD”的使用是指处于有序或不相关（无序）状态的策略信息体。附录B提供了一种算法，可用于解相关SPD条目，但可使用产生等效输出的任何算法。请注意，当SPD条目解相关时，所有结果条目必须链接在一起，以便从单个SPD条目派生的组的所有成员（解相关之前）都可以同时放入缓存和SAD中。例如，假设一个条目以条目A（来自有序SPD）开始，该条目在解相关时产生条目A1、A2和A3。当出现匹配的数据包（如A2）并触发SA的创建时，SA管理协议（如IKEv2）协商a和所有3个数据包
decorrelated entries, A1, A2, and A3, are placed in the appropriate SPD-S cache and linked to the SA. The intent is that use of a decorrelated SPD ought not to create more SAs than would have resulted from use of a not-decorrelated SPD.
解相关条目A1、A2和A3被放置在相应的SPD-S缓存中，并链接到SA。其目的是，使用不相关SPD不应产生比使用不相关SPD更多的SA。
If a decorrelated SPD is employed, there are three options for what an initiator sends to a peer via an SA management protocol (e.g., IKE). By sending the complete set of linked, decorrelated entries that were selected from the SPD, a peer is given the best possible information to enable selection of the appropriate SPD entry at its end, especially if the peer has also decorrelated its SPD. However, if a large number of decorrelated entries are linked, this may create large packets for SA negotiation, and hence fragmentation problems for the SA management protocol.
如果使用了解相关SPD，则启动器通过SA管理协议（例如IKE）向对等方发送的内容有三个选项。通过发送从SPD中选择的一整套链接的、不相关的条目，可以为对等方提供尽可能最好的信息，以便能够在其末端选择适当的SPD条目，特别是在对等方也已将其SPD解相关的情况下。然而，如果链接了大量不相关的条目，这可能会创建用于SA协商的大数据包，从而导致SA管理协议的碎片问题。
Alternatively, the original entry from the (correlated) SPD may be retained and passed to the SA management protocol. Passing the correlated SPD entry keeps the use of a decorrelated SPD a local matter, not visible to peers, and avoids possible fragmentation concerns, although it provides less precise information to a responder for matching against the responder's SPD.
或者，可以保留来自（相关）SPD的原始条目并将其传递给SA管理协议。传递相关的SPD条目将不相关的SPD的使用保持为本地事务，对对等方不可见，并避免可能的碎片问题，尽管它向响应方提供不太精确的信息，以便与响应方的SPD进行匹配。
An intermediate approach is to send a subset of the complete set of linked, decorrelated SPD entries. This approach can avoid the fragmentation problems cited above yet provide better information than the original, correlated entry. The major shortcoming of this approach is that it may cause additional SAs to be created later, since only a subset of the linked, decorrelated entries are sent to a peer. Implementers are free to employ any of the approaches cited above.
一种中间方法是发送一整套链接的、不相关的SPD条目的子集。这种方法可以避免上面提到的碎片问题，但比原始的相关条目提供更好的信息。这种方法的主要缺点是，它可能会导致以后创建额外的SA，因为只有链接的、不相关的条目的子集被发送到对等方。实施者可以自由使用上述任何方法。
A responder uses the traffic selector proposals it receives via an SA management protocol to select an appropriate entry in its SPD. The intent of the matching is to select an SPD entry and create an SA that most closely matches the intent of the initiator, so that traffic traversing the resulting SA will be accepted at both ends. If the responder employs a decorrelated SPD, it SHOULD use the decorrelated SPD entries for matching, as this will generally result in creation of SAs that are more likely to match the intent of both peers. If the responder has a correlated SPD, then it SHOULD match the proposals against the correlated entries. For IKEv2, use of a decorrelated SPD offers the best opportunity for a responder to generate a "narrowed" response.
响应者使用通过SA管理协议接收的流量选择器建议，在其SPD中选择适当的条目。匹配的目的是选择一个SPD条目，并创建一个与启动器的意图最为匹配的SA，以便两端都能接受通过结果SA的流量。如果响应者使用解相关SPD，则应使用解相关SPD条目进行匹配，因为这通常会导致创建更可能匹配两个对等方意图的SA。如果响应者有一个相关的SPD，那么它应该将建议与相关条目相匹配。对于IKEv2，使用解相关SPD为响应者提供了产生“缩小”响应的最佳机会。
In all cases, when a decorrelated SPD is available, the decorrelated entries are used to populate the SPD-S cache. If the SPD is not decorrelated, caching is not allowed and an ordered
在所有情况下，当解相关SPD可用时，解相关条目用于填充SPD-S缓存。如果SPD未被解相关，则不允许缓存，并且命令
search of SPD MUST be performed to verify that inbound traffic arriving on an SA is consistent with the access control policy expressed in the SPD.
必须执行SPD搜索，以验证到达SA的入站流量与SPD中表示的访问控制策略一致。
Handling Changes to the SPD While the System Is Running
在系统运行时处理对SPD的更改
If a change is made to the SPD while the system is running, a check SHOULD be made of the effect of this change on extant SAs. An implementation SHOULD check the impact of an SPD change on extant SAs and SHOULD provide a user/administrator with a mechanism for configuring what actions to take, e.g., delete an affected SA, allow an affected SA to continue unchanged, etc.
如果在系统运行时对SPD进行了更改，则应检查此更改对现有SA的影响。实施应检查SPD更改对现有SA的影响，并应为用户/管理员提供配置要采取的操作的机制，例如，删除受影响的SA，允许受影响的SA继续保持不变等。
An SA may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Layer Protocol and related fields, e.g., ports), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported by all IPsec implementations to facilitate control of SA granularity. Note that both Local and Remote addresses should either be IPv4 or IPv6, but not a mix of address types. Also, note that the Local/Remote port selectors (and ICMP message type and code, and Mobility Header type) may be labeled as OPAQUE to accommodate situations where these fields are inaccessible due to packet fragmentation.
SA可以是细粒度的，也可以是粗粒度的，这取决于用于定义SA流量集的选择器。例如，两台主机之间的所有流量都可以通过单个SA承载，并提供一组统一的安全服务。或者，一对主机之间的通信可能分布在多个SA上，具体取决于所使用的应用程序（由下一层协议和相关字段定义，例如端口），不同的SA提供不同的安全服务。类似地，一对安全网关之间的所有通信可以在单个SA上进行，或者可以为每个通信主机对分配一个SA。所有IPsec实现都必须支持以下选择器参数，以便于控制SA粒度。请注意，本地和远程地址都应该是IPv4或IPv6，但不能混合使用地址类型。另外，请注意，本地/远程端口选择器（以及ICMP消息类型和代码，以及移动报头类型）可能被标记为不透明，以适应由于数据包碎片而无法访问这些字段的情况。
- Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial range), or a range of addresses (low and high values, inclusive), as well as the most generic form of a list of ranges. Address ranges are used to support more than one remote system sharing the same SA, e.g., behind a security gateway.
- 远程IP地址（IPv4或IPv6）：这是IP地址范围的列表（单播、广播（仅IPv4））。此结构允许表达单个IP地址（通过普通范围）、地址列表（每个地址都是普通范围）或地址范围（包括低值和高值），以及范围列表的最通用形式。地址范围用于支持多个共享同一SA的远程系统，例如，在安全网关后面。
- Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial range), or a range of addresses (low and high values, inclusive), as well as the most generic form of a list of ranges. Address ranges are used to
- 本地IP地址（IPv4或IPv6）：这是IP地址范围的列表（单播、广播（仅IPv4））。此结构允许表达单个IP地址（通过普通范围）、地址列表（每个地址都是普通范围）或地址范围（包括低值和高值），以及范围列表的最通用形式。地址范围用于
support more than one source system sharing the same SA, e.g., behind a security gateway. Local refers to the address(es) being protected by this implementation (or policy entry).
支持多个源系统共享同一SA，例如，在安全网关后面。Local是指受此实现（或策略条目）保护的地址。
Note: The SPD does not include support for multicast address entries. To support multicast SAs, an implementation should make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries require a different structure, i.e., one cannot use the symmetric relationship associated with local and remote address values for unicast SAs in a multicast context. Specifically, outbound traffic directed to a multicast address on an SA would not be received on a companion, inbound SA with the multicast address as the source.
注意：SPD不支持多播地址条目。为了支持多播SAs，实现应使用[RFC3740]中定义的组SPD（GSPD）。GSPD条目需要不同的结构，即不能在多播上下文中使用与单播SA的本地和远程地址值相关联的对称关系。具体而言，定向到SA上的多播地址的出站流量不会在以多播地址为源的伴随入站SA上接收。
- Next Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This is an individual protocol number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol is whatever comes after any IP extension headers that are present. To simplify locating the Next Layer Protocol, there SHOULD be a mechanism for configuring which IPv6 extension headers to skip. The default configuration for which protocols to skip SHOULD include the following protocols: 0 (Hop-by-hop options), 43 (Routing Header), 44 (Fragmentation Header), and 60 (Destination Options). Note: The default list does NOT include 51 (AH) or 50 (ESP). From a selector lookup point of view, IPsec treats AH and ESP as Next Layer Protocols.
- 下一层协议：从IPv4“协议”或IPv6“下一个标头”字段获取。这是一个单独的协议编号（任意），或仅适用于IPv6，不透明。下一层协议是出现在任何IP扩展头之后的任何协议。为了简化下一层协议的定位，应该有一种机制来配置要跳过的IPv6扩展头。要跳过哪些协议的默认配置应包括以下协议：0（逐跳选项）、43（路由标头）、44（分段标头）和60（目标选项）。注意：默认列表不包括51（AH）或50（ESP）。从选择器查找的角度来看，IPsec将AH和ESP视为下一层协议。
Several additional selectors depend on the Next Layer Protocol value:
其他几个选择器取决于下一层协议值：
* If the Next Layer Protocol uses two ports (as do TCP, UDP, SCTP, and others), then there are selectors for Local and Remote Ports. Each of these selectors has a list of ranges of values. Note that the Local and Remote ports may not be available in the case of receipt of a fragmented packet or if the port fields have been protected by IPsec (encrypted); thus, a value of OPAQUE also MUST be supported. Note: In a non-initial fragment, port values will not be available. If a port selector specifies a value other than ANY or OPAQUE, it cannot match packets that are non-initial fragments. If the SA requires a port value other than ANY or OPAQUE, an arriving fragment without ports MUST be discarded. (See Section 7, "Handling Fragments".)
* 如果下一层协议使用两个端口（与TCP、UDP、SCTP和其他端口一样），则存在用于本地和远程端口的选择器。每个选择器都有一个值范围列表。注意，在接收到碎片数据包的情况下，或者如果端口字段受到IPsec（加密）的保护，则本地和远程端口可能不可用；因此，还必须支持不透明的值。注意：在非初始片段中，端口值将不可用。如果端口选择器指定的值不是ANY或不透明，则它无法匹配非初始片段的数据包。如果SA需要的端口值不是ANY或OPAQUE，则必须丢弃没有端口的到达片段。（参见第7节“碎片处理”。）
* If the Next Layer Protocol is a Mobility Header, then there is a selector for IPv6 Mobility Header message type (MH type) [Mobip]. This is an 8-bit value that identifies a particular mobility message. Note that the MH type may not be available
* 如果下一层协议是移动报头，那么IPv6移动报头消息类型（MH类型）[Mobip]有一个选择器。这是标识特定移动消息的8位值。请注意，MH类型可能不可用
in the case of receipt of a fragmented packet. (See Section 7, "Handling Fragments".) For IKE, the IPv6 Mobility Header message type (MH type) is placed in the most significant eight bits of the 16-bit local "port" selector.
在收到碎片数据包的情况下。（请参阅第7节“处理片段”）对于IKE，IPv6移动头消息类型（MH类型）位于16位本地“端口”选择器的最高有效8位。
* If the Next Layer Protocol value is ICMP, then there is a 16-bit selector for the ICMP message type and code. The message type is a single 8-bit value, which defines the type of an ICMP message, or ANY. The ICMP code is a single 8-bit value that defines a specific subtype for an ICMP message. For IKE, the message type is placed in the most significant 8 bits of the 16-bit selector and the code is placed in the least significant 8 bits. This 16-bit selector can contain a single type and a range of codes, a single type and ANY code, and ANY type and ANY code. Given a policy entry with a range of Types (T-start to T-end) and a range of Codes (C-start to C-end), and an ICMP packet with Type t and Code c, an implementation MUST test for a match using
* 如果下一层协议值为ICMP，则ICMP消息类型和代码有一个16位选择器。消息类型是一个8位值，它定义ICMP消息的类型或任何类型。ICMP代码是一个8位值，用于定义ICMP消息的特定子类型。对于IKE，消息类型放在16位选择器的最高有效8位，代码放在最低有效8位。此16位选择器可以包含单个类型和一系列代码、单个类型和任意代码以及任意类型和任意代码。给定一个具有一系列类型（T-start到T-end）和一系列代码（C-start到C-end）的策略条目，以及一个具有类型T和代码C的ICMP数据包，实现必须使用
(T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
C-end
(T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
C-end
Note that the ICMP message type and code may not be available in the case of receipt of a fragmented packet. (See Section 7, "Handling Fragments".)
请注意，在收到碎片数据包的情况下，ICMP消息类型和代码可能不可用。（参见第7节“碎片处理”。）
- Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways:
- 名称：这与上面的其他选择器不同。它不是从数据包中获取的。名称可用作IPsec本地或远程地址的符号标识符。命名的SPD条目有两种使用方式：
1. A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors". The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion. All IPsec implementations MUST support this use of names.
1. 当IP地址不适合远程IP地址选择器时，响应程序（而非启动器）使用命名的SPD条目来支持访问控制，例如“道路勇士”。用于匹配此字段的名称在ID有效负载中的IKE协商期间进行通信。在此上下文中，启动器的源IP地址（隧道模式下的内部IP报头）绑定到由IKE协商创建的SAD条目中的远程IP地址。以这种方式选择SPD条目时，此地址将覆盖SPD中的远程IP地址值。所有IPsec实现都必须支持这种名称的使用。
2. A named SPD entry may be used by an initiator to identify a user for whom an IPsec SA will be created (or for whom traffic may be bypassed). The initiator's IP source address (from inner IP header in tunnel mode) is used to replace the following if and when they are created:
2. 启动器可以使用命名的SPD条目来标识将为其创建IPsec SA（或可能绕过其流量）的用户。启动器的IP源地址（在隧道模式下来自内部IP标头）用于在创建以下地址时替换它们：
- local address in the SPD cache entry - local address in the outbound SAD entry - remote address in the inbound SAD entry
- SPD缓存项中的本地地址-出站SAD项中的本地地址-入站SAD项中的远程地址
Support for this use is optional for multi-user, native host implementations and not applicable to other implementations. Note that this name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context (see below).
对这种使用的支持对于多用户、本机主机实现是可选的，不适用于其他实现。请注意，此名称仅在本地使用；它不通过密钥管理协议进行通信。此外，除上述案例1（响应者）中使用的名称形式外，其他名称形式也适用于启动器上下文（见下文）。
An SPD entry can contain both a name (or a list of names) and also values for the Local or Remote IP address.
SPD条目既可以包含名称（或名称列表），也可以包含本地或远程IP地址的值。
For case 1, responder, the identifiers employed in named SPD entries are one of the following four types:
对于案例1，响应者，命名SPD条目中使用的标识符是以下四种类型之一：
a. a fully qualified user name string (email), e.g., mozart@foo.example.com (this corresponds to ID_RFC822_ADDR in IKEv2)
a. 完全限定的用户名字符串（电子邮件），例如。，mozart@foo.example.com（这与IKEv2中的ID_RFC822_ADDR相对应）
b. a fully qualified DNS name, e.g., foo.example.com (this corresponds to ID_FQDN in IKEv2)
b. 完全限定的DNS名称，例如foo.example.com（对应于IKEv2中的ID_FQDN）
c. X.500 distinguished name, e.g., [WaKiHo97], CN = Stephen T. Kent, O = BBN Technologies, SP = MA, C = US (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding)
c. X.500可分辨名称，例如[WaKiHo97]，CN=Stephen T.Kent，O=BBN Technologies，SP=MA，C=US（解码后对应于IKEv2中的ID_DER_ASN1_DN）
d. a byte string (this corresponds to Key_ID in IKEv2)
d. 一个字节字符串（对应于IKEv2中的Key_ID）
For case 2, initiator, the identifiers employed in named SPD entries are of type byte string. They are likely to be Unix UIDs, Windows security IDs, or something similar, but could also be a user name or account name. In all cases, this identifier is only of local concern and is not transmitted.
对于案例2，启动器，命名SPD条目中使用的标识符类型为字节字符串。它们可能是Unix UID、Windows安全ID或类似的东西，但也可能是用户名或帐户名。在所有情况下，该标识符仅与本地相关，不会被传输。
The IPsec implementation context determines how selectors are used. For example, a native host implementation typically makes use of a socket interface. When a new connection is established, the SPD can be consulted and an SA bound to the socket. Thus, traffic sent via that socket need not result in additional lookups to the SPD (SPD-O and SPD-S) cache. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD-O/SPD-S cache lookup based on the selectors.
IPsec实现上下文决定如何使用选择器。例如，本机主机实现通常使用套接字接口。建立新连接时，可以咨询SPD，并将SA绑定到插座。因此，通过该套接字发送的通信量不需要额外查找SPD（SPD-O和SPD-S）缓存。相反，BITS、BITW或安全网关实现需要查看每个数据包，并基于选择器执行SPD-O/SPD-S缓存查找。
This section contains a prose description of an SPD entry. Also, Appendix C provides an example of an ASN.1 definition of an SPD entry.
本节包含SPD条目的散文描述。此外，附录C提供了ASN.1对SPD条目的定义示例。
This text describes the SPD in a fashion that is intended to map directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Unfortunately, the semantics of the version of IKEv2 published concurrently with this document [Kau05] do not align precisely with those defined for the SPD. Specifically, IKEv2 does not enable negotiation of a single SA that binds multiple pairs of local and remote addresses and ports to a single SA. Instead, when multiple local and remote addresses and ports are negotiated for an SA, IKEv2 treats these not as pairs, but as (unordered) sets of local and remote values that can be arbitrarily paired. Until IKE provides a facility that conveys the semantics that are expressed in the SPD via selector sets (as described below), users MUST NOT include multiple selector sets in a single SPD entry unless the access control intent aligns with the IKE "mix and match" semantics. An implementation MAY warn users, to alert them to this problem if users create SPD entries with multiple selector sets, the syntax of which indicates possible conflicts with current IKE semantics.
本文以直接映射到IKE有效负载的方式描述SPD，以确保SPD条目所需的策略可以通过IKE协商。不幸的是，与本文档[Kau05]同时发布的IKEv2版本的语义与SPD定义的语义并不完全一致。具体而言，IKEv2不支持将多对本地和远程地址和端口绑定到单个SA的单个SA的协商。相反，当为SA协商多个本地和远程地址和端口时，IKEv2不会将它们视为成对的，而是可以任意配对的本地和远程值（无序）集。在IKE提供通过选择器集（如下所述）传达SPD中表达的语义的设施之前，用户不得在单个SPD条目中包含多个选择器集，除非访问控制意图与IKE“混合和匹配”语义一致。如果用户使用多个选择器集创建SPD条目（其语法表示可能与当前IKE语义冲突），则实现可能会警告用户，以提醒他们注意此问题。
The management GUI can offer the user other forms of data entry and display, e.g., the option of using address prefixes as well as ranges, and symbolic names for protocols, ports, etc. (Do not confuse the use of symbolic names in a management interface with the SPD selector "Name".) Note that Remote/Local apply only to IP addresses and ports, not to ICMP message type/code or Mobility Header type. Also, if the reserved, symbolic selector value OPAQUE or ANY is employed for a given selector type, only that value may appear in the list for that selector, and it must appear only once in the list for that selector. Note that ANY and OPAQUE are local syntax conventions -- IKEv2 negotiates these values via the ranges indicated below:
管理GUI可以为用户提供其他形式的数据输入和显示，例如，使用地址前缀、范围以及协议、端口等的符号名称的选项（不要将管理界面中符号名称的使用与SPD选择器“名称”混淆）。请注意，远程/本地仅适用于IP地址和端口，不适用于ICMP消息类型/代码或移动头类型。此外，如果为给定选择器类型使用保留的符号选择器值不透明或任意值，则该选择器的列表中只能出现该值，并且该选择器的列表中只能出现一次。注意，ANY和不透明都是本地语法约定——IKEv2通过以下指定的范围协商这些值：
ANY: start = 0 end = <max>
OPAQUE: start = <max> end = 0
ANY: start = 0 end = <max>
OPAQUE: start = <max> end = 0
An SPD is an ordered list of entries each of which contains the following fields.
SPD是条目的有序列表，每个条目包含以下字段。
o Name -- a list of IDs. This quasi-selector is optional. The forms that MUST be supported are described above in Section 4.4.1.1 under "Name".
o Name——ID的列表。此准选择器是可选的。上述第4.4.1.1节“名称”中描述了必须支持的表格。
o PFP flags -- one per traffic selector. A given flag, e.g., for Next Layer Protocol, applies to the relevant selector across all "selector sets" (see below) contained in an SPD entry. When creating an SA, each flag specifies for the corresponding traffic selector whether to instantiate the selector from the corresponding field in the packet that triggered the creation of the SA or from the value(s) in the corresponding SPD entry (see Section 4.4.1, "How to Derive the Values for an SAD Entry"). Whether a single flag is used for, e.g., source port, ICMP type/code, and MH type, or a separate flag is used for each, is a local matter. There are PFP flags for: - Local Address - Remote Address - Next Layer Protocol - Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol) - Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
o PFP标志——每个流量选择器一个。给定的标志（例如下一层协议）适用于SPD条目中包含的所有“选择器集”（见下文）的相关选择器。创建SA时，每个标志都为相应的流量选择器指定是从触发SA创建的数据包中的相应字段实例化选择器，还是从相应的SPD条目中的值实例化选择器（参见第4.4.1节“如何导出SAD条目的值”）。是否对源端口、ICMP类型/代码和MH类型使用单个标志，或对每个类型使用单独的标志，这是一个局部问题。有以下PFP标志：-本地地址-远程地址-下一层协议-本地端口，或ICMP消息类型/代码或移动头类型（取决于下一层协议）-远程端口，或ICMP消息类型/代码或移动头类型（取决于下一层协议）
o One to N selector sets that correspond to the "condition" for applying a particular IPsec action. Each selector set contains: - Local Address - Remote Address - Next Layer Protocol - Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol) - Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
o 一对N选择器集，对应于应用特定IPsec操作的“条件”。每个选择器集包含：-本地地址-远程地址-下一层协议-本地端口，或ICMP消息类型/代码或移动头类型（取决于下一层协议）-远程端口，或ICMP消息类型/代码或移动头类型（取决于下一层协议）
Note: The "next protocol" selector is an individual value (unlike the local and remote IP addresses) in a selector set entry. This is consistent with how IKEv2 negotiates the Traffic Selector (TS) values for an SA. It also makes sense because one may need to associate different port fields with different protocols. It is possible to associate multiple protocols (and ports) with a single SA by specifying multiple selector sets for that SA.
注意：“下一个协议”选择器是选择器集合项中的单个值（与本地和远程IP地址不同）。这与IKEv2为SA协商流量选择器（TS）值的方式一致。这也是有意义的，因为可能需要将不同的端口字段与不同的协议相关联。通过为单个SA指定多个选择器集，可以将多个协议（和端口）与该SA关联。
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
o 处理信息—需要执行哪些操作—保护、绕过或放弃。所有选择器集只有一个操作，而不是每个选择器集都有一个单独的操作。如果所需处理为PROTECT，则条目包含以下信息。-IPsec模式--隧道或传输
- (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) remote tunnel address -- There is no standard way to determine this. See 4.5.3, "Locating a Security Gateway". - Extended Sequence Number -- Is this SA using extended sequence numbers? - stateful fragment checking -- Is this SA using stateful fragment checking? (See Section 7 for more details.) - Bypass DF bit (T/F) -- applicable to tunnel mode SAs - Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs - IPsec protocol -- AH or ESP - algorithms -- which ones to use for AH, which ones to use for ESP, which ones to use for combined mode, ordered by decreasing priority
- （如果是隧道模式）本地隧道地址——对于非移动主机，如果只有一个接口，这很简单；如果有多个接口，则必须对其进行静态配置。对于移动主机，本地地址的规范在IPsec外部处理。-（如果是隧道模式）远程隧道地址——没有标准的方法来确定。见4.5.3，“定位安全网关”。-扩展序列号--此SA是否使用扩展序列号？-有状态片段检查——此SA是否使用有状态片段检查？（有关更多详细信息，请参见第7节）-绕过DF位（T/F）-适用于隧道模式SAs-绕过DSCP（T/F）或映射到未受保护的DSCP值（阵列），如果需要限制绕过DSCP值-适用于隧道模式SAs-IPsec协议-AH或ESP-算法-哪些用于AH，哪些用于ESP，按优先级递减顺序，组合模式使用哪种模式
It is a local matter as to what information is kept with regard to handling extant SAs when the SPD is changed.
当SPD发生变化时，关于如何处理现有SA，保留哪些信息是本地事务。
Additional selectors are often associated with fields in the Next Layer Protocol header. A particular Next Layer Protocol can have zero, one, or two selectors. There may be situations where there aren't both local and remote selectors for the fields that are dependent on the Next Layer Protocol. The IPv6 Mobility Header has only a Mobility Header message type. AH and ESP have no further selector fields. A system may be willing to send an ICMP message type and code that it does not want to receive. In the descriptions below, "port" is used to mean a field that is dependent on the Next Layer Protocol.
附加选择器通常与下一层协议头中的字段相关联。特定的下一层协议可以有零个、一个或两个选择器。在某些情况下，依赖于下一层协议的字段可能没有本地和远程选择器。IPv6移动头只有一个移动头消息类型。AH和ESP没有更多的选择器字段。系统可能愿意发送它不希望接收的ICMP消息类型和代码。在下面的描述中，“端口”用于表示依赖于下一层协议的字段。
A. If a Next Layer Protocol has no "port" selectors, then the Local and Remote "port" selectors are set to OPAQUE in the relevant SPD entry, e.g.,
A.如果下一层协议没有“端口”选择器，则本地和远程“端口”选择器在相关SPD条目中设置为不透明，例如。，
Local's next layer protocol = AH "port" selector = OPAQUE
本地的下一层协议=AH“端口”选择器=不透明
Remote's next layer protocol = AH "port" selector = OPAQUE
远程的下一层协议=AH“端口”选择器=不透明
B. Even if a Next Layer Protocol has only one selector, e.g., Mobility Header type, then the Local and Remote "port" selectors are used to indicate whether a system is willing to send and/or receive traffic with the specified "port" values. For example, if Mobility Headers of a specified type are allowed to be sent and received via an SA, then the relevant SPD entry would be set as follows:
B.即使下一层协议只有一个选择器，例如，移动报头类型，则本地和远程“端口”选择器用于指示系统是否愿意发送和/或接收具有指定“端口”值的流量。例如，如果允许通过SA发送和接收指定类型的移动报头，则相关SPD条目将设置如下：
Local's next layer protocol = Mobility Header "port" selector = Mobility Header message type
本地的下一层协议=移动头“端口”选择器=移动头消息类型
Remote's next layer protocol = Mobility Header "port" selector = Mobility Header message type
远程的下一层协议=移动头“端口”选择器=移动头消息类型
If Mobility Headers of a specified type are allowed to be sent but NOT received via an SA, then the relevant SPD entry would be set as follows:
如果允许通过SA发送但不接收指定类型的移动报头，则相关SPD条目将设置如下：
Local's next layer protocol = Mobility Header "port" selector = Mobility Header message type
本地的下一层协议=移动头“端口”选择器=移动头消息类型
Remote's next layer protocol = Mobility Header "port" selector = OPAQUE
远程的下一层协议=移动头“端口”选择器=不透明
If Mobility Headers of a specified type are allowed to be received but NOT sent via an SA, then the relevant SPD entry would be set as follows:
如果允许接收指定类型的移动报头，但不通过SA发送，则相关SPD条目将设置如下：
Local's next layer protocol = Mobility Header "port" selector = OPAQUE
本地的下一层协议=移动头“端口”选择器=不透明
Remote's next layer protocol = Mobility Header "port" selector = Mobility Header message type
远程的下一层协议=移动头“端口”选择器=移动头消息类型
C. If a system is willing to send traffic with a particular "port" value but NOT receive traffic with that kind of port value, the system's traffic selectors are set as follows in the relevant SPD entry:
C.如果系统愿意发送具有特定“端口”值的流量，但不接收具有该端口值的流量，则系统的流量选择器在相关SPD条目中设置如下：
Local's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
Local's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
Remote's next layer protocol = ICMP "port" selector = OPAQUE
远程的下一层协议=ICMP“端口”选择器=不透明
D. To indicate that a system is willing to receive traffic with a particular "port" value but NOT send that kind of traffic, the system's traffic selectors are set as follows in the relevant SPD entry:
D.为了表明系统愿意接收具有特定“端口”值的流量，但不发送此类流量，系统的流量选择器在相关SPD条目中设置如下：
Local's next layer protocol = ICMP "port" selector = OPAQUE
本地的下一层协议=ICMP“端口”选择器=不透明
Remote's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
Remote's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
For example, if a security gateway is willing to allow systems behind it to send ICMP traceroutes, but is not willing to let outside systems run ICMP traceroutes to systems behind it, then the security gateway's traffic selectors are set as follows in the relevant SPD entry:
例如，如果安全网关愿意允许其背后的系统发送ICMP跟踪路由，但不愿意让外部系统向其背后的系统运行ICMP跟踪路由，则安全网关的流量选择器在相关SPD条目中设置如下：
Local's next layer protocol = 1 (ICMPv4) "port" selector = 30 (traceroute)
本地的下一层协议=1（ICMPv4）“端口”选择器=30（跟踪路由）
Remote's next layer protocol = 1 (ICMPv4) "port" selector = OPAQUE
远程的下一层协议=1（ICMPv4）“端口”选择器=不透明
In each IPsec implementation, there is a nominal Security Association Database (SAD), in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. For inbound processing, for unicast SAs, the SPI is used either alone to look up an SA or in conjunction with the IPsec protocol type. If an IPsec implementation supports multicast, the SPI plus destination address, or SPI plus destination and source addresses are used to look up the SA. (See Section 4.1 for details on the algorithm that MUST be used for mapping inbound IPsec datagrams to SAs.) The following parameters are associated with each entry in
在每个IPsec实现中，都有一个标称安全关联数据库（SAD），其中每个条目定义与一个SA关联的参数。每个SA在SAD中都有一个条目。对于出站处理，每个SAD条目由SPD缓存的SPD-S部分中的条目指向。对于入站处理，对于单播SA，SPI单独用于查找SA或与IPsec协议类型结合使用。如果IPsec实现支持多播，则使用SPI plus目标地址或SPI plus目标和源地址查找SA。（有关将入站IPsec数据报映射到SAs时必须使用的算法的详细信息，请参见第4.1节。）以下参数与中的每个条目相关联
the SAD. They should all be present except where otherwise noted, e.g., AH Authentication algorithm. This description does not purport to be a MIB, only a specification of the minimal data items required to support an SA in an IPsec implementation.
悲伤。除非另有说明，否则它们都应存在，例如AH认证算法。此描述并不声称是MIB，只是IPsec实现中支持SA所需的最小数据项的规范。
For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created. (See the paragraph in Section 4.4.1 under "Handling Changes to the SPD while the System is Running" for guidance on the effect of SPD changes on extant SAs.) For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA. Thus, the SAD acts as a cache for checking the selectors of inbound traffic arriving on SAs. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1, "Selectors". Note also that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry.
对于第4.4.1.1节中定义的每个选择器，SAD中入站SA的条目必须首先填充创建SA时协商的一个或多个值。（请参阅第4.4.1节“在系统运行时处理对SPD的更改”中的段落，了解SPD更改对现有SA的影响的指导。）对于接收器，这些值用于检查入站数据包的报头字段（在IPsec处理后）是否与SA协商的选择器值相匹配。因此，SAD充当缓存，用于检查到达SAs的入站流量的选择器。对于接收器，这是验证到达SA的数据包是否与SA的策略一致的一部分。（有关ICMP消息的规则，请参见第6节。）这些字段可以具有特定值、范围、任意或不透明的形式，如第4.4.1.1节“选择器”所述。还请注意，有两种情况下，SAD可能会有SAs的条目，而这些条目在SPD中没有相应的条目。由于本文件不要求在更改SPD时有选择地清除SAD，因此在更改或删除创建SAD条目的SPD条目时，SAD条目可以保留。此外，如果创建了手动键控SA，则此SA可能存在与任何SPD条目不对应的SAD条目。
Note: The SAD can support multicast SAs, if manually configured. An outbound multicast SA has the same structure as a unicast SA. The source address is that of the sender, and the destination address is the multicast group address. An inbound, multicast SA must be configured with the source addresses of each peer authorized to transmit to the multicast SA in question. The SPI value for a multicast SA is provided by a multicast group controller, not by the receiver, as for a unicast SA. Because an SAD entry may be required to accommodate multiple, individual IP source addresses that were part of an SPD entry (for unicast SAs), the required facility for inbound, multicast SAs is a feature already present in an IPsec implementation. However, because the SPD has no provisions for accommodating multicast entries, this document does not specify an automated way to create an SAD entry for a multicast, inbound SA. Only manually configured SAD entries can be created to accommodate inbound, multicast traffic.
注意：如果手动配置，SAD可以支持多播SAs。出站多播SA与单播SA具有相同的结构。源地址是发送方的地址，目标地址是多播组地址。入站多播SA必须配置有每个被授权传输到相关多播SA的对等方的源地址。多播SA的SPI值由多播组控制器提供，而不像单播SA那样由接收机提供。由于可能需要SAD条目来容纳作为SPD条目一部分的多个单独IP源地址（对于单播SAs），因此入站多播SAs所需的功能已经存在于IPsec实现中。但是，由于SPD没有容纳多播条目的规定，因此本文档未指定为多播入站SA创建SAD条目的自动方法。只能创建手动配置的SAD条目以适应入站多播流量。
Implementation Guidance: This document does not specify how an SPD-S entry refers to the corresponding SAD entry, as this is an implementation-specific detail. However, some implementations (based on experience from RFC 2401) are known to have problems in this regard. In particular, simply storing the (remote tunnel header IP
实施指南：本文件未规定SPD-S条目如何引用相应的SAD条目，因为这是具体实施细节。然而，一些实现（基于RFC 2401的经验）在这方面存在问题。特别是，只需存储（远程隧道头IP）
address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT could choose the same SPI value. The situation also may arise if a host is assigned an IP address (e.g., via DHCP) previously used by some other host, and the SAs associated with the old host have not yet been deleted via dead peer detection mechanisms. This may lead to packets being sent over the wrong SA or, if key management ensures the pair is unique, denying the creation of otherwise valid SAs. Thus, implementors should implement links between the SPD cache and the SAD in a way that does not engender such problems.
SPD缓存中的地址（远程SPI）对不够，因为该对并不总是唯一标识单个SAD条目。例如，同一NAT后面的两台主机可以选择相同的SPI值。如果主机被分配了一个以前由其他主机使用的IP地址（例如，通过DHCP），并且与旧主机相关联的SA尚未通过死点检测机制删除，则也可能出现这种情况。这可能导致数据包通过错误的SA发送，或者，如果密钥管理确保数据包对是唯一的，则拒绝创建其他有效的SA。因此，实现者应该以不产生此类问题的方式实现SPD缓存和SAD之间的链接。
The following data items MUST be in the SAD:
以下数据项必须在SAD中：
o Security Parameter Index (SPI): a 32-bit value selected by the receiving end of an SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI is used to construct the packet's AH or ESP header. In an SAD entry for an inbound SA, the SPI is used to map traffic to the appropriate SA (see text on unicast/multicast in Section 4.1).
o 安全参数索引（SPI）：SA接收端选择的32位值，用于唯一标识SA。在出站SA的SAD条目中，SPI用于构造数据包的AH或ESP报头。在入站SA的SAD条目中，SPI用于将流量映射到适当的SA（请参阅第4.1节中有关单播/多播的文本）。
o Sequence Number Counter: a 64-bit counter used to generate the Sequence Number field in AH or ESP headers. 64-bit sequence numbers are the default, but 32-bit sequence numbers are also supported if negotiated.
o 序列号计数器：用于在AH或ESP标头中生成序列号字段的64位计数器。默认为64位序列号，但协商后也支持32位序列号。
o Sequence Counter Overflow: a flag indicating whether overflow of the sequence number counter should generate an auditable event and prevent transmission of additional packets on the SA, or whether rollover is permitted. The audit log entry for this event SHOULD include the SPI value, current date/time, Local Address, Remote Address, and the selectors from the relevant SAD entry.
o Sequence Counter Overflow（序列计数器溢出）：一个标志，指示序列号计数器溢出是否应生成可审核事件并防止在SA上传输附加数据包，或者是否允许滚动。此事件的审核日志条目应包括SPI值、当前日期/时间、本地地址、远程地址以及相关SAD条目中的选择器。
o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay.
o 反重播窗口：64位计数器和位映射（或等效值），用于确定入站AH或ESP数据包是否为重播。
Note: If anti-replay has been disabled by the receiver for an SA, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is ignored for the SA in question. 64-bit sequence numbers are the default, but this counter size accommodates 32-bit sequence numbers as well.
注意：如果某个SA的接收器已禁用反重播功能，例如，在手动键入SA的情况下，则该SA的反重播窗口将被忽略。默认为64位序列号，但此计数器大小也可容纳32位序列号。
o AH Authentication algorithm, key, etc. This is required only if AH is supported.
o AH身份验证算法、密钥等。仅当支持AH时才需要此项。
o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode algorithm is used, these fields will not be applicable.
o ESP加密算法、密钥、模式、IV等。如果使用组合模式算法，这些字段将不适用。
o ESP integrity algorithm, keys, etc. If the integrity service is not selected, these fields will not be applicable. If a combined mode algorithm is used, these fields will not be applicable.
o ESP完整性算法、密钥等。如果未选择完整性服务，这些字段将不适用。如果使用组合模式算法，这些字段将不适用。
o ESP combined mode algorithms, key(s), etc. This data is used when a combined mode (encryption and integrity) algorithm is used with ESP. If a combined mode algorithm is not used, these fields are not applicable.
o ESP组合模式算法、密钥等。当组合模式（加密和完整性）算法与ESP一起使用时，将使用此数据。如果未使用组合模式算法，则这些字段不适用。
o Lifetime of this SA: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count, or a simultaneous use of both with the first lifetime to expire taking precedence. A compliant implementation MUST support both types of lifetimes, and MUST support a simultaneous use of both. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the Certificate Revocation Lists (CRLs) used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining the SA lifetime in this fashion. Note: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is:
o 此SA的生存期：SA必须更换为新SA（和新SPI）或终止的时间间隔，加上这些操作应发生的指示。这可以表示为时间或字节计数，或者同时使用这两种计数，第一个生命周期以过期为准。兼容的实现必须支持这两种类型的生存期，并且必须支持同时使用这两种类型的生存期。如果使用时间，并且IKE使用X.509证书建立SA，则SA生存期必须受到证书的有效期间隔以及在IKE交换中用于SA的证书撤销列表（CRL）的下一个发布日期的约束。启动器和响应程序都负责以这种方式约束SA生存期。注意：SAs过期时如何处理密钥刷新的详细信息是本地事务。然而，一个合理的方法是：
(a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec cryptographic algorithm is applied. For ESP, this is the encryption algorithm (including Null encryption) and for AH, this is the authentication algorithm. This includes pad bytes, etc. Note that implementations MUST be able to handle having the counters at the ends of an SA get out of synch, e.g., because of packet loss or because the implementations at each end of the SA aren't doing things the same way.
(a) 如果使用字节计数，则实现应计算应用IPsec加密算法的字节数。对于ESP，这是加密算法（包括空加密），对于AH，这是身份验证算法。这包括pad字节等。请注意，实现必须能够处理SA两端的计数器不同步的问题，例如，由于数据包丢失或SA两端的实现方式不同。
(b) There SHOULD be two kinds of lifetime -- a soft lifetime that warns the implementation to initiate action such as setting up a replacement SA, and a hard lifetime when the current SA ends and is destroyed.
(b) 应该有两种生存期——一种是软生存期，警告实现启动操作，如设置替换SA；另一种是硬生存期，当当前SA结束并被销毁时。
(c) If the entire packet does not get delivered during the SA's lifetime, the packet SHOULD be discarded.
(c) 如果整个数据包在SA的生存期内未被传递，则应丢弃该数据包。
o IPsec protocol mode: tunnel or transport. Indicates which mode of AH or ESP is applied to traffic on this SA.
o IPsec协议模式：隧道或传输。指示将哪种AH或ESP模式应用于此SA上的流量。
o Stateful fragment checking flag. Indicates whether or not stateful fragment checking applies to this SA.
o 有状态片段检查标志。指示有状态片段检查是否应用于此SA。
o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both inner and outer headers are IPv4.
o 旁路DF位（T/F）--适用于内部和外部报头均为IPv4的隧道模式SAs。
o DSCP values -- the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA.
o DSCP值--此SA上承载的数据包所允许的DSCP值集。如果未指定任何值，则不会应用特定于DSCP的筛选。如果指定了一个或多个值，则这些值用于从与出站数据包的流量选择器匹配的多个SA中选择一个SA。请注意，不会根据SA上到达的入站流量检查这些值。
o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signaling concerns.
o 旁路DSCP（T/F）或映射到不受保护的DSCP值（阵列），如果需要限制DSCP值的旁路-适用于隧道模式SAs。此功能将DSCP值从内部报头映射到外部报头中的值，例如，以解决隐蔽信道信令问题。
o Path MTU: any observed path MTU and aging variables.
o 路径MTU：任何观察到的路径MTU和老化变量。
o Tunnel header IP source and destination address -- both addresses must be either IPv4 or IPv6 addresses. The version implies the type of IP header to be used. Only used when the IPsec protocol mode is tunnel.
o 隧道头IP源地址和目标地址--这两个地址必须是IPv4或IPv6地址。版本表示要使用的IP头的类型。仅在IPsec协议模式为隧道时使用。
For each selector, the following tables show the relationship between the value in the SPD, the PFP flag, the value in the triggering packet, and the resulting value in the SAD. Note that the administrative interface for IPsec can use various syntactic options to make it easier for the administrator to enter rules. For example, although a list of ranges is what IKEv2 sends, it might be clearer and less error prone for the user to enter a single IP address or IP address prefix.
对于每个选择器，下表显示了SPD中的值、PFP标志、触发数据包中的值和SAD中的结果值之间的关系。请注意，IPsec的管理界面可以使用各种语法选项，使管理员更容易输入规则。例如，尽管IKEv2发送的是一个范围列表，但用户输入单个IP地址或IP地址前缀可能更清晰，更不容易出错。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc addr list of ranges 0 IP addr "S" list of ranges
ANY 0 IP addr "S" ANY
list of ranges 1 IP addr "S" "S"
ANY 1 IP addr "S" "S"
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc addr list of ranges 0 IP addr "S" list of ranges
ANY 0 IP addr "S" ANY
list of ranges 1 IP addr "S" "S"
ANY 1 IP addr "S" "S"
rem addr list of ranges 0 IP addr "D" list of ranges ANY 0 IP addr "D" ANY list of ranges 1 IP addr "D" "D" ANY 1 IP addr "D" "D"
rem addr范围列表0 IP addr“D”范围列表任何0 IP addr“D”范围列表任何1 IP addr“D”D“D”范围列表任何1 IP addr“D”D
protocol list of prot's* 0 prot. "P" list of prot's*
ANY** 0 prot. "P" ANY
OPAQUE**** 0 prot. "P" OPAQUE
protocol list of prot's* 0 prot. "P" list of prot's*
ANY** 0 prot. "P" ANY
OPAQUE**** 0 prot. "P" OPAQUE
list of prot's* 0 not avail. discard packet
ANY** 0 not avail. ANY
OPAQUE**** 0 not avail. OPAQUE
list of prot's* 0 not avail. discard packet
ANY** 0 not avail. ANY
OPAQUE**** 0 not avail. OPAQUE
list of prot's* 1 prot. "P" "P"
ANY** 1 prot. "P" "P"
OPAQUE**** 1 prot. "P" ***
list of prot's* 1 prot. "P" "P"
ANY** 1 prot. "P" "P"
OPAQUE**** 1 prot. "P" ***
list of prot's* 1 not avail. discard packet
ANY** 1 not avail. discard packet
OPAQUE**** 1 not avail. ***
list of prot's* 1 not avail. discard packet
ANY** 1 not avail. discard packet
OPAQUE**** 1 not avail. ***
If the protocol is one that has two ports, then there will be selectors for both Local and Remote ports.
如果协议有两个端口，那么本地和远程端口都有选择器。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc port list of ranges 0 src port "s" list of ranges
ANY 0 src port "s" ANY
OPAQUE 0 src port "s" OPAQUE
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc port list of ranges 0 src port "s" list of ranges
ANY 0 src port "s" ANY
OPAQUE 0 src port "s" OPAQUE
list of ranges 0 not avail. discard packet ANY 0 not avail. ANY OPAQUE 0 not avail. OPAQUE
范围列表0无效。丢弃任何0无效的数据包。任何不透明的0都无效。不透明的
list of ranges 1 src port "s" "s"
ANY 1 src port "s" "s"
OPAQUE 1 src port "s" ***
list of ranges 1 src port "s" "s"
ANY 1 src port "s" "s"
OPAQUE 1 src port "s" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
rem port list of ranges 0 dst port "d" list of ranges ANY 0 dst port "d" ANY OPAQUE 0 dst port "d" OPAQUE
rem端口范围列表0 dst端口“d”范围列表任何0 dst端口“d”任何不透明0 dst端口“d”不透明
list of ranges 0 not avail. discard packet ANY 0 not avail. ANY OPAQUE 0 not avail. OPAQUE
范围列表0无效。丢弃任何0无效的数据包。任何不透明的0都无效。不透明的
list of ranges 1 dst port "d" "d"
ANY 1 dst port "d" "d"
OPAQUE 1 dst port "d" ***
list of ranges 1 dst port "d" "d"
ANY 1 dst port "d" "d"
OPAQUE 1 dst port "d" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
If the protocol is mobility header, then there will be a selector for mh type.
如果协议是mobility header，那么将有一个mh类型选择器。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
mh type list of ranges 0 mh type "T" list of ranges
ANY 0 mh type "T" ANY
OPAQUE 0 mh type "T" OPAQUE
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
mh type list of ranges 0 mh type "T" list of ranges
ANY 0 mh type "T" ANY
OPAQUE 0 mh type "T" OPAQUE
list of ranges 0 not avail. discard packet ANY 0 not avail. ANY OPAQUE 0 not avail. OPAQUE
范围列表0无效。丢弃任何0无效的数据包。任何不透明的0都无效。不透明的
list of ranges 1 mh type "T" "T"
ANY 1 mh type "T" "T"
OPAQUE 1 mh type "T" ***
list of ranges 1 mh type "T" "T"
ANY 1 mh type "T" "T"
OPAQUE 1 mh type "T" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
If the protocol is ICMP, then there will be a 16-bit selector for ICMP type and ICMP code. Note that the type and code are bound to each other, i.e., the codes apply to the particular type. This 16-bit selector can contain a single type and a range of codes, a single type and ANY code, and ANY type and ANY code.
如果协议是ICMP，则ICMP类型和ICMP代码将有一个16位选择器。请注意，类型和代码是相互绑定的，即代码适用于特定类型。此16位选择器可以包含单个类型和一系列代码、单个类型和任意代码以及任意类型和任意代码。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
ICMP type a single type & 0 type "t" & single type &
and code range of codes code "c" range of codes
a single type & 0 type "t" & single type &
ANY code code "c" ANY code
ANY type & ANY 0 type "t" & ANY type &
code code "c" ANY code
OPAQUE 0 type "t" & OPAQUE
code "c"
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
ICMP type a single type & 0 type "t" & single type &
and code range of codes code "c" range of codes
a single type & 0 type "t" & single type &
ANY code code "c" ANY code
ANY type & ANY 0 type "t" & ANY type &
code code "c" ANY code
OPAQUE 0 type "t" & OPAQUE
code "c"
a single type & 0 not avail. discard packet range of codes a single type & 0 not avail. discard packet ANY code ANY type & 0 not avail. ANY type & ANY code ANY code OPAQUE 0 not avail. OPAQUE
单一类型&0无效。丢弃单一类型的代码包范围&0无效。丢弃数据包任何代码任何类型&0无效。任何类型&任何代码任何代码不透明0无效。不透明的
a single type & 1 type "t" & "t" and "c"
range of codes code "c"
a single type & 1 type "t" & "t" and "c"
ANY code code "c"
ANY type & 1 type "t" & "t" and "c"
ANY code code "c"
OPAQUE 1 type "t" & ***
code "c"
a single type & 1 type "t" & "t" and "c"
range of codes code "c"
a single type & 1 type "t" & "t" and "c"
ANY code code "c"
ANY type & 1 type "t" & "t" and "c"
ANY code code "c"
OPAQUE 1 type "t" & ***
code "c"
a single type & 1 not avail. discard packet
range of codes
a single type & 1 not avail. discard packet
ANY code
ANY type & 1 not avail. discard packet
ANY code
OPAQUE 1 not avail. ***
a single type & 1 not avail. discard packet
range of codes
a single type & 1 not avail. discard packet
ANY code
ANY type & 1 not avail. discard packet
ANY code
OPAQUE 1 not avail. ***
If the name selector is used:
如果使用名称选择器：
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
name list of user or N/A N/A N/A
system names
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
name list of user or N/A N/A N/A
system names
* "List of protocols" is the information, not the way
that the SPD or SAD or IKEv2 have to represent this
information.
** 0 (zero) is used by IKE to indicate ANY for
protocol.
*** Use of PFP=1 with an OPAQUE value is an error and
SHOULD be prohibited by an IPsec implementation.
**** The protocol field cannot be OPAQUE in IPv4. This
table entry applies only to IPv6.
* "List of protocols" is the information, not the way
that the SPD or SAD or IKEv2 have to represent this
information.
** 0 (zero) is used by IKE to indicate ANY for
protocol.
*** Use of PFP=1 with an OPAQUE value is an error and
SHOULD be prohibited by an IPsec implementation.
**** The protocol field cannot be OPAQUE in IPv4. This
table entry applies only to IPv6.
The Peer Authorization Database (PAD) provides the link between the SPD and a security association management protocol such as IKE. It embodies several critical functions:
对等授权数据库（PAD）提供SPD和安全关联管理协议（如IKE）之间的链接。它包含几个关键功能：
o identifies the peers or groups of peers that are authorized to communicate with this IPsec entity o specifies the protocol and method used to authenticate each peer o provides the authentication data for each peer o constrains the types and values of IDs that can be asserted by a peer with regard to child SA creation, to ensure that the peer does not assert identities for lookup in the SPD that it is not authorized to represent, when child SAs are created o peer gateway location info, e.g., IP address(es) or DNS names, MAY be included for peers that are known to be "behind" a security gateway
o 标识被授权与此IPsec实体通信的对等方或对等方组o指定用于验证每个对等方的协议和方法o为每个对等方提供验证数据o限制对等方可以声明的ID类型和值，以创建子SA，为确保对等方不会在SPD中声明其未被授权表示的查找身份，当创建子SA时，对等方网关位置信息（例如IP地址或DNS名称）可能会包括在安全网关“后面”的对等方
The PAD provides these functions for an IKE peer when the peer acts as either the initiator or the responder.
当IKE对等方充当发起方或响应方时，PAD为该对等方提供这些功能。
To perform these functions, the PAD contains an entry for each peer or group of peers with which the IPsec entity will communicate. An entry names an individual peer (a user, end system or security gateway) or specifies a group of peers (using ID matching rules defined below). The entry specifies the authentication protocol (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre-shared secrets) and the authentication data (e.g., the pre-shared
要执行这些功能，PAD包含IPsec实体将与之通信的每个对等方或对等方组的条目。条目命名单个对等方（用户、终端系统或安全网关）或指定一组对等方（使用下面定义的ID匹配规则）。该条目指定使用的认证协议（例如，IKEv1、IKEv2、KINK）方法（例如，证书或预共享机密）和认证数据（例如，预共享机密）
secret or the 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 CRL repository or the name of an Online Certificate Status Protocol (OCSP) server associated with the peer or with the trust anchor associated with the peer.
机密或将验证对等方证书的信任锚点）。对于基于证书的认证，该条目还可以提供有助于验证对等方的撤销状态的信息，例如，指向CRL存储库的指针或与对等方或与对等方关联的信任锚关联的在线证书状态协议（OCSP）服务器的名称。
Each entry also specifies whether the IKE ID payload will be used as a symbolic name for SPD lookup, or whether the remote IP address provided in traffic selector payloads will be used for SPD lookups when child SAs are created.
每个条目还指定IKE ID有效负载是否将用作SPD查找的符号名，或者在创建子SA时，流量选择器有效负载中提供的远程IP地址是否将用于SPD查找。
Note that the PAD information MAY be used to support creation of more than one tunnel mode SA at a time between two peers, e.g., two tunnels to protect the same addresses/hosts, but with different tunnel endpoints.
注意，PAD信息可用于支持在两个对等方（例如，两个隧道）之间一次创建多个隧道模式SA，以保护相同的地址/主机，但具有不同的隧道端点。
The PAD is an ordered database, where the order is defined by an administrator (or a user in the case of a single-user end system). Usually, the same administrator will be responsible for both the PAD and SPD, since the two databases must be coordinated. The ordering requirement for the PAD arises for the same reason as for the SPD, i.e., because use of "star name" entries allows for overlaps in the set of IKE IDs that could match a specific entry.
PAD是一个有序数据库，其中的顺序由管理员（或单用户终端系统中的用户）定义。通常，同一个管理员将同时负责PAD和SPD，因为这两个数据库必须协调。PAD的订购要求产生的原因与SPD的原因相同，即使用“星型名称”条目允许IKE ID集合中的重叠可以匹配特定条目。
Six types of IDs are supported for entries in the PAD, consistent with the symbolic name types and IP addresses used to identify SPD entries. The ID for each entry acts as the index for the PAD, i.e., it is the value used to select an entry. All of these ID types can be used to match IKE ID payload types. The six types are:
PAD中的条目支持六种类型的ID，与用于标识SPD条目的符号名称类型和IP地址一致。每个条目的ID用作PAD的索引，即，它是用于选择条目的值。所有这些ID类型都可以用于匹配IKE ID有效负载类型。这六种类型是：
o DNS name (specific or partial) o Distinguished Name (complete or sub-tree constrained) o RFC 822 email address (complete or partially qualified) o IPv4 address (range) o IPv6 address (range) o Key ID (exact match only)
o DNS名称（特定或部分）o可分辨名称（完整或子树约束）o RFC 822电子邮件地址（完整或部分限定）o IPv4地址（范围）o IPv6地址（范围）o密钥ID（仅精确匹配）
The first three name types can accommodate sub-tree matching as well as exact matches. A DNS name may be fully qualified and thus match exactly one name, e.g., foo.example.com. Alternatively, the name may encompass a group of peers by being partially specified, e.g., the string ".example.com" could be used to match any DNS name ending in these two domain name components.
前三种名称类型可以适应子树匹配以及精确匹配。DNS名称可能是完全限定的，因此与一个名称完全匹配，例如foo.example.com。或者，名称可以通过部分指定来包含一组对等方，例如，字符串“.example.com”可以用于匹配以这两个域名组件结尾的任何DNS名称。
Similarly, a Distinguished Name may specify a complete Distinguished Name to match exactly one entry, e.g., CN = Stephen, O = BBN Technologies, SP = MA, C = US. Alternatively, an entry may encompass a group of peers by specifying a sub-tree, e.g., an entry of the form "C = US, SP = MA" might be used to match all DNs that contain these two attributes as the top two Relative Distinguished Names (RDNs).
类似地，可分辨名称可以指定一个完整的可分辨名称来精确匹配一个条目，例如，CN=Stephen，O=BBN Technologies，SP=MA，C=US。或者，条目可以通过指定子树来包含一组对等体，例如，形式为“C=US，SP=MA”的条目可以用于匹配包含这两个属性的所有dn，作为前两个相对可分辨名称（rdn）。
For an RFC 822 e-mail addresses, the same options exist. A complete address such as foo@example.com matches one entity, but a sub-tree name such as "@example.com" could be used to match all the entities with names ending in those two domain names to the right of the @.
对于RFC 822电子邮件地址，存在相同的选项。完整的地址，如foo@example.com匹配一个实体，但子树名称（如“@example.com”）可用于匹配名称以@右侧这两个域名结尾的所有实体。
The specific syntax used by an implementation to accommodate sub-tree matching for distinguished names, domain names or RFC 822 e-mail addresses is a local matter. But, at a minimum, sub-tree matching of the sort described above MUST be supported. (Substring matching within a DN, DNS name, or RFC 822 address MAY be supported, but is not required.)
实现用于容纳可分辨名称、域名或RFC 822电子邮件地址的子树匹配的特定语法是本地事务。但是，至少必须支持上述类型的子树匹配。（可能支持DN、DNS名称或RFC 822地址内的子字符串匹配，但不是必需的。）
For IPv4 and IPv6 addresses, the same address range syntax used for SPD entries MUST be supported. This allows specification of an individual address (via a trivial range), an address prefix (by choosing a range that adheres to Classless Inter-Domain Routing (CIDR)-style prefixes), or an arbitrary address range.
对于IPv4和IPv6地址，必须支持用于SPD条目的相同地址范围语法。这允许指定单个地址（通过普通范围）、地址前缀（通过选择遵循无类域间路由（CIDR）样式前缀的范围）或任意地址范围。
The Key ID field is defined as an OCTET string in IKE. For this name type, only exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type.
密钥ID字段在IKE中定义为八位字节字符串。对于此名称类型，必须只支持精确匹配语法（因为此ID类型没有显式结构）。此ID类型可能支持其他匹配函数。
Once an entry is located based on an ordered search of the PAD based on ID field matching, it is necessary to verify the asserted identity, i.e., to authenticate the asserted ID. For each PAD entry, there is an indication of the type of authentication to be performed. This document requires support for two required authentication data types:
一旦根据基于ID字段匹配的PAD有序搜索找到条目，就必须验证断言的身份，即验证断言的ID。对于每个PAD条目，都有要执行的验证类型的指示。本文档要求支持两种必需的身份验证数据类型：
- X.509 certificate - pre-shared secret
- X.509证书-预共享机密
For authentication based on an X.509 certificate, the PAD entry contains a trust anchor via which the end entity (EE) certificate for the peer must be verifiable, either directly or via a certificate path. See RFC 3280 for the definition of a trust anchor. An entry used with certificate-based authentication MAY include additional data to facilitate certificate revocation status, e.g., a list of
对于基于X.509证书的身份验证，PAD条目包含一个信任锚，通过该信任锚，对等方的终端实体（EE）证书必须可以直接或通过证书路径进行验证。有关信任锚的定义，请参见RFC 3280。与基于证书的认证一起使用的条目可以包括用于促进证书撤销状态的附加数据，例如，证书撤销状态列表
appropriate OCSP responders or CRL repositories, and associated authentication data. For authentication based on a pre-shared secret, the PAD contains the pre-shared secret to be used by IKE.
适当的OCSP响应程序或CRL存储库，以及相关的身份验证数据。对于基于预共享秘密的身份验证，PAD包含由IKE使用的预共享秘密。
This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. Thus, implementations MUST provide a means for an administrator to require a match between an asserted IKE ID and the subject name or subject alt name in a certificate. The former is applicable to IKE IDs expressed as distinguished names; the latter is appropriate for DNS names, RFC 822 e-mail addresses, and IP addresses. Since KEY ID is intended for identifying a peer authenticated via a pre-shared secret, there is no requirement to match this ID type to a certificate field.
本文档不要求对等方声明的IKE ID在语法上与用于认证该对等方身份的终端实体证书中的特定字段相关。然而，通常适用于实施此类要求，例如，当单个条目代表一组对等方时，每个对等方可能具有不同的SPD条目。因此，实现必须为管理员提供一种方法，要求在断言的IKE ID和证书中的使用者名称或使用者alt名称之间进行匹配。前者适用于以可分辨名称表示的IKE ID；后者适用于DNS名称、RFC 822电子邮件地址和IP地址。由于密钥ID用于识别通过预共享密钥进行身份验证的对等方，因此不需要将此ID类型与证书字段相匹配。
See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE performs peer authentication using certificates or pre-shared secrets.
有关IKE如何使用证书或预共享机密执行对等身份验证的详细信息，请参见IKEv1[HarCar98]和IKEv2[Kau05]。
This document does not mandate support for any other authentication methods, although such methods MAY be employed.
本文档不要求支持任何其他身份验证方法，尽管可以使用此类方法。
Once an IKE peer is authenticated, child SAs may be created. Each PAD entry contains data to constrain the set of IDs that can be asserted by an IKE peer, for matching against the SPD. Each PAD entry indicates whether the IKE ID is to be used as a symbolic name for SPD matching, or whether an IP address asserted in a traffic selector payload is to be used.
一旦IKE对等方经过身份验证，就可以创建子SA。每个PAD条目都包含用于约束IKE对等方可以断言的ID集的数据，以便与SPD进行匹配。每个PAD条目指示IKE ID是否用作SPD匹配的符号名，或者是否使用在流量选择器有效负载中声明的IP地址。
If the entry indicates that the IKE ID is to be used, then the PAD entry ID field defines the authorized set of IDs. If the entry indicates that child SAs traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges. (A peer may be authorized for both address types, so there MUST be provision for both a v4 and a v6 address range.)
如果条目指示要使用IKE ID，则PAD条目ID字段定义授权的ID集。如果条目指示要使用子SAs流量选择器，则需要一个额外的数据元素，其形式为IPv4和/或IPv6地址范围。（对等方可能被授权使用这两种地址类型，因此必须同时提供v4和v6地址范围。）
During the initial IKE exchange, the initiator and responder each assert their identity via the IKE ID payload and send an AUTH payload to verify the asserted identity. One or more CERT payloads may be transmitted to facilitate the verification of each asserted identity.
在初始IKE交换期间，发起方和响应方各自通过IKE ID有效负载声明其身份，并发送验证有效负载以验证声明的身份。可以传输一个或多个证书有效载荷，以便于验证每个断言的身份。
When an IKE entity receives an IKE ID payload, it uses the asserted ID to locate an entry in the PAD, using the matching rules described above. The PAD entry specifies the authentication method to be employed for the identified peer. This ensures that the right method is used for each peer and that different methods can be used for different peers. 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 peer, before any CHILD SAs are created.
当IKE实体接收到IKE ID有效负载时，它使用断言的ID，使用上述匹配规则在PAD中定位条目。PAD条目指定要用于已识别对等方的身份验证方法。这可以确保每个对等点使用正确的方法，并且不同的对等点可以使用不同的方法。该条目还指定将用于验证断言标识的身份验证数据。在创建任何子SA之前，此数据与指定方法一起用于对对等方进行身份验证。
Child SAs are created based on the exchange of traffic selector payloads, either at the end of the initial IKE exchange or in subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now authenticated) IKE peer is used to constrain creation of child SAs; specifically, the PAD entry specifies how the SPD is searched using a traffic selector proposal from a peer. There are two choices: either the IKE ID asserted by the peer is used to find an SPD entry via its symbolic name, or peer IP addresses asserted in traffic selector payloads are used for SPD lookups based on the remote IP address field portion of an SPD entry. It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers.
子SA是基于流量选择器有效负载的交换而创建的，可以在初始IKE交换结束时创建，也可以在后续的CREATE_Child_SA交换中创建。IKE对等方（现在已认证）的PAD条目用于约束子SA的创建；具体而言，PAD条目指定如何使用来自对等方的流量选择器建议搜索SPD。有两种选择：要么使用对等方声明的IKE ID通过其符号名称查找SPD条目，要么使用流量选择器有效负载中声明的对等IP地址根据SPD条目的远程IP地址字段部分进行SPD查找。有必要对子SA的创建施加这些约束，以防止经过身份验证的对等方欺骗与其他合法对等方关联的ID。
Note that because the PAD is checked before searching for an SPD entry, this safeguard protects an initiator against spoofing attacks. For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 [RFC2401] and this document do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. Thus, the PAD provides a binding of address ranges (or name sub-spaces) to peers, to counter such attacks.
请注意，由于在搜索SPD条目之前检查了PAD，因此此保护措施可保护启动器免受欺骗攻击。例如，假设IKE A接收到一个目的地为IP地址X（由安全网关服务的主机）的出站数据包。RFC 2401[RFC2401]和本文件未规定A如何确定服务于X的IKE对等方的地址。但是，A作为X的假定代表联系的任何对等方必须在PAD中注册，以便允许对IKE交换进行身份验证。此外，当经过身份验证的对等方断言其在其流量选择器交换中代表X时，将咨询PAD以确定所述对等方是否被授权代表X。因此，PAD向对等方提供地址范围（或名称子空间）的绑定，以对抗此类攻击。
All IPsec implementations MUST support both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti-replay service available for AH and ESP requires automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. In general, data origin authentication in AH and ESP is limited by the
所有IPsec实施都必须支持手动和自动SA和加密密钥管理。IPsec协议AH和ESP在很大程度上独立于相关的SA管理技术，尽管所涉及的技术确实会影响协议提供的一些安全服务。例如，AH和ESP的可选防重播服务需要自动化SA管理。此外，IPsec采用的密钥分发粒度决定了提供的身份验证的粒度。通常，AH和ESP中的数据源身份验证受到
extent to which secrets used with the integrity algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources.
与完整性算法（或与创建此类机密的密钥管理协议）一起使用的机密在多个可能的源之间共享的程度。
The following text describes the minimum requirements for both types of SA management.
以下文字描述了这两种SA管理的最低要求。
The simplest form of management is manual management, in which a person manually configures each system with keying material and SA management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a virtual private network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this might be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist.
最简单的管理形式是手动管理，在手动管理中，一个人使用与其他系统安全通信相关的密钥材料和SA管理数据手动配置每个系统。手动技术在小型静态环境中很实用，但不能很好地扩展。例如，一家公司可以在多个站点的安全网关中使用IPsec创建虚拟专用网络（VPN）。如果站点的数量很小，并且由于所有站点都在单个管理域的权限范围内，这可能是手动管理技术的可行环境。在这种情况下，安全网关可以使用手动配置的密钥选择性地保护与组织内其他站点之间的通信量，而不保护其他目的地的通信量。当只需要对选定的通信进行安全保护时，它也可能是合适的。类似的论点可能适用于在组织内对少量主机和/或网关完全使用IPsec。手动管理技术通常使用静态配置的对称密钥，尽管也存在其他选项。
Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.)
IPsec的广泛部署和使用需要一个Internet标准、可扩展、自动化的SA管理协议。需要此类支持，以便于使用AH和ESP的防重放功能，并适应SA的按需创建，例如面向用户和会话的键控。（请注意，“重新键入”SA的概念实际上意味着使用新的SPI创建新SA，这一过程通常意味着使用自动化SA/密钥管理协议。）
The default automated key management protocol selected for use with IPsec is IKEv2 [Kau05]. This document assumes the availability of certain functions from the key management protocol that are not supported by IKEv1. Other automated SA management protocols MAY be employed.
选择用于IPsec的默认自动密钥管理协议是IKEv2[Kau05]。本文档假设密钥管理协议中的某些功能可用，但IKEv1不支持这些功能。可采用其他自动化SA管理协议。
When an automated SA/key management protocol is employed, the output from this protocol is used to generate multiple keys for a single SA. This also occurs because distinct keys are used for each of the two
当采用自动化SA/密钥管理协议时，该协议的输出用于为单个SA生成多个密钥。这种情况也会发生，因为这两个键中的每一个都使用不同的键
SAs created by IKE. If both integrity and confidentiality are employed, then a minimum of four keys are required. Additionally, some cryptographic algorithms may require multiple keys, e.g., 3DES.
由IKE创建的SAs。如果同时采用完整性和保密性，则至少需要四把钥匙。此外，一些加密算法可能需要多个密钥，例如3DE。
The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all keys are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption keys MUST be taken from the first (left-most, high-order) bits and the integrity keys MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant cryptographic algorithm specification RFC. In the case of multiple encryption keys or multiple integrity keys, the specification for the cryptographic algorithm must specify the order in which they are to be selected from a single string of bits provided to the cryptographic algorithm.
密钥管理系统可以为每个密钥提供单独的比特串，或者可以生成一个比特串，从中提取所有密钥。如果提供单个比特串，则需要注意确保将比特串映射到所需密钥的系统部分在SA的两端以相同的方式进行映射。为了确保SA两端的IPsec实现对相同的密钥使用相同的位，并且无论系统的哪个部分将位串划分为单独的密钥，加密密钥必须从第一位（最左边的高阶）获取，完整性密钥必须从其余位获取。每个密钥的位数在相关密码算法规范RFC中定义。在多个加密密钥或多个完整性密钥的情况下，加密算法的规范必须指定从提供给加密算法的单个比特串中选择它们的顺序。
This section discusses issues relating to how a host learns about the existence of relevant security gateways and, once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter, but the Peer Authorization Database (PAD) described in Section 4.4 is the most likely candidate. (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2 below.)
本节讨论与主机如何了解相关安全网关的存在有关的问题，以及主机一旦接触这些安全网关，如何知道这些是正确的安全网关。所需信息存储位置的详细信息是本地事务，但第4.4节中描述的对等授权数据库（PAD）是最可能的候选数据库。（注意：S*表示运行IPsec的系统，例如下面的SH1和SG2。）
Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host crossing the Internet to his home organization's firewall (SG2). This situation raises several issues:
考虑远程主机（SH1）正在使用因特网来访问服务器或其他机器（H2）的情况，并且存在一个安全网关（SG2），例如防火墙，通过该防火墙，H1的流量必须通过。这种情况的一个例子是，一个移动主机通过互联网到达其所在组织的防火墙（SG2）。这种情况引发了几个问题：
1. How does SH1 know/learn about the existence of the security gateway SG2?
1. SH1如何知道/了解安全网关SG2的存在？
2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2?
2. 它如何认证SG2，一旦它认证了SG2，它如何确认SG2已被授权代表H2？
3. How does SG2 authenticate SH1 and verify that SH1 is authorized to contact H2?
3. SG2如何认证SH1并验证SH1有权联系H2？
4. How does SH1 know/learn about any additional gateways that provide alternate paths to H2?
4. SH1如何知道/了解提供H2备用路径的任何其他网关？
To address these problems, an IPsec-supporting host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of one or more security gateways for ranges of destination addresses that require its use. This includes the ability to configure information for locating and authenticating one or more security gateways and verifying the authorization of these gateways to represent the destination host. (The authorization function is implied in the PAD.) This document does not address the issue of how to automate the discovery/verification of security gateways.
要解决这些问题，支持IPsec的主机或安全网关必须具有一个管理界面，该界面允许用户/管理员为需要使用的目标地址范围配置一个或多个安全网关的地址。这包括配置信息以定位和验证一个或多个安全网关以及验证这些网关代表目标主机的授权的能力。（PAD中暗示了授权功能。）本文档不涉及如何自动发现/验证安全网关的问题。
The receiver-orientation of the SA implies that, in the case of unicast traffic, the destination system will select the SPI value. By having the destination select the SPI value, there is no potential for manually configured SAs to conflict with automatically configured (e.g., via a key management protocol) SAs or for SAs from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems associated with a single SA. So some system or person will need to coordinate among all multicast groups to select an SPI or SPIs on behalf of each multicast group and then communicate the group's IPsec information to all of the legitimate members of that multicast group via mechanisms not defined here.
SA的接收器方向意味着，在单播业务的情况下，目的地系统将选择SPI值。通过让目的地选择SPI值，手动配置的SAs不可能与自动配置（例如，通过密钥管理协议）的SAs冲突，也不可能来自多个源的SAs相互冲突。对于多播流量，有多个目标系统与单个SA关联。因此，一些系统或个人需要在所有多播组之间进行协调，以代表每个多播组选择一个或多个SPI，然后通过此处未定义的机制将组的IPsec信息传递给该多播组的所有合法成员。
Multiple senders to a multicast group SHOULD use a single Security Association (and hence SPI) for all traffic to that group when a symmetric key encryption or integrity algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic. Specifications for other, more general multicast approaches are deferred to the IETF Multicast Security Working Group.
当采用对称密钥加密或完整性算法时，一个多播组的多个发送方应该对该组的所有通信使用一个安全关联（从而使用SPI）。在这种情况下，接收方只知道消息来自拥有该多播组密钥的系统。在这种情况下，接收器通常无法验证哪个系统发送了多播流量。其他更通用的多播方法的规范由IETF多播安全工作组制定。
As mentioned in Section 4.4.1, "The Security Policy Database (SPD)", the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the
如第4.4.1节“安全策略数据库（SPD）”所述，在处理跨越IPsec保护边界的所有流量（包括IPsec管理流量）期间，必须查阅SPD（或相关缓存）。如果在SPD中未找到与数据包匹配的策略（对于入站或出站流量），则必须丢弃该数据包。为了简化处理，并允许非常快速的SA查找（对于SG/BITS/BITW），本文档介绍
notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As mentioned earlier, the SAD acts as a cache for checking the selectors of inbound IPsec-protected traffic arriving on SAs.) There is nominally one cache per SPD. For the purposes of this specification, it is assumed that each cached entry will map to exactly one SA. Note, however, exceptions arise when one uses multiple SAs to carry traffic of different priorities (e.g., as indicated by distinct DSCP values) but the same selectors. Note also, that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry.
所有出站流量的SPD缓存（SPD-O加上SPD-S）和入站非IPsec保护流量的缓存（SPD-I）的概念。（如前所述，SAD充当缓存，用于检查SAs上到达的受IPsec保护的入站流量的选择器。）每个SPD名义上有一个缓存。出于本规范的目的，假设每个缓存条目将映射到一个SA。但是，请注意，当使用多个SA承载不同优先级（例如，由不同的DSCP值指示）但具有相同选择器的流量时，会出现例外情况。还请注意，有两种情况下，SAD可能会有SAs的条目，而这些条目在SPD中没有相应的条目。由于本文件不要求在更改SPD时有选择地清除SAD，因此在更改或删除创建SAD条目的SPD条目时，SAD条目可以保留。此外，如果创建了手动键控SA，则此SA可能存在与任何SPD条目不对应的SAD条目。
Since SPD entries may overlap, one cannot safely cache these entries in general. Simple caching might result in a match against a cache entry, whereas an ordered search of the SPD would have resulted in a match against a different entry. But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached. Each cached entry will indicate that matching traffic should be bypassed or discarded, appropriately. (Note: The original SPD entry might result in multiple SAs, e.g., because of PFP.) Unless otherwise noted, all references below to the "SPD" or "SPD cache" or "cache" are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache containing entries from the decorrelated SPD.
由于SPD条目可能重叠，通常无法安全缓存这些条目。简单缓存可能会导致与缓存项的匹配，而对SPD的有序搜索可能会导致与其他项的匹配。但是，如果先将SPD条目解相关，则可以安全地缓存结果条目。每个缓存条目都将指示应适当地绕过或丢弃匹配的流量。（注意：原始SPD条目可能会导致多个SA，例如，由于PFP。）除非另有说明，以下所有对“SPD”或“SPD缓存”或“缓存”的引用都是指解相关SPD（SPD-I、SPD-O、SPD-S）或包含解相关SPD条目的SPD缓存。
Note: In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket. This provides an implicit caching mechanism, and the portions of the preceding discussion that address caching can be ignored in such implementations.
注意：在基于套接字的主机IPsec实现中，每当创建新套接字时，都会咨询SPD，以确定将对该套接字上的流量应用什么（如果有的话）IPsec处理。这提供了一种隐式缓存机制，前面讨论的地址缓存部分在这种实现中可以忽略。
Note: It is assumed that one starts with a correlated SPD because that is how users and administrators are accustomed to managing these sorts of access control lists or firewall filter rules. Then the decorrelation algorithm is applied to build a list of cache-able SPD entries. The decorrelation is invisible at the management interface.
注意：假设一个以相关的SPD开始，因为这是用户和管理员习惯于管理此类访问控制列表或防火墙过滤规则的方式。然后应用解相关算法建立一个可缓存SPD条目列表。在管理界面上，解相关是不可见的。
For inbound IPsec traffic, the SAD entry selected by the SPI serves as the cache for the selectors to be matched against arriving IPsec packets, after AH or ESP processing has been performed.
对于入站IPsec流量，在执行AH或ESP处理后，SPI选择的SAD条目用作选择器的缓存，以便与到达的IPsec数据包进行匹配。
First consider the path for traffic entering the implementation via a protected interface and exiting via an unprotected interface.
首先考虑通过受保护的接口进入实现的路径，并通过非保护接口退出。
Unprotected Interface
^
|
(nested SAs) +----------+
-------------------|Forwarding|<-----+
| +----------+ |
| ^ |
| | BYPASS |
V +-----+ |
+-------+ | SPD | +--------+
...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
| (*) | | (*) |---->|(AH/ESP)| boundary
+-------+ +-----+ +--------+
| +-------+ / ^
| |DISCARD| <--/ |
| +-------+ |
| |
| +-------------+
|---------------->|SPD Selection|
+-------------+
^
| +------+
| -->| ICMP |
| / +------+
|/
|
|
Protected Interface
Unprotected Interface
^
|
(nested SAs) +----------+
-------------------|Forwarding|<-----+
| +----------+ |
| ^ |
| | BYPASS |
V +-----+ |
+-------+ | SPD | +--------+
...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
| (*) | | (*) |---->|(AH/ESP)| boundary
+-------+ +-----+ +--------+
| +-------+ / ^
| |DISCARD| <--/ |
| +-------+ |
| |
| +-------------+
|---------------->|SPD Selection|
+-------------+
^
| +------+
| -->| ICMP |
| / +------+
|/
|
|
Protected Interface
Figure 2. Processing Model for Outbound Traffic (*) = The SPD caches are shown here. If there is a cache miss, then the SPD is checked. There is no requirement that an implementation buffer the packet if there is a cache miss.
图2。出站流量（*）的处理模型=此处显示了SPD缓存。如果缓存未命中，则检查SPD。如果缓存未命中，则不要求实现缓冲数据包。
IPsec MUST perform the following steps when processing outbound packets:
IPsec在处理出站数据包时必须执行以下步骤：
1. When a packet arrives from the subscriber (protected) interface, invoke the SPD selection function to obtain the SPD-ID needed to choose the appropriate SPD. (If the implementation uses only one SPD, this step is a no-op.)
1. 当数据包从用户（受保护）接口到达时，调用SPD选择功能以获取选择适当SPD所需的SPD-ID。（如果实施仅使用一个SPD，则此步骤为禁止操作。）
2. Match the packet headers against the cache for the SPD specified by the SPD-ID from step 1. Note that this cache contains entries from SPD-O and SPD-S.
2. 将数据包头与步骤1中SPD-ID指定的SPD缓存相匹配。请注意，此缓存包含来自SPD-O和SPD-S的条目。
3a. If there is a match, then process the packet as specified by the matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH or ESP. If IPsec processing is applied, there is a link from the SPD cache entry to the relevant SAD entry (specifying the mode, cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec processing is as previously defined, for tunnel or transport modes and for AH or ESP, as specified in their respective RFCs [Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of the stateful fragment checking flag (and the DF bit in the IP header of the outbound packet) determine whether the packet can (must) be fragmented prior to or after IPsec processing, or if it must be discarded and an ICMP PMTU message is sent.
3a。如果存在匹配项，则按照匹配缓存项指定的方式处理数据包，即使用AH或ESP绕过、丢弃或保护。如果应用IPsec处理，则存在从SPD缓存项到相关SAD项的链接（指定模式、加密算法、密钥、SPI、PMTU等）。IPsec处理如前所述，用于隧道或传输模式以及AH或ESP，如各自RFC[Ken05b，Ken05a]中所述。请注意，SA PMTU值加上有状态片段检查标志的值（以及出站数据包的IP报头中的DF位）确定数据包是否可以（必须）在IPsec处理之前或之后进行片段化，或者是否必须丢弃数据包并发送ICMP PMTU消息。
3b. If no match is found in the cache, search the SPD (SPD-S and SPD-O parts) specified by SPD-ID. If the SPD entry calls for BYPASS or DISCARD, create one or more new outbound SPD cache entries and if BYPASS, create one or more new inbound SPD cache entries. (More than one cache entry may be created since a decorrelated SPD entry may be linked to other such entries that were created as a side effect of the decorrelation process.) If the SPD entry calls for PROTECT, i.e., creation of an SA, the key management mechanism (e.g., IKEv2) is invoked to create the SA. If SA creation succeeds, a new outbound (SPD-S) cache entry is created, along with outbound and inbound SAD entries, otherwise the packet is discarded. (A packet that triggers an SPD lookup MAY be discarded by the implementation, or it MAY be processed against the newly created cache entry, if one is created.) Since SAs are created in pairs, an SAD entry for the corresponding inbound SA also is created, and it contains the selector values derived from the SPD entry (and packet, if any PFP flags were "true") used to create the inbound SA, for use in checking inbound traffic delivered via the SA.
3b。如果在缓存中未找到匹配项，则搜索由SPD-ID指定的SPD（SPD-S和SPD-O部件）。如果SPD条目要求绕过或放弃，则创建一个或多个新的出站SPD缓存条目，如果绕过，则创建一个或多个新的入站SPD缓存条目。（由于解相关的SPD条目可以链接到作为解相关过程的副作用而创建的其他此类条目，因此可以创建多个缓存条目。）如果SPD条目需要保护，即创建SA，则调用密钥管理机制（例如IKEv2）来创建SA。如果SA创建成功，将创建新的出站（SPD-S）缓存项以及出站和入站SAD项，否则将丢弃数据包。（触发SPD查找的数据包可能会被实现丢弃，或者可能会针对新创建的缓存条目（如果创建了缓存条目）进行处理。）由于SAs是成对创建的，因此也会为相应的入站SA创建SAD条目，并且它包含从SPD条目派生的选择器值（和数据包，如果任何PFP标志为“true”），用于创建入站SA，用于检查通过SA交付的入站流量。
4. The packet is passed to the outbound forwarding function (operating outside of the IPsec implementation), to select the interface to which the packet will be directed. This function
4. 数据包被传递到出站转发功能（在IPsec实现之外操作），以选择数据包将被定向到的接口。此函数
may cause the packet to be passed back across the IPsec boundary, for additional IPsec processing, e.g., in support of nested SAs. If so, there MUST be an entry in SPD-I database that permits inbound bypassing of the packet, otherwise the packet will be discarded. If necessary, i.e., if there is more than one SPD-I, the traffic being looped back MAY be tagged as coming from this internal interface. This would allow the use of a different SPD-I for "real" external traffic vs. looped traffic, if needed.
可能导致数据包通过IPsec边界传回，以进行额外的IPsec处理，例如，支持嵌套SAs。如果是这样，SPD-I数据库中必须有一个条目，允许对数据包进行入站旁路，否则数据包将被丢弃。如有必要，即，如果存在多个SPD-i，则被环回的流量可被标记为来自该内部接口。如果需要，这将允许使用不同的SPD-I，用于“真实”外部流量与环路流量。
Note: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. (This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.) The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers (or ICMP message type and code, or Mobility Header type) will only match rules having port (or ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for more details.)
注意：除IPv4和IPv6传输模式外，SG、BITS或BITW实现可能会在应用IPsec之前对数据包进行分段。（这仅适用于IPv4。对于IPv6数据包，仅允许原始发件人对其进行分段。）设备应具有禁用此功能的配置设置。以正常方式根据SPD评估产生的碎片。因此，不包含端口号（或ICMP消息类型和代码，或移动报头类型）的片段将只匹配具有不透明或任意类型的端口（或ICMP消息类型和代码，或MH类型）选择器的规则。（详见第7节。）
Note: With regard to determining and enforcing the PMTU of an SA, the IPsec system MUST follow the steps described in Section 8.2.
注意：关于确定和实施SA的PMTU，IPsec系统必须遵循第8.2节中描述的步骤。
If an IPsec system receives an outbound packet that it finds it must discard, it SHOULD be capable of generating and sending an ICMP message to indicate to the sender of the outbound packet that the packet was discarded. The type and code of the ICMP message will depend on the reason for discarding the packet, as specified below. The reason SHOULD be recorded in the audit log. The audit log entry for this event SHOULD include the reason, current date/time, and the selector values from the packet.
如果IPsec系统接收到它发现必须丢弃的出站数据包，它应该能够生成并发送ICMP消息，以向出站数据包的发送方指示该数据包已被丢弃。ICMP消息的类型和代码将取决于丢弃数据包的原因，如下所述。原因应记录在审核日志中。此事件的审核日志条目应包括原因、当前日期/时间以及数据包中的选择器值。
a. The selectors of the packet matched an SPD entry requiring the packet to be discarded.
a. 数据包的选择器与要求丢弃数据包的SPD条目匹配。
IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited)
IPv4类型=3（目标不可访问）代码=13（通信管理禁止）
IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited)
IPv6类型=1（目标不可访问）代码=1（与目标的通信被管理禁止）
b1. The IPsec system successfully reached the remote peer but was unable to negotiate the SA required by the SPD entry matching the packet because, for example, the remote peer is administratively prohibited from communicating with the initiator, the initiating
b1。IPsec系统已成功到达远程对等方，但无法协商与数据包匹配的SPD条目所需的SA，因为，例如，管理上禁止远程对等方与发起方（发起方）通信
peer was unable to authenticate itself to the remote peer, the remote peer was unable to authenticate itself to the initiating peer, or the SPD at the remote peer did not have a suitable entry.
对等方无法向远程对等方验证自身，远程对等方无法向发起对等方验证自身，或者远程对等方的SPD没有合适的条目。
IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited)
IPv4类型=3（目标不可访问）代码=13（通信管理禁止）
IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited)
IPv6类型=1（目标不可访问）代码=1（与目标的通信被管理禁止）
b2. The IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange could not be contacted.
b2。IPsec系统无法设置与数据包匹配的SPD条目所需的SA，因为无法联系交换机另一端的IPsec对等方。
IPv4 Type = 3 (destination unreachable) Code = 1 (host unreachable)
IPv4类型=3（目标不可访问）代码=1（主机不可访问）
IPv6 Type = 1 (destination unreachable) Code = 3 (address unreachable)
IPv6类型=1（无法访问目标）代码=3（无法访问地址）
Note that an attacker behind a security gateway could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity for a denial of service (DoS) attack among hosts behind a security gateway. To address this, a security gateway SHOULD include a management control to allow an administrator to configure an IPsec implementation to send or not send the ICMP messages under these circumstances, and if this facility is selected, to rate limit the transmission of such ICMP responses.
请注意，安全网关后面的攻击者可以向IPsec实体发送带有伪造源地址W.X.Y.Z的数据包，从而使其向W.X.Y.Z发送ICMP消息。这会在安全网关后面的主机之间造成拒绝服务（DoS）攻击的机会。为解决此问题，安全网关应包括一个管理控件，以允许管理员配置IPsec实现，以便在这些情况下发送或不发送ICMP消息，并且如果选择了此功能，则对此类ICMP响应的传输进行速率限制。
This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels, with regard to outbound traffic processing. This includes how to construct the encapsulating (outer) IP header, how to process fields in the inner IP header, and what other actions should be taken for outbound, tunnel mode traffic. The general processing described here is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
本节介绍了AH和ESP隧道内部和外部IP报头、扩展报头和选项的处理，以及出站流量处理。这包括如何构造封装（外部）IP报头，如何处理内部IP报头中的字段，以及对于出站、隧道模式流量应采取的其他操作。此处描述的一般处理是根据RFC 2003“IP内的IP封装”[Per96]建模的：
o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). 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.
o 外部IP头源地址和目标地址标识隧道的“端点”（封装器和解封装器）。内部IP报头源地址和目标地址分别标识数据报的原始发送方和接收方（从这个隧道的角度）。
(See footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.)
（有关封装源IP地址的更多详细信息，请参见5.1.2.1中表格后的脚注3。）
o The inner IP header is not changed except as noted below for TTL (or Hop Limit) and the DS/ECN Fields. The inner IP header otherwise remains unchanged during its delivery to the tunnel exit point.
o 内部IP报头不会更改，除非下面对TTL（或跃点限制）和DS/ECN字段进行了说明。否则，内部IP报头在传送到隧道出口点期间保持不变。
o No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel.
o 在通过隧道传递封装的数据报期间，内部报头中的IP选项或扩展报头不会发生任何更改。
Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC 2003 [Per96]) in several ways:
注意：IPsec隧道模式与IP隧道中的IP（RFC 2003[Per96]）在以下几个方面不同：
o IPsec offers certain controls to a security administrator to manage covert channels (which would not normally be a concern for tunneling) and to ensure that the receiver examines the right portions of the received packet with respect to application of access controls. An IPsec implementation MAY be configurable with regard to how it processes the outer DS field for tunnel mode for transmitted packets. For outbound traffic, one configuration setting for the outer DS field will operate as described in the following sections on IPv4 and IPv6 header processing for IPsec tunnels. Another will allow the outer DS field to be mapped to a fixed value, which MAY be configured on a per-SA basis. (The value might really be fixed for all traffic outbound from a device, but per-SA granularity allows that as well.) This configuration option allows a local administrator to decide whether the covert channel provided by copying these bits outweighs the benefits of copying.
o IPsec为安全管理员提供了某些控制，以管理隐蔽通道（这通常不会成为隧道的问题），并确保接收器检查接收到的数据包中与访问控制应用相关的正确部分。IPsec实现可以是可配置的，关于它如何处理用于传输分组的隧道模式的外部DS字段。对于出站流量，外部DS字段的一个配置设置将按照以下关于IPsec隧道的IPv4和IPv6报头处理的部分中所述操作。另一个将允许外部DS字段映射到一个固定值，该固定值可以基于每个SA进行配置。（对于设备的所有出站流量，该值可能确实是固定的，但每个SA粒度也允许该值。）此配置选项允许本地管理员决定复制这些位所提供的隐蔽通道是否超过复制的好处。
o IPsec describes how to handle ECN or DS and provides the ability to control propagation of changes in these fields between unprotected and protected domains. In general, propagation from a protected to an unprotected domain is a covert channel and thus controls are provided to manage the bandwidth of this channel. Propagation of ECN values in the other direction are controlled so that only legitimate ECN changes (indicating occurrence of congestion between the tunnel endpoints) are propagated. By default, DS propagation from an unprotected domain to a protected domain is not permitted. However, if the sender and receiver do not share the same DS code space, and the receiver has no way of learning how to map between the two spaces, then it may be appropriate to deviate from the default. Specifically, an IPsec implementation MAY be configurable in terms of how it processes the outer DS field for tunnel mode for received packets. It may be configured to either discard the outer DS value (the default) OR to overwrite the inner DS field with the outer DS field. If
o IPsec描述了如何处理ECN或DS，并提供了控制这些字段中的更改在未受保护域和受保护域之间传播的能力。一般来说，从受保护域到未受保护域的传播是一个隐蔽通道，因此提供控制来管理该通道的带宽。控制ECN值在另一个方向的传播，以便仅传播合法的ECN更改（指示隧道端点之间发生拥塞）。默认情况下，不允许DS从未受保护的域传播到受保护的域。但是，如果发送方和接收方不共享相同的DS代码空间，并且接收方无法学习如何在这两个空间之间映射，则可能需要偏离默认设置。具体地，IPsec实现可以根据其如何处理用于接收的分组的隧道模式的外部DS字段来配置。它可以配置为放弃外部DS值（默认值）或用外部DS字段覆盖内部DS字段。如果
offered, the discard vs. overwrite behavior MAY be configured on a per-SA basis. This configuration option allows a local administrator to decide whether the vulnerabilities created by copying these bits outweigh the benefits of copying. See [RFC2983] for further information on when each of these behaviors may be useful, and also for the possible need for diffserv traffic conditioning prior or subsequent to IPsec processing (including tunnel decapsulation).
提供时，可以根据每个SA配置放弃与覆盖行为。此配置选项允许本地管理员决定通过复制这些位创建的漏洞是否超过了复制的好处。请参阅[RFC2983]了解关于这些行为何时有用的更多信息，以及在IPsec处理之前或之后可能需要区分服务流量调节（包括隧道解除封装）。
o IPsec allows the IP version of the encapsulating header to be different from that of the inner header.
o IPsec允许封装头的IP版本与内部头的IP版本不同。
The tables in the following sub-sections show the handling for the different header/option fields ("constructed" means that the value in the outer field is constructed independently of the value in the inner).
以下小节中的表格显示了对不同标题/选项字段的处理（“构造”表示外部字段中的值独立于内部字段中的值构造）。
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragment offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP no change
checksum constructed constructed (2)(6)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragment offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP no change
checksum constructed constructed (2)(6)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
Notes:
笔记：
(1) The IP version in the encapsulating header can be different from the value in the inner header.
(1) 封装标头中的IP版本可能与内部标头中的值不同。
(2) The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The IPv4 checksum changes when the TTL changes.)
(2) 内部报头中的TTL在转发前由封装器递减，在转发数据包时由去封装器递减。（当TTL更改时，IPv4校验和将更改。）
Note: Decrementing the TTL value is a normal part of forwarding a packet. Thus, a packet originating from the same node as the encapsulator does not have its TTL decremented, since the sending node is originating the packet rather than forwarding it. This applies to BITS and native IPsec implementations in hosts and routers. However, the IPsec processing model includes an external forwarding capability. TTL processing can be used to prevent looping of packets, e.g., due to configuration errors, within the context of this processing model.
注意：减小TTL值是转发数据包的正常部分。因此，源于与封装器相同的节点的分组没有其TTL递减，因为发送节点是源于分组而不是转发它。这适用于主机和路由器中的BITS和本机IPsec实现。但是，IPsec处理模型包括外部转发功能。TTL处理可用于在该处理模型的上下文中防止数据包循环，例如由于配置错误。
(3) 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.
(3) 本地和远程地址取决于SA，SA用于确定远程地址，而远程地址又决定使用哪个本地地址（网络接口）转发数据包。
Note: For multicast traffic, the destination address, or source and destination addresses, may be required for demuxing. In that case, it is important to ensure consistency over the lifetime of the SA by ensuring that the source address that appears in the encapsulating tunnel header is the same as the one that was negotiated during the SA establishment process. There is an exception to this general rule, i.e., a mobile IPsec implementation will update its source address as it moves.
注意：对于多播流量，解复用可能需要目标地址或源地址和目标地址。在这种情况下，通过确保封装隧道头中出现的源地址与SA建立过程中协商的源地址相同，确保SA整个生命周期的一致性非常重要。此一般规则有一个例外，即移动IPsec实现将在移动时更新其源地址。
(4) Configuration determines whether to copy from the inner header (IPv4 only), clear, or set the DF.
(4) 配置决定是从内部标头复制（仅限IPv4）、清除还是设置DF。
(5) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further information.
(5) 如果数据包将立即进入外部报头中的DSCP值不适用的域，则该值必须映射到该域的适当值[NiBlBaBL98]。有关更多信息，请参阅RFC 2475[BBCDWW98]。
(6) If the ECN field in the inner header is set to ECT(0) or ECT(1), where ECT is ECN-Capable Transport (ECT), and if the ECN field in the outer header is set to Congestion Experienced (CE), then set the ECN field in the inner header to CE; otherwise, make no change to the ECN field in the inner header. (The IPv4 checksum changes when the ECN changes.)
(6) 如果内部报头中的ECN字段设置为ECT（0）或ECT（1），其中ECT为ECN能力传输（ECT），并且如果外部报头中的ECN字段设置为拥塞经历（CE），则将内部报头中的ECN字段设置为CE；否则，不要更改内部标题中的ECN字段。（当ECN更改时，IPv4校验和将更改。）
Note: IPsec does not copy the options from the inner header into the outer header, nor does IPsec construct the options in the outer header. However, post-IPsec code MAY insert/construct options for the outer header.
注意：IPsec不会将选项从内部头复制到外部头，也不会在外部头中构造选项。但是，post IPsec代码可能会为外部头插入/构造选项。
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
DS Field copied from inner hdr (5) no change (9)
ECN Field copied from inner hdr constructed (6)
flow label copied or configured (8) no change
payload length constructed no change
next header AH,ESP,routing hdr no change
hop limit constructed (2) decrement (2)
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied (7) no change
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
DS Field copied from inner hdr (5) no change (9)
ECN Field copied from inner hdr constructed (6)
flow label copied or configured (8) no change
payload length constructed no change
next header AH,ESP,routing hdr no change
hop limit constructed (2) decrement (2)
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied (7) no change
Notes:
笔记：
(1) - (6) See Section 5.1.2.1.
(1) -（6）见第5.1.2.1节。
(7) IPsec does not copy the extension headers from the inner packet into outer headers, nor does IPsec construct extension headers in the outer header. However, post-IPsec code MAY insert/construct extension headers for the outer header.
(7) IPsec不会将扩展标头从内部数据包复制到外部标头，也不会在外部标头中构造扩展标头。但是，后IPsec代码可能会为外部头插入/构造扩展头。
(8) See [RaCoCaDe04]. Copying is acceptable only for end systems, not SGs. If an SG copied flow labels from the inner header to the outer header, collisions might result.
(8) 见[RaCoCaDe04]。复制仅适用于终端系统，不适用于SGs。如果SG将流量标签从内部收割台复制到外部收割台，可能会导致冲突。
(9) An implementation MAY choose to provide a facility to pass the DS value from the outer header to the inner header, on a per-SA basis, for received tunnel mode packets. The motivation for providing this feature is to accommodate situations in which the DS code space at the receiver is different from that of the sender and the receiver has no way of knowing how to translate from the sender's space. There is a danger in copying this value from the outer header to the inner header, since it enables an attacker to modify the outer DSCP value in a fashion that may adversely affect other traffic at the receiver. Hence the default behavior for IPsec implementations is NOT to permit such copying.
(9) 一种实现可以选择为接收到的隧道模式分组提供一种基于每SA将DS值从外部报头传递到内部报头的设施。提供此功能的动机是为了适应以下情况：接收方的DS代码空间不同于发送方的DS代码空间，并且接收方无法知道如何从发送方的空间进行翻译。将此值从外部报头复制到内部报头会有危险，因为攻击者可以通过这种方式修改外部DSCP值，从而可能对接收器上的其他流量产生不利影响。因此，IPsec实现的默认行为是不允许这种复制。
Inbound processing is somewhat different from outbound processing, because of the use of SPIs to map IPsec-protected traffic to SAs. The inbound SPD cache (SPD-I) is applied only to bypassed or
入站处理与出站处理有些不同，因为使用SPI将受IPsec保护的流量映射到SAs。入站SPD缓存（SPD-I）仅应用于旁路或
discarded traffic. If an arriving packet appears to be an IPsec fragment from an unprotected interface, reassembly is performed prior to IPsec processing. The intent for any SPD cache is that a packet that fails to match any entry is then referred to the corresponding SPD. Every SPD SHOULD have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This ensures that non-IPsec-protected traffic that arrives and does not match any SPD-I entry will be discarded.
丢弃的交通。如果到达的数据包似乎是来自未受保护接口的IPsec片段，则在IPsec处理之前执行重新组装。任何SPD缓存的目的是，不匹配任何条目的数据包随后被引用到相应的SPD。每一个SPD都应该有一个名义上的、最终的条目，该条目捕获任何其他不匹配的内容，并将其丢弃。这可确保到达且与任何SPD-I条目不匹配的非IPsec保护流量将被丢弃。
Unprotected Interface
|
V
+-----+ IPsec protected
------------------->|Demux|-------------------+
| +-----+ |
| | |
| Not IPsec | |
| | |
| V |
| +-------+ +---------+ |
| |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 | |
| | |
| V |
| +-------+ +---------+ |
| |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 3. Processing Model for Inbound Traffic
图3。入站流量处理模型
(*) = The caches are shown here. If there is
a cache miss, then the SPD is checked.
There is no requirement that an
implementation buffer the packet if
there is a cache miss.
(**) = This processing includes using the
packet's SPI, etc., to look up the SA
in the SAD, which forms a cache of the
SPD for inbound packets (except for
cases noted in Sections 4.4.2 and 5).
See step 3a below.
(***) = This SAD check refers to step 4 below.
(*) = The caches are shown here. If there is
a cache miss, then the SPD is checked.
There is no requirement that an
implementation buffer the packet if
there is a cache miss.
(**) = This processing includes using the
packet's SPI, etc., to look up the SA
in the SAD, which forms a cache of the
SPD for inbound packets (except for
cases noted in Sections 4.4.2 and 5).
See step 3a below.
(***) = This SAD check refers to step 4 below.
Prior to performing AH or ESP processing, any IP fragments that arrive via the unprotected interface are reassembled (by IP). Each inbound IP datagram to which IPsec processing will be applied is identified by the appearance of the AH or ESP values in the IP Next Protocol field (or of AH or ESP as a next layer protocol in the IPv6 context).
在执行AH或ESP处理之前，通过未受保护的接口到达的任何IP片段都会重新组装（通过IP）。IPsec处理将应用到的每个入站IP数据报通过IP下一个协议字段中的AH或ESP值（或IPv6上下文中作为下一层协议的AH或ESP）的外观进行标识。
IPsec MUST perform the following steps:
IPsec必须执行以下步骤：
1. When a packet arrives, it may be tagged with the ID of the interface (physical or virtual) via which it arrived, if necessary, to support multiple SPDs and associated SPD-I caches. (The interface ID is mapped to a corresponding SPD-ID.)
1. 当数据包到达时，如有必要，可使用其到达的接口ID（物理或虚拟）对其进行标记，以支持多个SPD和相关的SPD-I缓存。（接口ID映射到相应的SPD-ID。）
2. The packet is examined and demuxed into one of two categories: - If the packet appears to be IPsec protected and it is addressed to this device, 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. - Traffic not addressed to this device, or addressed to this device and not AH or ESP, is directed to SPD-I lookup. (This implies that IKE traffic MUST have an explicit BYPASS entry in the SPD.) If multiple SPDs are employed, the tag assigned to the packet in step 1 is used to select the appropriate SPD-I (and cache) to search. SPD-I lookup determines whether the action is DISCARD or BYPASS.
2. 将对数据包进行检查并将其分解为两类之一：-如果数据包似乎受到IPsec保护，并将其发送到此设备，则会尝试通过SAD将其映射到活动SA。注意，设备可能具有多个IP地址，这些IP地址可用于SAD查找，例如，在协议（如SCTP）的情况下。-未寻址到此设备的通信量，或寻址到此设备而非AH或ESP的通信量，将定向到SPD-I查找。（这意味着IKE通信必须在SPD中有一个明确的旁路条目。）如果使用多个SPD，则在步骤1中分配给数据包的标签用于选择适当的SPD-I（和缓存）进行搜索。SPD-I查找确定操作是放弃还是绕过。
3a. If the packet is addressed to the IPsec device and AH or ESP is specified as the protocol, the packet is looked up in the SAD. For unicast traffic, use only the SPI (or SPI plus protocol). For multicast traffic, use the SPI plus the destination or SPI plus destination and source addresses, as specified in Section 4.1. In either case (unicast or multicast), if there is no match, discard the traffic. This is an auditable event. The audit log
3a。如果数据包被发送到IPsec设备，并且AH或ESP被指定为协议，则在SAD中查找数据包。对于单播通信，仅使用SPI（或SPI plus协议）。对于多播通信，使用SPI加上目的地或SPI加上目的地和源地址，如第4.1节所述。在任何一种情况下（单播或多播），如果没有匹配，则丢弃通信量。这是一个可审核的事件。审核日志
entry for this event SHOULD include the current date/time, SPI, source and destination of the packet, IPsec protocol, and any other selector values of the packet that are available. If the packet is found in the SAD, process it accordingly (see step 4).
此事件的条目应包括当前日期/时间、SPI、数据包的源和目标、IPsec协议以及数据包的任何其他可用选择器值。如果在SAD中找到数据包，则相应地对其进行处理（参见步骤4）。
3b. If the packet is not addressed to the device or is addressed to this device and is not AH or ESP, look up the packet header in the (appropriate) SPD-I cache. If there is a match and the packet is to be discarded or bypassed, do so. If there is no cache match, look up the packet in the corresponding SPD-I and create a cache entry as appropriate. (No SAs are created in response to receipt of a packet that requires IPsec protection; only BYPASS or DISCARD cache entries can be created this way.) If there is no match, discard the traffic. This is an auditable event. The audit log entry for this event SHOULD include the current date/time, SPI if available, IPsec protocol if available, source and destination of the packet, and any other selector values of the packet that are available.
3b。如果数据包未发送至设备或发送至该设备且不是AH或ESP，请在（适当的）SPD-I缓存中查找数据包头。如果存在匹配项，且数据包将被丢弃或绕过，请执行此操作。如果没有缓存匹配，请在相应的SPD-I中查找数据包，并根据需要创建缓存条目。（接收到需要IPsec保护的数据包时，不会创建SA；通过这种方式只能创建绕过或放弃缓存项。）如果没有匹配项，则放弃通信量。这是一个可审核的事件。此事件的审核日志项应包括当前日期/时间、SPI（如果可用）、IPsec协议（如果可用）、数据包的源和目标以及数据包的任何其他可用选择器值。
3c. Processing of ICMP messages is assumed to take place on the unprotected side of the IPsec boundary. Unprotected ICMP messages are examined and local policy is applied to determine whether to accept or reject these messages and, if accepted, what action to take as a result. For example, if an ICMP unreachable message is received, the implementation must decide whether to act on it, reject it, or act on it with constraints. (See Section 6.)
3c。假定ICMP消息的处理在IPsec边界的未受保护一侧进行。将检查未受保护的ICMP消息，并应用本地策略来确定是否接受或拒绝这些消息，以及如果接受，将采取何种操作。例如，如果接收到ICMP不可访问消息，则实现必须决定是对其进行操作、拒绝它，还是对其进行约束。（见第6节。）
4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received.
4. 使用上述步骤3a中选择的SAD条目，按规定应用AH或ESP处理。然后将数据包与SAD条目标识的入站选择器进行匹配，以验证接收到的数据包是否适合通过其接收数据包的SA。
5. If an IPsec system receives an inbound packet on an SA and the packet's header fields are not consistent with the selectors for the SA, it MUST discard the packet. This is an auditable event. The audit log entry for this event SHOULD include the current date/time, SPI, IPsec protocol(s), source and destination of the packet, any other selector values of the packet that are available, and the selector values from the relevant SAD entry. The system SHOULD also be capable of generating and sending an IKE notification of INVALID_SELECTORS to the sender (IPsec peer), indicating that the received packet was discarded because of failure to pass selector checks.
5. 如果IPsec系统在SA上接收到入站数据包，并且数据包的头字段与SA的选择器不一致，则必须丢弃该数据包。这是一个可审核的事件。此事件的审核日志条目应包括当前日期/时间、SPI、IPsec协议、数据包的源和目标、可用数据包的任何其他选择器值以及相关SAD条目中的选择器值。系统还应能够生成并向发送方（IPsec对等方）发送无效选择器的IKE通知，指示由于未能通过选择器检查而丢弃接收的数据包。
To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure the IPsec implementation to send or not send this IKE notification, and if this facility is selected, to rate limit the transmission of such notifications.
为了将DoS攻击或错误配置的对等方的影响降至最低，IPsec系统应包括一个管理控件，以允许管理员配置IPsec实现以发送或不发送此IKE通知，并且如果选择了此功能，则对此类通知的传输进行速率限制。
After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition. This function may cause the packet to be sent (outbound) across the IPsec boundary for additional inbound IPsec processing, e.g., in support of nested SAs. If so, then as with ALL outbound traffic that is to be bypassed, the packet MUST be matched against an SPD-O entry. Ultimately, the packet should be forwarded to the destination host or process for disposition.
在通过IPsec绕过或处理流量后，它将被交给入站转发功能进行处理。此函数可能导致数据包跨IPsec边界发送（出站），以进行额外的入站IPsec处理，例如，支持嵌套SAs。如果是这样，那么与所有要绕过的出站流量一样，数据包必须与SPD-O条目匹配。最终，数据包应转发到目标主机或进程进行处置。
This section describes IPsec handling of ICMP traffic. There are two categories of ICMP traffic: error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This section applies exclusively to error messages. Disposition of non-error, ICMP messages (that are not addressed to the IPsec implementation itself) MUST be explicitly accounted for using SPD entries.
本节介绍ICMP通信的IPsec处理。ICMP通信有两类：错误消息（例如，类型=无法到达目的地）和非错误消息（例如，类型=回音）。本节仅适用于错误消息。必须使用SPD条目明确说明非错误ICMP消息（未发送到IPsec实现本身）的处置。
The discussion in this section applies to ICMPv6 as well as to ICMPv4. Also, a mechanism SHOULD be provided to allow an administrator to cause ICMP error messages (selected, all, or none) to be logged as an aid to problem diagnosis.
本节中的讨论适用于ICMPv6以及ICMPv4。此外，还应提供一种机制，允许管理员记录ICMP错误消息（选定、全部或无），以帮助进行问题诊断。
6.1.1. ICMP Error Messages Received on the Unprotected Side of the Boundary
6.1.1. 在边界未受保护的一侧接收到ICMP错误消息
Figure 3 in Section 5.2 shows a distinct ICMP processing module on the unprotected side of the IPsec boundary, for processing ICMP messages (error or otherwise) that are addressed to the IPsec device and that are not protected via AH or ESP. An ICMP message of this sort is unauthenticated, and its processing may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus, there is also a motivation for accepting and acting upon unauthenticated ICMP messages.
第5.2节中的图3显示了IPsec边界未受保护一侧的独特ICMP处理模块，用于处理发往IPsec设备且未通过AH或ESP保护的ICMP消息（错误或其他）。此类ICMP消息未经验证，其处理可能导致拒绝或服务降级。这表明，一般而言，最好忽略这些信息。但是，许多ICMP消息将由主机或安全网关从未经验证的来源接收，例如公共互联网中的路由器。忽略这些ICMP消息可能会降低服务质量，例如，由于无法处理PMTU消息和重定向消息。因此，还存在接受未经验证的ICMP消息并对其采取行动的动机。
To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size.
为了适应此范围的两端，兼容的IPsec实现必须允许本地管理员配置IPsec实现以接受或拒绝未经验证的ICMP通信。此控件的粒度必须为ICMP类型，也可以为ICMP类型和代码的粒度。此外，实现应包含处理此类流量的机制和参数。例如，可以建立流量的最小PMTU（基于每个目的地），以防止收到未经验证的ICMP而将PMTU设置为较小的大小。
If an ICMP PMTU message passes the checks above and the system is configured to accept it, then there are two possibilities. If the implementation applies fragmentation on the ciphertext side of the boundary, then the accepted PMTU information is passed to the forwarding module (outside of the IPsec implementation), which uses it to manage outbound packet fragmentation. If the implementation is configured to effect plaintext side fragmentation, then the PMTU information is passed to the plaintext side and processed as described in Section 8.2.
如果ICMP PMTU消息通过上述检查，并且系统配置为接受该消息，则有两种可能性。如果实现在边界的密文端应用分段，则接受的PMTU信息将传递给转发模块（在IPsec实现之外），该模块使用它来管理出站数据包分段。如果将实现配置为影响明文端分段，则PMTU信息将传递到明文端，并按照第8.2节所述进行处理。
6.1.2. ICMP Error Messages Received on the Protected Side of the Boundary
6.1.2. 在边界的受保护一侧接收到ICMP错误消息
These ICMP messages are not authenticated, but they do come from sources on the protected side of the IPsec boundary. Thus, these messages generally are viewed as more "trustworthy" than their counterparts arriving from sources on the unprotected side of the boundary. The major security concern here is that a compromised host or router might emit erroneous ICMP error messages that could degrade service for other devices "behind" the security gateway, or that could even result in violations of confidentiality. For example, if a bogus ICMP redirect were consumed by a security gateway, it could cause the forwarding table on the protected side of the boundary to be modified so as to deliver traffic to an inappropriate destination "behind" the gateway. Thus, implementers MUST provide controls to allow local administrators to constrain the processing of ICMP error messages received on the protected side of the boundary, and directed to the IPsec implementation. These controls are of the same type as those employed on the unprotected side, described above in Section 6.1.1.
这些ICMP消息未经过身份验证，但它们确实来自IPsec边界受保护一侧的源。因此，这些消息通常被视为比来自边界未受保护一侧的源的消息更“可信”。这里的主要安全问题是，受损主机或路由器可能会发出错误的ICMP错误消息，这可能会降低“安全网关”后面的其他设备的服务，甚至可能导致违反保密性。例如，如果安全网关使用了伪造的ICMP重定向，则可能会导致修改边界受保护一侧的转发表，从而将流量传送到网关“后面”的不适当目的地。因此，实现者必须提供控制，以允许本地管理员限制在边界受保护端接收并指向IPsec实现的ICMP错误消息的处理。这些控制装置的类型与上文第6.1.1节所述的无保护侧的控制装置相同。
When an ICMP error message is transmitted via an SA to a device "behind" an IPsec implementation, both the payload and the header of the ICMP message require checking from an access control perspective. If one of these messages is forwarded to a host behind a security
当ICMP错误消息通过SA传输到IPsec实现“后面”的设备时，ICMP消息的有效负载和报头都需要从访问控制的角度进行检查。如果其中一条消息被转发到安全协议后面的主机
gateway, the receiving host IP implementation will make decisions based on the payload, i.e., the header of the packet that purportedly triggered the error response. Thus, an IPsec implementation MUST be configurable to check that this payload header information is consistent with the SA via which it arrives. (This means that the payload header, with source and destination address and port fields reversed, matches the traffic selectors for the SA.) If this sort of check is not performed, then, for example, anyone with whom the receiving IPsec system (A) has an active SA could send an ICMP Destination Unreachable message that refers to any host/net with which A is currently communicating, and thus effect a highly efficient DoS attack regarding communication with other peers of A. Normal IPsec receiver processing of traffic is not sufficient to protect against such attacks. However, not all contexts may require such checks, so it is also necessary to allow a local administrator to configure an implementation to NOT perform such checks.
网关，接收主机IP实现将基于有效载荷（即据称触发错误响应的分组的报头）做出决策。因此，IPsec实现必须是可配置的，以检查此有效负载头信息是否与它到达的SA一致。（这意味着源地址和目标地址以及端口字段颠倒的有效负载报头与SA的流量选择器匹配。）如果未执行此类检查，那么，例如，接收IPsec系统（A）的任何人具有活动SA可能会发送ICMP目的地不可访问消息，该消息指的是A当前与之通信的任何主机/网络，从而对与A的其他对等方的通信造成高效的DoS攻击。正常的IPsec接收器流量处理不足以防止此类攻击。但是，并非所有上下文都需要此类检查，因此还需要允许本地管理员将实现配置为不执行此类检查。
To accommodate both policies, the following convention is adopted. If an administrator wants to allow ICMP error messages to be carried by an SA without inspection of the payload, then configure an SPD entry that explicitly allows for carriage of such traffic. If an administrator wants IPsec to check the payload of ICMP error messages for consistency, then do not create any SPD entries that accommodate carriage of such traffic based on the ICMP packet header. This convention motivates the following processing description.
为了适应这两种政策，通过了以下公约。如果管理员希望允许SA在不检查有效负载的情况下传输ICMP错误消息，则配置明确允许传输此类流量的SPD条目。如果管理员希望IPsec检查ICMP错误消息的有效负载的一致性，则不要创建任何基于ICMP数据包头的SPD条目来容纳此类流量的传输。此约定激发了以下处理描述。
IPsec senders and receivers MUST support the following processing for ICMP error messages that are sent and received via SAs.
IPsec发送方和接收方必须支持对通过SAs发送和接收的ICMP错误消息的以下处理。
If an SA exists that accommodates an outbound ICMP error message, then the message is mapped to the SA and only the IP and ICMP headers are checked upon receipt, just as would be the case for other traffic. If no SA exists that matches the traffic selectors associated with an ICMP error message, then the SPD is searched to determine if such an SA can be created. If so, the SA is created and the ICMP error message is transmitted via that SA. Upon receipt, this message is subject to the usual traffic selector checks at the receiver. This processing is exactly what would happen for traffic in general, and thus does not represent any special processing for ICMP error messages.
如果存在容纳出站ICMP错误消息的SA，则该消息将映射到SA，并且在接收时仅检查IP和ICMP头，与其他流量的情况一样。如果不存在与ICMP错误消息关联的流量选择器匹配的SA，则搜索SPD以确定是否可以创建此类SA。如果是，则创建SA，并通过该SA传输ICMP错误消息。收到此消息后，接收方将对其进行常规流量选择器检查。这种处理通常是针对通信量的，因此不代表对ICMP错误消息的任何特殊处理。
If no SA exists that would carry the outbound ICMP message in question, and if no SPD entry would allow carriage of this outbound ICMP error message, then an IPsec implementation MUST map the message to the SA that would carry the return traffic associated with the packet that triggered the ICMP error message. This requires an IPsec implementation to detect outbound ICMP error messages that map to no extant SA or SPD entry, and treat them specially with regard to SA
如果不存在将携带有问题的出站ICMP消息的SA，并且如果没有SPD条目将允许携带此出站ICMP错误消息，则IPsec实现必须将该消息映射到将携带与触发ICMP错误消息的数据包相关联的返回流量的SA。这需要IPsec实现来检测映射到不存在SA或SPD条目的出站ICMP错误消息，并针对SA对其进行特殊处理
creation and lookup. The implementation extracts the header for the packet that triggered the error (from the ICMP message payload), reverses the source and destination IP address fields, extracts the protocol field, and reverses the port fields (if accessible). It then uses this extracted information to locate an appropriate, active outbound SA, and transmits the error message via this SA. If no such SA exists, no SA will be created, and this is an auditable event.
创建和查找。该实现提取触发错误的数据包的报头（来自ICMP消息负载），反转源和目标IP地址字段，提取协议字段，并反转端口字段（如果可访问）。然后，它使用此提取的信息来定位适当的、活动的出站SA，并通过此SA传输错误消息。如果不存在此类SA，则不会创建SA，这是一个可审核事件。
If an IPsec implementation receives an inbound ICMP error message on an SA, and the IP and ICMP headers of the message do not match the traffic selectors for the SA, the receiver MUST process the received message in a special fashion. Specifically, the receiver must extract the header of the triggering packet from the ICMP payload, and reverse fields as described above to determine if the packet is consistent with the selectors for the SA via which the ICMP error message was received. If the packet fails this check, the IPsec implementation MUST NOT forwarded the ICMP message to the destination. This is an auditable event.
如果IPsec实现在SA上接收到入站ICMP错误消息，并且消息的IP和ICMP头与SA的流量选择器不匹配，则接收方必须以特殊方式处理接收到的消息。具体地说，接收机必须从ICMP有效载荷中提取触发分组的报头，并如上所述反转字段，以确定分组是否与通过其接收ICMP错误消息的SA的选择器一致。如果数据包未通过此检查，IPsec实现不得将ICMP消息转发到目标。这是一个可审核的事件。
Earlier sections of this document describe mechanisms for (a) fragmenting an outbound packet after IPsec processing has been applied and reassembling it at the receiver before IPsec processing and (b) handling inbound fragments received from the unprotected side of the IPsec boundary. This section describes how an implementation should handle the processing of outbound plaintext fragments on the protected side of the IPsec boundary. (See Appendix D, "Fragment Handling Rationale".) In particular, it addresses:
本文档的前面部分描述了以下机制：（a）在应用IPsec处理后对出站数据包进行分段，并在IPsec处理之前在接收器处重新组装数据包；（b）处理从IPsec边界的未受保护一侧接收的入站数据包。本节描述实现应如何处理IPsec边界受保护端的出站明文片段的处理。（参见附录D“碎片处理原理”）特别是，它涉及：
o mapping an outbound non-initial fragment to the right SA (or finding the right SPD entry) o verifying that a received non-initial fragment is authorized for the SA via which it was received o mapping outbound and inbound non-initial fragments to the right SPD-O/SPD-I entry or the relevant cache entry, for BYPASS/DISCARD traffic
o 将出站非初始片段映射到正确的SA（或查找正确的SPD条目）o验证接收到的非初始片段是否被授权用于通过其接收到的SA o将出站和入站非初始片段映射到正确的SPD-o/SPD-I条目或相关缓存条目，以便绕过/丢弃流量
Note: In Section 4.1, transport mode SAs have been defined to not carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two special values, ANY and OPAQUE, were defined for selectors and that ANY includes OPAQUE. The term "non-trivial" is used to mean that the selector has a value other than OPAQUE or ANY.
注意：在第4.1节中，传输模式SA被定义为不携带片段（IPv4或IPv6）。还请注意，在第4.4.1节中，为选择器定义了两个特殊值，ANY和不透明，ANY包括不透明。术语“非平凡”用于表示选择器具有不透明或任何其他值。
Note: The term "non-initial fragment" is used here to indicate a fragment that does not contain all the selector values that may be needed for access control. As observed in Section 4.4.1, depending on the Next Layer Protocol, in addition to Ports, the ICMP message
注意：这里使用术语“非初始片段”来表示不包含访问控制可能需要的所有选择器值的片段。如第4.4.1节所述，根据下一层协议，除端口外，ICMP消息
type/code or Mobility Header type could be missing from non-initial fragments. Also, for IPv6, even the first fragment might NOT contain the Next Layer Protocol or Ports (or ICMP message type/code, or Mobility Header type) depending on the kind and number of extension headers present. If a non-initial fragment contains the Port (or ICMP type and code or Mobility Header type) but not the Next Layer Protocol, then unless there is an SPD entry for the relevant Local/Remote addresses with ANY for Next Layer Protocol and Port (or ICMP type and code or Mobility Header type), the fragment would not contain all the selector information needed for access control.
非初始片段中可能缺少类型/代码或移动标头类型。此外，对于IPv6，根据存在的扩展头的种类和数量，即使第一个片段也可能不包含下一层协议或端口（或ICMP消息类型/代码，或移动头类型）。如果非初始片段包含端口（或ICMP类型和代码或移动性标头类型），但不包含下一层协议，则除非有相关本地/远程地址的SPD条目以及下一层协议和端口的SPD条目（或ICMP类型和代码或移动性标头类型），该片段不包含访问控制所需的所有选择器信息。
To address the above issues, three approaches have been defined:
为了解决上述问题，定义了三种方法：
o Tunnel mode SAs that carry initial and non-initial fragments (See Section 7.1.) o Separate tunnel mode SAs for non-initial fragments (See Section 7.2.) o Stateful fragment checking (See Section 7.3.)
o 携带初始和非初始碎片的隧道模式SAs（见第7.1节）o非初始碎片的单独隧道模式SAs（见第7.2节）o有状态碎片检查（见第7.3节）
All implementations MUST support tunnel mode SAs that are configured to pass traffic without regard to port field (or ICMP type/code or Mobility Header type) values. If the SA will carry traffic for specified protocols, the selector set for the SA MUST specify the port fields (or ICMP type/code or Mobility Header type) as ANY. An SA defined in this fashion will carry all traffic including initial and non-initial fragments for the indicated Local/Remote addresses and specified Next Layer protocol(s). If the SA will carry traffic without regard to a specific protocol value (i.e., ANY is specified as the (Next Layer) protocol selector value), then the port field values are undefined and MUST be set to ANY as well. (As noted in 4.4.1, ANY includes OPAQUE as well as all specific values.)
所有实现都必须支持隧道模式SAs，这些SA被配置为在不考虑端口字段（或ICMP类型/代码或移动报头类型）值的情况下传递流量。如果SA将承载指定协议的通信量，则SA的选择器集必须将端口字段（或ICMP类型/代码或移动报头类型）指定为任意。以这种方式定义的SA将承载所有流量，包括指示的本地/远程地址和指定的下一层协议的初始和非初始片段。如果SA将在不考虑特定协议值的情况下承载流量（即，ANY被指定为（下一层）协议选择器值），则端口字段值未定义，并且必须设置为ANY。（如4.4.1所述，任何值包括不透明值和所有特定值。）
An implementation MAY support tunnel mode SAs that will carry only non-initial fragments, separate from non-fragmented packets and initial fragments. The OPAQUE value will be used to specify port (or ICMP type/code or Mobility Header type) field selectors for an SA to carry such fragments. Receivers MUST perform a minimum offset check on IPv4 (non-initial) fragments to protect against overlapping fragment attacks when SAs of this type are employed. Because such checks cannot be performed on IPv6 non-initial fragments, users and administrators are advised that carriage of such fragments may be dangerous, and implementers may choose to NOT support such SAs for IPv6 traffic. Also, an SA of this sort will carry all non-initial fragments that match a specified Local/Remote address pair and
一种实现可以支持隧道模式sa，该模式sa将仅携带非初始片段，与非片段化分组和初始片段分离。不透明值将用于为SA指定端口（或ICMP类型/代码或移动标头类型）字段选择器，以承载此类片段。当使用这种类型的SA时，接收器必须对IPv4（非初始）片段执行最小偏移量检查，以防止重叠片段攻击。由于无法对IPv6非初始片段执行此类检查，因此建议用户和管理员携带此类片段可能会有危险，并且实施者可能选择不支持IPv6流量的此类SA。此外，此类SA将携带与指定的本地/远程地址对匹配的所有非初始片段，并且
protocol value, i.e., the fragments carried on this SA belong to packets that if not fragmented, might have gone on separate SAs of differing security. Therefore, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms in use between both peers. (Determination of the "strongest" algorithms requires imposing an ordering of the available algorithms, a local determination at the discretion of the initiator of the SA.)
协议值，即，此SA上携带的片段属于数据包，如果没有片段化，则可能在不同安全性的单独SA上。因此，建议用户和管理员使用ESP（具有完整性）以及两个对等方之间使用的“最强”完整性和加密算法来保护此类流量。（确定“最强”算法需要对可用算法进行排序，由SA发起人自行决定进行局部确定。）
Specific port (or ICMP type/code or Mobility Header type) selector values will be used to define SAs to carry initial fragments and non-fragmented packets. This approach can be used if a user or administrator wants to create one or more tunnel mode SAs between the same Local/Remote addresses that discriminate based on port (or ICMP type/code or Mobility Header type) fields. These SAs MUST have non-trivial protocol selector values, otherwise approach #1 above MUST be used.
特定端口（或ICMP类型/代码或移动头类型）选择器值将用于定义SA以承载初始片段和非片段数据包。如果用户或管理员希望在相同的本地/远程地址之间创建一个或多个基于端口（或ICMP类型/代码或移动头类型）字段进行区分的隧道模式SA，则可以使用此方法。这些SA必须具有非平凡的协议选择器值，否则必须使用上述方法#1。
Note: In general, for the approach described in this section, one needs only a single SA between two implementations to carry all non-initial fragments. However, if one chooses to have multiple SAs between the two implementations for QoS differentiation, then one might also want multiple SAs to carry fragments-without-ports, one for each supported QoS class. Since support for QoS via distinct SAs is a local matter, not mandated by this document, the choice to have multiple SAs to carry non-initial fragments should also be local.
注意：一般来说，对于本节中描述的方法，两个实现之间只需要一个SA就可以携带所有非初始片段。但是，如果您选择在两个实现之间使用多个SA来区分QoS，那么您可能还希望多个SA携带没有端口的片段，每个支持的QoS类一个。由于通过不同的SA支持QoS是一个本地问题，而不是本文档强制要求的，因此让多个SA携带非初始片段的选择也应该是本地的。
An implementation MAY support some form of stateful fragment checking for a tunnel mode SA with non-trivial port (or ICMP type/code or MH type) field values (not ANY or OPAQUE). Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
一个实现可能支持对隧道模式SA进行某种形式的有状态片段检查，该SA具有非平凡端口（或ICMP类型/代码或MH类型）字段值（不是任何或不透明）。将在使用非平凡端口（或ICMP类型/代码或MH类型）选择器的隧道模式SA上传输非初始片段的实现必须通过IKE notify non_FIRST_fragments_Alway有效负载通知对等方。
The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA. This standard does not specify how peers will deal with such fragments, e.g., via reassembly or other means, at either sender or receiver. However, a receiver MUST discard non-initial fragments that arrive on an SA with non-trivial port (or ICMP type/code or MH type) selector values unless this feature has been negotiated. Also, the receiver MUST discard non-initial fragments that do not comply with the security policy applied to the overall packet. Discarding such packets is an auditable event. Note that in network configurations where fragments
如果对等方在此上下文中不接受非初始片段，则必须拒绝该提议。如果实现未成功协商此类SA的非初始片段传输，则它不得通过SA发送此类片段。本标准未规定对等方在发送方或接收方如何处理此类碎片，例如通过重新组装或其他方式。但是，除非已协商此功能，否则接收方必须丢弃到达SA的具有非平凡端口（或ICMP类型/代码或MH类型）选择器值的非初始片段。此外，接收方必须丢弃不符合应用于整个数据包的安全策略的非初始片段。丢弃此类数据包是一个可审核的事件。请注意，在网络配置中
of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.
如果数据包的状态可能通过不同的安全网关或BITW实现发送或接收，则用于跟踪片段的有状态策略可能会失败。
All implementations MUST support DISCARDing of fragments using the normal SPD packet classification mechanisms. All implementations MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort. As noted above, in network configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.
所有实现都必须支持使用普通SPD数据包分类机制丢弃片段。所有实现都必须支持有状态片段检查，以适应指定了非平凡端口范围的旁路流量。令人担忧的是，绕过到达IPsec实现的明文、非初始片段可能会破坏指向同一目的地的IPsec保护通信的安全性。例如，考虑用SPD条目配置的IPSec实现，其要求对特定源/目的地址对之间的业务进行IPSec保护，以及针对特定的协议和目的端口，例如端口23上的TCP流量（TELNET）。假设该实现还允许绕过来自相同源/目的地地址对和协议的流量，但针对不同的目的地端口，例如端口119（NNTP）。攻击者可以发送非初始片段（带有伪造的源地址），如果绕过该片段，可能会与来自同一源的受IPsec保护的流量重叠，从而破坏受IPsec保护的流量的完整性。需要对具有非平凡端口范围的旁路条目进行有状态片段检查，以防止此类攻击。如上所述，在可能通过不同的安全网关或BITW实现发送或接收数据包片段的网络配置中，用于跟踪片段的有状态策略可能会失败。
The application of AH or ESP to an outbound packet increases the size of a packet and thus may cause a packet to exceed the PMTU for the SA via which the packet will travel. An IPsec implementation also may receive an unprotected ICMP PMTU message and, if it chooses to act upon the message, the result will affect outbound traffic processing. This section describes the processing required of an IPsec implementation to deal with these two PMTU issues.
对出站数据包应用AH或ESP会增加数据包的大小，因此可能导致数据包超过SA的PMTU，数据包将通过该SA传输。IPsec实现还可能接收未受保护的ICMP PMTU消息，如果它选择对该消息采取行动，结果将影响出站流量处理。本节描述IPsec实现处理这两个PMTU问题所需的处理。
All IPsec implementations MUST support the option of copying the DF bit from an outbound packet to the tunnel mode header that it emits, when traffic is carried via a tunnel mode SA. This means that it MUST be possible to configure the implementation's treatment of the DF bit (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4.
当流量通过隧道模式SA传输时，所有IPsec实现必须支持将DF位从出站数据包复制到它发出的隧道模式报头的选项。这意味着必须能够为每个SA配置实现对DF位的处理（设置、清除、从内部标头复制）。这适用于内部和外部头都是IPv4的SAs。
This section discusses IPsec handling for unprotected Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for:
本节讨论未受保护路径MTU发现消息的IPsec处理。此处使用ICMP PMTU来引用ICMP消息：
IPv4 (RFC 792 [Pos81b]): - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labeled "unused" in RFC 792), with high-order 16 bits set to zero)
IPv4（RFC 792[Pos81b]）：-Type=3（无法到达目的地）-Code=4（需要分段并设置DF）-ICMP报头第二个字低16位的下一跳MTU（在RFC 792中标记为“未使用”），高16位设置为零）
IPv6 (RFC 2463 [CD98]): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed) - Next-Hop MTU in the 32-bit MTU field of the ICMP6 message
IPv6（RFC 2463[CD98]）：-Type=2（数据包太大）-Code=0（需要分段）-ICMP6消息的32位MTU字段中的下一跳MTU
When an IPsec implementation receives an unauthenticated PMTU message, and it is configured to process (vs. ignore) such messages, it maps the message to the SA to which it corresponds. This mapping is effected by extracting the header information from the payload of the PMTU message and applying the procedure described in Section 5.2. The PMTU determined by this message is used to update the SAD PMTU field, taking into account the size of the AH or ESP header that will be applied, any crypto synchronization data, and the overhead imposed by an additional IP header, in the case of a tunnel mode SA.
当IPsec实现接收到未经验证的PMTU消息，并将其配置为处理（而不是忽略）此类消息时，它会将该消息映射到它所对应的SA。该映射通过从PMTU消息的有效载荷中提取报头信息并应用第5.2节中描述的程序来实现。在隧道模式SA的情况下，该消息确定的PMTU用于更新SAD PMTU字段，同时考虑将应用的AH或ESP报头的大小、任何加密同步数据以及附加IP报头施加的开销。
In a native host implementation, it is possible to maintain PMTU data at the same granularity as for unprotected communication, so there is no loss of functionality. Signaling of the PMTU information is internal to the host. For all other IPsec implementation options, the PMTU data must be propagated via a synthesized ICMP PMTU. In these cases, the IPsec implementation SHOULD wait for outbound traffic to be mapped to the SAD entry. When such traffic arrives, if the traffic would exceed the updated PMTU value the traffic MUST be handled as follows:
在本机主机实现中，可以以与无保护通信相同的粒度维护PMTU数据，因此不会丢失功能。PMTU信息的信令是主机内部的。对于所有其他IPsec实现选项，PMTU数据必须通过合成的ICMP PMTU进行传播。在这些情况下，IPsec实现应该等待出站流量映射到SAD条目。当此类流量到达时，如果流量将超过更新的PMTU值，则必须按照以下方式处理流量：
Case 1: Original (cleartext) packet is IPv4 and has the DF bit set. The implementation SHOULD discard the packet and send a PMTU ICMP message.
案例1：原始（明文）数据包是IPv4，并设置了DF位。实现应丢弃该数据包并发送PMTU ICMP消息。
Case 2: Original (cleartext) packet is IPv4 and has the DF bit clear. The implementation SHOULD fragment (before or after encryption per its configuration) and then forward the fragments. It SHOULD NOT send a PMTU ICMP message.
案例2：原始（明文）数据包是IPv4，DF位为clear。实现应该分段（根据其配置在加密之前或之后），然后转发这些分段。它不应发送PMTU ICMP消息。
Case 3: Original (cleartext) packet is IPv6. The implementation SHOULD discard the packet and send a PMTU ICMP message.
案例3：原始（明文）数据包是IPv6。实现应丢弃该数据包并发送PMTU ICMP消息。
In all IPsec implementations, the PMTU associated with an SA MUST be "aged" and some mechanism is required to update the PMTU in a timely manner, especially for discovering if the PMTU is smaller than required by current network conditions. A given PMTU has to remain in place long enough for a packet to get from the source of the SA to the peer, and to propagate an ICMP error message if the current PMTU is too big.
在所有IPsec实现中，与SA关联的PMTU必须“老化”，并且需要某种机制来及时更新PMTU，特别是用于发现PMTU是否小于当前网络条件所需的值。给定的PMTU必须保持在适当的位置足够长的时间，以便数据包从SA源到达对等方，并且如果当前PMTU太大，则必须传播ICMP错误消息。
Implementations SHOULD use the approach described in the Path MTU Discovery document (RFC 1191 [MD90], Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable.
实施应使用路径MTU发现文件（RFC 1191[MD90]，第6.3节）中描述的方法，该文件建议定期将PMTU重置为第一跳数据链路MTU，然后让正常PMTU发现过程根据需要更新PMTU。周期应该是可配置的。
IPsec implementations are not required to support auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this document, and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
IPsec实现不需要支持审核。在大多数情况下，审计的粒度是一个局部问题。然而，本文件中确定了几个可审计事件，并且为每个事件定义了应包含在审计日志中的最低信息集。审计日志中还可能包含这些事件的附加信息，本规范中未明确指出的附加事件也可能导致审计日志条目。不要求接收方在检测到可审计事件时向声称的发送方发送任何消息，因为通过这种行为可能导致拒绝服务。
All IPv4 IPsec implementations MUST comply with all requirements of this document. All IPv6 implementations MUST comply with all requirements of this document.
所有IPv4 IPsec实施必须符合本文档的所有要求。所有IPv6实施必须符合本文档的所有要求。
The focus of this document is security; hence security considerations permeate this specification.
本文件的重点是安全；因此，安全考虑贯穿于本规范中。
IPsec imposes stringent constraints on bypass of IP header data in both directions, across the IPsec barrier, especially when tunnel mode SAs are employed. Some constraints are absolute, while others are subject to local administrative controls, often on a per-SA basis. For outbound traffic, these constraints are designed to limit covert channel bandwidth. For inbound traffic, the constraints are designed to prevent an adversary who has the ability to tamper with one data stream (on the unprotected side of the IPsec barrier) from adversely affecting other data streams (on the protected side of the barrier). The discussion in Section 5 dealing with processing DSCP values for tunnel mode SAs illustrates this concern.
IPsec对通过IPsec屏障在两个方向绕过IP头数据施加了严格的限制，特别是在采用隧道模式SAs时。一些约束是绝对的，而其他约束则受到当地行政控制，通常是基于每个SA。对于出站流量，这些约束旨在限制隐蔽通道带宽。对于入站流量，这些限制旨在防止能够篡改一个数据流（在IPsec屏障的未受保护一侧）的对手对其他数据流（在屏障的受保护一侧）产生不利影响。第5节中关于处理隧道模式SAs的DSCP值的讨论说明了这一问题。
If an IPsec implementation is configured to pass ICMP error messages over SAs based on the ICMP header values, without checking the header information from the ICMP message payload, serious vulnerabilities may arise. Consider a scenario in which several sites (A, B, and C) are connected to one another via ESP-protected tunnels: A-B, A-C, and B-C. Also assume that the traffic selectors for each tunnel specify ANY for protocol and port fields and IP source/destination address ranges that encompass the address range for the systems behind the security gateways serving each site. This would allow a host at site B to send an ICMP Destination Unreachable message to any host at site A, that declares all hosts on the net at site C to be unreachable. This is a very efficient DoS attack that could have been prevented if the ICMP error messages were subjected to the checks that IPsec provides, if the SPD is suitably configured, as described in Section 6.2.
如果IPsec实现配置为基于ICMP标头值通过SAs传递ICMP错误消息，而不检查ICMP消息负载中的标头信息，则可能会出现严重漏洞。考虑一个场景，其中几个站点（A、B和C）通过ESP保护隧道彼此连接：和B-C。还假设每个隧道的流量选择器为协议和端口字段以及包含服务于每个站点的安全网关后面的系统的地址范围的IP源/目标地址范围指定了任何值。这将允许站点B上的主机向站点a上的任何主机发送ICMP目的地不可访问消息，该消息声明站点C上网络上的所有主机都不可访问。这是一种非常有效的DoS攻击，如果ICMP错误消息经过IPsec提供的检查，并且SPD配置正确，则可以防止这种攻击，如第6.2节所述。
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".
IANA已为asn1模块注册表分配了值（3），并为SPD模块分配了对象标识符1.3.6.1.5.8.3.1。参见附录C，“ASN.1中的SPD条目”。
This architecture document differs substantially from RFC 2401 [RFC2401] in detail and in organization, but the fundamental notions are unchanged.
本架构（architecture）文档在细节和组织上与RFC 2401[RFC2401]有很大不同，但基本概念没有改变。
o The processing model has been revised to address new IPsec scenarios, improve performance, and simplify implementation. This includes a separation between forwarding (routing) and SPD
o 处理模型已经过修改，以解决新的IPsec方案、提高性能和简化实现。这包括转发（路由）和SPD之间的分离
selection, several SPD changes, and the addition of an outbound SPD cache and an inbound SPD cache for bypassed or discarded traffic. There is also a new database, the Peer Authorization Database (PAD). This provides a link between an SA management protocol (such as IKE) and the SPD.
选择、多个SPD更改，以及为绕过或丢弃的流量添加出站SPD缓存和入站SPD缓存。还有一个新的数据库，对等授权数据库（PAD）。这提供了SA管理协议（如IKE）和SPD之间的链接。
o There is no longer a requirement to support nested SAs or "SA bundles". Instead this functionality can be achieved through SPD and forwarding table configuration. An example of a configuration has been added in Appendix E.
o 不再需要支持嵌套的SA或“SA捆绑包”。相反，此功能可以通过SPD和转发表配置来实现。附录E中增加了一个配置示例。
o SPD entries were redefined to provide more flexibility. Each SPD entry now consists of 1 to N sets of selectors, where each selector set contains one protocol and a "list of ranges" can now be specified for the Local IP address, Remote IP address, and whatever fields (if any) are associated with the Next Layer Protocol (Local Port, Remote Port, ICMP message type and code, and Mobility Header type). An individual value for a selector is represented via a trivial range and ANY is represented via a range than spans all values for the selector. An example of an ASN.1 description is included in Appendix C.
o 重新定义了SPD条目，以提供更大的灵活性。每个SPD条目现在由1到N组选择器组成，其中每个选择器集包含一个协议，现在可以为本地IP地址、远程IP地址以及与下一层协议（本地端口、远程端口、ICMP消息类型和代码以及移动报头类型）关联的任何字段（如果有）指定“范围列表”。选择器的单个值通过普通范围表示，任何值通过范围表示，而不是跨越选择器的所有值。附录C中包含了ASN.1说明的示例。
o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and ECN. The tunnel section has been updated to explain how to handle DSCP and ECN bits.
o TOS（IPv4）和流量类别（IPv6）已被DSCP和ECN取代。隧道部分已更新，以解释如何处理DSCP和ECN位。
o For tunnel mode SAs, an SG, BITS, or BITW implementation is now allowed to fragment packets before applying IPsec. This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.
o 对于隧道模式SAs，现在允许SG、BITS或BITW实现在应用IPsec之前对数据包进行分段。这仅适用于IPv4。对于IPv6数据包，仅允许发起者对其进行分段。
o When security is desired between two intermediate systems along a path or between an intermediate system and an end system, transport mode may now be used between security gateways and between a security gateway and a host.
o 当需要沿路径的两个中间系统之间或中间系统与终端系统之间的安全性时，现在可以在安全网关之间以及安全网关与主机之间使用传输模式。
o This document clarifies that for all traffic that crosses the IPsec boundary, including IPsec management traffic, the SPD or associated caches must be consulted.
o 本文档阐明，对于所有跨越IPsec边界的流量，包括IPsec管理流量，必须咨询SPD或相关缓存。
o This document defines how to handle the situation of a security gateway with multiple subscribers requiring separate IPsec contexts.
o 本文档定义了如何处理多个订户需要单独IPsec上下文的安全网关的情况。
o A definition of reserved SPIs has been added.
o 已添加保留SPI的定义。
o Text has been added explaining why ALL IP packets must be checked -- IPsec includes minimal firewall functionality to support access control at the IP layer.
o 添加了解释为什么必须检查所有IP数据包的文本——IPsec包含最低限度的防火墙功能，以支持IP层的访问控制。
o The tunnel section has been updated to clarify how to handle the IP options field and IPv6 extension headers when constructing the outer header.
o 隧道部分已更新，以澄清在构造外部标头时如何处理IP选项字段和IPv6扩展标头。
o SA mapping for inbound traffic has been updated to be consistent with the changes made in AH and ESP for support of unicast and multicast SAs.
o 入站流量的SA映射已更新，以与AH和ESP中为支持单播和多播SAs所做的更改保持一致。
o Guidance has been added regarding how to handle the covert channel created in tunnel mode by copying the DSCP value to outer header.
o 增加了有关如何通过将DSCP值复制到外部标头来处理在隧道模式下创建的隐蔽通道的指南。
o Support for AH in both IPv4 and IPv6 is no longer required.
o 不再需要在IPv4和IPv6中支持AH。
o PMTU handling has been updated. The appendix on PMTU/DF/Fragmentation has been deleted.
o PMTU处理已更新。关于PMTU/DF/分段的附录已删除。
o Three approaches have been added for handling plaintext fragments on the protected side of the IPsec boundary. Appendix D documents the rationale behind them.
o 添加了三种方法来处理IPsec边界受保护一侧的明文片段。附录D记录了它们背后的基本原理。
o Added revised text describing how to derive selector values for SAs (from the SPD entry or from the packet, etc.)
o 添加了修订文本，说明如何导出SAs的选择器值（从SPD条目或数据包等）
o Added a new table describing the relationship between selector values in an SPD entry, the PFP flag, and resulting selector values in the corresponding SAD entry.
o 添加了一个新表，描述SPD条目中的选择器值、PFP标志和相应SAD条目中的结果选择器值之间的关系。
o Added Appendix B to describe decorrelation.
o 增加了附录B来描述去相关。
o Added text describing how to handle an outbound packet that must be discarded.
o 添加了描述如何处理必须丢弃的出站数据包的文本。
o Added text describing how to handle a DISCARDED inbound packet, i.e., one that does not match the SA upon which it arrived.
o 添加了描述如何处理丢弃的入站数据包的文本，即与到达的SA不匹配的数据包。
o IPv6 mobility header has been added as a possible Next Layer Protocol. IPv6 Mobility Header message type has been added as a selector.
o IPv6移动头已添加为可能的下一层协议。IPv6移动标头消息类型已添加为选择器。
o ICMP message type and code have been added as selectors.
o ICMP消息类型和代码已添加为选择器。
o The selector "data sensitivity level" has been removed to simplify things.
o 选择器“数据敏感度级别”已被删除，以简化操作。
o Updated text describing handling ICMP error messages. The appendix on "Categorization of ICMP Messages" has been deleted.
o 描述处理ICMP错误消息的更新文本。关于“ICMP消息分类”的附录已删除。
o The text for the selector name has been updated and clarified.
o 选择器名称的文本已更新并澄清。
o The "Next Layer Protocol" has been further explained and a default list of protocols to skip when looking for the Next Layer Protocol has been added.
o 进一步解释了“下一层协议”，并添加了查找下一层协议时要跳过的默认协议列表。
o The text has been amended to say that this document assumes use of IKEv2 or an SA management protocol with comparable features.
o 文本已修改为：本文件假定使用IKEv2或具有类似特征的SA管理协议。
o Text has been added clarifying the algorithm for mapping inbound IPsec datagrams to SAs in the presence of multicast SAs.
o 添加的文本阐明了在存在多播SAs的情况下将入站IPsec数据报映射到SAs的算法。
o The appendix "Sequence Space Window Code Example" has been removed.
o 附录“序列空间窗口代码示例”已删除。
o With respect to IP addresses and ports, the terms "Local" and "Remote" are used for policy rules (replacing source and destination). "Local" refers to the entity being protected by an IPsec implementation, i.e., the "source" address/port of outbound packets or the "destination" address/port of inbound packets. "Remote" refers to a peer entity or peer entities. The terms "source" and "destination" are still used for packet header fields.
o 关于IP地址和端口，术语“本地”和“远程”用于策略规则（替换源和目标）。“本地”是指受IPsec实现保护的实体，即出站数据包的“源”地址/端口或入站数据包的“目的”地址/端口。“远程”指对等实体或对等实体。术语“源”和“目的地”仍然用于数据包头字段。
The authors would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827; and Charlie Lynn, who made significant contributions to the second series of IPsec standards (RFCs 2401, 2402, and 2406) and to the current versions, especially with regard to IPv6 issues. The authors also would like to thank the members of the IPsec and MSEC working groups who have contributed to the development of this protocol specification.
作者要感谢Ran Atkinson的贡献，他在最初的IPsec活动中发挥了关键作用，并编写了第一系列IPsec标准：RFCs 1825-1827；Charlie Lynn，他对第二系列IPsec标准（RFCs 2401、2402和2406）和当前版本做出了重大贡献，特别是在IPv6问题上。作者还要感谢IPsec和MSEC工作组的成员，他们为本协议规范的开发做出了贡献。
Appendix A: Glossary
附录A：词汇表
This section provides definitions for several key terms that are employed in this document. Other documents provide additional definitions and background information relevant to this technology, e.g., [Shi00], [VK83], and [HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms.
本节提供了本文件中使用的几个关键术语的定义。其他文件提供了与该技术相关的其他定义和背景信息，例如[Shi00]、[VK83]和[HA94]。本词汇表中包括通用安全服务和安全机制术语，以及IPsec特定术语。
Access Control A security service that prevents unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. In the IPsec context, the resource to which access is being controlled is often:
访问控制防止未经授权使用资源的安全服务，包括防止以未经授权的方式使用资源。在IPsec上下文中，控制访问的资源通常是：
o for a host, computing cycles or data o for a security gateway, a network behind the gateway or bandwidth on that network.
o 对于主机，安全网关的计算周期或数据o、网关后面的网络或该网络上的带宽。
Anti-replay See "Integrity" below.
反重播请参阅下面的“完整性”。
Authentication Used informally to refer to the combination of two nominally distinct security services, data origin authentication and connectionless integrity. See the definitions below for each of these services.
身份验证非正式地用于指两种名义上不同的安全服务的组合，即数据源身份验证和无连接完整性。请参阅以下每个服务的定义。
Availability When viewed as a security service, addresses the security concerns engendered by attacks against networks that deny or degrade service. For example, in the IPsec context, the use of anti-replay mechanisms in AH and ESP support availability.
当将可用性视为安全服务时，它解决了因攻击拒绝或降级服务的网络而引起的安全问题。例如，在IPsec上下文中，AH和ESP中使用的反重播机制支持可用性。
Confidentiality The security service that protects data from unauthorized disclosure. The primary confidentiality concern in most instances is unauthorized disclosure of application-level data, but disclosure of the external characteristics of communication also can be a concern in some circumstances. Traffic flow confidentiality is the service that addresses this latter concern by concealing source and destination addresses, message length, or frequency of communication. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality. (See also "Traffic Analysis" below.)
保密性保护数据不被未经授权泄露的安全服务。在大多数情况下，主要的保密问题是未经授权披露应用程序级数据，但在某些情况下，披露通信的外部特征也可能是一个问题。流量机密性是通过隐藏源和目标地址、消息长度或通信频率来解决后一个问题的服务。在IPsec上下文中，在隧道模式下使用ESP，特别是在安全网关上，可以提供一定级别的流量机密性。（另请参见下面的“流量分析”。）
Data Origin Authentication A security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service.
数据源身份验证—验证声明的数据源身份的安全服务。此服务通常与无连接完整性服务捆绑在一起。
Encryption A security mechanism used to transform data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is designated "decryption". Often the term "encryption" is used to generically refer to both processes.
加密一种安全机制，用于将数据从可理解形式（明文）转换为不可理解形式（密文），以提供机密性。逆变换过程被称为“解密”。术语“加密”通常用于泛指这两个过程。
Integrity A security service that ensures that modifications to data are detectable. Integrity comes in various flavors to match application requirements. IPsec supports two forms of integrity: connectionless and a form of partial sequence integrity. Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic. The form of partial sequence integrity offered in IPsec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). This is in contrast to connection-oriented integrity, which imposes more stringent sequencing requirements on traffic, e.g., to be able to detect lost or re-ordered messages. Although authentication and integrity services often are cited separately, in practice they are intimately connected and almost always offered in tandem.
完整性—确保数据修改可检测的安全服务。完整性有多种形式，以满足应用程序的要求。IPsec支持两种形式的完整性：无连接和部分序列完整性。无连接完整性是一种检测单个IP数据报修改的服务，不考虑数据报在流量流中的顺序。IPsec中提供的部分序列完整性形式称为反重放完整性，它检测重复IP数据报的到达（在受约束的窗口内）。这与面向连接的完整性形成对比，后者对流量提出了更严格的排序要求，例如，能够检测丢失或重新排序的消息。虽然认证和完整性服务通常是分开引用的，但实际上它们是紧密相连的，几乎总是同时提供的。
Protected vs. Unprotected "Protected" refers to the systems or interfaces that are inside the IPsec protection boundary, and "unprotected" refers to the systems or interfaces that are outside the IPsec protection boundary. IPsec provides a boundary through which traffic passes. There is an asymmetry to this barrier, which is reflected in the processing model. Outbound data, if not discarded or bypassed, is protected via the application of AH or ESP and the addition of the corresponding headers. Inbound data, if not discarded or bypassed, is processed via the removal of AH or ESP headers. In this document, inbound traffic enters an IPsec implementation from the "unprotected" interface. Outbound traffic enters the implementation via the "protected" interface, or is internally generated by the implementation on the "protected" side of the boundary and directed toward the "unprotected" interface. An IPsec implementation may support more than one interface on either or both sides of the boundary. The protected interface may be
受保护与未受保护“受保护”是指IPsec保护边界内的系统或接口，“未受保护”是指IPsec保护边界外的系统或接口。IPsec提供了流量通过的边界。这一障碍存在不对称性，这反映在加工模型中。如果出站数据未被丢弃或绕过，则通过应用AH或ESP以及添加相应的头来保护。如果未丢弃或绕过入站数据，则通过删除AH或ESP头进行处理。在本文档中，入站流量从“未受保护”接口进入IPsec实现。出站流量通过“受保护”接口进入实现，或由边界“受保护”一侧的实现内部生成，并指向“未受保护”接口。IPsec实现可以在边界的一侧或两侧支持多个接口。受保护的接口可能是
internal, e.g., in a host implementation of IPsec. The protected interface may link to a socket layer interface presented by the OS.
内部，例如，在IPsec的主机实现中。受保护的接口可以链接到操作系统提供的套接字层接口。
Security Association (SA) A simplex (uni-directional) logical connection, created for security purposes. All traffic traversing an SA is provided the same security processing. In IPsec, an SA is an Internet-layer abstraction implemented through the use of AH or ESP. State data associated with an SA is represented in the SA Database (SAD).
安全关联（SA）为安全目的创建的单工（单向）逻辑连接。通过SA的所有流量都提供相同的安全处理。在IPsec中，SA是通过使用AH或ESP实现的Internet层抽象。与SA关联的状态数据在SA数据库（SAD）中表示。
Security Gateway An intermediate system that acts as the communications interface between two networks. The set of hosts (and networks) on the external side of the security gateway is termed unprotected (they are generally at least less protected than those "behind" the SG), while the networks and hosts on the internal side are viewed as protected. The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. In the IPsec context, a security gateway is a point at which AH and/or ESP is implemented in order to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also employing IPsec (either directly or via another security gateway).
安全网关作为两个网络之间通信接口的中间系统。安全网关外部的一组主机（和网络）被称为未受保护的（它们通常至少比“在”SG后面的主机保护得少），而内部的网络和主机被视为受保护的。安全网关所服务的内部子网和主机通过共享公共的本地安全管理而被认为是可信的。在IPsec上下文中，安全网关是实现AH和/或ESP以服务于一组内部主机的点，当这些主机与也采用IPsec（直接或通过另一个安全网关）的外部主机通信时，为这些主机提供安全服务。
Security Parameters Index (SPI) An arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet should be bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type. Additional IP address information is used to identify multicast SAs. The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing.
安全参数索引（SPI）接收器用于标识传入数据包应绑定到的SA的任意32位值。对于单播SA，SPI可以自己指定SA，也可以与IPsec协议类型一起使用。其他IP地址信息用于标识多播SA。SPI在AH和ESP协议中携带，以使接收系统能够选择SA，在该SA下处理接收到的数据包。SPI仅具有本地意义，如SA的创建者（通常是承载SPI的分组的接收器）所定义；因此，SPI通常被视为不透明的位字符串。然而，SA的创建者可以选择解释SPI中的比特以促进本地处理。
Traffic Analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, and flow identifiers [Sch94].
流量分析为了推断对对手有用的信息而对网络流量进行的分析。此类信息的示例包括传输频率、转换方的身份、数据包的大小和流标识符[Sch94]。
Appendix B: Decorrelation
附录B：去相关
This appendix is based on work done for caching of policies in the IP Security Policy Working Group by Luis Sanchez, Matt Condell, and John Zao.
本附录基于Luis Sanchez、Matt Condell和John Zao在IP安全策略工作组中为策略缓存所做的工作。
Two SPD entries are correlated if there is a non-null intersection between the values of corresponding selectors in each entry. Caching correlated SPD entries can lead to incorrect policy enforcement. A solution to this problem, which still allows for caching, is to remove the ambiguities by decorrelating the entries. That is, the SPD entries must be rewritten so that for every pair of entries there exists a selector for which there is a null intersection between the values in both of the entries. Once the entries are decorrelated, there is no longer any ordering requirement on them, since only one entry will match any lookup. The next section describes decorrelation in more detail and presents an algorithm that may be used to implement decorrelation.
如果每个条目中相应选择器的值之间存在非空交叉点，则两个SPD条目相互关联。缓存相关的SPD条目可能会导致错误的策略实施。这个问题的一个解决方案仍然允许缓存，就是通过解相关条目来消除歧义。也就是说，必须重写SPD条目，以便每对条目都存在一个选择器，两个条目中的值之间存在空交叉。一旦条目不相关，就不再需要对它们进行任何排序，因为只有一个条目将匹配任何查找。下一节将更详细地描述去相关，并介绍可用于实现去相关的算法。
The basic decorrelation algorithm takes each entry in a correlated SPD and divides it into a set of entries using a tree structure. The nodes of the tree are the selectors that may overlap between the policies. At each node, the algorithm creates a branch for each of the values of the selector. It also creates one branch for the complement of the union of all selector values. Policies are then formed by traversing the tree from the root to each leaf. The policies at the leaves are compared to the set of already decorrelated policy rules. Each policy at a leaf is either completely overridden by a policy in the already decorrelated set and is discarded or is decorrelated with all the policies in the decorrelated set and is added to it.
基本的去相关算法采用相关SPD中的每个条目，并使用树结构将其划分为一组条目。树的节点是策略之间可能重叠的选择器。在每个节点上，算法为选择器的每个值创建一个分支。它还为所有选择器值的并集的补码创建一个分支。然后通过从根到每个叶遍历树来形成策略。将叶上的策略与已解相关的策略规则集进行比较。叶上的每个策略要么被已解相关集中的策略完全覆盖并丢弃，要么与解相关集中的所有策略解相关并添加到其中。
The basic algorithm does not guarantee an optimal set of decorrelated entries. That is, the entries may be broken up into smaller sets than is necessary, though they will still provide all the necessary policy information. Some extensions to the basic algorithm are described later to improve this and improve the performance of the algorithm.
基本算法不能保证解相关项的最佳集合。也就是说，条目可能被划分为比必要的更小的集合，尽管它们仍将提供所有必要的策略信息。后面将描述对基本算法的一些扩展，以改进此算法并提高算法的性能。
C A set of ordered, correlated entries (a correlated SPD). Ci The ith entry in C. U The set of decorrelated entries being built from C. Ui The ith entry in U. Sik The kth selection for policy Ci. Ai The action for policy Ci.
C一组有序的相关条目（相关SPD）。Ci C.U中的第i个条目。从C.Ui中构建的一组不相关条目。U中的第i个条目。Sik策略Ci的第k个选择。Ai政策Ci的行动。
A policy (SPD entry) P may be expressed as a sequence of selector values and an action (BYPASS, DISCARD, or PROTECT):
策略（SPD条目）P可以表示为选择器值序列和操作（旁路、放弃或保护）：
Ci = Si1 x Si2 x ... x Sik -> Ai
Ci = Si1 x Si2 x ... x Sik -> Ai
1) Put C1 in set U as U1
1) 将C1放在U组中作为U1
For each policy Cj (j > 1) in C
对于C中的每个策略Cj（j>1）
2) If Cj is decorrelated with every entry in U, then add it to U.
2) 如果Cj与U中的每个条目不相关，则将其添加到U。
3) If Cj is correlated with one or more entries in U, create a tree rooted at the policy Cj that partitions Cj into a set of decorrelated entries. The algorithm starts with a root node where no selectors have yet been chosen.
3) 如果Cj与U中的一个或多个条目相关，则创建一个以策略Cj为根的树，将Cj划分为一组不相关的条目。该算法从根节点开始，其中尚未选择选择器。
A) Choose a selector in Cj, Sjn, that has not yet been chosen when traversing the tree from the root to this node. If there are no selectors not yet used, continue to the next unfinished branch until all branches have been completed. When the tree is completed, go to step D.
A） 在Cj，Sjn中选择一个选择器，该选择器在将树从根遍历到此节点时尚未选择。如果没有尚未使用的选择器，请继续执行下一个未完成的分支，直到所有分支都已完成。树完成后，转至步骤D。
T is the set of entries in U that are correlated with the entry at this node.
T是U中与此节点上的条目相关的条目集。
The entry at this node is the entry formed by the selector values of each of the branches between the root and this node. Any selector values that are not yet represented by branches assume the corresponding selector value in Cj, since the values in Cj represent the maximum value for each selector.
此节点上的条目是由根和此节点之间的每个分支的选择器值形成的条目。由于Cj中的值表示每个选择器的最大值，因此任何尚未由分支表示的选择器值均采用Cj中相应的选择器值。
B) Add a branch to the tree for each value of the selector Sjn that appears in any of the entries in T. (If the value is a superset of the value of Sjn in Cj, then use the value in Cj, since that value represents the universal set.) Also add a branch for the complement of the union of all the values of the selector Sjn in T. When taking the complement, remember that the universal set is the value of Sjn in Cj. A branch need not be created for the null set.
B） 为T中任何条目中出现的选择器Sjn的每个值向树中添加分支。（如果该值是Cj中Sjn值的超集，则使用Cj中的值，因为该值表示通用集。）还为选择器Sjn在T中的所有值的并集的补码添加一个分支。在获取补码时，请记住，通用集是Cj中Sjn的值。无需为空集合创建分支。
C) Repeat A and B until the tree is completed.
C） 重复A和B，直到完成树。
D) The entry to each leaf now represents an entry that is a subset of Cj. The entries at the leaves completely partition Cj in such a way that each entry is either completely overridden by an entry in U, or is decorrelated with the entries in U.
D） 每个叶的条目现在表示一个属于Cj子集的条目。叶中的条目完全划分Cj，这样每个条目要么被U中的条目完全覆盖，要么与U中的条目不相关。
Add all the decorrelated entries at the leaves of the tree to U.
将树叶上所有不相关的条目添加到U。
4) Get next Cj and go to 2.
4) 找到下一个Cj并转到2。
5) When all entries in C have been processed, then U will contain an decorrelated version of C.
5) 处理完C中的所有条目后，U将包含C的一个不相关版本。
There are several optimizations that can be made to this algorithm. A few of them are presented here.
可以对该算法进行若干优化。这里介绍了其中的一些。
It is possible to optimize, or at least improve, the amount of branching that occurs by carefully choosing the order of the selectors used for the next branch. For example, if a selector Sjn can be chosen so that all the values for that selector in T are equal to or a superset of the value of Sjn in Cj, then only a single branch needs to be created (since the complement will be null).
通过仔细选择用于下一个分支的选择器的顺序，可以优化或至少改进发生的分支量。例如，如果可以选择选择器Sjn，使T中该选择器的所有值等于Cj中的Sjn值或其超集，则只需要创建一个分支（因为补码将为null）。
Branches of the tree do not have to proceed with the entire decorrelation algorithm. For example, if a node represents an entry that is decorrelated with all the entries in U, then there is no reason to continue decorrelating that branch. Also, if a branch is completely overridden by an entry in U, then there is no reason to continue decorrelating the branch.
树的分支不必执行整个去相关算法。例如，如果一个节点表示一个与U中的所有条目解相关的条目，那么就没有理由继续解相关该分支。此外，如果一个分支被U中的一个条目完全覆盖，则没有理由继续对该分支进行解相关。
An additional optimization is to check to see if a branch is overridden by one of the CORRELATED entries in set C that has already been decorrelated. That is, if the branch is part of decorrelating Cj, then check to see if it was overridden by an entry Cm, m < j. This is a valid check, since all the entries Cm are already expressed in U.
另一个优化是检查分支是否被集合C中已解相关的一个相关项覆盖。也就是说，如果分支是解相关Cj的一部分，则检查它是否被条目Cm，m<j覆盖。这是一个有效的检查，因为所有条目Cm都已用U表示。
Along with checking if an entry is already decorrelated in step 2, check if Cj is overridden by any entry in U. If it is, skip it since it is not relevant. An entry x is overridden by another entry y if every selector in x is equal to or a subset of the corresponding selector in entry y.
在检查一个条目是否已在步骤2中解除关联的同时，检查Cj是否被U中的任何条目覆盖。如果是，则跳过它，因为它不相关。如果x中的每个选择器等于条目y中的相应选择器或其子集，则条目x将被另一个条目y覆盖。
Appendix C: ASN.1 for an SPD Entry
附录C:ASN.1适用于SPD条目
This appendix is included as an additional way to describe SPD entries, as defined in Section 4.4.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 SPD description in Section 4.4.1 is normative.
根据第4.4.1节的定义，本附录作为描述SPD条目的附加方式。它使用已成功编译的ASN.1语法。此语法只是说明性的，不需要在实现中使用以实现法规遵从性。第4.4.1节中的SPD描述是规范性的。
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
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
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) }
SelectorLists ::= SET OF SelectorList
SelectorLists ::= SET OF SelectorList
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice }
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice }
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,
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
df DF,
addresses TunnelAddresses }
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE Copy CE to inner header
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
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
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
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
终止
Appendix D: Fragment Handling Rationale
附录D：碎片处理原理
There are three issues that must be resolved regarding processing of (plaintext) fragments in IPsec:
关于IPsec中（纯文本）片段的处理，必须解决三个问题：
- mapping a non-initial, outbound fragment to the right SA (or finding the right SPD entry) - verifying that a received, non-initial fragment is authorized for the SA via which it is received - mapping outbound and inbound non-initial fragments to the right SPD/cache entry, for BYPASS/DISCARD traffic
- 将非初始出站片段映射到正确的SA（或查找正确的SPD条目）-验证接收到的非初始片段是否被授权用于接收该片段的SA-将出站和入站非初始片段映射到正确的SPD/缓存条目，用于绕过/丢弃流量
The first and third issues arise because we need a deterministic algorithm for mapping traffic to SAs (and SPD/cache entries). All three issues are important because we want to make sure that non-initial fragments that cross the IPsec boundary do not cause the access control policies in place at the receiver (or transmitter) to be violated.
出现第一个和第三个问题是因为我们需要一个确定性算法来将流量映射到SAs（和SPD/缓存条目）。这三个问题都很重要，因为我们希望确保跨越IPsec边界的非初始片段不会导致违反接收方（或发送方）的访问控制策略。
First, we note that transport mode SAs have been defined to not carry fragments. This is a carryover from RFC 2401, where transport mode SAs always terminated at endpoints. This is a fundamental requirement because, in the worst case, an IPv4 fragment to which IPsec was applied might then be fragmented (as a ciphertext packet), en route to the destination. IP fragment reassembly procedures at the IPsec receiver would not be able to distinguish between pre-IPsec fragments and fragments created after IPsec processing.
首先，我们注意到传输模式SA被定义为不携带片段。这是RFC 2401的遗留，其中传输模式SAs始终在端点终止。这是一项基本要求，因为在最坏的情况下，应用了IPsec的IPv4片段可能会在到达目的地的途中被分段（作为密文数据包）。IPsec接收器上的IP片段重组过程将无法区分IPsec前的片段和IPsec处理后创建的片段。
For IPv6, only the sender is allowed to fragment a packet. As for IPv4, an IPsec implementation is allowed to fragment tunnel mode packets after IPsec processing, because it is the sender relative to the (outer) tunnel header. However, unlike IPv4, it would be feasible to carry a plaintext fragment on a transport mode SA, because the fragment header in IPv6 would appear after the AH or ESP header, and thus would not cause confusion at the receiver with respect to reassembly. Specifically, the receiver would not attempt reassembly for the fragment until after IPsec processing. To keep things simple, this specification prohibits carriage of fragments on transport mode SAs for IPv6 traffic.
对于IPv6，只允许发送方对数据包进行分段。对于IPv4，允许IPsec实现在IPsec处理后对隧道模式数据包进行分段，因为它是相对于（外部）隧道头的发送方。然而，与IPv4不同的是，在传输模式SA上携带明文片段是可行的，因为IPv6中的片段标头将出现在AH或ESP标头之后，因此不会在接收器处造成重组方面的混淆。具体来说，在IPsec处理完成之前，接收方不会尝试重新组装片段。为了简单起见，此规范禁止在IPv6通信的传输模式SAs上传输片段。
When only end systems used transport mode SAs, the prohibition on carriage of fragments was not a problem, since we assumed that the end system could be configured to not offer a fragment to IPsec. For a native host implementation, this seems reasonable, and, as someone already noted, RFC 2401 warned that a BITS implementation might have to reassemble fragments before performing an SA lookup. (It would
当只有终端系统使用传输模式SAs时，禁止携带片段不是问题，因为我们假设可以将终端系统配置为不向IPsec提供片段。对于本机主机实现来说，这似乎是合理的，而且正如有人已经指出的，RFC 2401警告说，BITS实现可能必须在执行SA查找之前重新组装片段。（会的
then apply AH or ESP and could re-fragment the packet after IPsec processing.) Because a BITS implementation is assumed to be able to have access to all traffic emanating from its host, even if the host has multiple interfaces, this was deemed a reasonable mandate.
然后应用AH或ESP，并在IPsec处理后重新分割数据包。）因为假定BITS实现能够访问来自其主机的所有流量，即使主机有多个接口，这被认为是合理的要求。
In this specification, it is acceptable to use transport mode in cases where the IPsec implementation is not the ultimate destination, e.g., between two SGs. In principle, this creates a new opportunity for outbound, plaintext fragments to be mapped to a transport mode SA for IPsec processing. However, in these new contexts in which a transport mode SA is now approved for use, it seems likely that we can continue to prohibit transmission of fragments, as seen by IPsec, i.e., packets that have an "outer header" with a non-zero fragment offset field. For example, in an IP overlay network, packets being sent over transport mode SAs are IP-in-IP tunneled and thus have the necessary inner header to accommodate fragmentation prior to IPsec processing. When carried via a transport mode SA, IPsec would not examine the inner IP header for such traffic, and thus would not consider the packet to be a fragment.
在本规范中，可以在IPsec实现不是最终目的地的情况下使用传输模式，例如，在两个SGs之间。原则上，这为出站明文片段映射到传输模式SA以进行IPsec处理创造了新的机会。然而，在这些新的上下文中，传输模式SA现在被批准使用，我们似乎可以继续禁止片段的传输，如IPsec所示，即具有非零片段偏移字段的“外部报头”的数据包。例如，在IP覆盖网络中，通过传输模式SA发送的数据包是IP隧道中的IP，因此具有必要的内部报头以适应IPsec处理之前的碎片。当通过传输模式SA进行传输时，IPSec不会检查这样的业务的内部IP报头，因此不会认为包是片段。
For tunnel mode SAs, it has always been the case that outbound fragments might arrive for processing at an IPsec implementation. The need to accommodate fragmented outbound packets can pose a problem because a non-initial fragment generally will not contain the port fields associated with a next layer protocol such as TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a given IPsec implementation, plaintext fragments might or might not pose a problem.
对于隧道模式SAs，出站片段可能到达IPsec实现进行处理的情况一直存在。由于非初始片段通常不包含与下一层协议（如TCP、UDP或SCTP）相关联的端口字段，因此需要容纳分段出站数据包可能会带来问题。因此，根据给定IPsec实现的SPD配置，明文片段可能会也可能不会造成问题。
For example, if the SPD requires that all traffic between two address ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries apply to this address range), then it should be easy to carry non-initial fragments on the SA defined for this address range, since the SPD entry implies an intent to carry ALL traffic between the address ranges. But, if there are multiple SPD entries that could match a fragment, and if these entries reference different subsets of port fields (vs. ANY), then it is not possible to map an outbound non-initial fragment to the right entry, unambiguously. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the problems arises in that context as well.)
例如，如果SPD要求为两个地址范围之间的所有通信提供IPsec保护（没有旁路或丢弃SPD条目适用于此地址范围），那么在为该地址范围定义的SA上携带非初始片段应该很容易，因为SPD条目意味着要在地址范围之间传输所有通信量。但是，如果有多个SPD条目可以匹配一个片段，并且如果这些条目引用不同的端口字段子集（与任何字段相比），那么就不可能将出站非初始片段映射到正确的条目，这是毫无疑问的。（如果我们选择允许在IPv6的传输模式SAs上传输片段，那么在这种情况下也会出现问题。）
This problem largely, though not exclusively, motivated the definition of OPAQUE as a selector value for port fields in RFC 2401. The other motivation for OPAQUE is the observation that port fields might not be accessible due to the prior application of IPsec. For example, if a host applied IPsec to its traffic and that traffic
这个问题在很大程度上（尽管不是唯一的）促使RFC 2401将不透明定义为端口字段的选择器值。不透明的另一个动机是观察到由于先前应用了IPsec，端口字段可能无法访问。例如，如果主机将IPsec应用于其流量和该流量
arrived at an SG, these fields would be encrypted. The algorithm specified for locating the "next layer protocol" described in RFC 2401 also motivated use of OPAQUE to accommodate an encrypted next layer protocol field in such circumstances. Nonetheless, the primary use of the OPAQUE value was to match traffic selector fields in packets that did not contain port fields (non-initial fragments), or packets in which the port fields were already encrypted (as a result of nested application of IPsec). RFC 2401 was ambiguous in discussing the use of OPAQUE vs. ANY, suggesting in some places that ANY might be an alternative to OPAQUE.
到达SG后，这些字段将被加密。RFC 2401中描述的用于定位“下一层协议”的算法也促使在这种情况下使用不透明来容纳加密的下一层协议字段。尽管如此，不透明值的主要用途是匹配不包含端口字段（非初始片段）的数据包中的流量选择器字段，或者匹配端口字段已经加密的数据包（由于IPsec的嵌套应用）。RFC 2401在讨论“不透明”与“任何”的使用时模棱两可，这表明在某些地方，“任何”可能是“不透明”的替代品。
We gain additional access control capability by defining both ANY and OPAQUE values. OPAQUE can be defined to match only fields that are not accessible. We could define ANY as the complement of OPAQUE, i.e., it would match all values but only for accessible port fields. We have therefore simplified the procedure employed to locate the next layer protocol in this document, so that we treat ESP and AH as next layer protocols. As a result, the notion of an encrypted next layer protocol field has vanished, and there is also no need to worry about encrypted port fields either. And accordingly, OPAQUE will be applicable only to non-initial fragments.
我们通过定义任意值和不透明值来获得额外的访问控制能力。可以将不透明定义为仅匹配不可访问的字段。我们可以将ANY定义为不透明的补充，即，它将匹配所有值，但只匹配可访问的端口字段。因此，我们简化了本文件中用于定位下一层协议的程序，以便将ESP和AH视为下一层协议。因此，加密的下一层协议字段的概念已经消失，也不需要担心加密的端口字段。因此，不透明将仅适用于非初始片段。
Since we have adopted the definitions above for ANY and OPAQUE, we need to clarify how these values work when the specified protocol does not have port fields, and when ANY is used for the protocol selector. Accordingly, if a specific protocol value is used as a selector, and if that protocol has no port fields, then the port field selectors are to be ignored and ANY MUST be specified as the value for the port fields. (In this context, ICMP TYPE and CODE values are lumped together as a single port field (for IKEv2 negotiation), as is the IPv6 Mobility Header TYPE value.) If the protocol selector is ANY, then this should be treated as equivalent to specifying a protocol for which no port fields are defined, and thus the port selectors should be ignored, and MUST be set to ANY.
由于我们采用了上面对ANY和不透明的定义，我们需要澄清当指定的协议没有端口字段时，以及当ANY用于协议选择器时，这些值是如何工作的。因此，如果使用特定协议值作为选择器，并且该协议没有端口字段，则端口字段选择器将被忽略，并且必须将任意值指定为端口字段的值。（在此上下文中，ICMP类型和代码值与IPv6移动报头类型值一起被归为一个端口字段（用于IKEv2协商）。如果协议选择器为ANY，则应将其视为等同于指定未定义端口字段的协议，因此应忽略端口选择器，并且必须设置为任意。
For an SG implementation, it is obvious that fragments might arrive from end systems behind the SG. A BITW implementation also may encounter fragments from a host or gateway behind it. (As noted earlier, native host implementations and BITS implementations probably can avoid the problems described below.) In the worst case, fragments from a packet might arrive at distinct BITW or SG instantiations and thus preclude reassembly as a solution option. Hence, in RFC 2401 we adopted a general requirement that fragments must be accommodated in tunnel mode for all implementations. However,
对于SG实现，很明显，片段可能来自SG后面的终端系统。BITW实现还可能遇到来自其背后的主机或网关的碎片。（如前所述，本机主机实现和BITS实现可能可以避免下面所述的问题。）在最坏的情况下，数据包中的片段可能会到达不同的BITW或SG实例化，从而排除重新组装作为解决方案选项。因此，在RFC2401中，我们采用了一个通用要求，即对于所有实现，必须以隧道模式容纳片段。然而
RFC 2401 did not provide a perfect solution. The use of OPAQUE as a selector value for port fields (a SHOULD in RFC 2401) allowed an SA to carry non-initial fragments.
RFC 2401并没有提供完美的解决方案。使用不透明作为端口字段的选择器值（RFC 2401中的a应）允许SA携带非初始片段。
Using the features defined in RFC 2401, if one defined an SA between two IPsec (SG or BITW) implementations using the OPAQUE value for both port fields, then all non-initial fragments matching the source/destination (S/D) address and protocol values for the SA would be mapped to that SA. Initial fragments would NOT map to this SA, if we adopt a strict definition of OPAQUE. However, RFC 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA.
使用RFC 2401中定义的功能，如果使用两个端口字段的不透明值在两个IPsec（SG或BITW）实现之间定义SA，则所有与SA的源/目标（S/D）地址和协议值匹配的非初始片段都将映射到该SA。如果我们采用不透明的严格定义，初始片段将不会映射到此SA。然而，RFC 2401并未就此提供详细的指导，因此，使用此功能基本上不会创建“仅非初始片段”SA，这一点可能并不明显。
In the course of discussing the "fragment-only" SA approach, it was noted that some subtle problems, problems not considered in RFC 2401, would have to be avoided. For example, an SA of this sort must be configured to offer the "highest quality" security services for any traffic between the indicated S/D addresses (for the specified protocol). This is necessary to ensure that any traffic captured by the fragment-only SA is not offered degraded security relative to what it would have been offered if the packet were not fragmented. A possible problem here is that we may not be able to identify the "highest quality" security services defined for use between two IPsec implementation, since the choice of security protocols, options, and algorithms is a lattice, not a totally ordered set. (We might safely say that BYPASS < AH < ESP w/integrity, but it gets complicated if we have multiple ESP encryption or integrity algorithm options.) So, one has to impose a total ordering on these security parameters to make this work, but this can be done locally.
在讨论“仅片段”SA方法的过程中，注意到必须避免一些细微的问题，即RFC 2401中未考虑的问题。例如，必须将此类SA配置为为为指示的S/D地址（针对指定协议）之间的任何通信提供“最高质量”的安全服务。这对于确保仅片段SA捕获的任何流量不会提供相对于数据包未片段化时所提供的降级安全性是必要的。这里可能存在的一个问题是，我们可能无法确定为在两个IPsec实现之间使用而定义的“最高质量”安全服务，因为安全协议、选项和算法的选择是一个晶格，而不是一个完全有序的集合。（我们可以有把握地说绕过<AH<ESP w/integrity，但如果我们有多个ESP加密或integrity算法选项，它会变得复杂。）因此，必须对这些安全参数进行总体排序才能使其工作，但这可以在本地完成。
However, this conservative strategy has a possible performance downside. If most traffic traversing an IPsec implementation for a given S/D address pair (and specified protocol) is bypassed, then a fragment-only SA for that address pair might cause a dramatic increase in the volume of traffic afforded crypto processing. If the crypto implementation cannot support high traffic rates, this could cause problems. (An IPsec implementation that is capable of line rate or near line rate crypto performance would not be adversely affected by this SA configuration approach. Nonetheless, the performance impact is a potential concern, specific to implementation capabilities.)
然而，这种保守的策略可能会降低性能。如果绕过了通过给定S/D地址对（和指定协议）的IPsec实现的大多数通信量，则该地址对的仅片段SA可能会导致加密处理所提供的通信量急剧增加。如果加密实现无法支持高通信速率，则可能会导致问题。（能够实现线速率或近线速率加密性能的IPsec实现不会受到此SA配置方法的不利影响。但是，性能影响是一个潜在问题，具体取决于实现能力。）
Another concern is that non-initial fragments sent over a dedicated SA might be used to effect overlapping reassembly attacks, when combined with an apparently acceptable initial fragment. (This sort of attack assumes creation of bogus fragments and is not a side effect of normal fragmentation.) This concern is easily addressed in
另一个问题是，通过专用SA发送的非初始片段可能会与明显可接受的初始片段结合使用，从而导致重叠重组攻击。（这类攻击假定创建虚假碎片，而不是正常碎片的副作用。）这一问题在中很容易解决
IPv4, by checking the fragment offset value to ensure that no non-initial fragments have a small enough offset to overlap port fields that should be contained in the initial fragment. Recall that the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 bytes, so any ports should be present in the initial fragment. If we require all non-initial fragments to have an offset of, say, 128 or greater, just to be on the safe side, this should prevent successful attacks of this sort. If the intent is only to protect against this sort of reassembly attack, this check need be implemented only by a receiver.
IPv4，通过检查片段偏移量值确保没有非初始片段具有足够小的偏移量来重叠初始片段中应包含的端口字段。回想一下，IPv4 MTU的最小值是576字节，最大IP头长度是60字节，因此任何端口都应该出现在初始片段中。如果为了安全起见，我们要求所有非初始片段的偏移量为（比如）128或更大，这应该可以防止此类成功的攻击。如果目的只是为了防止这种重新组装攻击，那么该检查只需要由接收器执行。
IPv6 also has a fragment offset, carried in the fragmentation extension header. However, IPv6 extension headers are variable in length and there is no analogous max header length value that we can use to check non-initial fragments, to reject ones that might be used for an attack of the sort noted above. A receiver would need to maintain state analogous to reassembly state, to provide equivalent protection. So, only for IPv4 is it feasible to impose a fragment offset check that would reject attacks designed to circumvent port field checks by IPsec (or firewalls) when passing non-initial fragments.
IPv6还有一个片段偏移量，在片段扩展标头中携带。然而，IPv6扩展头的长度是可变的，并且没有类似的最大头长度值，我们可以用来检查非初始片段，拒绝可能用于上述类型攻击的片段。接收器需要保持类似于重新组装状态的状态，以提供等效的保护。因此，只有对于IPv4，才有可能实施片段偏移检查，该检查将拒绝旨在绕过IPsec（或防火墙）在传递非初始片段时进行的端口字段检查的攻击。
Another possible concern is that in some topologies and SPD configurations this approach might result in an access control surprise. The notion is that if we create an SA to carry ALL (non-initial) fragments, then that SA would carry some traffic that might otherwise arrive as plaintext via a separate path, e.g., a path monitored by a proxy firewall. But, this concern arises only if the other path allows initial fragments to traverse it without requiring reassembly, presumably a bad idea for a proxy firewall. Nonetheless, this does represent a potential problem in some topologies and under certain assumptions with respect to SPD and (other) firewall rule sets, and administrators need to be warned of this possibility.
另一个可能的问题是，在某些拓扑和SPD配置中，这种方法可能会导致访问控制意外。其概念是，如果我们创建一个SA来承载所有（非初始）片段，那么SA将承载一些流量，这些流量可能通过单独的路径（例如，由代理防火墙监控的路径）以明文形式到达。但是，只有当另一条路径允许初始片段在不需要重新组装的情况下遍历它时，才会出现这种问题，这对于代理防火墙来说可能是个坏主意。尽管如此，在某些拓扑中，以及在与SPD和（其他）防火墙规则集相关的某些假设下，这确实是一个潜在问题，需要提醒管理员注意这种可能性。
A less serious concern is that non-initial fragments sent over a non-initial fragment-only SA might represent a DoS opportunity, in that they could be sent when no valid, initial fragment will ever arrive. This might be used to attack hosts behind an SG or BITW device. However, the incremental risk posed by this sort of attack, which can be mounted only by hosts behind an SG or BITW device, seems small.
一个不太严重的问题是，通过非初始片段仅SA发送的非初始片段可能代表DoS机会，因为它们可能在没有有效初始片段到达时发送。这可能用于攻击SG或BITW设备后面的主机。然而，这种攻击所带来的增量风险似乎很小，这种攻击只能由SG或BITW设备后面的主机进行。
If we interpret the ANY selector value as encompassing OPAQUE, then a single SA with ANY values for both port fields would be able to accommodate all traffic matching the S/D address and protocol traffic selectors, an alternative to using the OPAQUE value. But, using ANY
如果我们将任意选择器值解释为包含不透明，那么对于两个端口字段，具有任意值的单个SA将能够容纳与S/D地址和协议流量选择器匹配的所有流量，这是使用不透明值的替代方法。但是，使用任何
here precludes multiple, distinct SAs between the same IPsec implementations for the same address pairs and protocol. So, it is not an exactly equivalent alternative.
这里排除了相同地址对和协议的相同IPsec实现之间的多个不同SA。因此，这不是一个完全相同的替代方案。
Fundamentally, fragment handling problems arise only when more than one SA is defined with the same S/D address and protocol selector values, but with different port field selector values.
从根本上说，只有当使用相同的S/D地址和协议选择器值定义多个SA，但使用不同的端口字段选择器值时，才会出现片段处理问题。
We also have to address the non-initial fragment processing issue for BYPASS/DISCARD entries, independent of SA processing. This is largely a local matter for two reasons:
我们还必须解决绕过/放弃条目的非初始片段处理问题，独立于SA处理。这主要是一个地方问题，原因有二：
1) We have no means for coordinating SPD entries for such traffic between IPsec implementations since IKE is not invoked. 2) Many of these entries refer to traffic that is NOT directed to or received from a location that is using IPsec. So there is no peer IPsec implementation with which to coordinate via any means.
1) 我们没有办法在IPsec实现之间协调此类流量的SPD条目，因为没有调用IKE。2） 其中许多条目指的是未定向到使用IPsec的位置或从该位置接收到的通信量。因此，没有对等的IPsec实现可以通过任何方式进行协调。
However, this document should provide guidance here, consistent with our goal of offering a well-defined, access control function for all traffic, relative to the IPsec boundary. To that end, this document says that implementations MUST support fragment reassembly for BYPASS/DISCARD traffic when port fields are specified. An implementation also MUST permit a user or administrator to accept such traffic or reject such traffic using the SPD conventions described in Section 4.4.1. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec-protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort.
但是，本文档应在此提供指导，这与我们为所有流量提供定义良好的访问控制功能（相对于IPsec边界）的目标一致。为此，本文指出，当指定端口字段时，实现必须支持旁路/丢弃通信的片段重组。实施还必须允许用户或管理员使用第4.4.1节中描述的SPD约定接受或拒绝此类通信。令人担忧的是，绕过到达IPsec实现的明文、非初始片段可能会破坏指向同一目的地的IPsec保护通信的安全性。例如，考虑用SPD条目配置的IPSec实现，其要求对特定源/目的地址对之间的业务进行IPSec保护，以及针对特定的协议和目的端口，例如端口23上的TCP流量（TELNET）。假设该实现还允许绕过来自相同源/目的地地址对和协议的流量，但针对不同的目的地端口，例如端口119（NNTP）。攻击者可以发送非初始片段（带有伪造的源地址），如果绕过该片段，可能会与来自同一源的受IPsec保护的流量重叠，从而破坏受IPsec保护的流量的完整性。需要对具有非平凡端口范围的旁路条目进行有状态片段检查，以防止此类攻击。
It has been suggested that we could avoid the problems described above by not allowing port field selectors to be used in tunnel mode. But the discussion above shows this to be an unnecessarily stringent approach, i.e., since no problems arise for the native OS and BITS implementations. Moreover, some WG members have described scenarios where use of tunnel mode SAs with (non-trivial) port field selectors is appropriate. So the challenge is defining a strategy that can deal with this problem in BITW and SG contexts. Also note that BYPASS/DISCARD entries in the SPD that make use of ports pose the same problems, irrespective of tunnel vs. transport mode notions.
有人建议，我们可以通过不允许在隧道模式下使用端口字段选择器来避免上述问题。但是上面的讨论表明，这是一种不必要的严格方法，也就是说，因为本机OS和BITS实现不会出现任何问题。此外，一些工作组成员描述了使用隧道模式SAs和（非平凡的）端口字段选择器的场景。因此，挑战在于定义一种能够在BITW和SG环境中处理此问题的策略。还请注意，无论隧道与传输模式的概念如何，SPD中使用端口的旁路/丢弃条目都会造成相同的问题。
Some folks have suggested that a firewall behind an SG or BITW should be left to enforce port-level access controls and the effects of fragmentation. However, this seems to be an incongruous suggestion in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned about firewalls that always discard fragments. If many firewalls don't pass fragments in general, why should we expect them to deal with fragments in this case? So, this analysis rejects the suggestion of disallowing use of port field selectors with tunnel mode SAs.
一些人建议，应该在SG或BITW后面设置防火墙，以强制实施端口级访问控制和碎片效应。然而，这似乎是一个不一致的建议，因为在IPsec的其他地方（例如IKE有效负载），我们担心总是丢弃碎片的防火墙。如果许多防火墙通常不传递碎片，那么在这种情况下，我们为什么要期望它们处理碎片呢？因此，该分析拒绝了不允许在隧道模式SAs中使用端口字段选择器的建议。
One suggestion is to reassemble fragments at the sending IPsec implementation, and thus avoid the problem entirely. This approach is invisible to a receiver and thus could be adopted as a purely local implementation option.
一个建议是在发送IPsec实现时重新组装片段，从而完全避免问题。这种方法对接收器是不可见的，因此可以作为一种纯粹的本地实现选项来采用。
A more sophisticated version of this suggestion calls for establishing and maintaining minimal state from each initial fragment encountered, to allow non-initial fragments to be matched to the right SAs or SPD/cache entries. This implies an extension to the current processing model (and the old one). The IPsec implementation would intercept all fragments; capture Source/Destination IP addresses, protocol, packet ID, and port fields from initial fragments; and then use this data to map non-initial fragments to SAs that require port fields. If this approach is employed, the receiver needs to employ an equivalent scheme, as it too must verify that received fragments are consistent with SA selector values. A non-initial fragment that arrives prior to an initial fragment could be cached or discarded, awaiting arrival of the corresponding initial fragment.
此建议的更复杂版本要求从遇到的每个初始片段建立并维护最小状态，以允许非初始片段与正确的SAs或SPD/缓存条目匹配。这意味着对当前处理模型（和旧模型）的扩展。IPsec实现将拦截所有片段；从初始片段捕获源/目标IP地址、协议、数据包ID和端口字段；然后使用此数据将非初始片段映射到需要端口字段的SA。如果采用这种方法，接收器需要采用等效方案，因为它也必须验证接收到的片段是否与SA选择器值一致。可以缓存或丢弃在初始片段之前到达的非初始片段，等待相应初始片段的到达。
A downside of both approaches noted above is that they will not always work. When a BITW device or SG is configured in a topology that might allow some fragments for a packet to be processed at different SGs or BITW devices, then there is no guarantee that all
上述两种方法的缺点是它们并不总是有效。当BITW设备或SG配置在允许在不同的SGs或BITW设备上处理数据包的某些片段的拓扑结构中时，无法保证
fragments will ever arrive at the same IPsec device. This approach also raises possible processing problems. If the sender caches non-initial fragments until the corresponding initial fragment arrives, buffering problems might arise, especially at high speeds. If the non-initial fragments are discarded rather than cached, there is no guarantee that traffic will ever pass, e.g., retransmission will result in different packet IDs that cannot be matched with prior transmissions. In any case, housekeeping procedures will be needed to decide when to delete the fragment state data, adding some complexity to the system. Nonetheless, this is a viable solution in some topologies, and these are likely to be common topologies.
碎片将永远到达同一IPsec设备。这种方法还可能引起处理问题。如果发送方缓存非初始片段直到相应的初始片段到达，则可能会出现缓冲问题，特别是在高速情况下。如果非初始片段被丢弃而不是被缓存，则不能保证通信量会通过，例如，重新传输将导致不同的分组id不能与先前的传输匹配。在任何情况下，都需要内务管理过程来决定何时删除片段状态数据，这给系统增加了一些复杂性。尽管如此，在某些拓扑中这是一个可行的解决方案，并且这些拓扑可能是常见的拓扑。
The Working Group rejected an earlier version of the convention of creating an SA to carry only non-initial fragments, something that was supported implicitly under the RFC 2401 model via use of OPAQUE port fields, but never clearly articulated in RFC 2401. The (rejected) text called for each non-initial fragment to be treated as protocol 44 (the IPv6 fragment header protocol ID) by the sender and receiver. This approach has the potential to make IPv4 and IPv6 fragment handling more uniform, but it does not fundamentally change the problem, nor does it address the issue of fragment handling for BYPASS/DISCARD traffic. Given the fragment overlap attack problem that IPv6 poses, it does not seem that it is worth the effort to adopt this strategy.
工作组拒绝了创建仅携带非初始片段的SA公约的早期版本，这在RFC 2401模型下通过使用不透明端口字段得到了隐式支持，但在RFC 2401中从未明确阐明。（被拒绝的）文本要求发送方和接收方将每个非初始片段视为协议44（IPv6片段头协议ID）。这种方法有可能使IPv4和IPv6片段处理更加统一，但它不能从根本上改变问题，也不能解决绕过/丢弃流量的片段处理问题。考虑到IPv6带来的碎片重叠攻击问题，似乎不值得采取这种策略。
Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform fragmentation prior to IPsec processing. If this fragmentation is performed after SA lookup at the sender, there is no "mapping to the right SA" problem. But, the receiver still needs to be able to verify that the non-initial fragments are consistent with the SA via which they are received. Since the initial fragment might be lost en route, the receiver encounters all of the potential problems noted above. Thus, if we are to be consistent in our decisions, we need to say how a receiver will deal with the non-initial fragments that arrive.
早些时候，工作组同意在IPsec处理之前允许IPsec BITS、BITW或SG执行分段。如果在发送方的SA查找之后执行此分段，则不存在“映射到右侧SA”问题。但是，接收器仍然需要能够验证非初始片段是否与接收它们的SA一致。由于初始片段可能在途中丢失，因此接收器会遇到上述所有潜在问题。因此，如果我们要在决策中保持一致，我们需要说明接收者将如何处理到达的非初始片段。
There is no simple, uniform way to handle fragments in all contexts. Different approaches work better in different contexts. Thus, this document offers 3 choices -- one MUST and two MAYs. At some point in the future, if the community gains experience with the two MAYs, they may become SHOULDs or MUSTs or other approaches may be proposed.
没有简单、统一的方法在所有上下文中处理片段。不同的方法在不同的环境下效果更好。因此，本文件提供了三种选择——一个必须，两个可能。在将来的某个时候，如果社区获得了这两个五月的经验，它们可能成为应该或必须，或者可能会提出其他方法。
Appendix E: Example of Supporting Nested SAs via SPD and Forwarding Table Entries
附录E：通过SPD和转发表项支持嵌套SAs的示例
This appendix provides an example of how to configure the SPD and forwarding tables to support a nested pair of SAs, consistent with the new processing model. For simplicity, this example assumes just one SPD-I.
本附录提供了一个示例，说明如何配置SPD和转发表，以支持与新处理模型一致的一对嵌套SA。为简单起见，本例假设只有一个SPD-I。
The goal in this example is to support a transport mode SA from A to C, carried over a tunnel mode SA from A to B. For example, A might be a laptop connected to the public Internet, B might be a firewall that protects a corporate network, and C might be a server on the corporate network that demands end-to-end authentication of A's traffic.
本例中的目标是支持从a到C的传输模式SA，通过隧道模式SA从a到B。例如，a可能是连接到公共互联网的笔记本电脑，B可能是保护公司网络的防火墙，C可能是公司网络上要求对a的流量进行端到端身份验证的服务器。
+---+ +---+ +---+
| A |=====| B | | C |
| |------------| |
| |=====| | | |
+---+ +---+ +---+
+---+ +---+ +---+
| A |=====| B | | C |
| |------------| |
| |=====| | | |
+---+ +---+ +---+
A's SPD contains entries of the form:
A的SPD包含以下形式的条目：
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- -----------------------
1 C A ESP BYPASS
2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf)
3 A C ANY PROTECT(ESP,transport,integr-only)
4 A B ICMP,IKE BYPASS
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- -----------------------
1 C A ESP BYPASS
2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf)
3 A C ANY PROTECT(ESP,transport,integr-only)
4 A B ICMP,IKE BYPASS
A's unprotected-side forwarding table is set so that outbound packets destined for C are looped back to the protected side. A's protected-side forwarding table is set so that inbound ESP packets are looped back to the unprotected side. A's forwarding tables contain entries of the form:
设置A的未受保护端转发表，以便将发往C的出站数据包循环回受保护端。A的受保护端转发表设置为使入站ESP数据包循环回未受保护端。A的转发表包含以下形式的条目：
Unprotected-side forwarding table
无保护侧转发表
Rule Local Remote Protocol Action
---- ----- ------ -------- ---------------------------
1 A C ANY loop back to protected side
2 A B ANY forward to B
Rule Local Remote Protocol Action
---- ----- ------ -------- ---------------------------
1 A C ANY loop back to protected side
2 A B ANY forward to B
Protected-side forwarding table
受保护侧转发表
Rule Local Remote Protocol Action
---- ----- ------ -------- -----------------------------
1 A C ESP loop back to unprotected side
Rule Local Remote Protocol Action
---- ----- ------ -------- -----------------------------
1 A C ESP loop back to unprotected side
An outbound TCP packet from A to C would match SPD rule 3 and have transport mode ESP applied to it. The unprotected-side forwarding table would then loop back the packet. The packet is compared against SPD-I (see Figure 2), matches SPD rule 1, and so it is BYPASSed. The packet is treated as an outbound packet and compared against the SPD for a third time. This time it matches SPD rule 2, so ESP is applied in tunnel mode. This time the forwarding table doesn't loop back the packet, because the outer destination address is B, so the packet goes out onto the wire.
从A到C的出站TCP数据包将匹配SPD规则3，并应用传输模式ESP。然后，未受保护的端转发表将循环回数据包。该数据包与SPD-I进行比较（见图2），与SPD规则1相匹配，因此被绕过。该数据包被视为出站数据包，并第三次与SPD进行比较。这一次它符合SPD规则2，因此ESP应用于隧道模式。这一次，转发表不会循环回数据包，因为外部目的地地址是B，所以数据包会发送到线路上。
An inbound TCP packet from C to A is wrapped in two ESP headers; the outer header (ESP in tunnel mode) shows B as the source, whereas the inner header (ESP transport mode) shows C as the source. Upon arrival at A, the packet would be mapped to an SA based on the SPI, have the outer header removed, and be decrypted and integrity-checked. Then it would be matched against the SAD selectors for this SA, which would specify C as the source and A as the destination, derived from SPD rule 2. The protected-side forwarding function would then send it back to the unprotected side based on the addresses and the next layer protocol (ESP), indicative of nesting. It is compared against SPD-O (see Figure 3) and found to match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA based on the SPI, integrity-checked, and compared against the SAD selectors derived from SPD rule 3. The forwarding function then passes it up to the next layer, because it isn't an ESP packet.
从C到A的入站TCP包被包装在两个ESP头中；外部标题（ESP在隧道模式下）显示B为源，而内部标题（ESP传输模式）显示C为源。到达A时，数据包将根据SPI映射到SA，移除外部报头，并进行解密和完整性检查。然后，它将与此SA的SAD选择器相匹配，该选择器将指定C作为源，指定A作为目标，从SPD规则2派生。然后，受保护端转发功能将根据地址和下一层协议（ESP）将其发送回未受保护端，表示嵌套。将其与SPD-O（见图3）进行比较，发现符合SPD规则1，因此将其忽略。数据包基于SPI映射到SA，完整性检查，并与从SPD规则3派生的SAD选择器进行比较。转发功能然后将其传递到下一层，因为它不是ESP数据包。
References
工具书类
Normative References
规范性引用文件
[BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[BBCDWW98]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[CD98] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[CD98]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[Eas05] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements For Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[Eas05]第三届Eastlake，D.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4305，2005年12月。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HarCar98]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Kau05]Kaufman，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[Ken05a]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[Ken05b] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[Ken05b]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[MD90]Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[Mobip]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81a]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981.
[Pos81b]Postel，J.，“互联网控制消息协议”，RFC 792，1981年9月。
[Sch05] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[Sch05]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[WaKiHo97]Wahl，M.，Kille，S.，和T.Howes，“轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示”，RFC 2253，1997年12月。
Informative References
资料性引用
[CoSa04] Condell, M., and L. Sanchez, "On the Deterministic Enforcement of Un-ordered Security Policies", BBN Technical Memo 1346, March 2004.
[CoSa04]Condell，M.和L.Sanchez，“关于联合国下令的安全政策的确定性实施”，BBN技术备忘录1346，2004年3月。
[FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[FaLiHaMeTr00]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[Gro02] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress, November 3, 2002.
[Gro02]Grossman，D.“区分服务的新术语和澄清”，RFC3260，2002年4月。[HC03]Holbrook，H.和B.Cain，“IP的源特定多播”，正在进行的工作，2002年11月3日。
[HA94] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[HA94]Haller，N.和R.Atkinson，“互联网认证”，RFC 17041994年10月。
[NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[NiBlBaBL98]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 24741998年12月。
[Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[Per96]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RaFlBl01]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加明确拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年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月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RaCoCaDe04]Rajahalme，J.，Conta，A.，Carpenter，B.，和S.Deering，“IPv6流标签规范”，RFC 36972004年3月。
[Sch94] Schneier, B., Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
[Sch94]Schneier，B.，应用密码学，第8.6节，John Wiley&Sons，纽约，纽约，1994年。
[Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[Shi00]Shirey，R.，“互联网安全词汇表”，RFC 28282000年5月。
[SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[SMPT01]Shacham，A.，Monsour，B.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 31732001年9月。
[ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[ToEgWa04]Touch，J.，Eggert，L.，和Y.Wang，“使用IPsec传输模式进行动态路由”，RFC 3884，2004年9月。
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[VK83]V.L.Voydock&S.T.Kent，“高级网络中的安全机制”，ACM计算调查，第15卷，第2期，1983年6月。
Authors' Addresses
作者地址
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Stephen Kent BBN Technologies 02138
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Karen Seo BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Karen Seo BBN Technologies 02138
Phone: +1 (617) 873-3152
EMail: kseo@bbn.com
Phone: +1 (617) 873-3152
EMail: kseo@bbn.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。