Network Working Group S. Kent
Request for Comments: 2401 BBN Corp
Obsoletes: 1825 R. Atkinson
Category: Standards Track @Home Network
November 1998
Network Working Group S. Kent
Request for Comments: 2401 BBN Corp
Obsoletes: 1825 R. Atkinson
Category: Standards Track @Home Network
November 1998
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Table of Contents
目录
1. Introduction........................................................3
1.1 Summary of Contents of Document..................................3
1.2 Audience.........................................................3
1.3 Related Documents................................................4
2. Design Objectives...................................................4
2.1 Goals/Objectives/Requirements/Problem Description................4
2.2 Caveats and Assumptions..........................................5
3. System Overview.....................................................5
3.1 What IPsec Does..................................................6
3.2 How IPsec Works..................................................6
3.3 Where IPsec May Be Implemented...................................7
4. Security Associations...............................................8
4.1 Definition and Scope.............................................8
4.2 Security Association Functionality..............................10
4.3 Combining Security Associations.................................11
4.4 Security Association Databases..................................13
4.4.1 The Security Policy Database (SPD).........................14
4.4.2 Selectors..................................................17
4.4.3 Security Association Database (SAD)........................21
4.5 Basic Combinations of Security Associations.....................24
4.6 SA and Key Management...........................................26
4.6.1 Manual Techniques..........................................27
4.6.2 Automated SA and Key Management............................27
4.6.3 Locating a Security Gateway................................28
4.7 Security Associations and Multicast.............................29
1. Introduction........................................................3
1.1 Summary of Contents of Document..................................3
1.2 Audience.........................................................3
1.3 Related Documents................................................4
2. Design Objectives...................................................4
2.1 Goals/Objectives/Requirements/Problem Description................4
2.2 Caveats and Assumptions..........................................5
3. System Overview.....................................................5
3.1 What IPsec Does..................................................6
3.2 How IPsec Works..................................................6
3.3 Where IPsec May Be Implemented...................................7
4. Security Associations...............................................8
4.1 Definition and Scope.............................................8
4.2 Security Association Functionality..............................10
4.3 Combining Security Associations.................................11
4.4 Security Association Databases..................................13
4.4.1 The Security Policy Database (SPD).........................14
4.4.2 Selectors..................................................17
4.4.3 Security Association Database (SAD)........................21
4.5 Basic Combinations of Security Associations.....................24
4.6 SA and Key Management...........................................26
4.6.1 Manual Techniques..........................................27
4.6.2 Automated SA and Key Management............................27
4.6.3 Locating a Security Gateway................................28
4.7 Security Associations and Multicast.............................29
5. IP Traffic Processing..............................................30
5.1 Outbound IP Traffic Processing..................................30
5.1.1 Selecting and Using an SA or SA Bundle.....................30
5.1.2 Header Construction for Tunnel Mode........................31
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32
5.2 Processing Inbound IP Traffic...................................33
5.2.1 Selecting and Using an SA or SA Bundle.....................33
5.2.2 Handling of AH and ESP tunnels.............................34
6. ICMP Processing (relevant to IPsec)................................35
6.1 PMTU/DF Processing..............................................36
6.1.1 DF Bit.....................................................36
6.1.2 Path MTU Discovery (PMTU)..................................36
6.1.2.1 Propagation of PMTU...................................36
6.1.2.2 Calculation of PMTU...................................37
6.1.2.3 Granularity of PMTU Processing........................37
6.1.2.4 PMTU Aging............................................38
7. Auditing...........................................................39
8. Use in Systems Supporting Information Flow Security................39
8.1 Relationship Between Security Associations and Data Sensitivity.40
8.2 Sensitivity Consistency Checking................................40
8.3 Additional MLS Attributes for Security Association Databases....41
8.4 Additional Inbound Processing Steps for MLS Networking..........41
8.5 Additional Outbound Processing Steps for MLS Networking.........41
8.6 Additional MLS Processing for Security Gateways.................42
9. Performance Issues.................................................42
10. Conformance Requirements..........................................43
11. Security Considerations...........................................43
12. Differences from RFC 1825.........................................43
Acknowledgements......................................................44
Appendix A -- Glossary................................................45
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.....48
B.1 DF bit..........................................................48
B.2 Fragmentation...................................................48
B.3 Path MTU Discovery..............................................52
B.3.1 Identifying the Originating Host(s)........................53
B.3.2 Calculation of PMTU........................................55
B.3.3 Granularity of Maintaining PMTU Data.......................56
B.3.4 Per Socket Maintenance of PMTU Data........................57
B.3.5 Delivery of PMTU Data to the Transport Layer...............57
B.3.6 Aging of PMTU Data.........................................57
Appendix C -- Sequence Space Window Code Example......................58
Appendix D -- Categorization of ICMP messages.........................60
References............................................................63
Disclaimer............................................................64
Author Information....................................................65
Full Copyright Statement..............................................66
5. IP Traffic Processing..............................................30
5.1 Outbound IP Traffic Processing..................................30
5.1.1 Selecting and Using an SA or SA Bundle.....................30
5.1.2 Header Construction for Tunnel Mode........................31
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32
5.2 Processing Inbound IP Traffic...................................33
5.2.1 Selecting and Using an SA or SA Bundle.....................33
5.2.2 Handling of AH and ESP tunnels.............................34
6. ICMP Processing (relevant to IPsec)................................35
6.1 PMTU/DF Processing..............................................36
6.1.1 DF Bit.....................................................36
6.1.2 Path MTU Discovery (PMTU)..................................36
6.1.2.1 Propagation of PMTU...................................36
6.1.2.2 Calculation of PMTU...................................37
6.1.2.3 Granularity of PMTU Processing........................37
6.1.2.4 PMTU Aging............................................38
7. Auditing...........................................................39
8. Use in Systems Supporting Information Flow Security................39
8.1 Relationship Between Security Associations and Data Sensitivity.40
8.2 Sensitivity Consistency Checking................................40
8.3 Additional MLS Attributes for Security Association Databases....41
8.4 Additional Inbound Processing Steps for MLS Networking..........41
8.5 Additional Outbound Processing Steps for MLS Networking.........41
8.6 Additional MLS Processing for Security Gateways.................42
9. Performance Issues.................................................42
10. Conformance Requirements..........................................43
11. Security Considerations...........................................43
12. Differences from RFC 1825.........................................43
Acknowledgements......................................................44
Appendix A -- Glossary................................................45
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.....48
B.1 DF bit..........................................................48
B.2 Fragmentation...................................................48
B.3 Path MTU Discovery..............................................52
B.3.1 Identifying the Originating Host(s)........................53
B.3.2 Calculation of PMTU........................................55
B.3.3 Granularity of Maintaining PMTU Data.......................56
B.3.4 Per Socket Maintenance of PMTU Data........................57
B.3.5 Delivery of PMTU Data to the Transport Layer...............57
B.3.6 Aging of PMTU Data.........................................57
Appendix C -- Sequence Space Window Code Example......................58
Appendix D -- Categorization of ICMP messages.........................60
References............................................................63
Disclaimer............................................................64
Author Information....................................................65
Full Copyright Statement..............................................66
This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and 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 IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following 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和IPv6环境中为IP层的流量提供各种安全服务。本文档描述了此类系统的目标、组件以及它们如何相互配合并融入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 automatic (The Internet Key Exchange (IKE)) d. Algorithms for authentication and encryption
a. 安全协议——认证头（AH）和封装安全有效负载（ESP）b。安全关联——它们是什么、如何工作、如何管理、关联处理c。密钥管理——手动和自动（Internet密钥交换（IKE））d。身份验证和加密算法
This document is not an overall 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 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 includes implementers of this IP security technology and others interested in gaining a general background understanding of this system. In particular, prospective users of this technology (end users or system administrators) are part of the target audience. A glossary is provided as an appendix
本文档的目标受众包括该IP安全技术的实施者和其他有兴趣了解该系统的一般背景知识的人。特别是，该技术的潜在用户（最终用户或系统管理员）是目标受众的一部分。术语表作为附录提供
to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general security terms and concepts.
帮助填补背景/词汇方面的空白。本文档假定读者熟悉互联网协议、相关网络技术以及一般安全术语和概念。
As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their inter-relationship. They include RFCs on the following topics:
如上所述，其他文档提供了IPsec的一些组件及其相互关系的详细定义。它们包括以下主题的RFC：
a. "IP Security Document Roadmap" [TDG97] -- a document providing guidelines for specifications describing encryption and authentication algorithms used in this system. b. security protocols -- RFCs describing the Authentication Header (AH) [KA98a] and Encapsulating Security Payload (ESP) [KA98b] protocols. c. algorithms for authentication and encryption -- a separate RFC for each algorithm. d. automatic key management -- RFCs on "The Internet Key Exchange (IKE)" [HC98], "Internet Security Association and Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key Determination Protocol" [Orm97], and "The Internet IP Security Domain of Interpretation for ISAKMP" [Pip98].
a. “IP安全文档路线图”[TDG97]——为描述本系统中使用的加密和身份验证算法的规范提供指南的文档。B安全协议——描述认证头（AH）[KA98a]和封装安全有效负载（ESP）[KA98b]协议的RFC。C身份验证和加密算法——每个算法都有一个单独的RFC。D自动密钥管理——关于“Internet密钥交换（IKE）”[HC98]、“Internet安全关联和密钥管理协议（ISAKMP）”[MSST97]、“OAKLEY密钥确定协议”[Orm97]和“ISAKMP解释的Internet IP安全域”[Pip98]的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, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols.
IPsec旨在为IPv4和IPv6提供可互操作、高质量、基于加密的安全性。提供的一组安全服务包括访问控制、无连接完整性、数据源身份验证、防止重播（部分序列完整性的一种形式）、机密性（加密）和有限流量机密性。这些服务在IP层提供，为IP和/或上层协议提供保护。
These objectives are met through the 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 any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations.
通过使用两个流量安全协议，即身份验证头（AH）和封装安全负载（ESP），以及通过使用加密密钥管理程序和协议，可以实现这些目标。在任何上下文中使用的IPsec协议集及其使用方式将由用户、应用程序和/或站点/组织的安全和系统要求决定。
When these mechanisms are correctly implemented and deployed, they ought not to adversely affect users, hosts, and other Internet components that do not employ these security mechanisms for
当这些机制得到正确的实现和部署时，它们不应该对用户、主机和其他不使用这些安全机制的Internet组件产生负面影响
protection of their traffic. These mechanisms also are designed to be algorithm-independent. This modularity permits selection of different sets of algorithms without affecting the other parts of the implementation. For example, different user communities may select different sets of algorithms (creating cliques) if required.
保护他们的交通。这些机制也被设计为与算法无关。这种模块化允许选择不同的算法集，而不会影响实现的其他部分。例如，如果需要，不同的用户社区可以选择不同的算法集（创建派系）。
A standard set of default algorithms is specified to facilitate interoperability in the global Internet. The use of these 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.
指定了一组标准的默认算法，以促进全球互联网的互操作性。这些算法与IPsec流量保护和密钥管理协议结合使用，旨在允许系统和应用程序开发人员部署高质量的Internet层加密安全技术。
The suite of IPsec protocols and associated default 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 the their implementation, which is 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协议套件和相关的默认算法旨在为Internet流量提供高质量的安全性。然而，使用这些协议提供的安全性最终取决于其实现的质量，这超出了这组标准的范围。此外，计算机系统或网络的安全是许多因素的函数，包括人员、物理、程序、泄漏和计算机安全实践。因此，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 or a security gateway environment, affording protection to IP traffic. The protection offered 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
IPsec实现在主机或安全网关环境中运行，为IP通信提供保护。所提供的保护基于由用户或系统管理员建立和维护的安全策略数据库（SPD）定义的要求，或由在约束条件下运行的应用程序定义的要求
established by either of the above. In general, packets are selected for one of three processing modes based on IP and transport layer header information (Selectors, Section 4.4.2) matched against entries in the database (SPD). Each packet is either afforded IPsec security services, discarded, or allowed to bypass IPsec, based on the applicable database policies identified by the Selectors.
由上述任何一项确定。通常，根据与数据库（SPD）中的条目相匹配的IP和传输层报头信息（选择器，第4.4.2节），为三种处理模式之一选择数据包。根据选择器识别的适用数据库策略，每个数据包要么被提供IPsec安全服务，要么被丢弃，要么被允许绕过IPsec。
IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.)
IPsec通过使系统能够选择所需的安全协议，确定用于服务的算法，并放置提供请求的服务所需的任何加密密钥，在IP层提供安全服务。IPsec可用于保护一对主机之间、一对安全网关之间或安全网关与主机之间的一条或多条“路径”。（在IPsec文档中，术语“安全网关”用于指代实现IPsec协议的中间系统。例如，实现IPsec的路由器或防火墙就是安全网关。）
The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc.
IPsec可以提供的一组安全服务包括访问控制、无连接完整性、数据源身份验证、拒绝重播数据包（部分序列完整性的一种形式）、机密性（加密）和有限流量机密性。因为这些服务是在IP层提供的，所以它们可以被任何更高层的协议使用，例如TCP、UDP、ICMP、BGP等。
The IPsec DOI also supports negotiation of IP compression [SMPT98], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers.
IPsec DOI还支持IP压缩协商[SMPT98]，部分原因是观察到，当IPsec中使用加密时，它会阻止较低协议层的有效压缩。
IPsec uses two protocols to provide traffic security -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in more detail in their respective RFCs [KA98a, KA98b].
IPsec使用两种协议来提供流量安全性——身份验证头（AH）和封装安全负载（ESP）。这两个协议在各自的RFC[KA98a，KA98b]中有更详细的描述。
o The IP Authentication Header (AH) [KA98a] provides connectionless integrity, data origin authentication, and an optional anti-replay service. o The Encapsulating Security Payload (ESP) protocol [KA98b] may provide confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless
o IP身份验证头（AH）[KA98a]提供无连接完整性、数据源身份验证和可选的反重放服务。o封装安全有效载荷（ESP）协议[KA98b]可提供机密性（加密）和有限的通信流机密性。它还可以提供无连接
integrity, data origin authentication, and an anti-replay service. (One or the other set of these security services must be applied whenever ESP is invoked.) o Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols.
完整性、数据源身份验证和反重播服务。（每当调用ESP时，必须应用这些安全服务的一组或另一组。）o AH和ESP都是访问控制的工具，基于加密密钥的分发和与这些安全协议相关的流量管理。
These protocols may be applied alone or in combination with each other to provide a desired set of security services in IPv4 and IPv6. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4.
这些协议可以单独应用，也可以相互结合应用，以在IPv4和IPv6中提供所需的一组安全服务。每个协议支持两种使用模式：传输模式和隧道模式。在传输模式下，协议主要为上层协议提供保护；在隧道模式下，协议应用于隧道IP数据包。第4节讨论了两种模式之间的差异。
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 management must incorporate facilities for specifying:
IPsec允许用户（或系统管理员）控制提供安全服务的粒度。例如，可以创建一个加密隧道来承载两个安全网关之间的所有流量，或者可以为通过这些网关通信的每对主机之间的每个TCP连接创建一个单独的加密隧道。IPsec管理必须包含用于指定以下内容的设施：
o which security services to use and in what combinations o the granularity at which a given security protection should be applied o the algorithms used to effect cryptographic-based security
o 要使用哪些安全服务以及以何种组合o应用给定安全保护的粒度o用于实现基于加密的安全性的算法
Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place. (The keys are used for authentication/integrity and encryption services.) This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (IKE -- [MSST97, Orm97, HC98]) for automatic key management, but other automated key distribution techniques MAY be used. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed.
由于这些安全服务使用共享秘密值（加密密钥），IPsec依赖于一组单独的机制来放置这些密钥。（密钥用于身份验证/完整性和加密服务。）本文档要求支持手动和自动分发密钥。它指定了用于自动密钥管理的特定基于公钥的方法（IKE--[MSST97，Orm97，HC98]），但也可以使用其他自动密钥分发技术。例如，可以使用基于KDC的系统（如Kerberos）和其他公钥系统（如SKIP）。
There are several ways in which IPsec may be implemented in a host or in conjunction with a router or firewall (to create a security gateway). Several common examples are provided below:
有几种方法可以在主机中实现IPsec，或者与路由器或防火墙结合使用（以创建安全网关）。下面提供了几个常见示例：
a. Integration of IPsec into the native IP implementation. This requires access to the IP source code and is applicable to both hosts and security gateways.
a. 将IPsec集成到本机IP实现中。这需要访问IP源代码，并且适用于主机和安全网关。
b. "Bump-in-the-stack" (BITS) implementations, where 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 an outboard crypto processor is a common design feature of network security 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 (or both). Usually the BITW device is 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 section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. 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 Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques.
本节定义了所有IPv6实现以及实现AH、ESP或两者的IPv4实现的安全关联管理要求。“安全关联”（SA）的概念是IPsec的基础。AH和ESP都使用SAs，IKE的主要功能是建立和维护安全关联。AH或ESP的所有实现必须支持如下所述的安全关联概念。本节的其余部分描述了安全关联管理的各个方面，定义了SA策略管理、流量处理和SA管理技术所需的特征。
A Security Association (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 is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required.
安全关联（SA）是一个单一的“连接”，为其承载的流量提供安全服务。通过使用AH或ESP向SA提供安全服务，但不能同时使用两者。如果AH和ESP保护都应用于业务流，则会创建两个（或更多）SA来为业务流提供保护。为了保护两台主机之间或两个安全网关之间的典型双向通信，需要两个安全关联（每个方向一个）。
A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the
安全关联由三元组唯一标识，三元组由安全参数索引（SPI）、IP目标地址和安全协议（AH或ESP）标识符组成。原则上，目的地地址可以是单播地址、IP广播地址或多播组地址。但是，IPsec SA管理机制目前仅为单播SA定义。因此,
discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well.
随后的讨论将在点对点通信的上下文中描述SAs，即使该概念也适用于点对多点的情况。
As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher layer protocols. In the case of ESP, a transport mode SA provides security services only for these higher 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, 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 [KA98a].
如上所述，定义了两种类型的SA：传输模式和隧道模式。传输模式SA是两台主机之间的安全关联。在IPv4中，传输模式安全协议头立即出现在IP头和任何选项之后，并出现在任何更高层协议（如TCP或UDP）之前。在IPv6中，安全协议标头出现在基本IP标头和扩展之后，但可能出现在目标选项之前或之后，以及更高层协议之前。对于ESP，传输模式SA仅为这些高层协议提供安全服务，而不为IP头或ESP头之前的任何扩展头提供安全服务。在AH的情况下，保护还扩展到IP报头的选定部分、扩展报头的选定部分和选定选项（包含在IPv4报头、IPv6逐跳扩展报头或IPv6目标扩展报头中）。有关AH提供的覆盖范围的更多详细信息，请参阅AH规范[KA98a]。
A tunnel mode SA is essentially an SA applied to an IP tunnel. 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 always a tunnel mode SA, as is an SA between a host and a security gateway. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. But in that case, the security gateway is not acting as a gateway, i.e., not transiting traffic. Two hosts MAY establish a tunnel mode SA between themselves. The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways.
隧道模式SA本质上是应用于IP隧道的SA。每当安全关联的任意一端是安全网关时，SA必须是隧道模式。因此，两个安全网关之间的SA始终是隧道模式SA，主机和安全网关之间的SA也是如此。请注意，对于将通信量发送到安全网关（例如SNMP命令）的情况，安全网关充当主机，允许使用传输模式。但在这种情况下，安全网关不充当网关，即不传输流量。两台主机可以在它们之间建立隧道模式SA。涉及安全网关的任何（传输流量）SA都需要成为隧道SA，这是因为需要避免与IPsec数据包的碎片化和重新组装有关的潜在问题，并且在安全网关后面存在多条路径（例如，通过不同的安全网关）到同一目的地的情况下。
For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate 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 higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header.
对于隧道模式SA，有一个“外部”IP头指定IPsec处理目的地，还有一个“内部”IP头指定（显然）数据包的最终目的地。安全协议头显示在外部IP头之后，内部IP头之前。如果在隧道模式中使用AH，则外部IP报头的部分被提供保护（如上所述），以及所有隧道IP分组（即，所有内部IP报头被保护，以及更高层协议）。如果使用ESP，则仅对隧道数据包提供保护，而不对外部报头提供保护。
In summary, a) A host MUST support both transport and tunnel mode. b) A security gateway is required to support only tunnel 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.
总之，a）主机必须同时支持传输模式和隧道模式。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 on the election of optional services within the protocol. For example, AH provides data origin authentication and connectionless integrity for IP datagrams (hereafter referred to as just "authentication"). The "precision" of the authentication service is a function of the granularity of the security association with which AH is employed, as discussed in Section 4.4.2, "Selectors".
SA提供的安全服务集取决于所选的安全协议、SA模式、SA的端点以及协议内可选服务的选择。例如，AH为IP数据报提供数据源身份验证和无连接完整性（以下简称“身份验证”）。认证服务的“精度”是使用AH的安全关联粒度的函数，如第4.4.2节“选择器”所述。
AH also offers an anti-replay (partial sequence integrity) service at the discretion of the receiver, to help counter denial of service attacks. AH is an appropriate protocol to employ when confidentiality is not required (or is not permitted, e.g , due to government restrictions on use of encryption). AH also provides authentication for selected portions of the IP header, which may be necessary in some contexts. For example, 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 the non-predictable but mutable parts of the IP header.)
AH还提供由接收方自行决定的反重播（部分序列完整性）服务，以帮助抵御拒绝服务攻击。AH是在不需要保密（或由于政府对加密使用的限制而不允许保密）时使用的适当协议。AH还为IP报头的选定部分提供身份验证，这在某些上下文中可能是必要的。例如，如果在发送方和接收方之间的路由中必须保护IPv4选项或IPv6扩展标头的完整性，AH可以提供此服务（IP标头的不可预测但可变部分除外）
ESP optionally provides confidentiality for traffic. (The strength of the confidentiality service depends in part, on the encryption algorithm employed.) ESP also may optionally provide authentication (as defined above). If authentication is negotiated for an ESP SA, the receiver also may elect to enforce an anti-replay service with the same features as the AH anti-replay service. The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header(s) "outside" the ESP header is(are) not protected. If only the upper layer protocols need to be authenticated, then ESP authentication is an appropriate choice and is more space efficient than use of AH encapsulating ESP. Note that although both confidentiality and authentication are optional, they cannot both be omitted. At least one of them MUST be selected.
ESP选择性地为流量提供保密性。（保密服务的强度部分取决于所采用的加密算法。）ESP还可以选择提供身份验证（如上所述）。如果针对ESP SA协商认证，则接收方还可以选择强制实施具有与AH反重播服务相同功能的反重播服务。ESP提供的认证范围比AH窄，即ESP报头“外部”的IP报头不受保护。如果只需要对上层协议进行身份验证，则ESP身份验证是一个合适的选择，并且比使用AH封装ESP更节省空间。请注意，尽管机密性和身份验证都是可选的，但它们不能同时省略。必须至少选择其中一个。
If confidentiality service 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
如果选择了保密服务，则两个安全网关之间的ESP（隧道模式）SA可以提供部分流量保密性。隧道模式的使用允许对内部IP报头进行加密，从而隐藏（最终）流量源和目的地的身份。此外，ESP有效负载填充也可以
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 which are carrying traffic from many subscribers.
调用以隐藏数据包的大小，进一步隐藏流量的外部特征。当在拨号上下文中为移动用户分配动态IP地址，并建立（隧道模式）ESP SA到公司防火墙（充当安全网关）时，可以提供类似的流量保密服务。请注意，细粒度SA通常比承载来自多个订户的流量的粗粒度SA更容易受到流量分析的影响。
The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.)
通过单个SA传输的IP数据报仅由一个安全协议（AH或ESP）提供保护，但并非两者都提供保护。有时，安全策略可能会要求针对特定流量的服务组合，这是单个SA无法实现的。在这种情况下，需要使用多个SA来实施所需的安全策略。术语“安全关联捆绑包”或“SA捆绑包”适用于SA序列，必须通过该序列处理流量以满足安全策略。序列的顺序由策略定义。（请注意，组成捆绑包的SA可能会在不同的端点终止。例如，一个SA可能会在移动主机和安全网关之间扩展，另一个嵌套SA可能会扩展到网关后面的主机。）
Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling.
安全关联可以通过两种方式组合成束：传输邻接和迭代隧道。
o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit (assuming use of adequately strong algorithms in each protocol) since the processing is performed at one IPsec instance at the (ultimate) destination.
o 传输邻接是指对同一IP数据报应用多个安全协议，而不调用隧道。这种结合AH和ESP的方法只允许一个层次的结合；进一步嵌套不会产生额外的好处（假设在每个协议中使用足够强大的算法），因为处理是在（最终）目的地的一个IPsec实例上执行的。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -----Security Association 1 (ESP transport)------- |
| |
-------Security Association 2 (AH transport)----------
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -----Security Association 1 (ESP transport)------- |
| |
-------Security Association 2 (AH transport)----------
o Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec
o 迭代隧道是指通过IP隧道实现的多层安全协议的应用。这种方法允许多级嵌套，因为每个隧道可以在不同的IPsec上发起或终止
site along the path. No special treatment is expected for ISAKMP traffic at intermediate security gateways other than what can be specified through appropriate SPD entries (See Case 3 in Section 4.5)
沿着路径的站点。对于中间安全网关上的ISAKMP流量，除通过适当的SPD入口指定的流量外，不需要特殊处理（见第4.5节中的情况3）
There are 3 basic cases of iterated tunneling -- support is required only for cases 2 and 3.:
迭代隧道有3种基本情况——仅在情况2和3中需要支持
1. both endpoints for the SAs are the same -- The inner and outer tunnels could each be either AH or ESP, though it is unlikely that Host 1 would specify both to be the same, i.e., AH inside of AH or ESP inside of ESP.
1. SAs的两个端点都是相同的——内部通道和外部通道都可以是AH或ESP，但主机1不太可能指定两者相同，即AH内的AH或ESP内的ESP。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------
2. one endpoint of the SAs is the same -- The inner and uter tunnels could each be either AH or ESP.
2. SAs的一个端点是相同的——内部通道和外部通道可以是AH或ESP。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------
3. neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.
3. 两个端点都不相同——内部通道和外部通道都可以是AH或ESP。
Host 1 --- Security ---- Internet -- Security --- Host 2
| Gwy 1 Gwy 2 |
| | | |
| --Security Assoc 1 (tunnel)- |
| |
-----------Security Association 2 (tunnel)-----------
Host 1 --- Security ---- Internet -- Security --- Host 2
| Gwy 1 Gwy 2 |
| | | |
| --Security Assoc 1 (tunnel)- |
| |
-----------Security Association 2 (tunnel)-----------
These two approaches also can be combined, e.g., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. (See Section 4.5 "Basic Combinations of Security Associations.") Note that nested tunnels can also occur where neither the source nor the destination endpoints of any of the tunnels are the same. In that case, there would be no host or security gateway with a bundle corresponding to the nested tunnels.
这两种方法也可以组合，例如，SA束可以由一个隧道模式SA和一个或两个传输模式SA按顺序应用而构建。（请参见第4.5节“安全关联的基本组合”）注意，如果任何隧道的源端点和目标端点都不相同，则也可能出现嵌套隧道。在这种情况下，没有主机或安全网关具有与嵌套隧道对应的捆绑包。
For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and (parts of) the IP header. Thus if AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. The required set of SA bundle types that MUST be supported by a compliant IPsec implementation is described in Section 4.5.
对于传输模式SAs，似乎只有一种安全协议顺序是合适的。AH应用于上层协议和（部分）IP报头。因此，如果AH与ESP一起在传输模式中使用，AH应在ESP出现之前作为IP之后的第一个报头出现。在这种情况下，AH应用于ESP的密文输出。相反，对于隧道模式SAs，您可以想象AH和ESP的各种排序的用途。第4.5节描述了必须由兼容的IPsec实现支持的所需SA捆绑包类型集。
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 security associations, in support of these interoperability and functionality goals. The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model.
IPsec实现中与处理IP流量相关的许多细节主要是本地事务，不受标准化的约束。但是，必须对处理的某些外部方面进行标准化，以确保互操作性，并提供对IPsec的生产性使用至关重要的最低管理能力。本节描述了处理与安全关联相关的IP流量的通用模型，以支持这些互操作性和功能目标。以下描述的模型为标称模型；兼容的实现不需要与所提供的模型的细节相匹配，但是这些实现的外部行为必须能够映射到该模型的外部可观察特征。
There are two nominal databases in this model: the Security Policy Database and the Security Association Database. The former specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host, security gateway, or BITS or BITW IPsec implementation. The latter database contains parameters that are associated with each (active) security association. This section also defines the concept of a Selector, a set of IP and upper layer protocol field values that is used by the Security Policy Database to map traffic to a policy, i.e., an SA (or SA bundle).
该模型中有两个标称数据库：安全策略数据库和安全关联数据库。前者指定用于确定主机、安全网关或BITS或BITW IPsec实现的所有入站或出站IP流量的处置的策略。后一个数据库包含与每个（活动）安全关联关联的参数。本节还定义了选择器的概念，即一组IP和上层协议字段值，安全策略数据库使用这些值将流量映射到策略，即SA（或SA捆绑包）。
Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors. Typically there is just one such interface, for a host or security gateway (SG). Note that an SG would always have at least 2 interfaces, but the "internal" one to the corporate net, usually would not have IPsec enabled and so only one pair of SADs and one pair of SPDs would be needed. On the other hand, if a host had multiple interfaces or an SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface.
启用IPsec的每个接口都需要名义上独立的入站和出站数据库（SAD和SPD），因为用作选择器的许多字段具有方向性。通常只有一个这样的接口，用于主机或安全网关（SG）。请注意，SG始终至少有2个接口，但公司网络的“内部”接口通常不会启用IPsec，因此只需要一对SAD和一对SPD。另一方面，如果主机有多个接口或SG有多个外部接口，则可能需要为每个接口提供单独的SAD和SPD对。
Ultimately, a security association is a management construct used to enforce a security policy in the IPsec environment. 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 does specify certain minimum management functionality that must be provided, to allow a user or system administrator to control how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway.
最终，安全关联是一种管理构造，用于在IPsec环境中强制实施安全策略。因此，SA处理的一个基本元素是一个底层安全策略数据库（SPD），它指定要向IP数据报提供哪些服务以及以何种方式提供。数据库的形式及其接口不在本规范的范围内。但是，本节确实规定了必须提供的某些最低管理功能，以允许用户或系统管理员控制如何将IPsec应用于主机传输或接收的流量或传输安全网关的流量。
The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. In order to support this, the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). In addition, a nominally separate SPD must be provided for each IPsec-enabled interface.
在处理所有流量（入站和出站）期间，包括非IPsec流量，必须咨询SPD。为了支持这一点，SPD需要入站和出站流量的不同条目。可以将其视为单独的SPD（入站与出站）。此外，必须为每个启用IPsec的接口提供名义上独立的SPD。
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 apply IPsec. The first choice refers to traffic that is not allowed to exit the host, traverse the security gateway, or be delivered to an application at all. The second choice refers to traffic that is allowed to pass without additional IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security services to be provided, protocols to be employed, algorithms to be used, etc.
SPD必须区分提供IPsec保护的流量和允许绕过IPsec的流量。这适用于发送方应用的IPsec保护和接收方必须存在的IPsec保护。对于任何出站或入站数据报，有三种处理选择：放弃、绕过IPsec或应用IPsec。第一种选择是指不允许退出主机、穿越安全网关或传送到应用程序的流量。第二种选择是指允许在没有额外IPsec保护的情况下通过的流量。第三种选择是指提供IPsec保护的流量，对于此类流量，SPD必须指定要提供的安全服务、要使用的协议、要使用的算法等。
For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. Specifically, every inbound or outbound packet is subject to processing by IPsec and the SPD must specify what action will be taken in each case. Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any packet entering or exiting the system, on a packet by packet basis. (In a host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per packet basis, but the effect is still the same.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support (total) ordering of these entries. It is expected that through the use of wildcards in various selector fields, and because all packets on a
对于每个IPsec实现，必须有一个允许用户或系统管理员管理SPD的管理界面。具体而言，每个入站或出站数据包都由IPsec处理，SPD必须指定在每种情况下将采取的操作。因此，管理界面必须允许用户（或系统管理员）在分组的基础上指定应用于进入或退出系统的任何分组的安全处理。（在使用套接字接口的主机IPsec实现中，可能不需要对每个数据包咨询SPD，但效果仍然相同。）SPD的管理接口必须允许创建与第4.4.2节中定义的选择器一致的条目，并且必须支持这些条目的（总）排序。预计通过在各种选择器字段中使用通配符，并且由于
single UDP or TCP connection will tend to match a single SPD entry, this requirement will not impose an unreasonably detailed level of SPD specification. The selectors are analogous to what are found in a stateless firewall or filtering router and which are currently manageable this way.
单个UDP或TCP连接将倾向于匹配单个SPD条目，此要求不会对SPD规范施加不合理的详细级别。选择器类似于无状态防火墙或过滤路由器中的选择器，目前可通过这种方式进行管理。
In host systems, applications MAY be allowed to select what security processing is to be applied to the traffic they generate and consume. (Means of signalling 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. Note that application specified policies may satisfy system requirements, so that the system may not need to do additional IPsec processing beyond that needed to meet an application's requirements. 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.
在主机系统中，可以允许应用程序选择对其生成和使用的流量应用何种安全处理。（向IPsec实现发送此类请求的方式不在本标准的范围内。）但是，系统管理员必须能够指定用户或应用程序是否可以覆盖（默认）系统策略。请注意，应用程序指定的策略可能满足系统要求，因此系统可能不需要执行超出满足应用程序要求所需的额外IPsec处理。本文档未指定管理接口的形式，主机与安全网关可能不同，主机内基于套接字与BITS实现的接口可能不同。但是，本文档确实指定了所有IPsec实现都必须支持的一组标准SPD元素。
The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry. (The required selector types are defined in Section 4.4.2.) These define the granularity of policies or SAs. Each entry includes an indication of whether traffic matching this policy will be bypassed, discarded, or subject to IPsec processing. If IPsec processing is to be applied, the entry includes an SA (or SA bundle) specification, listing the IPsec protocols, modes, and algorithms to be employed, including any nesting requirements. For example, an entry may call for all matching traffic to be protected by ESP in transport mode using 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode using HMAC/SHA-1. For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors):
SPD包含一个有序的策略条目列表。每个策略条目都由一个或多个选择器键入，这些选择器定义此策略条目包含的IP流量集。（第4.4.2节定义了所需的选择器类型。）这些选择器定义了策略或SA的粒度。每个条目都包含一个指示，指示与此策略匹配的流量是否将被绕过、丢弃或接受IPsec处理。如果要应用IPsec处理，则条目包括SA（或SA bundle）规范，其中列出了要采用的IPsec协议、模式和算法，包括任何嵌套要求。例如，条目可能要求ESP在传输模式下使用3DES-CBC和显式IV保护所有匹配流量，并在隧道模式下使用HMAC/SHA-1嵌套在AH内。对于每个选择器，策略条目指定如何从SPD和数据包中的值导出新安全关联数据库（SAD，请参阅第4.4.3节）条目的相应值（请注意，目前，仅支持IP地址的范围；但可以为所有选择器表示通配符）：
a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector are a range (for IP addresses) or
a. 使用数据包本身中的值——这将限制SA的使用，使其仅限于具有该数据包的选择器值的数据包，即使策略项的选择器具有允许的值范围或该选择器的通配符。B使用与策略项关联的值——如果这只是一个值，那么（b）和（a）之间就没有区别。但是，如果选择器允许的值是一个范围（对于IP地址）或
wildcard, then in the case of a range,(b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. In the case of a wildcard, (b) would allow use of the SA by packets with any value for this selector.
通配符，然后在范围的情况下，（b）将允许选择器值在范围内的任何数据包使用SA，而不仅仅是具有触发SA创建的数据包的选择器值的数据包使用SA。在通配符的情况下，（b）将允许具有此选择器的任何值的数据包使用SA。
For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). And suppose that a packet is to be sent that has a source address of 192.168.2.3. The value to be used for the SA could be any of the sample values below depending on what the policy entry for this selector says is the source of the selector value:
例如，假设有一个SPD条目，其中源地址的允许值是主机范围（192.168.2.1到192.168.2.10）中的任意一个。假设要发送的数据包的源地址为192.168.2.3。SA使用的值可以是以下任何示例值，具体取决于此选择器的策略条目所述的选择器值的来源：
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts)
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts)
Note that if the SPD entry had an allowed value of wildcard for the source address, then the SAD selector value could be wildcard (any host). Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry.
请注意，如果SPD条目的源地址具有允许的通配符值，则SAD选择器值可以是通配符（任何主机）。情况（a）可用于禁止共享，即使在匹配相同SPD条目的数据包之间也是如此。
As described below in Section 4.4.3, selectors may include "wildcard" entries and hence the selectors for two entries may overlap. (This is analogous to the overlap that arises with ACLs or filter entries in routers or packet filtering firewalls.) Thus, to ensure consistent, predictable processing, SPD entries MUST be ordered and the SPD MUST always be searched in the same order, so that the first matching entry is consistently selected. (This requirement is necessary as the effect of processing traffic against SPD entries must be deterministic, but there is no way to canonicalize SPD entries given the use of wildcards for some selectors.) More detail on matching of packets against SPD entries is provided in Section 5.
如下文第4.4.3节所述，选择器可能包括“通配符”条目，因此两个条目的选择器可能重叠。（这类似于路由器或包过滤防火墙中ACL或筛选器条目出现的重叠。）因此，为了确保一致、可预测的处理，必须对SPD条目进行排序，并且必须始终以相同的顺序搜索SPD，以便一致地选择第一个匹配条目。（这一要求是必要的，因为针对SPD条目处理流量的效果必须是确定的，但由于某些选择器使用通配符，因此无法规范化SPD条目。）第5节提供了有关数据包与SPD条目匹配的更多详细信息。
Note that if ESP is specified, either (but not both) authentication or encryption can be omitted. So it MUST be possible to configure the SPD value for the authentication or encryption algorithms to be "NULL". However, at least one of these services MUST be selected, i.e., it MUST NOT be possible to configure both of them as "NULL".
请注意，如果指定了ESP，则可以省略（但不能同时省略）身份验证或加密。因此，必须能够将身份验证或加密算法的SPD值配置为“NULL”。但是，必须至少选择其中一个服务，即不能将它们都配置为“NULL”。
The SPD can be used to map traffic to specific SAs or SA bundles. Thus it can function both as the reference database for security policy and as the map to existing SAs (or SA bundles). (To accommodate the bypass and discard policies cited above, the SPD also
SPD可用于将流量映射到特定SA或SA捆绑包。因此，它既可以作为安全策略的参考数据库，也可以作为现有SA（或SA捆绑包）的映射。（为了适应上述旁路和丢弃政策，SPD还
MUST provide a means of mapping traffic to these functions, even though they are not, per se, IPsec processing.) The way in which the SPD operates is different for inbound vs. outbound traffic and it also may differ for host vs. security gateway, BITS, and BITW implementations. Sections 5.1 and 5.2 describe the use of the SPD for outbound and inbound processing, respectively.
必须提供一种将流量映射到这些功能的方法，即使它们本身不是IPsec处理。）SPD的操作方式对于入站和出站流量是不同的，对于主机和安全网关、BITS和BITW实现也是不同的。第5.1节和第5.2节分别描述了SPD在出站和入站处理中的使用。
Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements, when present. Thus, it must be possible for an IPsec implementation to determine that an outbound or inbound packet must be processed thorough a sequence of SAs. Conceptually, for outbound processing, one might imagine links (to the SAD) from an SPD entry for which there are active SAs, and each entry would consist of either a single SA or an ordered list of SAs that comprise an SA bundle. When a packet is matched against an SPD entry and there is an existing SA or SA bundle that can be used to carry the traffic, the processing of the packet is controlled by the SA or SA bundle entry on the list. For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA.
由于安全策略可能要求对一组指定的流量应用多个SA，因此SPD中的策略条目必须保留这些排序要求（如果存在）。因此，IPsec实现必须能够确定出站或入站数据包必须通过SAs序列进行处理。从概念上讲，对于出站处理，您可能会设想来自有活动SA的SPD条目的链接（到SAD），并且每个条目将由单个SA或组成SA束的SA有序列表组成。当数据包与SPD条目匹配并且存在可用于承载流量的现有SA或SA捆绑包时，数据包的处理由列表上的SA或SA捆绑包条目控制。对于要应用多个IPsec SA的入站IPsec数据包，基于目标地址、IPsec协议和SPI的查找应标识单个SA。
The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway.
SPD用于控制通过IPsec系统的所有流量，包括来自/到安全网关后面实体的安全和密钥管理流量（如ISAKMP）。这意味着ISAKMP流量必须在SPD中明确说明，否则将被丢弃。请注意，安全网关可以以各种方式禁止遍历加密的数据包，例如，在SPD中为ESP数据包设置丢弃条目或提供代理密钥交换。在后一种情况下，通信量将在内部路由到安全网关中的密钥管理模块。
An SA (or SA bundle) 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 Protocol and Port fields), 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 for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW
SA（或SA bundle）可以是细粒度的，也可以是粗粒度的，这取决于用于定义SA流量集的选择器。例如，两台主机之间的所有流量都可以通过单个SA承载，并提供一组统一的安全服务。或者，一对主机之间的通信量可能分布在多个SA上，具体取决于所使用的应用程序（由下一个协议和端口字段定义），不同的SA提供不同的安全服务。类似地，一对安全网关之间的所有通信可以在单个SA上进行，或者可以为每个通信主机对分配一个SA。SA管理必须支持以下选择器参数，以便于控制SA粒度。请注意，在接收带有ESP报头的数据包的情况下，例如，在封装安全网关或BITW处
implementation, the transport layer protocol, source/destination ports, and Name (if present) may be "OPAQUE", i.e., inaccessible because of encryption or fragmentation. Note also that both Source and Destination addresses should either be IPv4 or IPv6.
在实现中，传输层协议、源/目标端口和名称（如果存在）可能是“不透明的”，即由于加密或碎片而无法访问。还要注意，源地址和目标地址都应该是IPv4或IPv6。
- Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address. The last three are used to support more than one destination system sharing the same SA (e.g., behind a security gateway). Note that this selector is conceptually different from the "Destination IP Address" field in the <Destination IP Address, IPsec Protocol, SPI> tuple used to uniquely identify an SA. When a tunneled packet arrives at the tunnel endpoint, its SPI/Destination address/Protocol are used to look up the SA for this packet in the SAD. This destination address comes from the encapsulating IP header. Once the packet has been processed according to the tunnel SA and has come out of the tunnel, its selectors are "looked up" in the Inbound SPD. The Inbound SPD has a selector called destination address. This IP destination address is the one in the inner (encapsulated) IP header. In the case of a transport'd packet, there will be only one IP header and this ambiguity does not exist. [REQUIRED for all implementations]
- 目标IP地址（IPv4或IPv6）：这可能是单个IP地址（单播、选播、广播（仅IPv4）或多播组）、一系列地址（高值和低值（包括）、地址+掩码或通配符地址。后三个用于支持多个共享同一SA的目标系统（例如，在安全网关后面）。请注意，此选择器在概念上不同于“目标IP地址”用于唯一标识SA的<Destination IP Address，IPsec Protocol，SPI>元组中的字段。当隧道数据包到达隧道端点时，其SPI/目标地址/协议用于在SAD中查找此数据包的SA。此目标地址来自封装IP标头。一旦数据包被acc处理根据隧道SA和已出隧道，其选择器在入站SPD中“查找”。入站SPD有一个称为目的地地址的选择器。此IP目的地地址位于内部（封装）IP报头中。对于传输数据包，将只有一个IP报头，且不存在这种歧义。[所有实施都需要]
- Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. The last three are used to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations]
- 源IP地址（IPv4或IPv6）：这可能是单个IP地址（单播、选播、广播（仅IPv4）或多播组）、地址范围（包括高值和低值）、地址+掩码或通配符地址。最后三个用于支持多个共享同一SA的源系统（例如，在安全网关后面或在多主机中）。[所有实施都需要]
- Name: There are 2 cases (Note that these name forms are supported in the IPsec DOI.) 1. User ID a. a fully qualified user name string (DNS), e.g., mozart@foo.bar.com b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent. 2. System name (host, security gateway, etc.) a. a fully qualified DNS name, e.g., foo.bar.com b. X.500 distinguished name c. X.500 general name
- 名称：有两种情况（请注意，IPsec DOI中支持这些名称表单。）1。用户ID a。完全限定的用户名字符串（DNS），例如。，mozart@foo.bar.comBX.500可分辨名称，例如C=US，SP=MA，O=GTE互联，CN=Stephen T.Kent。2.系统名称（主机、安全网关等）a。完全限定的DNS名称，例如foo.bar.com b。X.500可分辨名称c。X.500通用名称
NOTE: One of the possible values of this selector is "OPAQUE".
注意：此选择器的一个可能值为“不透明”。
[REQUIRED for the following cases. Note that support for name forms other than addresses is not required for manually keyed SAs. o User ID - native host implementations - BITW and BITS implementations acting as HOSTS with only one user - security gateway implementations for INBOUND processing. o System names -- all implementations]
[在以下情况下需要。请注意，手动键入的SAs不需要支持除地址以外的名称形式。o用户ID-本机主机实现-BITW和BITS实现充当只有一个用户的主机-用于入站处理的安全网关实现。o系统名称-所有实现]
- Data sensitivity level: (IPSO/CIPSO labels) [REQUIRED for all systems providing information flow security as per Section 8, OPTIONAL for all other systems.]
- 数据敏感度等级：（IPSO/CIPSO标签）[根据第8节提供信息流安全的所有系统都需要，所有其他系统可选。]
- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations]
- 传输层协议：从IPv4“协议”或IPv6“下一个标头”字段获取。这可能是一个单独的协议编号。由于存在IP扩展报头，这些数据包字段可能不包含传输协议，例如路由报头、AH、ESP、分段报头、目的地选项、逐跳选项等。请注意，在接收到带有ESP报头的数据包的情况下，传输协议可能不可用，因此值为“不透明”应该得到支持。[所有实施都需要]
NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque.
注意：要定位传输协议，系统必须通过数据包头链接，检查“协议”或“下一个头”字段，直到遇到一个它识别为传输协议的数据包头，或者直到到达一个不在扩展头列表中的数据包头，或者直到遇到使传输协议不透明的ESP报头。
- Source and Destination (e.g., TCP/UDP) Ports: These may be individual UDP or TCP port values or a wildcard port. (The use of the Next Protocol field and the Source and/or Destination Port fields (in conjunction with the Source and/or Destination Address fields), as an SA selector is sometimes referred to as "session-oriented keying."). Note that the source and destination ports may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported.
- 源和目标（例如TCP/UDP）端口：这些端口可以是单个UDP或TCP端口值，也可以是通配符端口。（将下一个协议字段和源和/或目标端口字段（与源和/或目标地址字段一起）用作SA选择器有时被称为“面向会话的键控”）。请注意，在接收到带有ESP头的数据包的情况下，源端口和目标端口可能不可用，因此应支持“不透明”值。
The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the derived Port Selector value for the SPD and SAD.
下表总结了数据包和SPD中的“下一个标头”值与SPD和SAD的派生端口选择器值之间的关系。
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment
If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. [MAY be supported]
如果数据包已分段，则端口信息可能在当前分段中不可用。如果是，则丢弃该片段。应为第一个片段发送ICMP PMTU，该片段将包含端口信息。[可能得到支持]
The IPsec implementation context determines how selectors are used. For example, a host implementation integrated into the stack may make use of a socket interface. When a new connection is established the SPD can be consulted and an SA (or SA bundle) bound to the socket. Thus traffic sent via that socket need not result in additional lookups to the SPD/SAD. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD/SAD lookup based on the selectors. The allowable values for the selector fields differ between the traffic flow, the security association, and the security policy.
IPsec实现上下文决定如何使用选择器。例如，集成到堆栈中的主机实现可以使用套接字接口。当建立新连接时，可以咨询SPD，并将SA（或SA束）绑定到插座。因此，通过该套接字发送的通信量不需要额外查找SPD/SAD。相反，BITS、BITW或安全网关实现需要查看每个数据包，并基于选择器执行SPD/SAD查找。选择器字段的允许值在流量、安全关联和安全策略之间有所不同。
The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It shows how they relate to the fields in data traffic being subjected to IPsec screening. (Note: the "wild" or "wildcard" entry for src and dst addresses includes a mask, range, etc.)
下表总结了需要在SPD和SAD中表达的条目类型。它显示了它们与受IPsec屏蔽的数据通信中的字段的关系。（注：src和dst地址的“野生”或“通配符”条目包括掩码、范围等。）
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
* The SAD and SPD entries for these fields could be "OPAQUE" because the traffic value is encrypted.
* 这些字段的SAD和SPD条目可能是“不透明的”，因为流量值是加密的。
NOTE: In principle, one could have selectors and/or selector values in the SPD which cannot be negotiated for an SA or SA bundle. Examples might include selector values used to select traffic for
注意：原则上，SPD中可能有选择器和/或选择器值，不能为SA或SA捆绑进行协商。示例可能包括用于选择流量的选择器值
discarding or enumerated lists which cause a separate SA to be created for each item on the list. For now, this is left for future versions of this document and the list of required selectors and selector values is the same for the SPD and the SAD. However, it is acceptable to have an administrative interface that supports use of selector values which cannot be negotiated provided that it does not mislead the user into believing it is creating an SA with these selector values. For example, the interface may allow the user to specify an enumerated list of values but would result in the creation of a separate policy and SA for each item on the list. A vendor might support such an interface to make it easier for its customers to specify clear and concise policy specifications.
丢弃或枚举列表，导致为列表上的每个项目创建单独的SA。目前，这将留待本文档的未来版本使用，SPD和SAD所需选择器和选择器值的列表是相同的。但是，可以接受具有支持使用无法协商的选择器值的管理界面，前提是它不会误导用户相信它正在使用这些选择器值创建SA。例如，该接口可能允许用户指定枚举的值列表，但会导致为列表上的每个项目创建单独的策略和SA。供应商可能支持这样的接口，使其客户更容易指定清晰简洁的策略规范。
In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, the implementation creates an appropriate SA (or SA Bundle) and links the SPD entry to the SAD entry (see Section 5.1.1). For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation.
在每个IPsec实现中都有一个标称安全关联数据库，其中每个条目定义了与一个SA关联的参数。每个SA在SAD中都有一个条目。对于出站处理，条目由SPD中的条目指向。请注意，如果SPD条目当前未指向适合该数据包的SA，则实现将创建一个适当的SA（或SA包），并将SPD条目链接到SAD条目（请参见第5.1.1节）。对于入站处理，SAD中的每个条目都由目标IP地址、IPsec协议类型和SPI索引。以下参数与SAD中的每个条目相关联。此描述并不声称是MIB，而是IPsec实现中支持SA所需的最小数据项的规范。
For inbound processing: The following packet fields are used to look up the SA in the SAD:
对于入站处理：以下数据包字段用于在SAD中查找SA：
o Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations] o IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations]
o 外部标头的目标IP地址：IPv4或IPv6目标地址。[所有实现都需要]o IPsec协议：AH或ESP，用作此数据库中SA查找的索引。指定要应用于此SA上的流量的IPsec协议。[所有实现都需要]o SPI：32位值，用于区分终止于同一目标并使用相同IPsec协议的不同SAs。[所有实施都需要]
For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA
对于第4.4.2节中定义的每个选择器，SAD中的SA条目必须包含创建SA时协商的一个或多个值。对于发送方，这些值用于确定给定SA是否适合用于出站数据包。这是检查是否存在现有SA的一部分
that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy). For the receiver, this is part of verifying that the SA was appropriate for this packet. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, wildcards, or "OPAQUE" as described in section 4.4.2, "Selectors". Note that for an ESP SA, the encryption algorithm or the authentication algorithm could be "NULL". However they MUST not both be "NULL".
这是可以使用的。对于接收方，这些值用于检查入站数据包中的选择器值是否与SA的选择器值匹配（从而间接地与匹配策略的选择器值匹配）。对于接收器，这是验证SA是否适合此数据包的一部分。（有关ICMP消息的规则，请参见第6节。）这些字段可以具有特定值、范围、通配符或“不透明”的形式，如第4.4.2节“选择器”所述。请注意，对于ESP SA，加密算法或身份验证算法可能为“NULL”。但是，它们不能同时为“NULL”。
The following SAD fields are used in doing IPsec processing:
以下SAD字段用于执行IPsec处理：
o Sequence Number Counter: a 32-bit value used to generate the Sequence Number field in AH or ESP headers. [REQUIRED for all implementations, but used only for outbound traffic.] 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. [REQUIRED for all implementations, but used only for outbound traffic.] o Anti-Replay Window: a 32-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. [REQUIRED for all implementations but used only for inbound traffic. NOTE: If anti-replay has been disabled by the receiver, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is not used.] o AH Authentication algorithm, keys, etc. [REQUIRED for AH implementations] o ESP Encryption algorithm, keys, IV mode, IV, etc. [REQUIRED for ESP implementations] o ESP authentication algorithm, keys, etc. If the authentication service is not selected, this field will be null. [REQUIRED for ESP implementations] o Lifetime of this Security Association: 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, 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 CRLs used in the IKE exchange
o 序列号计数器：用于在AH或ESP标头中生成序列号字段的32位值。[所有实现都需要，但仅用于出站流量。]o序列号计数器溢出：一个标志，指示序列号计数器溢出是否应生成可审核事件并防止在SA上传输其他数据包。[所有实现都需要，但仅用于出站流量。]o反重播窗口：用于确定入站AH或ESP数据包是否为重播的32位计数器和位映射（或等效值）。[所有实施都需要，但仅用于入站流量。注意：如果接收器已禁用反重放，例如，在手动设置密钥的SA的情况下，则不使用反重放窗口。]o AH身份验证算法、密钥等[AH实施需要]o ESP加密算法、密钥、IV模式、IV等。[ESP实施所需]o ESP认证算法、密钥等。如果未选择认证服务，此字段将为空。[ESP实施所需]o此安全关联的生存期：在此时间间隔之后，必须用新SA（和新SPI）替换SA或终止，加上这些操作中应发生的操作的指示。这可以表示为时间或字节计数，或同时使用两者，过期的第一个生存期优先。符合要求的实现必须支持这两种类型的生存期，并且必须支持同时使用这两种类型的生存期。如果使用时间，如果使用IKEs X.509证书对于SA建立，SA生存期必须受到证书的有效期间隔以及IKE交换中使用的CRL的下一个发布日期的约束
for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. [REQUIRED for all implementations]
对于SA。发起方和响应方都负责以这种方式约束SA生存期。[所有实施都需要]
NOTE: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is: (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec 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 SHOULD 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. (b) There SHOULD be two kinds of lifetime -- a soft lifetime which warns the implementation to initiate action such as setting up a replacement SA and a hard lifetime when the current SA ends. (c) If the entire packet does not get delivered during the SAs lifetime, the packet SHOULD be discarded.
注意：SAs过期时如何处理密钥刷新的详细信息是本地事务。然而，一种合理的方法是：（a）如果使用字节计数，那么实现应该计算应用IPsec算法的字节数。对于ESP，这是加密算法（包括空加密），对于AH，这是身份验证算法。这包括pad字节等。请注意，实现应该能够处理SA两端的计数器不同步的问题，例如，由于数据包丢失或SA两端的实现方式不同。（b） 应该有两种生存期——一种是软生存期，它警告实现启动操作，例如设置替换SA；另一种是硬生存期，当当前SA结束时。（c） 如果整个数据包在SAs生存期内未送达，则应丢弃该数据包。
o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. Note that if this field is "wildcard" at the sending end of the SA, then the application has to specify the mode to the IPsec implementation. This use of wildcard allows the same SA to be used for either tunnel or transport mode traffic on a per packet basis, e.g., by different sockets. The receiver does not need to know the mode in order to properly process the packet's IPsec headers.
o IPsec协议模式：隧道、传输或通配符。指示将哪种AH或ESP模式应用于此SA上的流量。请注意，如果此字段在SA的发送端为“通配符”，则应用程序必须指定IPsec实现的模式。这种通配符的使用允许相同的SA在每个分组的基础上（例如，通过不同的套接字）用于隧道或传输模式流量。接收方无需知道模式即可正确处理数据包的IPsec头。
[REQUIRED as follows, unless implicitly defined by context: - host implementations must support all modes - gateway implementations must support tunnel mode]
[要求如下，除非上下文隐式定义：-主机实现必须支持所有模式-网关实现必须支持隧道模式]
NOTE: The use of wildcard for the protocol mode of an inbound SA may add complexity to the situation in the receiver (host only). Since the packets on such an SA could be delivered in either tunnel or transport mode, the security of an incoming packet could depend in part on which mode had been used to deliver it. If, as a result, an application cared about the SA mode of a given packet, then the application would need a mechanism to obtain this mode information.
注意：对入站SA的协议模式使用通配符可能会增加接收器（仅主机）中情况的复杂性。由于这样一个SA上的分组可以以隧道或传输模式进行传送，因此传入分组的安全性可以部分地取决于用于传送它的模式。因此，如果应用程序关心给定数据包的SA模式，那么应用程序将需要一种机制来获取该模式信息。
o Path MTU: any observed path MTU and aging variables. See Section 6.1.2.4 [REQUIRED for all implementations but used only for outbound traffic]
o 路径MTU：任何观察到的路径MTU和老化变量。参见第6.1.2.4节[所有实施都需要，但仅用于出站流量]
This section describes four examples of combinations of security associations that MUST be supported by compliant IPsec hosts or security gateways. Additional combinations of AH and/or ESP in tunnel and/or transport modes MAY be supported at the discretion of the implementor. Compliant implementations MUST be capable of generating these four combinations and on receipt, of processing them, but SHOULD be able to receive and process any combination. The diagrams and text below describe the basic cases. The legend for the diagrams is:
本节描述了兼容IPsec主机或安全网关必须支持的安全关联组合的四个示例。在隧道和/或运输模式中，AH和/或ESP的其他组合可由实施者自行决定予以支持。兼容的实现必须能够生成这四种组合，并且在接收时能够处理它们，但应该能够接收和处理任何组合。下面的图表和文本描述了基本情况。图表的图例为：
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsec
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsec
NOTE: The security associations below can be either AH or ESP. The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel.
注意：下面的安全关联可以是AH或ESP。模式（隧道与传输）由端点的性质决定。对于主机到主机SAs，模式可以是传输模式或隧道模式。
Case 1. The case of providing end-to-end security between 2 hosts across the Internet (or an Intranet).
案例1。通过Internet（或Intranet）在两台主机之间提供端到端安全性的情况。
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
Note that either transport or tunnel mode can be selected by the hosts. So the headers in a packet between H1 and H2 could look like any of the following:
请注意，主机可以选择传输模式或隧道模式。因此，H1和H2之间的数据包中的头可以类似于以下任意一种：
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet.
请注意，不需要支持常规嵌套，但在传输模式下，AH和ESP都可以应用于数据包。在这种情况下，SA建立程序必须确保首先对数据包应用ESP，然后应用AH。
Case 2. This case illustrates simple virtual private networks support.
案例2。本案例说明了简单的虚拟专用网络支持。
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Only tunnel mode is required here. So the headers in a packet between SG1 and SG2 could look like either of the following:
这里只需要隧道模式。因此，SG1和SG2之间的数据包中的头可以如下所示：
Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
Case 3. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it.
案例3。本例结合了案例1和案例2，增加了发送主机和接收主机之间的端到端安全性。它对主机或安全网关没有新的要求，只要求安全网关可配置为为为其背后的主机传递IPsec流量（包括ISAKMP流量）。
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Case 4. This covers the situation where a remote host (H1) uses the Internet to reach an organization's firewall (SG2) and to then gain access to some server or other machine (H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall (SG2), etc. The
案例4。这包括远程主机（H1）使用Internet访问组织的防火墙（SG2），然后访问某些服务器或其他机器（H2）的情况。远程主机可以是一个移动主机（H1），拨号到Internet上的本地PPP/ARA服务器（未显示），然后通过Internet连接到主组织的防火墙（SG2）等
details of support for this case, (how H1 locates SG2, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.6.3, "Locating a Security Gateway".
第4.6.3节“定位安全网关”中讨论了此案例的支持细节（H1如何定位SG2、如何对其进行身份验证以及如何验证其代表H2的授权）。
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
Only tunnel mode is required between H1 and SG2. So the choices for the SA between H1 and SG2 would be one of the ones in case 2. The choices for the SA between H1 and H2 would be one of the ones in case 1.
H1和SG2之间只需要隧道模式。因此，H1和SG2之间的SA选择将是案例2中的选择之一。在H1和H2之间的SA选择将是案例1中的选择之一。
Note that in this case, the sender MUST apply the transport header before the tunnel header. Therefore the management interface to the IPsec implementation MUST support configuration of the SPD and SAD to ensure this ordering of IPsec header application.
注意，在这种情况下，发送方必须在隧道头之前应用传输头。因此，IPsec实现的管理接口必须支持SPD和SAD的配置，以确保IPsec报头应用程序的这种顺序。
As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability.
如上所述，支持AH和ESP的附加组合是可选的。使用其他可选组合可能会对互操作性产生不利影响。
IPsec mandates support for 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 services available for AH and ESP require automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. (See also a discussion of this issue in Section 4.7.) In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the authentication algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources.
IPsec要求支持手动和自动SA以及加密密钥管理。IPsec协议AH和ESP在很大程度上独立于相关的SA管理技术，尽管所涉及的技术确实会影响协议提供的一些安全服务。例如，AH和ESP的可选反重播服务需要自动化SA管理。此外，IPsec采用的密钥分发粒度决定了提供的身份验证的粒度。（另请参见第4.7节中对该问题的讨论。）一般而言，AH和ESP中的数据源身份验证受身份验证算法（或创建此类机密的密钥管理协议）使用的机密在多个可能来源之间共享程度的限制。
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 security association 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 is likely to 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.
最简单的管理形式是手动管理，在手动管理中，一个人使用与其他系统安全通信相关的密钥材料和安全关联管理数据手动配置每个系统。手动技术在小型静态环境中很实用，但不能很好地扩展。例如，一家公司可以在多个站点的安全网关中使用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 IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed.
选择用于IPsec的默认自动密钥管理协议是IPsec解释域[Pip98]下的IKE[MSST97，Orm97，HC98]。可采用其他自动化SA管理协议。
When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because:
当采用自动SA/密钥管理协议时，该协议的输出可用于生成多个密钥，例如，用于单个ESP SA。这可能是因为：
o the encryption algorithm uses multiple keys (e.g., triple DES) o the authentication algorithm uses multiple keys o both encryption and authentication algorithms are employed
o 加密算法使用多个密钥（例如，三重DES）o身份验证算法使用多个密钥o同时使用加密和身份验证算法
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 of them 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 key(s) MUST be taken from the first (left-most, high-order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the 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.
本节讨论与主机如何了解相关安全网关的存在以及一旦主机联系了这些安全网关，主机如何知道这些是正确的安全网关有关的问题。所需信息存储位置的详细信息是本地事务。
Consider a situation in which a remote host (H1) 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 (Road Warrior) crossing the Internet to the home organization's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This situation raises several issues:
考虑远程主机（H1）正在使用因特网来访问服务器或其他机器（H2）的情况，并且存在一个安全网关（SG2），例如防火墙，通过该防火墙，H1的流量必须通过。这种情况的一个例子是一个移动主机（Road Warrior），它通过互联网连接到主组织的防火墙（SG2）。（参见第4.5节“安全关联的基本组合”中的案例4）这种情况引发了几个问题：
1. How does H1 know/learn about the existence of the security gateway 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? 3. How does SG2 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know/learn about backup gateways which provide alternate paths to H2?
1. H1如何知道/了解安全网关SG2的存在？2.它如何认证SG2，一旦它认证了SG2，它如何确认SG2已被授权代表H2？3.SG2如何认证H1并验证H1是否有权联系H2？4.H1如何知道/了解提供H2备用路径的备份网关？
To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure:
为了解决这些问题，主机或安全网关必须有一个管理界面，允许用户/管理员为需要使用的任何一组目标地址配置安全网关的地址。这包括能够配置：
o the requisite information for locating and authenticating the security gateway and verifying its authorization to represent the destination host. o the requisite information for locating and authenticating any backup gateways and verifying their authorization to represent the destination host.
o 用于定位和验证安全网关以及验证其代表目标主机的授权的必要信息。o定位和验证任何备份网关以及验证其代表目标主机的授权所需的信息。
It is assumed that the SPD is also configured with policy information that covers any other IPsec requirements for the path to the security gateway and the destination host.
假定SPD还配置了策略信息，这些信息涵盖安全网关和目标主机路径的任何其他IPsec要求。
This document does not address the issue of how to automate the discovery/verification of security gateways.
本文档不涉及如何自动发现/验证安全网关的问题。
The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems per multicast group. 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.
安全关联的接收器方向意味着，在单播业务的情况下，目的地系统通常会选择SPI值。通过让目的地选择SPI值，手动配置的安全关联不会与自动配置（例如，通过密钥管理协议）的安全关联发生冲突，或者来自多个源的安全关联不会相互冲突。对于多播流量，每个多播组有多个目标系统。因此，一些系统或个人需要在所有多播组之间进行协调，以代表每个多播组选择一个或多个SPI，然后通过此处未定义的机制将组的IPsec信息传递给该多播组的所有合法成员。
Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to that group when a symmetric key encryption or authentication 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 cases are deferred to later IPsec documents.
当采用对称密钥加密或身份验证算法时，一个多播组的多个发送方应为该组的所有流量使用单个安全关联（因此安全参数索引）。在这种情况下，接收方只知道消息来自拥有该多播组密钥的系统。在这种情况下，接收器通常无法验证哪个系统发送了多播流量。其他更一般的多播情况的规范将推迟到稍后的IPsec文档中。
At the time this specification was published, automated protocols for multicast key distribution were not considered adequately mature for standardization. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. An example of current work in this area is the Group Key Management Protocol (GKMP) [HM97].
在本规范发布时，用于多播密钥分发的自动化协议尚未被认为是标准化的成熟协议。对于成员相对较少的多播组，手动密钥分配或多次使用现有的单播密钥分配算法（如改进的Diffie-Hellman）似乎是可行的。对于非常大的群体，需要新的可扩展技术。该领域当前工作的一个例子是组密钥管理协议（GKPP）[HM97]。
As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded.
如第4.4.1节“安全策略数据库（SPD）”所述，在处理所有流量（入站和出站），包括非IPsec流量期间，必须咨询SPD。如果在SPD中未找到与数据包匹配的策略（对于入站或出站流量），则必须丢弃数据包。
NOTE: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
注意：IPsec中使用的所有加密算法都希望以规范的网络字节顺序输入（请参见RFC 791中的附录），并以规范的网络字节顺序生成输出。IP数据包也以网络字节顺序传输。
In a security gateway or BITW implementation (and in many BITS implementations), each outbound packet is compared against the SPD to determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event. If the traffic is allowed to bypass IPsec processing, the packet continues through "normal" processing for the environment in which the IPsec processing is taking place. If IPsec processing is required, the packet is either mapped to an existing SA (or SA bundle), or a new SA (or SA bundle) is created for the packet. Since a packet's selectors might match multiple policies or multiple extant SAs and since the SPD is ordered, but the SAD is not, IPsec MUST:
在安全网关或BITW实现（以及许多BITS实现）中，将每个出站数据包与SPD进行比较，以确定数据包需要进行哪些处理。如果要丢弃数据包，则这是一个可审核事件。如果允许流量绕过IPsec处理，则对于正在进行IPsec处理的环境，数据包将继续通过“正常”处理。如果需要IPsec处理，则将数据包映射到现有SA（或SA包），或者为数据包创建新SA（或SA包）。由于数据包的选择器可能匹配多个策略或多个现有SA，并且由于SPD已排序，但SAD未排序，因此IPsec必须：
1. Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD.
1. 将数据包的选择器字段与SPD中的出站策略相匹配，以找到第一个适当的策略，该策略将指向SAD中的零个或多个SA捆绑包。
2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet.
2. 将数据包的选择器字段与（1）中的SA捆绑包中的字段相匹配，以找到匹配的第一个SA捆绑包。如果找不到SA或不匹配，请创建适当的SA捆绑包，并将SPD条目链接到SAD条目。如果找不到密钥管理实体，则丢弃该数据包。
3. Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt.
3. 使用（2）中找到/创建的SA捆绑包执行所需的IPsec处理，例如身份验证和加密。
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.
在基于套接字的主机IPsec实现中，每当创建新套接字时，都会咨询SPD，以确定将对该套接字上的流量应用什么（如果有的话）IPsec处理。
NOTE: A compliant implementation MUST not allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event.
注意：兼容实现不得允许实例化同时使用空加密和空身份验证算法的ESP SA。协商此类SA的尝试是可审核的事件。
This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP":
本节介绍AH和ESP隧道的内部和外部IP头、扩展头以及选项的处理。这包括如何构造封装（外部）IP头，如何处理内部IP头中的字段，以及应该采取的其他操作。总体思路模仿RFC 2003“IP封装与IP”中使用的思路：
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. (see footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.) o The inner IP header is not changed except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point. o No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel. o If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header and the inner IP header.
o 外部IP头源地址和目标地址标识隧道的“端点”（封装器和解封装器）。内部IP报头源地址和目标地址分别标识数据报的原始发送方和接收方（从这个隧道的角度）。（有关封装源IP地址的更多详细信息，请参见5.1.2.1中表格后的脚注3。）o内部IP报头未更改，除非按如下所述减少TTL，并且在其交付至隧道出口点期间保持不变。o在通过隧道传递封装的数据报期间，内部报头中的IP选项或扩展报头不会发生任何更改。o如果需要，可以在外部IP报头和内部IP报头之间插入其他协议报头，例如IP认证报头。
The tables in the following sub-sections show the handling for the different header/option fields (constructed = 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
TOS copied from inner hdr (5) no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragmt offset constructed 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
TOS copied from inner hdr (5) no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragmt offset constructed no change
TTL constructed (2) decrement (2) protocol AH, ESP, routing hdr no change checksum constructed constructed (2) src address constructed (3) no change dest address constructed (3) no change Options never copied no change
TTL构造（2）递减（2）协议AH，ESP，路由hdr无更改校验和构造（2）src地址构造（3）无更改dest地址构造（3）无更改选项从未复制无更改
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 checksum changes when the TTL changes.)
2. 内部报头中的TTL在转发前由封装器递减，在转发数据包时由去封装器递减。（当TTL改变时，校验和改变。）
Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTL's decremented, as the sending node is originating the packet rather than forwarding it.
注意：TTL的递减是转发数据包时发生的常见操作之一。源于与封装器相同的节点的数据包的TTL不会减少，因为发送节点是源于数据包而不是转发数据包。
3. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet.
3. src和dest地址取决于SA，SA用于确定dest地址，而dest地址又决定使用哪个src地址（网络接口）转发数据包。
NOTE: In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as the address is reachable through the encapsulator from the environment into which the packet is sent. This does not cause a problem because IPsec does not currently have any INBOUND processing requirement that involves the Source Address of the encapsulating IP header. So while the receiving tunnel endpoint looks at the Destination Address in the encapsulating IP header, it only looks at the Source Address in the inner (encapsulated) IP header.
注意：原则上，封装IP源地址可以是封装器的任何接口地址，甚至是与封装器的任何IP地址不同的地址（例如，如果它充当NAT盒），只要该地址可以通过封装器从包发送到的环境中访问。这不会导致问题，因为IPsec当前没有任何涉及封装IP头的源地址的入站处理要求。因此，当接收隧道端点查看封装IP报头中的目标地址时，它只查看内部（封装）IP报头中的源地址。
4. configuration determines whether to copy from the inner header (IPv4 only), clear or set the DF.
4. 配置决定是从内部标头复制（仅限IPv4）、清除还是设置DF。
5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner Hdr is IPv6 (Protocol = 41), map the Class to TOS.
5. 如果内部Hdr是IPv4（协议=4），则复制TOS。如果内部Hdr是IPv6（协议=41），则将该类映射到TOS。
See previous section 5.1.2 for notes 1-5 indicated by (footnote number).
注1-5（脚注编号）见前一节5.1.2。
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
class copied or configured (6) no change
flow id copied or configured no change
len 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 no change
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
class copied or configured (6) no change
flow id copied or configured no change
len 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 no change
6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class.
6. 如果内部Hdr是IPv6（下一个标头=41），则复制该类。如果内部Hdr是IPv4（下一个标头=4），则将TOS映射到类。
Prior to performing AH or ESP processing, any IP fragments are reassembled. 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 an extension header in the IPv6 context).
在执行AH或ESP处理之前，重新组装所有IP片段。IPsec处理将应用到的每个入站IP数据报通过IP Next协议字段中的AH或ESP值（或IPv6上下文中作为扩展头的AH或ESP）的外观来标识。
Note: Appendix C contains sample code for a bitmask check for a 32 packet window that can be used for implementing anti-replay service.
注意：附录C包含32数据包窗口的位掩码检查示例代码，该窗口可用于实现反重播服务。
Mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. Note that the selector checks are made on the inner headers not the outer (tunnel) headers. The steps followed are:
由于AH或ESP报头中存在SPI，因此将IP数据报映射到适当的SA变得简单。请注意，选择器检查是在内部集管上进行的，而不是在外部（通道）集管上进行的。以下步骤是：
1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error.
1. 使用数据包的目标地址（外部IP头）、IPsec协议和SPI在SAD中查找SA。如果SA查找失败，请丢弃数据包并记录/报告错误。
2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA may have a source address
2. 使用（1）中的SA进行IPsec处理，例如验证和解密。此步骤包括将数据包（如果有隧道，则为内部报头）选择器与SA中的选择器相匹配。本地策略确定SA选择器的特定性（单值、列表、范围、通配符）。通常，数据包的源地址必须与SA选择器值匹配。然而，在隧道模式SA上接收的ICMP数据包可能有一个源地址
other than that bound to the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA. Note that some or all of these selectors may be inaccessible because of limitations on how many bits of the problem packet the ICMP packet is allowed to carry or due to encryption. See Section 6.
除绑定到SA的数据包外，应允许此类数据包作为该检查的例外情况。对于ICMP数据包，应对照SA的选择器检查随附问题数据包中的选择器（应交换源地址和目标地址以及端口）。请注意，由于ICMP数据包允许携带的问题数据包位数的限制或由于加密，这些选择器中的部分或全部可能无法访问。见第6节。
Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. Keep track of what SAs have been used and their order of application.
对每个IPsec标头执行（1）和（2），直到遇到不适用于此系统的传输协议标头或IP标头。跟踪已使用的SAs及其应用顺序。
3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD.
3. 在SPD中查找与数据包匹配的传入策略。例如，可以通过使用从SAs到SPD的反向指针，或者通过将数据包的选择器（如果有隧道，则为内部报头）与SPD中的策略条目的选择器相匹配来实现。
4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3).
4. 检查是否已应用所需的IPsec处理，即验证（1）和（2）中找到的SA是否与（3）中找到的策略所需的SA种类和顺序相匹配。
NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds.
注意：正确的“匹配”策略不一定是找到的第一个入站策略。如果签入（4）失败，则重复步骤（3）和（4），直到检查完所有策略条目或检查成功为止。
At the end of these steps, pass the resulting packet to the Transport Layer or forward the packet. Note that any IPsec headers processed in these steps may have been removed, but that this information, i.e., what SAs were used and the order of their application, may be needed for subsequent IPsec or firewall processing.
在这些步骤结束时，将生成的数据包传递给传输层或转发数据包。请注意，在这些步骤中处理的任何IPsec头都可能已被删除，但后续IPsec或防火墙处理可能需要这些信息，即使用了哪些SA及其应用程序的顺序。
Note that in the case of a security gateway, if forwarding causes a packet to exit via an IPsec-enabled interface, then additional IPsec processing may be applied.
注意，在安全网关的情况下，如果转发导致数据包通过启用IPsec的接口退出，则可以应用额外的IPsec处理。
The handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be performed as described in the tables in Section 5.1.
AH和ESP隧道的内部和外部IP头、扩展头和选项的处理应按照第5.1节表格中的说明进行。
The focus of this section is on the handling of ICMP error messages. Other ICMP traffic, e.g., Echo/Reply, should be treated like other traffic and can be protected on an end-to-end basis using SAs in the usual fashion.
本节的重点是ICMP错误消息的处理。其他ICMP通信量，如回送/回复，应与其他通信量一样对待，并可使用SAs以通常方式进行端到端保护。
An ICMP error message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy determines whether or not it is subjected to source address checks by the router at the destination end of the tunnel. Note that if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail. An ICMP message protected by AH or ESP and generated by a router MUST NOT be forwarded on a transport mode SA (unless the SA has been established to the router acting as a host, e.g., a Telnet connection used to manage a router). An ICMP message generated by a host SHOULD be checked against the source IP address selectors bound to the SA in which the message arrives. Note that even if the source of an ICMP error message is authenticated, the returned IP header could be invalid. Accordingly, the selector values in the IP header SHOULD also be checked to be sure that they are consistent with the selectors for the SA over which the ICMP message was received.
由AH或ESP保护并由路由器生成的ICMP错误消息应以隧道模式SA进行处理和转发。本地策略确定它是否受到隧道目标端路由器的源地址检查。请注意，如果隧道起始端的路由器正在转发来自另一路由器的ICMP错误消息，则源地址检查将失败。受AH或ESP保护并由路由器生成的ICMP消息不得在传输模式SA上转发（除非SA已建立到充当主机的路由器，例如，用于管理路由器的Telnet连接）。应根据绑定到消息到达的SA的源IP地址选择器检查主机生成的ICMP消息。请注意，即使ICMP错误消息的源经过身份验证，返回的IP头也可能无效。因此，还应检查IP报头中的选择器值，以确保它们与接收ICMP消息的SA的选择器一致。
The table in Appendix D characterize ICMP messages as being either host generated, router generated, both, unknown/unassigned. ICMP messages falling into the last two categories should be handled as determined by the receiver's policy.
附录D中的表格将ICMP消息描述为主机生成、路由器生成、未知/未分配。属于最后两类的ICMP消息应按照接收方的策略进行处理。
An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial of service. This suggests that, in general, it would be desirable to ignore such messages. However, it is expected that many routers (vs. security gateways) will not implement IPsec for transit traffic and thus strict adherence to this rule would cause many ICMP messages to be discarded. The result is that some critical IP functions would be lost, e.g., redirection and PMTU processing. Thus it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic as per local security policy.
不受AH或ESP保护的ICMP消息未经验证，其处理和/或转发可能导致拒绝服务。这表明，一般而言，最好忽略这些信息。但是，预计许多路由器（与安全网关相比）不会为传输流量实施IPsec，因此严格遵守此规则将导致许多ICMP消息被丢弃。结果是一些关键IP功能将丢失，例如重定向和PMTU处理。因此，必须能够根据本地安全策略将IPsec实现配置为接受或拒绝（路由器）ICMP流量。
The remainder of this section addresses how PMTU processing MUST be performed at hosts and security gateways. It addresses processing of both authenticated and unauthenticated ICMP PMTU messages. However, as noted above, unauthenticated ICMP messages MAY be discarded based on local policy.
本节的其余部分介绍必须如何在主机和安全网关上执行PMTU处理。它处理经过身份验证和未经身份验证的ICMP PMTU消息。但是，如上所述，根据本地策略，可能会丢弃未经验证的ICMP消息。
In cases where a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.)
在系统（主机或网关）添加封装头（ESP隧道或AH隧道）的情况下，它必须支持将DF位从原始数据包复制到封装头（并处理ICMP PMTU消息）的选项。这意味着必须能够为每个接口配置系统对DF位的处理（设置、清除、从封装头复制）。（基本原理见附录B。）
This section discusses IPsec handling for Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for:
本节讨论路径MTU发现消息的IPsec处理。此处使用ICMP PMTU来引用ICMP消息：
IPv4 (RFC 792): - 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 (labelled "unused" in RFC 792), with high-order 16 bits set to zero
IPv4（RFC 792）：-Type=3（无法到达目的地）-Code=4（需要分段并设置DF）-ICMP头的第二个字的低阶16位中的下一跳MTU（RFC 792中标记为“未使用”），高阶16位设置为零
IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message
IPv6（RFC 1885）：-Type=2（数据包太大）-Code=0（需要分段）-ICMP6消息的32位MTU字段中的下一跳MTU
The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix B for more detailed discussion of this topic.)
ICMP PMTU消息（IPv4或IPv6）返回的信息量有限，这会影响可用于进一步传播PMTU信息的选择器。（有关此主题的详细讨论，请参见附录B。）
o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU message contains only 64 bits of the IPsec header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis:
o 具有64位IPsec标头的PMTU消息--如果ICMP PMTU消息仅包含64位IPsec标头（IPv4的最小值），则安全网关必须基于每个SPI/SA支持以下选项：
a. if the originating host can be determined (or the possible sources narrowed down to a manageable number), send the PM information to all the possible originating hosts. b. if the originating host cannot be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the originating host for the relevant security association. If
a. 如果可以确定始发主机（或将可能的源缩小到可管理的数量），则将PM信息发送给所有可能的始发主机。B如果无法确定始发主机，请将PMTU与SA一起存储，并等待相关安全关联的下一个数据包从始发主机到达。如果
the packet(s) are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host. Retain the PMTU information for any message that might arrive subsequently (see Section 6.1.2.4, "PMTU Aging").
数据包大于PMTU，丢弃数据包，并用新数据包和更新的PMTU组成ICMP PMTU消息，并将有关问题的ICMP消息发送给发起主机。保留可能随后到达的任何消息的PMTU信息（见第6.1.2.4节“PMTU老化”）。
o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet then there may be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path.
o IPsec报头大于64位的PMTU消息——如果ICMP消息包含来自原始数据包的更多信息，则可能有足够的非不透明信息来立即确定将ICMP/PMTU消息传播到哪个主机，并向该系统提供5个字段（源地址、目标地址、源端口、目标端口、传输协议）需要确定在何处存储/更新PMTU。在这种情况下，安全网关必须在从路径较远的位置收到ICMP PMTU后立即生成ICMP PMTU消息。
o Distributing the PMTU to the Transport Layer -- The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).
o 将PMTU分发到传输层——将更新后的PMTU分发到传输层的主机机制不变，如RFC 1191（路径MTU发现）中所述。
The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPsec header -- AH transport, ESP transport, AH/ESP transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of implementation issues.)
从ICMP PMTU计算PMTU时必须考虑添加的任何IPsec头—AH传输、ESP传输、AH/ESP传输、ESP隧道、AH隧道。（有关实施问题的讨论，请参见附录B。）
Note: In some situations the addition of IPsec headers could result in an effective PMTU (as seen by the host or application) that is unacceptably small. To avoid this problem, the implementation may establish a threshold below which it will not report a reduced PMTU. In such cases, the implementation would apply IPsec and then fragment the resulting packet according to the PMTU. This would result in a more efficient use of the available bandwidth.
注意：在某些情况下，添加IPsec头可能会导致有效的PMTU（由主机或应用程序看到）小得令人无法接受。为避免此问题，实施可能会设定一个阈值，低于该阈值时，不会报告减少的PMTU。在这种情况下，实现将应用IPsec，然后根据PMTU对生成的数据包进行分段。这将导致更有效地利用可用带宽。
In hosts, the granularity with which ICMP PMTU processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix B for additional details on this topic.):
在主机中，ICMP PMTU处理的粒度因实施情况而异。就主机而言，有3种情况与PMTU问题有关（有关此主题的更多详细信息，请参见附录B）：
a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers
a. 将IPsec集成到本机IP实现b中。堆栈实现中的碰撞，其中IPsec在本机IP和本地网络驱动程序之间的TCP/IP协议堆栈的现有实现“之下”实现
c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host.
c. 没有IPsec实现——之所以包括这种情况，是因为它与安全网关将PMTU信息发送回主机的情况有关。
Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally TOS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms).
只有在（a）种情况下，PMTU数据才能保持与通信关联相同的粒度。在（b）和（c）中，如RFC 1191中所述，IP层将只能以源和目标IP地址（以及可选的TOS）的粒度维护PMTU数据。这是一个重要的区别，因为多个通信关联可能映射到相同的源和目标IP地址，并且每个通信关联可能具有不同的IPsec头开销（例如，由于使用不同的转换或不同的算法）。
Implementation of the calculation of PMTU and support for PMTUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message.
在单个通信关联的粒度上实现PMTU的计算和对PMTU的支持是一个局部问题。但是，主机中基于套接字的IPsec实现应基于每个套接字维护信息。堆栈中的Bump系统必须在针对这些系统增加的任何IPsec头开销进行调整后，将ICMP PMTU传递给主机IP实现。开销的计算应通过分析SPI和返回的ICMP PMTU消息中存在的任何其他选择器信息来确定。
In all systems (host or gateway) implementing IPsec and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Note that if there are nested tunnels, multiple packets and round trip times might be required to get an ICMP message back to an encapsulator or originating host.
在实施IPsec并维护PMTU信息的所有系统（主机或网关）中，与安全关联（传输或隧道）相关联的PMTU必须“老化”，并且必须建立某种机制以及时更新PMTU，特别是用于发现PMTU是否小于需要的大小。给定的PMTU必须保持足够长的时间，以便数据包从安全关联的源端到达安全关联另一端的系统，并在当前PMTU太大时传回ICMP错误消息。请注意，如果存在嵌套隧道，则可能需要多个数据包和往返时间才能将ICMP消息返回到封装器或原始主机。
Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, 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，第6.3节）中描述的方法，该方法建议定期将PMTU重置为第一跳数据链路MTU，然后让正常PMTU发现过程根据需要更新PMTU。周期应该是可配置的。
Not all systems that implement IPsec will implement auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications 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的系统都将实现审核。在大多数情况下，审计的粒度是一个局部问题。然而，AH和ESP规范中确定了几个可审核事件，并且为每个事件定义了应包含在审核日志中的最小信息集。审计日志中还可能包含这些事件的附加信息，本规范中未明确指出的附加事件也可能导致审计日志条目。不要求接收方在检测到可审计事件时向声称的发送方发送任何消息，因为通过这种行为可能导致拒绝服务。
Information of various sensitivity levels may be carried over a single network. Information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish such information. The use of labels facilitates segregation of information, in support of information flow security models, e.g., the Bell-LaPadula model [BL73]. Such models, and corresponding supporting technology, are designed to prevent the unauthorized flow of sensitive information, even in the face of Trojan Horse attacks. Conventional, discretionary access control (DAC) mechanisms, e.g., based on access control lists, generally are not sufficient to support such policies, and thus facilities such as the SPD do not suffice in such environments.
各种灵敏度级别的信息可以通过单个网络传输。信息标签（例如，非机密、公司专有、机密）[DoD85、DoD87]通常用于区分此类信息。标签的使用有助于信息分离，以支持信息流安全模型，例如Bell-LaPadula模型[BL73]。此类模型和相应的支持技术旨在防止敏感信息的未经授权的流动，即使在面临特洛伊木马攻击时也是如此。传统的自主访问控制（DAC）机制，例如基于访问控制列表的机制，通常不足以支持此类策略，因此SPD等设施在此类环境中是不够的。
In the military context, technology that supports such models is often referred to as multi-level security (MLS). Computers and networks often are designated "multi-level secure" if they support the separation of labelled data in conjunction with information flow security policies. Although such technology is more broadly applicable than just military applications, this document uses the acronym "MLS" to designate the technology, consistent with much extant literature.
在军事领域，支持此类模型的技术通常被称为多级安全（MLS）。如果计算机和网络支持标签数据的分离以及信息流安全策略，则它们通常被指定为“多级安全”。尽管此类技术的应用范围比军事应用更广，但本文件使用缩写词“MLS”来表示该技术，这与许多现存文献一致。
IPsec mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes are incapable of controlling or violating. This section pertains only to the use of these IP security mechanisms in MLS (information flow security policy) environments. Nothing in this section applies to systems not claiming to provide MLS.
IPsec机制可以轻松支持MLS网络。MLS网络要求使用强强制性访问控制（MAC），非特权用户或非特权进程无法控制或违反。本节仅涉及在MLS（信息流安全策略）环境中使用这些IP安全机制。本节中的任何内容均不适用于未声称提供MLS的系统。
As used in this section, "sensitivity information" might include implementation-defined hierarchic levels, categories, and/or releasability information.
如本节所用，“敏感度信息”可能包括实现定义的层次结构级别、类别和/或可发布性信息。
AH can be used to provide strong authentication in support of mandatory access control decisions in MLS environments. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, AH can be used to authenticate the binding between sensitivity labels in the IP header and the IP payload (including user data). This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both.
AH可用于提供强身份验证，以支持MLS环境中的强制访问控制决策。如果使用了明确的IP敏感度信息（例如IPSO[Ken91]），并且认为在特定操作环境中不需要保密，则可以使用AH来验证IP报头中的敏感度标签与IP有效载荷（包括用户数据）之间的绑定。这是对标记的IPv4网络的重大改进，在标记的IPv4网络中，敏感度信息是可信的，即使该信息与IP报头和用户数据没有身份验证或加密绑定。IPv4网络可能使用也可能不使用显式标签。IPv6通常会使用作为IPsec安全关联一部分但未随每个数据包一起传输的隐式敏感度信息，而不是使用显式敏感度信息。所有显式IP敏感信息必须使用ESP、AH或两者进行身份验证。
Encryption is useful and can be desirable even when all of the hosts are within a protected environment, for example, behind a firewall or disjoint from any external connectivity. ESP can be used, in conjunction with appropriate key management and encryption algorithms, in support of both DAC and MAC. (The choice of encryption and authentication algorithms, and the assurance level of an IPsec implementation will determine the environments in which an implementation may be deemed sufficient to satisfy MLS requirements.) Key management can make use of sensitivity information to provide MAC. IPsec implementations on systems claiming to provide MLS SHOULD be capable of using IPsec to provide MAC for IP-based communications.
加密非常有用，即使所有主机都在受保护的环境中（例如，防火墙后面或与任何外部连接分离），加密也是可取的。ESP可与适当的密钥管理和加密算法结合使用，以支持DAC和MAC。（加密和身份验证算法的选择，以及IPsec实现的保证级别，将决定一个实现可能被认为足以满足MLS要求的环境。）密钥管理可以利用敏感信息提供MAC。声称提供MLS的系统上的IPsec实现应能够使用IPsec为基于IP的通信提供MAC。
Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance".
封装的安全负载和身份验证报头都可以与适当的安全关联策略相结合，以提供多级安全联网。在这种情况下，每个SA（或SA包）通常仅用于敏感度信息的单个实例。例如，“专有互联网工程”必须与不同于“专有金融”的SA（或SA包）相关联。
An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an
MLS实现（主机和路由器）可以将敏感度信息或一系列敏感度信息与接口相关联，或将配置的IP地址与其关联的前缀（后者有时称为逻辑接口，或路由器）相关联
interface alias). If such properties exist, an implementation SHOULD compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet arrived, or through which the packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix.
接口别名）。如果存在此类属性，则实现应将与分组相关联的敏感度信息与与与接口或地址/前缀相关联的敏感度信息进行比较，该接口或地址/前缀是分组到达的起点，或分组将通过其离开的起点。该检查将验证灵敏度是否匹配，或者数据包的灵敏度是否在接口或地址/前缀的范围内。
The checking SHOULD be done on both inbound and outbound processing.
应该对入站和出站处理进行检查。
Section 4.4 discussed two Security Association databases (the Security Policy Database (SPD) and the Security Association Database (SAD)) and the associated policy selectors and SA attributes. MLS networking introduces an additional selector/attribute:
第4.4节讨论了两个安全关联数据库（安全策略数据库（SPD）和安全关联数据库（SAD））以及相关的策略选择器和SA属性。MLS网络引入了一个额外的选择器/属性：
- Sensitivity information.
- 敏感信息。
The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 8.1. The exact syntax of the sensitivity information is implementation defined.
敏感度信息有助于选择适当的算法和密钥强度，从而使通信量获得与第8.1节所述重要性或敏感度相适应的保护级别。灵敏度信息的确切语法由实现定义。
After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) with the interface or address/prefix as described in section 8.2 before delivering the datagram to an upper-layer protocol or forwarding it.
入站数据包通过IPsec处理后，MLS实现应首先使用第8.2节所述的接口或地址/前缀检查数据包的灵敏度（由用于数据包的SA（或SA捆绑包）定义），然后再将数据报交付给上层协议或转发数据报。
The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. The means for maintaining this binding are implementation specific.
MLS系统必须保留IPsec保护数据包中接收的数据与SA或SAs中用于处理的敏感度信息之间的绑定，以便在将数据报交付给应用程序或转发引擎时做出适当的策略决策。维护此绑定的方法是特定于实现的。
An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section 5.1.1. When consulting the SPD or the SAD to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an
除了第5.1.1节中详述的正常步骤外，IPsec的MLS实现还必须执行两个附加检查。当咨询SPD或SAD以查找出站安全关联时，MLS实施必须使用数据的敏感性来选择一个安全关联
appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity consistency checking described in section 8.2.
适当的出站SA或SA捆绑包。第二次检查是在将数据包转发到目的地之前进行的，是第8.2节中描述的灵敏度一致性检查。
An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment.
MLS安全网关必须遵循前面提到的入站和出站处理规则，并执行一些特定于MLS环境中数据包中间保护的附加处理。
A security gateway MAY act as an outbound proxy, creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards.
安全网关可以充当出站代理，为MLS系统创建SA，这些系统发起网关转发的数据包。这些MLS系统可以明确地标记要转发的分组，或者整个发起网络可以具有与其相关联的敏感特性。安全网关必须为AH、ESP或两者创建并使用适当的SAs，以保护其转发的此类流量。
Similarly such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network.
类似地，此类网关应接受和处理入站AH和/或ESP数据包，并使用显式数据包标签或依赖目的地网络的敏感特性进行适当转发。
The use of IPsec imposes computational performance costs on the hosts or security gateways that implement these protocols. These costs are associated with the memory needed for IPsec code and data structures, and the computation of integrity check values, encryption and decryption, and added per-packet handling. The per-packet computational costs will be manifested by increased latency and, possibly, reduced throughout. Use of SA/key management protocols, especially ones that employ public key cryptography, also adds computational performance costs to use of IPsec. These per-association computational costs will be manifested in terms of increased latency in association establishment. For many hosts, it is anticipated that software-based cryptography will not appreciably reduce throughput, but hardware may be required for security gateways (since they represent aggregation points), and for some hosts.
IPsec的使用给实现这些协议的主机或安全网关带来了计算性能成本。这些成本与IPsec代码和数据结构所需的内存、完整性检查值的计算、加密和解密以及每个数据包处理的增加有关。每个数据包的计算成本将表现为延迟的增加，并可能在整个过程中降低。SA/密钥管理协议的使用，特别是采用公钥加密的协议，也会增加IPsec使用的计算性能成本。这些每个关联的计算成本将表现为关联建立延迟的增加。对于许多主机，预计基于软件的加密不会明显降低吞吐量，但安全网关（因为它们代表聚合点）和某些主机可能需要硬件。
The use of IPsec also imposes bandwidth utilization costs on transmission, switching, and routing components of the Internet infrastructure, components not implementing IPsec. This is due to the increase in the packet size resulting from the addition of AH and/or ESP headers, AH and ESP tunneling (which adds a second IP header), and the increased packet traffic associated with key management protocols. It is anticipated that, in most instances,
IPsec的使用还对Internet基础设施的传输、交换和路由组件（未实现IPsec的组件）施加了带宽利用成本。这是由于添加AH和/或ESP报头、AH和ESP隧道（添加第二个IP报头）以及与密钥管理协议相关的数据包流量增加而导致的数据包大小增加。预计在大多数情况下，
this increased bandwidth demand will not noticeably affect the Internet infrastructure. However, in some instances, the effects may be significant, e.g., transmission of ESP encrypted traffic over a dialup link that otherwise would have compressed the traffic.
这种增加的带宽需求不会显著影响互联网基础设施。然而，在某些情况下，影响可能是显著的，例如，通过拨号链路传输ESP加密流量，否则会压缩流量。
Note: The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet.
注意：初始SA建立开销将在第一个数据包中感受到。此延迟可能会影响传输层和应用程序。例如，它可能导致TCP在ISAKMP交换完成之前重新传输SYN。延迟对UDP的影响将不同于TCP，因为在建立连接之前，TCP不应传输除SYN之外的任何内容，而UDP将继续并传输第一个数据包之外的数据。
Note: As discussed earlier, compression can still be employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by IPsec protocols."
注：如前所述，压缩仍然可以在IP以上的层上使用。有一个IETF工作组（IP有效负载压缩协议（ippcp））正在研究“协议规范，使得在有效负载被加密协议处理之前，可以对单个有效负载执行无损压缩。这些规范将允许在IPsec协议加密有效负载之前执行压缩操作。”
All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document.
声称实现IPsec的所有IPv4系统必须符合安全体系结构文档的所有要求。所有IPv6系统必须符合安全体系结构文档的所有要求。
The focus of this document is security; hence security considerations permeate this specification.
本文件的重点是安全；因此，安全考虑贯穿于本规范中。
This architecture document differs substantially from RFC 1825 in detail and in organization, but the fundamental notions are unchanged. This document provides considerable additional detail in terms of compliance specifications. It introduces the SPD and SAD, and the notion of SA selectors. It is aligned with the new versions of AH and ESP, which also differ from their predecessors. Specific requirements for supported combinations of AH and ESP are newly added, as are details of PMTU management.
本架构（architecture）文档在细节和组织上与RFC 1825有很大不同，但基本概念没有改变。本文件在合规性规范方面提供了相当多的额外细节。它介绍了SPD和SAD，以及SA选择器的概念。它与AH和ESP的新版本保持一致，这两个版本也不同于它们的前辈。新增了AH和ESP支持组合的具体要求，以及PMTU管理的细节。
Acknowledgements
致谢
Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security.
本规范中包含的许多概念源自或受美国政府的SP3安全协议、ISO/IEC的NLSP、建议的刷卡安全协议[SDNS、ISO、IB93、IBK93]以及为SNMP安全和SNMPv2安全所做的工作的影响。
For over 3 years (although it sometimes seems *much* longer), this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, Harry Varnis, and Nina Yuan.
在3年多的时间里（虽然有时看起来要长得多），本文档经过了多个版本和迭代。在这段时间里，许多人为这一过程和文件本身贡献了重要的思想和精力。作者要感谢Karen Seo在本规范版本的审查、编辑、背景研究和协调方面提供的广泛帮助。作者还要感谢IPsec和IPng工作组的成员，并特别提到（按字母顺序排列）Steve Bellovin、Steve Deering、James Hughes、Phil Karn、Frank Kastenholz、Perry Metzger、David Mihelcic、Hilarie Orman、Norman Shulman、William Simpson、Harry Varnis和Nina Yuan的努力。
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., [VK83, HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms.
本节提供了本文件中使用的几个关键术语的定义。其他文件提供了与该技术相关的其他定义和背景信息，例如[VK83，HA94]。本词汇表中包括通用安全服务和安全机制术语，以及IPsec特定术语。
Access Control Access control is 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: o for a host, computing cycles or data o for a security gateway, a network behind the gateway or bandwidth on that network.
访问控制访问控制是防止未经授权使用资源的安全服务，包括防止以未经授权的方式使用资源。在IPsec上下文中，控制访问的资源通常是：主机的o、安全网关的计算周期或数据o、网关后面的网络或该网络上的带宽。
Anti-replay [See "Integrity" below]
反重播[见下面的“完整性”）
Authentication This term is 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 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 Confidentiality is 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，特别是在安全网关上，可以提供一定级别的流量机密性。（另请参见下面的流量分析。）
Encryption Encryption is 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". Oftimes the term "encryption" is used to generically refer to both processes.
加密是一种安全机制，用于将数据从可理解形式（明文）转换为不可理解形式（密文），以提供机密性。逆变换过程被称为“解密”。术语“加密”通常指这两个过程。
Data Origin Authentication Data origin authentication is a security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service.
数据源身份验证数据源身份验证是一种安全服务，用于验证声明的数据源的身份。此服务通常与无连接完整性服务捆绑在一起。
Integrity Integrity is 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数据报的到达（在受约束的窗口内）。这与面向连接的完整性形成对比，后者对流量提出了更严格的排序要求，例如，能够检测丢失或重新排序的消息。虽然认证和完整性服务通常是分开引用的，但实际上它们是紧密相连的，几乎总是同时提供的。
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.
安全关联（SA）为安全目的创建的单工（单向）逻辑连接。通过SA的所有流量都提供相同的安全处理。在IPsec中，SA是通过使用AH或ESP实现的internet层抽象。
Security Gateway A security gateway is 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 viewed as untrusted (or less trusted), while the networks and hosts and on the internal side are viewed as trusted (or more trusted). The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. (See "Trusted Subnetwork" below.) In the IPsec context, a security gateway is a point at which AH and/or ESP is implemented in order to serve
安全网关安全网关是充当两个网络之间通信接口的中间系统。安全网关外部的一组主机（和网络）被视为不受信任（或不太受信任），而内部的网络和主机被视为受信任（或更受信任）。安全网关所服务的内部子网和主机通过共享公共的本地安全管理而被认为是可信的。（请参阅下面的“受信任子网”）在IPsec上下文中，安全网关是实现AH和/或ESP以提供服务的点
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).
一组内部主机，当这些主机与也采用IPsec（直接或通过另一个安全网关）的外部主机通信时，为这些主机提供安全服务。
SPI Acronym for "Security Parameters Index". The combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). 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是“安全参数索引”的首字母缩写。目标地址、安全协议和SPI的组合唯一地标识安全关联（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, flow identifiers, etc. [Sch94]
流量分析为了推断对对手有用的信息而对网络流量进行的分析。此类信息的示例包括传输频率、转换方的身份、数据包大小、流标识符等。[Sch94]
Trusted Subnetwork A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. There also is an assumption that the underlying communications channel (e.g., a LAN or CAN) isn't being attacked by other means.
可信子网包含主机和路由器的子网，主机和路由器相互信任，不会进行主动或被动攻击。还有一种假设，即底层通信信道（如LAN或CAN）没有受到其他方式的攻击。
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues
In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header?
在系统（主机或网关）添加封装报头（例如ESP隧道）的情况下，是否应/必须将原始数据包中的DF位复制到封装报头？
Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface.
对于某些情况，分段似乎是正确的，例如，在具有非常小的MTU的网络上（例如，分组无线电网络或移动电话跳到移动节点）分段分组可能是合适的，而不是传播回非常小的PMTU以便在路径的其余部分上使用。在其他情况下，设置DF位可能是合适的，以便从以后的路由器获得关于需要分段的PMTU约束的反馈。这两种情况的存在都要求系统能够决定是否在特定网络“链路”上进行分段，即要求实现能够复制DF位（并处理ICMP PMTU消息），但使其成为一个选项，以每个接口为基础进行选择。换句话说，管理员应该能够为每个接口配置路由器对DF位的处理（设置、清除、从封装头复制）。
Note: If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments.
注意：如果IPsec的堆栈实现中有一个bump试图基于源/目标端口应用不同的IPsec算法，则很难应用路径MTU调整。
If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump-in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that BITS or BITW implementations are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec.
如果需要，IP碎片会在IPsec实现中的IPsec处理之后发生。因此，传输模式AH或ESP仅应用于整个IP数据报（而不是IP片段）。已应用AH或ESP的IP数据包本身可能在路由中被路由器分段，并且必须在接收器处进行IPsec处理之前重新组装这些分段。在隧道模式下，AH或ESP应用于IP数据包，其有效载荷可以是分段的IP数据包。例如，安全网关、“堆栈中的通气”（BITS）或“线路中的通气”（BITW）IPsec实现可将隧道模式AH应用于此类片段。请注意，BITS或BITW实现是主机IPsec实现可能接收要应用隧道模式的片段的示例。但是，如果要应用传输模式，则这些实现必须在应用IPsec之前重新组装片段。
NOTE: IPsec always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPsec and is intrinsic to the definition of IPsec. Therefore any IPsec implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (e.g., IP2):
注意：IPsec必须始终确定封装IP头字段是什么。这与插入IPsec的位置无关，并且是IPsec定义的固有特性。因此，任何未集成到IP实现中的IPsec实现必须包含用于构造必要IP头（例如IP2）的代码：
o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer
o AH通道-->IP2-AH-IP1-Transport-Data o ESP通道-->IP2-ESP_hdr-IP1-Transport-Data-ESP_拖车
*********************************************************************
*********************************************************************
Overall, the fragmentation/reassembly approach described above works for all cases examined.
总的来说，上述碎片/重新组装方法适用于所检查的所有情况。
AH Xport AH Tunnel ESP Xport ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor *
AH Xport AH Tunnel ESP Xport ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor *
* If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPsec processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers.
* 如果加密处理器系统有自己的IP地址，那么它就属于安全网关案例的范围。此框从主机接收数据包并执行IPsec处理。它必须能够处理安全网关必须处理的AH、ESP和相关IPv4/IPv6隧道处理。如果它没有自己的地址，那么它类似于IP和网络驱动程序之间堆栈实现中的碰撞。
The following analysis assumes that:
以下分析假设：
1. There is only one IPsec module in a given system's stack. There isn't an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPsec module B. 2. There are several places where IPsec could be implemented (as shown in the table above). a. Hosts with integration of IPsec into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPsec is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPsec code to be incorporated into the system.
1. 给定系统堆栈中只有一个IPsec模块。没有IPsec模块A（添加ESP/encryption，从而）向IPsec模块B隐藏传输协议、SRC端口和DEST端口。2。有几个地方可以实现IPsec（如上表所示）。A.将IPsec集成到本机IP实现中的主机。实现者可以访问堆栈的源。B在堆栈实现中使用bump的主机，其中IPsec在IP和本地网络驱动程序之间实现。堆栈的源访问不可用；但是有定义良好的接口，允许将IPsec代码合并到系统中。
c. Security gateways and outboard crypto processors with integration of IPsec into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible.
C安全网关和外部加密处理器，将IPsec集成到堆栈中。3.并非所有上述方法都适用于所有主机。但我们假设，对于每种方法，都有一些主机的方法是可行的。
For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4).
对于上述三类中的每一类，都有IPv4和IPv6、AH传输和隧道模式以及ESP传输和隧道模式，总共有24种情况（3 x 2 x 4）。
Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.)
此处列出了一些标题字段和接口字段以便于参考——它们不按标题顺序排列，而是列出以允许在列之间进行比较。（*=AH身份验证未涵盖。ESP身份验证不涵盖其前面的任何标头。）
IP/Transport Interface
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt
IP/Transport Interface
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt
? = AH covers Option-Type and Option-Length, but might not cover Option-Data.
? = AH包括期权类型和期权长度，但可能不包括期权数据。
The results for each of the 20 cases is shown below ("works" = will work if system fragments after outbound IPsec processing, reassembles before inbound IPsec processing). Notes indicate implementation issues.
这20种情况的结果如下所示（“works”=如果系统在出站IPsec处理后断开，在入站IPsec处理前重新组装，则将工作”）。说明说明了执行问题。
a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works
o ESP传输-->（IP1-ESP_hdr-transport-Data-ESP_trailer）-IPv4--工作-IPv6--工作到ESP隧道-->（IP2-ESP_hdr-IP1-transport-Data-ESP_trailer）-IPv4--工作到IPv6--工作
b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network drivers. In this case, the IPsec module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel end is at the ultimate destination, this is fine. But in AH or ESP tunnel modes where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal routing because the IPsec module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPsec would need to know the LAN interface and the next-hop gateway for the tunnel end. (Note: The tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall.) OR - pass the IPsec'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPsec module would have to check and let IPsec'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header
b. 主机（堆栈中的凹凸）——将IPsec置于IP层和网络驱动程序之间。在这种情况下，IPsec模块必须执行以下操作之一来进行分段和重新组装。-自行执行碎片/重组工作，并直接向网络层发送/接收数据包。在AH或ESP传输模式下，这很好。在AH或ESP隧道模式下，如果隧道端位于最终目的地，则可以。但是，在AH或ESP隧道模式中，如果隧道端与最终目的地不同，并且源主机是多宿的，这种方法可能会导致次优路由，因为IPsec模块可能无法获得所需的信息（LAN接口和下一跳网关）将数据包定向到适当的网络接口。如果最终目的地和隧道端的接口和下一跳网关相同，则这不是问题。但是如果它们不同，那么IPsec需要知道LAN接口和隧道端的下一跳网关。（注意：隧道端（安全网关）很可能位于通往最终目的地的常规路径上。但也可能有多条通往目的地的路径，例如，主机可能位于具有2个防火墙的组织中。并且使用的路径可能涉及不太常用的防火墙。）或者-将IPsec的数据包传递回IP层，在那里额外的IP报头将被预先挂起，IPsec模块必须检查并让IPsec的片段通过。或-将数据包内容以某种形式传递给IP层，以便IP层重新创建适当的IP头
At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPsec has access to the Name. It is assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s).
在网络层，IPsec模块可以从数据包访问以下选择器--SRC地址、DST地址、Next协议，如果有传输层头-->SRC端口和DST端口。不能假定IPsec可以访问该名称。假设可用的选择器信息足以确定相关的安全策略条目和安全关联。
o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works
o AH传输-->（IP1 AH传输数据）-IPv4--works-IPv6--works o AH隧道-->（IP2-AH-IP1-transport-Data）-IPv4--works o ESP传输-->（IP1-ESP-hdr-transport-Data-ESP-trailer）-IPv4--works-IPv6--works o ESP隧道-->（IP2-ESP-hdr-IP1-transport-Data-ESP-trailer）-IPv4--works IPv6--works
c. Security gateways -- integrate IPsec into the IP stack
c. 安全网关——将IPsec集成到IP堆栈中
NOTE: The IPsec module will have access to the following selectors from the packet -- SRC address, DST address, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) Unlike some Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries. It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s).
注意：IPsec模块将可以从数据包访问以下选择器——SRC地址、DST地址、Next协议，以及如果存在传输层头-->SRC端口和DST端口。它将无法访问用户ID（只有主机可以访问用户ID信息）。与堆栈中的某些Bump实现不同，安全网关可能能够在DNS中查找源地址以提供系统名称，例如。，在涉及使用动态分配的IP地址和动态更新的DNS条目的情况下。如果存在ESP报头，或者如果它不是分段消息的第一个片段，它也将无法访问传输层信息。假设可用的选择器信息足以确定相关的安全策略条目和安全关联。
o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works
o AH隧道-->（IP2-AH-IP1-Transport-Data）-IPv4--works-IPv6--works-o ESP隧道-->（IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer）-IPv4--works-IPv6--works
**********************************************************************
**********************************************************************
As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery.
如前所述，“ICMP PMTU”是指用于路径MTU发现的ICMP消息。
The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) is:
B.3.1和B.3.3（但不是B.3.2）中下图的图例为：
==== = security association (AH or ESP, transport or tunnel)
==== = security association (AH or ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for
IPv4: - 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 (labelled unused in RFC 792), with high-order 16 bits set to zero
IPv4:-类型=3（目标不可访问）-代码=4（需要分段并设置DF）-ICMP头第二个字的低阶16位（在RFC 792中标记为未使用）中的下一跳MTU，高阶16位设置为零
IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6
IPv6（RFC 1885）：-Type=2（数据包太大）-Code=0（需要分段并设置DF）-ICMP6的32位MTU字段中的下一跳MTU
Hx = host x Rx = router x SGx = security gateway x X* = X supports IPsec
Hx=主机x Rx=路由器x SGx=安全网关x*=x支持IPsec
The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information.
ICMP消息返回的信息量是有限的，这会影响可用于识别安全关联、原始主机等的选择器，以便在进一步传播PMTU信息时使用。
In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits
简言之ICMP消息必须包含来自“违规”数据包的以下信息：-IPv4（RFC 792）--IP标头加上至少64位
Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted.
因此，在IPv4上下文中，ICMP PMTU可能仅识别第一个（最外层）安全关联。这是因为ICMP PMTU可能仅包含IP报头之外的64位“违规”数据包，这将仅捕获AH或ESP的第一个SPI。在IPv6上下文中，ICMP PMTU可能会提供IP报头中的所有SPI和选择器，但可能不会提供SRC/DST端口（传输报头中）或封装的端口（TCP、UDP等）协议。此外，如果使用ESP，传输端口和协议选择器可能会被加密。
Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)...
查看下面的安全网关隧道图（如其他地方所述，安全网关不使用传输模式）。。。
H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4
H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4
Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. And suppose H0 sends a data packet to H5 which causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message.
假设SG1的安全策略是对主机H0、H1和H2与主机H3、H4和H5之间的所有流量使用单个SA到SG2。假设H0向H5发送数据包，导致R1向SG1发送ICMP PMTU消息。如果PMTU消息只有SPI，SG1将能够查找SA并找到可能的主机列表（H0、H1、H2、通配符）；但是SG1将无法确定H0发送了触发ICMP PMTU消息的流量。
original after IPsec ICMP
packet processing packet
-------- ----------- ------
IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header IP-2 header (S = SG1, D = SG2)
ESP header minimum of 64 bits of ESP hdr (*)
IP-1 header IP-1 header
TCP header TCP header
TCP data TCP data
ESP trailer
original after IPsec ICMP
packet processing packet
-------- ----------- ------
IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header IP-2 header (S = SG1, D = SG2)
ESP header minimum of 64 bits of ESP hdr (*)
IP-1 header IP-1 header
TCP header TCP header
TCP data TCP data
ESP trailer
(*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), Seq number (32 bits) - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits)
（*）64位将包含足够的ESP（或AH）头，以包含SPI。-ESP—SPI（32位）、序列号（32位）—AH—下一个报头（8位）、有效负载Len（8位）、保留（16位）、SPI（32位）
This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPsec header (minimum for IPv4), then the IPsec selectors (e.g., Source and Destination addresses, Next Protocol, Source and Destination ports, etc.) will have been lost. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association.
对ICMP消息返回的信息量的这种限制在识别数据包的原始主机（以便知道在何处进一步传播ICMP PMTU信息）方面产生了问题。如果ICMP消息仅包含64位IPsec头（IPv4的最小值），则IPsec选择器（例如，源和目标地址、下一个协议、源和目标端口等）将丢失。但ICMP错误消息仍将向SG1提供SPI、PMTU信息以及相关安全关联的源和目标网关。
The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could:
目标安全网关和SPI唯一地定义了一个安全关联，该关联反过来定义了一组可能的原始主机。此时，SG1可以：
a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one or a small number of hosts. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a).
a. 将PMTU信息发送到所有可能的原始主机。如果主机列表是通配符，或者如果许多/大多数主机没有发送到SG1，那么这将不起作用；但是，如果SPI/destination/etc只映射到一个或少数主机，那么它可能会工作。B将PMTU与SPI/etc一起存储，并等待相关安全关联的下一个数据包从发起主机到达。如果它/它们大于PMTU，则丢弃数据包，并用新数据包和更新的PMTU组成ICMP PMTU消息，并向发起主机发送有关问题的ICMP消息。这涉及延迟通知发起主机，但避免了（a）的问题。
Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, then there may be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field may not be contained in the ICMP message and the use of ESP encryption may hide the selector fields that have been encrypted.
由于只有后一种方法在所有情况下都是可行的，安全网关必须作为一种选择提供这种支持。但是，如果ICMP消息包含来自原始数据包的更多信息，则可能有足够的信息来立即确定将ICMP/PMTU消息传播到哪个主机，并向该系统提供5个字段（源地址、目标地址、源端口、目标端口和传输协议）需要确定存储/更新PMTU的位置。在这种情况下，安全网关必须在收到来自路径下游的ICMP PMTU后立即生成ICMP PMTU消息。注意：ICMP消息中可能不包含下一个协议字段，使用ESP加密可能会隐藏已加密的选择器字段。
The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. (See Section 4.5 Basic Combinations of Security Associations for description of the combinations that MUST be supported). The diagram below illustrates an example of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPx or AHx = transport mode)
从ICMP PMTU计算PMTU时，必须考虑通过H1--AH和/或ESP传输或ESP或AH隧道添加任何IPsec头。在单个主机内，多个应用程序可能共享一个SPI，并且可能会发生安全关联嵌套。（有关必须支持的组合的说明，请参见第4.5节安全关联的基本组合）。下图显示了一对主机之间的安全关联示例（从其中一个主机的角度来看）（ESPx或AHx=传输模式）
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
In order to figure out the PMTU for each socket that maps to SPI-B, it will be necessary to have backpointers from SPI-B to each of the 2 paths that lead to it -- Socket 1 and Socket 2/SPI-A.
为了计算映射到SPI-B的每个套接字的PMTU，需要从SPI-B到通向它的两条路径中的每一条——套接字1和套接字2/SPI-A的反向指针。
In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are three situations that are of interest with respect to PMTU issues:
在主机中，PMTU ICMP处理的粒度因实施情况而异。从主持人的角度来看，有三种情况与PMTU问题有关：
a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host.
a. 将IPsec集成到本机IP实现b中。堆栈实现中的Bump，其中IPsec在本机IP和本地网络驱动程序c之间的TCP/IP协议堆栈的现有实现“之下”实现。没有IPsec实现——之所以包括这种情况，是因为它与安全网关将PMTU信息发送回主机的情况有关。
Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally TOS/Class), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this.
只有在（a）种情况下，PMTU数据才能保持与通信关联相同的粒度。在其他情况下，IP层将以源和目标IP地址（以及可选的TOS/类）的粒度维护PMTU数据，如RFC 1191中所述。这是一个重要的区别，因为多个通信关联可能映射到相同的源和目标IP地址，并且每个通信关联可能具有不同的IPsec头开销（例如，由于使用不同的转换或不同的算法）。下面的例子说明了这一点。
In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them.
在（a）和（b）种情况下。。。假设您有以下情况。H1正在发送到H2，并且要从R1发送到R2的数据包超过了它们之间网络跳的PMTU。
==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|
==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|
If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPsec implementation in H1 can store/update the PMTU for the associated socket. In case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly TOS/Class, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination.
如果R1配置为不分割订户通信量，则R1向H1发送带有适当PMTU的ICMP PMTU消息。H1的处理将随实现的性质而变化。在（a）种情况下（本机IP），安全服务绑定到套接字或等效端口。在这里，H1中的IP/IPsec实现可以存储/更新关联套接字的PMTU。在情况（b）中，H1中的IP层可以存储/更新PMTU，但仅以源地址和目的地址的粒度以及可能的TOS/Class进行存储/更新，如上所述。因此，结果可能是次优的，因为给定SRC/DST/TOS/类的PMTU将减去用于给定源和目标之间的任何通信关联的最大数量的IPsec报头。
In case (c), there has to be a security gateway to have any IPsec processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them.
在案例（c）中，必须有一个安全网关才能进行任何IPsec处理。假设你有以下情况。H1正在发送到H2，并且要从SG1发送到R的数据包超过了它们之间网络跳的PMTU。
================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|
================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|
As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly TOS/Class. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination.
如上文针对情况（b）所述，H1中的IP层可以存储/更新PMTU，但仅以源地址和目的地址的粒度，并且可能以TOS/类的粒度存储/更新PMTU。因此，结果可能是次优的，因为给定SRC/DST/TOS/类的PMTU将减去用于给定源和目标之间的任何通信关联的最大数量的IPsec报头。
Implementation of the calculation of PMTU (Section B.3.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.3.3) is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message.
PMTU计算的实施（第B.3.2节）和在单个“通信关联”（第B.3.3节）粒度上对PMTU的支持是一个局部问题。但是，主机中基于套接字的IPsec实现应基于每个套接字维护信息。堆栈中的Bump系统必须在针对这些系统增加的任何IPsec头开销进行调整后，将ICMP PMTU传递给主机IP实现。开销的确定应通过分析SPI和返回的ICMP PMTU消息中存在的任何其他选择器信息来确定。
The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).
按照RFC 1191（路径MTU发现）中的规定，用于将更新后的PMTU发送到传输层的主机机制保持不变。
This topic is covered in Section 6.1.2.4.
本主题见第6.1.2.4节。
Appendix C -- Sequence Space Window Code Example
附录C——序列空间窗口代码示例
This appendix contains a routine that implements a bitmask check for a 32 packet window. It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) and is intended as an implementation example. Note that this code both checks for a replay and updates the window. Thus the algorithm, as shown, should only be called AFTER the packet has been authenticated. Implementers might wish to consider splitting the code to do the check for replays before computing the ICV. If the packet is not a replay, the code would then compute the ICV, (discard any bad packets), and if the packet is OK, update the window.
本附录包含一个例程，用于对32数据包窗口执行位掩码检查。它是由詹姆斯·休斯（吉姆·休斯）提供的_hughes@stortek.com)还有哈里·瓦尼斯(hgv@anubis.network.com)并打算作为一个实现示例。请注意，此代码既检查重播，又更新窗口。因此，如图所示，仅应在数据包经过身份验证后调用该算法。在计算ICV之前，实现者可能希望考虑拆分代码来检查重放。如果数据包不是重播，则代码将计算ICV（丢弃任何坏数据包），如果数据包正常，则更新窗口。
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
enum {
ReplayWindowSize = 32
};
enum {
ReplayWindowSize = 32
};
u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */
u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */
/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);
/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);
int ChkReplayWindow(u_long seq) {
u_long diff;
int ChkReplayWindow(u_long seq) {
u_long diff;
if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}
if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}
char string_buffer[512];
字符字符串_缓冲区[512]；
#define STRING_BUFFER_SIZE sizeof(string_buffer)
#定义字符串缓冲区大小sizeof（字符串缓冲区）
int main() {
int result;
u_long last, current, bits;
int main() {
int result;
u_long last, current, bits;
printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");
printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}
Appendix D -- Categorization of ICMP messages
附录D——ICMP消息的分类
The tables below characterize ICMP messages as being either host generated, router generated, both, unassigned/unknown. The first set are IPv4. The second set are IPv6.
下表将ICMP消息描述为主机生成、路由器生成、未分配/未知。第一组是IPv4。第二组是IPv6。
IPv4
IPv4
Type Name/Codes Reference
========================================================================
HOST GENERATED:
3 Destination Unreachable
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
8 Source Host Isolated [RFC792]
14 Host Precedence Violation [RFC1812]
10 Router Selection [RFC1256]
Type Name/Codes Reference
========================================================================
HOST GENERATED:
3 Destination Unreachable
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
8 Source Host Isolated [RFC792]
14 Host Precedence Violation [RFC1812]
10 Router Selection [RFC1256]
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
3 Destination Unreachable
0 Net Unreachable [RFC792]
4 Fragmentation Needed, Don't Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC792]
7 Destination Host Unknown [RFC792]
9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792]
11 Destination Network Unreachable for Type of Service[RFC792]
5 Redirect
0 Redirect Datagram for the Network (or subnet) [RFC792]
2 Redirect Datagram for the Type of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
3 Destination Unreachable
0 Net Unreachable [RFC792]
4 Fragmentation Needed, Don't Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC792]
7 Destination Host Unknown [RFC792]
9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792]
11 Destination Network Unreachable for Type of Service[RFC792]
5 Redirect
0 Redirect Datagram for the Network (or subnet) [RFC792]
2 Redirect Datagram for the Type of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]
IPv4
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
0 Echo Reply [RFC792]
3 Destination Unreachable
1 Host Unreachable [RFC792]
10 Comm. w/Dest. Host is Administratively Prohibited [RFC792]
12 Destination Host Unreachable for Type of Service [RFC792]
13 Communication Administratively Prohibited [RFC1812]
15 Precedence cutoff in effect [RFC1812]
4 Source Quench [RFC792]
5 Redirect
1 Redirect Datagram for the Host [RFC792]
3 Redirect Datagram for the Type of Service and Host [RFC792]
6 Alternate Host Address [JBP]
8 Echo [RFC792]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792,RFC1108]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [Johnson]
39 SKIP [Markson]
40 Photuris [Simpson]
IPv4
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
0 Echo Reply [RFC792]
3 Destination Unreachable
1 Host Unreachable [RFC792]
10 Comm. w/Dest. Host is Administratively Prohibited [RFC792]
12 Destination Host Unreachable for Type of Service [RFC792]
13 Communication Administratively Prohibited [RFC1812]
15 Precedence cutoff in effect [RFC1812]
4 Source Quench [RFC792]
5 Redirect
1 Redirect Datagram for the Host [RFC792]
3 Redirect Datagram for the Type of Service and Host [RFC792]
6 Alternate Host Address [JBP]
8 Echo [RFC792]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792,RFC1108]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [Johnson]
39 SKIP [Markson]
40 Photuris [Simpson]
Type Name/Codes Reference
========================================================================
UNASSIGNED TYPE OR UNKNOWN GENERATOR:
1 Unassigned [JBP]
2 Unassigned [JBP]
7 Unassigned [JBP]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
33 IPv6 Where-Are-You [Simpson]
34 IPv6 I-Am-Here [Simpson]
35 Mobile Registration Request [Simpson]
36 Mobile Registration Reply [Simpson]
37 Domain Name Request [Simpson]
38 Domain Name Reply [Simpson]
41-255 Reserved [JBP]
Type Name/Codes Reference
========================================================================
UNASSIGNED TYPE OR UNKNOWN GENERATOR:
1 Unassigned [JBP]
2 Unassigned [JBP]
7 Unassigned [JBP]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
33 IPv6 Where-Are-You [Simpson]
34 IPv6 I-Am-Here [Simpson]
35 Mobile Registration Request [Simpson]
36 Mobile Registration Reply [Simpson]
37 Domain Name Request [Simpson]
38 Domain Name Reply [Simpson]
41-255 Reserved [JBP]
IPv6
IPv6
Type Name/Codes Reference
========================================================================
HOST GENERATED:
1 Destination Unreachable [RFC 1885]
4 Port Unreachable
Type Name/Codes Reference
========================================================================
HOST GENERATED:
1 Destination Unreachable [RFC 1885]
4 Port Unreachable
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
1 Destination Unreachable [RFC1885]
0 No Route to Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a Neighbor
3 Address Unreachable
2 Packet Too Big [RFC1885]
0
3 Time Exceeded [RFC1885]
0 Hop Limit Exceeded in Transit
1 Fragment reassembly time exceeded
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
1 Destination Unreachable [RFC1885]
0 No Route to Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a Neighbor
3 Address Unreachable
2 Packet Too Big [RFC1885]
0
3 Time Exceeded [RFC1885]
0 Hop Limit Exceeded in Transit
1 Fragment reassembly time exceeded
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
4 Parameter Problem [RFC1885]
0 Erroneous Header Field Encountered
1 Unrecognized Next Header Type Encountered
2 Unrecognized IPv6 Option Encountered
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
4 Parameter Problem [RFC1885]
0 Erroneous Header Field Encountered
1 Unrecognized Next Header Type Encountered
2 Unrecognized IPv6 Option Encountered
References
工具书类
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74- 244, The MITRE Corporation, Bedford, MA, May 1973.
[BL73]Bell，D.E.和LaPadula，L.J.，“安全计算机系统：数学基础和模型”，技术报告M74-244，麻省贝德福德米特尔公司，1973年5月。
[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月。
[DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985.
[DoD85]美国国家计算机安全中心，“国防部可信计算机系统评估标准”，国防部5200.28-STD，美国国防部，马里兰州米德堡，1985年12月。
[DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987.
[DoD87]美国国家计算机安全中心，“可信计算机系统评估标准的可信网络解释”，NCSC-TG-005，第1版，美国国防部，马里兰州米德堡，1987年7月31日。
[HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[HA94]Haller，N.和R.Atkinson，“互联网认证”，RFC 17041994年10月。
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC98]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[HM97] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[HM97]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）体系结构”，RFC 2094，1997年7月。
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
[ISO]ISO/IEC JTC1/SC6，网络层安全协议，ISO-IEC DIS 11577，国际标准组织，瑞士日内瓦，1992年11月29日。
[IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993.
[IB93]John Ioannidis和Matt Blaze，“Unix下网络层安全的体系结构和实现”，USENIX安全研讨会论文集，加利福尼亚州圣克拉拉，1993年10月。
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio
[IBK93]John Ioannidis、Matt Blaze和Phil Karn，“刷卡：IP的网络层安全”，在俄亥俄州哥伦布市1993年春季IETF会议上的演讲
[KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[KA98a]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[KA98b]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, November 1991.
[Ken91]Kent，S.，“美国国防部互联网协议的安全选项”，RFC 1108，1991年11月。
[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[MSST97]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[Orm97]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[Pip98]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
[Sch94]Bruce Schneier，应用密码学，第8.6节，John Wiley&Sons，纽约州纽约市，1994年。
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990.
[SDNS]SDNS安全数据网络系统，安全协议3，SP3，文件SDN.301，修订版1.5，1989年5月15日，发表于NIST出版物NIST-IR-90-4250，1990年2月。
[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.
[SMPT98]Shacham，A.，Monsour，R.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 23931998年8月。
[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[TDG97]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[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月。
Disclaimer
免责声明
The views and specification expressed in this document are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design.
本文件中表达的观点和规范是作者的观点和规范，不一定是其雇主的观点和规范。作者及其雇主明确否认对正确或不正确实施或使用本设计产生的任何问题负责。
Author Information
作者信息
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA
美国马萨诸塞州剑桥福塞特街70号Stephen Kent BBN Corporation 02140
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson @Home Network 425 Broadway Redwood City, CA 94063 USA
Randall Atkinson@Home Network美国加利福尼亚州百老汇红木城425号，邮编94063
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。