rfc4301- IP 安全架构

1. 引言

1.1. 文档内容摘要

本文档规定了符合IPsec标准的系统的基本架构。它描述了如何为IP层的流量提供一组安全服务，同时适用于IPv4 [Pos81a] 和 IPv6 [DH98] 环境。本文档描述了实现IPsec的系统的要求，这些系统的基本元素以及如何将这些元素结合起来并融入IP环境中。它还描述了IPsec协议所提供的安全服务以及这些服务如何在IP环境中使用。本文档没有涉及IPsec架构的所有方面。其他文档涉及专门环境下的其他架构细节，例如在网络地址转换（NAT）环境中使用IPsec以及对IP组播的更全面支持。IPsec安全架构的基本组件根据其所需的底层功能进行讨论。其他RFC文档（参见第1.3节的指明的其他文档）定义了以下协议：

a. 安全协议 - 身份验证头（AH：Authentication Header）和封装安全载荷（ESP:Encapsulating Security Payload）

b. 安全关联（Security Associations） - 它们是什么以及如何工作，如何管理，关联处理

c. 密钥管理 - 手动和自动（Internet密钥交换（IKE：Internet Key Exchange））

d. 用于身份验证和加密的密码算法

本文档不是互联网的安全架构；它仅涉及IP层的安全，通过使用加密和协议安全机制的组合来实现。在本文档和所有相关的IPsec标准中，首选并使用拼写"IPsec"。其他对于"IPsec"的首字母大写形式（例如IPSEC、IPSec、ipsec）已被弃用。然而，任何"IPsec"字母序列的首字母大写形式都应被理解为指代IPsec协议。

本文档中的关键词"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"和"OPTIONAL"，当它们出现在本文档中时，应按照RFC 2119 [Bra97]中的描述进行解释。

1.2. 目标读者

本文档的目标读者主要是那些实现IP安全技术或设计将使用该技术的系统的个人。技术熟练的技术用户（终端用户或系统管理员）也是目标受众的一部分。附录A提供了一个术语表，以帮助填补基础知识/词汇的差距。本文档假定读者熟悉Internet协议（IP）、相关的网络技术以及一般的信息系统安全术语和概念。

1.3 相关文档

如上所述，其他文档提供了IPsec组件及其相互关系的详细定义。它们包括以下主题的RFC文档：

a. 安全协议 - 描述身份验证头（AH） [Ken05b] 和封装安全载荷（ESP）[Ken05a] 协议的RFC文档。

b. 用于完整性和加密的密码算法 - 一个定义与AH和ESP默认使用的强制性加密算法的RFC [Eas05]，一个定义IKEv2协议强制性使用的加密算法的类似RFC [Sch05]，以及每种密码算法的单独RFC文件。

c. 自动密钥管理 - 描述"Internet密钥交换(IKEv2)协议"的RFC文档[Kau05]和"用于Internet密钥交换版本2(IKEv2)中的加密算法"的RFC文档[Sch05]。

译注：

[Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[Ken05b] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[Eas05] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements For Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.

[Sch05] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.

[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

2. 设计目标

2.1. 目标/要求/问题描述

IPsec的设计目标是为IPv4和IPv6提供互操作性强、基于密码学的高质量安全性。提供的安全服务包括访问控制、无连接完整性、数据源验证、重播检测和拒绝（一种部分序列完整性）、机密性（通过加密）以及有限的流量流机密性。这些服务在IP层提供，以标准的方式为可能在IP上运行的所有协议（包括IP本身）提供保护。

IPsec包括最小防火墙功能的规范，因为这是IP层访问控制的重要方面。实现可以提供更复杂的防火墙机制，并使用这些更复杂的机制实现IPsec规定的功能。请注意，如果IPsec实现对流量流添加了额外的防火墙限制，但无法基于本文档中定义和协商的流量选择器的功能进行协商，则互操作性可能会受到影响。

大部分安全服务是通过使用两个流量安全协议（认证头AH和封装安全载荷ESP）和使用密码密钥管理程序和协议来提供的。在特定环境中使用的IPsec协议集合及其使用方式将由该环境中的用户/管理员确定。IPsec架构的目标是确保符合规范的实现包括满足广泛用户群安全需求所需的服务和管理接口。

当正确实施和部署IPsec时，它不应对未使用IPsec进行流量保护的用户、主机和其他Internet组件产生不利影响。IPsec安全协议（AH和ESP，以及在较小程度上的IKE）设计为与密码算法无关。这种模块化允许根据需要选择不同的密码算法集合，而不会影响实现的其他部分。例如，如果需要，不同的用户群体可以选择不同的密码算法集合（创建密码学强制执行的群组）。

为了促进全球Internet的互操作性，在[Eas05]中指定了与为AH和ESP使用的默认密码算法集合，并在[Sch05]中指定了IKEv2的强制实施算法集合。[Eas05]和[Sch05]将定期更新，以适应计算和密码学的进步。通过在与AH、ESP和IKEv2规范分开的文档中指定这些算法，可以更新或替换这些算法，而不会影响IPsec文档套件的标准化进程。使用这些密码算法，结合IPsec流量保护和密钥管理协议，旨在允许系统和应用程序开发人员部署高质量的、Internet层的密码学安全技术。

2.2. 注意事项和假设

IPsec协议套件及其相关默认密码算法的设计目的是为Internet流量提供高质量的安全性。然而，通过使用这些协议提供的安全性，最终取决于它们的实现质量，而这超出了这套标准的范围。此外，计算机系统或网络的安全性受多种因素的影响，包括人员、物理因素、程序、泄漏威胁和计算机安全实践。因此，IPsec只是整体系统安全架构的一部分。

最后，通过使用IPsec所提供的安全性在很大程度上取决于IPsec实现执行的操作环境的许多方面。例如，操作系统安全性的缺陷、随机数源的质量不佳、系统管理协议和实践不严谨等都可能降低IPsec提供的安全性。如上所述，这些环境属性中的任何一个都不在本标准或其他IPsec标准的范围之内。

3. 系统概述

本节提供了IPsec工作原理的高层描述，系统组件以及它们如何结合提供上述安全服务的概述。这一描述的目标是使读者能够"构想"整个流程/系统，了解它如何融入IP环境，并为本文档后续部分提供背景，该部分将更详细地描述每个组件。

IPsec实施可以作为主机、安全网关 (SG：security gateway) 或独立设备运行，为IP流量提供保护。（安全网关是实施了IPsec的中间系统，例如已启用IPsec的防火墙或路由器。）对这些实现类别的更详细说明将在第3.3节中提供。IPsec所提供的保护是基于由用户或系统管理员建立和维护的安全策略数据库 (SPD：Security Policy Database) 所定义的要求，或者是由受上述任一方约束的应用程序所实施的。通常来说，根据IP和下一层头信息（"选择器（Selectors）"，第4.4.1.1节），数据包根据与SPD条目匹配而被选择执行三种处理操作中的一种。每个数据包根据选择器所识别的适用SPD策略，要么使用IPsec安全服务进行保护，要么被丢弃，要么被允许绕过IPsec保护。

3.1. IPsec 提供的功能

IPsec在主机或网络中创建了一个未受保护和受保护接口之间的边界（见下图）。穿越该边界的流量按照由负责IPsec配置的用户或管理员指定的访问控制进行限制。这些控制指示数据包是畅通无阻地穿越边界，还是通过AH或ESP获得安全服务，或者被丢弃。

IPsec安全服务通过选择合适的安全协议、密码算法和加密密钥在IP层提供。IPsec可用于保护一个或多个"路径"：

(a) 一对主机之间，

(b) 一对安全网关之间，或

符合要求的主机实现必须支持(a)和(c)，而符合要求的安全网关必须支持这三种连接形式，因为在某些情况下，安全网关会充当一个主机。

在这个图中，“未受保护(unprotected)”指的是一个的接口，也可能被称为"黑色(black)"或"密文(ciphertext)"。在这里，"受保护(protected)"指的是一个的接口，也可能被称为"红色(red)"或"明文(plaintext)"。上面提到的受保护接口可能是内部的，例如，对于IPsec的主机实现，受保护接口可能连接到由操作系统提供的套接字层接口。在本文档中，术语"入站(inbound)"是指通过未受保护接口进入IPsec实现的流量，或由实现在边界的未受保护侧发出并指向受保护接口的流量。术语"出站(outbound)"是指通过受保护接口进入实现的流量，或由实现在边界的受保护侧发出并指向未受保护接口的流量。IPsec实现可能在边界的一个或两个侧面支持多个接口。

请注意IPsec边界两侧丢弃流量的功能，允许流量在未经密码保护的情况下跨越边界的绕过功能，以及将IKE作为受保护侧的密钥和安全管理功能的说明。

请注意，在IPsec边界的两侧都有丢弃流量的功能，还有一个绕过功能，允许流量在没有加密保护的情况下通过边界，以及引用IKE作为受保护端的密钥和安全管理功能。

IPsec还可以选择性地支持IP压缩的协商[SMPT01]，部分原因是观察到在IPsec中使用加密时，它会阻止下层协议有效地进行压缩。

译注[SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas,"IP Payload Compression Protocol (IPComp)", RFC 3173,September 2001.

3.2. IPsec的工作原理

IPsec使用两个协议提供流量安全服务——验证头部（Authentication Header，AH）和封装安全负载（Encapsulating Security Payload，ESP）。这两个协议在各自的RFC文件中有详细描述[Ken05b，Ken05a]。IPsec的实现必须支持ESP，并可以支持AH（由于经验表明，在很少的情况下，ESP无法提供所需的安全服务，因此对AH的支持已降级为可选。请注意，ESP可以用于仅提供完整性，而无需保密性，在大多数情况下与AH类似。）

IP认证头（AH）[Ken05b]提供完整性和数据源身份验证，接收方可以选择（自行决定）使用抗重放特性。
封装安全负载（ESP）协议[Ken05a]提供相同的服务，并且还提供机密性。不推荐使用ESP仅提供机密性而不提供完整性。当启用了机密性的ESP时，可以通过特殊的措施来限制流量的机密性，例如隐藏数据包长度和便于生成和丢弃虚拟数据包。这种能力主要适用于虚拟私有网络（VPN）和叠加网络的上下文中。
AH和ESP都提供访问控制，通过分发加密密钥并根据安全策略数据库（Security Policy Database，SPD，第4.4.1节）管理流量流动来执行。

这些协议可以单独应用或者相互结合，以提供IPv4和IPv6安全服务。然而，大多数安全需求可以通过单独使用ESP来满足。每个协议都支持两种使用模式：传输模式（transport mode）和隧道模式（tunnel mode）。在传输模式下，AH和ESP主要为下一层协议提供保护；在隧道模式下，AH和ESP应用于隧道化的IP数据包。这两种模式之间的区别在第4.1节中讨论。

IPsec允许用户（或系统管理员）控制安全服务提供的粒度。例如，可以创建一个单一的加密隧道来承载两个安全网关之间的所有流量，或者可以为每对跨越这些网关进行通信的主机之间的每个TCP连接创建一个单独的加密隧道。通过SPD（Security Policy Database）管理范式，IPsec提供以下功能的设定：

选择使用的安全协议（AH或ESP）
模式（传输模式或隧道模式）
安全服务选项
使用哪些密码算法以及以何种组合使用指定的协议和服务
适用保护的粒度。

由于IPsec提供的大多数安全服务都需要使用加密密钥，因此它依赖于一组单独的机制来确保这些密钥的安全。本文档要求同时支持手动和自动的密钥分发。它规定了一种特定的基于公钥的方法（IKEv2）进行自动密钥管理，但也可以使用其他自动密钥分发技术。

注意：本文档要求支持一些在IKEv2中可用但在IKEv1中不可用的功能，例如协商表示本地和远程端口范围的SA，或者协商具有相同选择器（selectors）的多个SA。因此，本文档假定使用了IKEv2或具有类似功能的密钥和安全关联管理系统。

3.3. IPsec的实现方式

IPsec可以以多种方式在主机上实现，或者与路由器或防火墙相结合以创建安全网关，或作为独立的安全设备。

a. IPsec可以集成到本机IP协议栈中。这需要访问IP源代码，适用于主机和安全网关，虽然本机主机实现最能从该策略中受益，这将在后面解释（第4.4.1节，第6段; 4.4.1.1节，最后一段）。

b. 在“栈中实施（bump-in-the-stack）”（BITS）实现中，IPsec被实现在已有的IP协议栈实现之下，在本机IP和本地网络驱动程序之间。在这种情况下，不需要访问IP堆栈的源代码，使得这种实现方法适合用于旧系统。当采用此方法时，通常用于主机。

c. 使用专用的内联安全协议处理器是军事系统和一些商业系统常见的设计特征。有时它被称为“线中实施（bump-in-the-wire）”（BITW）。这样的实现可以设计为为主机或网关提供服务。通常，BITW设备本身是IP可寻址的。当支持单个主机时，它可能与BITS实现非常类似，但在支持路由器或防火墙时，它必须像安全网关一样运行。

本文档经常讨论主机或安全网关使用IPsec，而不考虑实现是本机、BITS或BITW。当这三种实现选项之间的区别很重要时，文档将提到特定的实现方法。

本文档通常在使用IPsec的术语中提到主机或安全网关，而不考虑实现是本机、BITS或BITW。当这些实现选项之间的差异很重要时，本文将引用特定的实现方法。

IPsec的主机实现可能出现在可能不被视为“主机（hosts）”的设备上。例如，路由器可以使用IPsec来保护路由协议（例如BGP）和管理功能（例如Telnet），而不影响通过路由器的订阅者流量。安全网关可以使用单独的IPsec实现来保护其管理流量和订阅者流量。本文档描述的架构非常灵活。例如，具有功能齐全、符合标准的本机操作系统IPsec实现的计算机应该能够被配置为保护本机（主机）应用程序，并为通过计算机的流量提供安全网关保护。这种配置将使用第5.1节和第5.2节中描述的转发表和SPD选择功能。

4. 安全联盟

本节定义了所有IPv6实现以及实现AH、ESP或同时实现AH和ESP的IPv4实现的安全联盟管理要求。安全联盟(Security Association, SA)是IPsec的基础概念。AH和ESP都使用安全联盟，IKE的一个主要功能就是建立和维护安全联盟。所有AH或ESP的实现必须支持如下所述的SA概念。本节的其余部分将描述SA管理的各个方面，定义SA策略管理和SA管理技术所需的特征。

4.1. 定义和范围

SA是一个单向的“连接”，为其承载的流量提供安全服务。SA通过使用AH或ESP来提供安全服务，但不能同时使用两者。如果一个流量同时应用了AH和ESP保护，则必须创建两个安全联盟，并通过安全协议的迭代应用来协调两个安全联盟，从而实现保护。为了保护两个启用ipsec的系统之间典型的双向通信，需要一对sa(每个方向一个)。IKE显式地创建SA对，以满足这种常见的使用需求。

对于用于传输单播流量的SA，仅仅使用安全参数索引（SPI：Security Parameters Index）即可指定一个SA。（有关SPI的详细信息，请参见附录 A 和 AH、ESP 规范 [Ken05b, Ken05a]。）然而，作为一个本地事务，实现可以选择将SPI与IPsec协议类型（AH或ESP）结合使用来标识SA。如果IPsec实现支持组播，那么它必须支持组播sa，使用下面的算法将入站IPsec数据报映射到sa。仅支持单播流量的实现不需要实现此解复用算法。

在许多安全的组播架构中，例如[RFC3740]，一个中央的组控制器/密钥服务器单方面分配组安全关联（GSA）的SPI。这个SPI的分配不是与组成该组的各个终端系统中的密钥管理（如IKE）子系统协商或协调的。因此，可能会出现GSA和单播SA同时使用相同SPI的情况。一个支持组播的IPsec实现必须能够正确地在SPI冲突的情况下对入站流量进行多路分解。

SA数据库(SAD：SA Database)中的每个条目(第4.4.2节)必须表明SA查找是使用目的IP地址，还是除了SPI之外还使用目的IP地址和源IP地址。对于组播SA，协议字段不用于SA查找。对于每个入站的、受IPsec保护的数据包，实现必须根据SA标识进行SAD搜索，以找到与之匹配的"最长"条目。在这种情况下，如果两个或多个SAD条目基于SPI值匹配，那么根据目标地址或目标和源地址（如SAD条目中指示的）进行匹配的条目就是"最长"匹配。这意味着SAD搜索的逻辑排序如下：

搜索SA数据库（SAD）以匹配SPI、目标地址和源地址的组合。如果有一个SAD条目匹配，则用该匹配的SAD条目处理入站数据包。否则，转到步骤2。
在SAD中搜索SPI和目标地址的匹配项。如果SAD条目匹配，则用该匹配的SAD条目处理入站数据包。否则，转到步骤3。
如果接收者选择维护AH和ESP的单个SPI空间，则只在SPI上搜索匹配项，否则在SPI和协议两者上都进行搜索。如果有一个SAD条目匹配，则用该匹配的SAD条目处理入站数据包。否则，丢弃数据包并记录可审计事件。

实际上，实现可以选择任何方法（或不选择任何方法）来加速这个搜索过程，尽管其外部可见行为必须在功能上等同于按照上述顺序搜索SAD。例如，基于软件的实现可以通过SPI在哈希表中进行索引。每个哈希表桶的链接列表中的SAD条目可以保持排序，使得具有最长SA标识符的SAD条目在该链表中排在前面。那些具有最短SA标识符的SAD条目可以排序，使其成为链表中的最后几个条目。基于硬件的实现可以使用通用的三态内容寻址存储器（TCAM：Ternary Content-Addressable Memory）功能来实现最长匹配搜索。

指示是否需要通过源地址和目标地址匹配来将入站IPsec流量映射到SA必须是手动SA配置的副作用之一，或者通过使用SA管理协议（如IKE或组域解释（GDOI：Group Domain of Interpretation）[RFC3547]）进行协商而设置的。通常，源特定组播（SSM：Source-Specific Multicast）[HC03]组使用由SPI、目标组播地址和源地址组成的3元组SA标识符。任意源组播组的SA仅需要SPI和目标组播地址作为标识符。

如果在同一个SA上发送不同类别的流量（通过区分服务代码点（DSCP：Differentiated Services Code Point）位[NiBlBaBL98]，[Gro02]进行区分），并且接收器正在使用AH和ESP中可用的可选的反重放功能，这可能导致由于该功能使用的窗口机制而不适当地丢弃低优先级的数据包。因此，发送方应该将不同类别但具有相同选择器值的流量放置在不同的SA上以适当支持服务质量（QoS：Quality of Service）。为了实现这一点，IPsec实现必须允许在给定的发送方和接收方之间建立和维护多个具有相同选择器的SA。在这些并行SA之间分配流量以支持QoS是由发送方在本地决定的，并且不是通过IKE进行协商。接收方必须无偏见地处理来自不同SA的数据包。这些要求适用于传输模式和隧道模式的SA。在隧道模式SA的情况下，有问题的DSCP值出现在内部IP头中。在传输模式下，DSCP值可能在传输过程中发生变化，但这不应该对IPsec处理产生问题，因为该值不用于SA选择，并且在SA/数据包验证的过程中不得进行检查。然而，如果在一个SA中发生了显著的数据包重排序，例如由于在传输过程中对DSCP值的更改，这可能会触发接收器通过应用反重放机制来丢弃数据包。

讨论：尽管差分服务代码点(DSCP)[NiBlBaBL98，Gro02]和显式拥塞通知(ECN)[RaFlBl01]字段不是该体系结构中所指的 "selectors"，但发送方需要一种机制将具有给定（一组）DSCP值的数据包引导到适当的安全关联(SA)。这种机制可能被称为 "分类器"。

正如上面所述，定义了两种SA类型：传输模式和隧道模式。IKE创建SA对，因此为简单起见，我们选择要求一对中的两个SA具有相同的模式，传输或隧道。

传输模式SA通常在一对主机之间使用，以提供端到端的安全服务。当希望在路径上两个中间系统之间提供安全性时（而不是IPsec的端到端时），可以在安全网关之间或安全网关和主机之间使用传输模式。在将传输模式用于安全网关之间或安全网关和主机之间时，可以使用传输模式支持传输模式SA上的IP内隧道（例如，IP-in-IP [Per96]或通用路由封装（GRE）隧道[FaLiHaMeTr00]或动态路由[ToEgWa04]）。需要澄清的是，只有当传输模式应用于源地址（对于出站数据包）或目标地址（对于入站数据包）属于中间系统本身的地址的数据包时，中间系统（例如安全网关）才允许使用传输模式。在这种情况下，IPsec的访问控制功能在很大程度上受到限制，因为它们不能应用于以这种方式使用的传输模式SA所遍历的数据包的端到端标头。因此，在特定环境中使用传输模式的这种方式应该经过仔细评估后再使用。

在IPv4中，传输模式安全协议头出现在IP头和任何选项之后，但在任何下一层协议（例如TCP或UDP）之前。在IPv6中，安全协议头出现在基本IP头和选定的扩展头之后，但可以出现在目标选项之前或之后；它必须出现在下一层协议（例如TCP、UDP、传输控制协议（SCTP））之前。在ESP的情况下，传输模式SA仅为这些下一层协议提供安全服务，而不是IP头或在ESP头之前的任何扩展头。在AH的情况下，保护范围还扩展到其前面的IP头的选定部分，扩展头的选定部分以及选定的选项（包含在IPv4头、IPv6 Hop-by-Hop extension头或IPv6 Destination extension头中）。关于AH提供的覆盖范围的更多细节，请参阅AH规范[Kan05b]。

隧道模式的安全关联（SA）本质上是应用于IP隧道的SA，其将访问控制应用于隧道内部流量的头部。两个主机可以在它们之间建立隧道模式的SA。除了下面的两个例外情况外，只要安全关联的任一端是安全网关，SA必须是隧道模式。因此，两个安全网关之间的SA通常是隧道模式的SA，主机和安全网关之间的SA也是如此。

如果流量的目的地是安全网关，例如简单网络管理协议（SNMP）命令，安全网关将充当主机，并允许使用传输模式。在这种情况下，SA终止于安全网关内的主机（管理）功能，因此需要不同的处理方式。
如上所述，安全网关可以支持传输模式SA，以为路径上的两个中间系统之间的IP流量提供安全性，例如在主机和安全网关之间或两个安全网关之间。

使用隧道模式来处理涉及安全网关的SA有几个原因。例如，如果有多条路径（例如通过不同的安全网关）到达安全网关后面的同一目标，那么将IPsec数据包发送到与SA协商的安全网关非常重要。同样，可能在传输过程中进行分片的数据包必须全部交付给同一IPsec实例以进行重组，然后再进行加密处理。此外，当片段经过IPsec处理和传输后再进行分片时，内部和外部头部必须存在以保留前IPsec数据包格式和后IPsec数据包格式的分片状态数据。因此，当SA的任一端是安全网关时，使用隧道模式有多个原因。（在使用传输模式配合IP-in-IP隧道时，也可以解决这些分片问题。然而，这种配置限制了IPsec对流量执行访问控制策略的能力。）

注意：AH和ESP在传输模式下无法应用于IPv4的分片数据包。在这种情况下只能使用隧道模式。对于IPv6，可以在传输模式SA中携带明文分片，但为简单起见，这个限制也适用于IPv6数据包。有关在IPsec屏障保护的一侧处理明文分片的详细信息，请参阅第7节。

对于隧道模式的SA，有一个“外部”IP头部来指定IPsec处理的源和目的地，并且还有一个“内部”IP头部来指定数据包的（表面上的）最终源和目的地。安全协议头部出现在外部IP头部之后，内部IP头部之前。如果在隧道模式下使用AH，外部IP头部的部分内容得到了保护（如上所述），同时隧道内的整个IP数据包也得到了保护（即内部IP头部以及下一层协议）。如果使用ESP，则只对隧道内的数据包进行保护，而不包括外部头部。

总结一下：

a）IPsec的主机实现必须同时支持传输模式和隧道模式。这对于主机的原生、BITS和BITW实现都是适用的。

b）安全网关必须支持隧道模式，可以支持传输模式。如果支持传输模式，那只应该在安全网关充当主机（例如用于网络管理）或为路径上的两个中间系统之间提供安全性时使用。

4.2. SA功能

SA提供的安全服务取决于所选的安全协议、SA模式、SA的端点以及协议内的可选服务选择。

例如，AH和ESP都提供完整性和认证服务，但每个协议的覆盖范围不同，并且在传输模式和隧道模式下也不同。如果在发送方和接收方之间必须保护IPv4选项或IPv6扩展头的完整性，AH可以提供此服务，但不能保护可能以发送方无法预测的方式更改的IP或扩展头。

然而，在某些情况下，通过将ESP应用到承载数据包的隧道中，可以实现相同的安全性。

提供的访问控制粒度取决于定义每个SA的选择器的选择。此外，IPsec对等方在创建IKE（vs. child）SA时使用的认证方式也会影响提供的访问控制的粒度。

如果选择了保密性，则两个安全网关之间的ESP（隧道模式）SA可以提供部分流量保密性。使用隧道模式可以加密内部IP头，隐藏（最终）流量源和目的地的身份。此外，还可以调用ESP负载填充来隐藏数据包的大小，进一步隐藏流量的外部特征。当移动用户在拨号上下文中被分配动态IP地址，并与公司防火墙（充当安全网关）建立（隧道模式）ESP SA时，也可以提供类似的流量保密性服务。请注意，细粒度的SA通常比承载来自许多用户的流量的粗粒度的SA更容易受到流量分析的攻击。

注意：符合规范的实现不能允许实例化同时使用NULL加密和无完整性算法的ESP SA。尝试协商此类SA是一个可审核的事件，由发起方和响应方都会记录审核日志。此事件的审核日志条目应包括当前日期/时间，本地IKE IP地址和远程IKE IP地址。发起方应记录相关的SPD条目。

4.3. 合并安全关联（SAs）

本文档不要求支持嵌套的安全关联或RFC 2401 [RFC2401]所称的“SA bundles”。通过适当配置SPD和本地转发功能（用于入站和出站流量），仍然可以实现这些功能，但这种能力超出了IPsec模块的范围，因此不在本规范的范围内。因此，管理嵌套/捆绑的SAs可能会更复杂，不如RFC 2401 [RFC2401]所暗示的模型那样可靠。支持嵌套SAs的实施应该提供一种管理接口，使用户或管理员能够表达嵌套要求，然后创建相应的SPD条目和转发表条目以实现必需的处理。（有关配置嵌套SAs的示例，请参见附录E。）

4.4. IPsec的主要数据库

在IPsec实现中处理IP流量的许多详细信息大多是本地事务，不受规范的约束。但是，必须对处理的某些外部方面进行标准化，以确保互操作性，并提供至关重要的最低限度管理能力，使IPsec能够得到有效使用。本节描述了一个相对于IPsec功能的IP流量处理的一般模型，以支持这些互操作性和功能性目标。下面描述的模型是名义上的；实现不需要与所提供的模型细节匹配，但是实现的外部行为必须符合模型的外部观察特征，以便符合规范。

这个模型有三个名义上的数据库：安全策略数据库（SPD：Security Policy Database）、安全关联数据库（SAD：Security Association Database）和对等授权数据库（PAD：Peer Authorization Database）。第一个指定决定从主机或安全网关入站或出站的所有IP流量的规则（第4.4.1节）。第二个数据库包含与每个已建立（加密）SA相关联的参数（第4.4.2节）。第三个数据库PAD提供了SA管理协议（如IKE）和SPD之间的链接（第4.4.3节）。

多个独立的IPsec上下文

如果一个IPsec实现作为多个订阅者的安全网关，它可以实现多个独立的IPsec上下文。每个上下文可以具有和使用完全独立的身份标识、策略、密钥管理SA和/或IPsec SA。这在很大程度上是一个本地实施问题。然而，需要一种将入站（SA）提议与本地上下文相关联的方法。为此，如果使用的密钥管理协议支持，上下文标识符可以在信令消息中从发起者传递给响应者，结果是创建与特定上下文绑定的IPsec SA。例如，一个为多个客户提供VPN服务的安全网关将能够将每个客户的流量与正确的VPN相关联。

转发与安全决策

在这里描述的IPsec模型体现了转发（路由）和安全决策之间的明确分离，以适应IPsec可能被应用的各种上下文。转发可能是简单的，例如只有两个接口的情况，或者可能是复杂的，例如如果实施IPsec的上下文使用了复杂的转发功能。IPsec只假定已通过IPsec处理的出站和入站流量是按照实施IPsec的上下文一致的方式进行转发的。对于嵌套的SA的支持是可选的；如果需要，需要在转发表和SPD条目之间进行协调，以使数据包多次穿越IPsec边界。

“本地”与“远程”

在本文中，对于IP地址和端口，术语“本地”和“远程”用于策略规则。“本地”指的是由IPsec实施保护的实体，即出站数据包的“源”地址/端口或入站数据包的“目的地”地址/端口。“远程”指的是对等实体或对等实体。术语“源”和“目的地”用于数据包头字段。

“非初始”与“初始”分段

在整个文档中，“非初始分段(non-initial fragments)”这一短语用于表示不包含用于访问控制的所有选择器值的分段（例如，它们可能不包含下一层协议、源和目的地端口、ICMP消息类型/代码、移动性标头类型）。而“初始分段(initial fragment)”这一短语用于表示包含所有用于访问控制所需选择器值的分段。然而，需要注意的是，对于IPv6而言，包含下一层协议和端口（或ICMP消息类型/代码或移动性标头类型[Mobip]）的分段将取决于存在的扩展标头的种类和数量。“初始分段”在这种情况下可能不是第一个分段。

4.4.1. 安全策略数据库（SPD）

SA是一个管理结构，用于执行IPsec边界上的安全策略。因此，SA处理的一个重要要素是底层的安全策略数据库（SPD），它指定了IP数据报应该提供的服务及其方式。数据库的形式和接口超出了本规范的范围。然而，本节指定了必须提供的最小管理功能，以允许用户或系统管理员控制主机发送或接收的流量是否以及如何应用IPsec，以及流经安全网关的流量。SPD，或相关的缓存，在处理所有流量（入站和出站）时必须进行查询，包括未受IPsec保护的流量，以及IPsec管理流量，如IKE。一个IPsec实现必须至少有一个SPD，并且如果适用于IPsec实现操作的上下文，则可以支持多个SPD。不需要在每个接口上维护SPD，如在RFC 2401 [RFC2401]中指定的那样。然而，如果一个实现支持多个SPD，那么它必须包括一个明确的SPD选择功能，用于选择适合出站流量处理的SPD。这个函数的输入是出站数据包和任何本地元数据（例如，数据包到达的接口），用于执行SPD选择功能。函数的输出是一个SPD标识符（SPD-ID）。

SPD是一个有序的数据库，与防火墙、路由器等中使用的访问控制列表（ACLs:Access Control Lists）或数据包过滤器一致。由于选择器的取值存在（non-trivial）范围，条目通常会重叠，所以需要排序。因此，用户或管理员必须能够对条目进行排序，以表达所需的访问控制策略。由于选择器值允许使用通配符，并且不同类型的选择器之间没有层次关系，所以无法对SPD条目强加一种通用的、规范的排序方式。

处理选择：丢弃（DISCARD）、绕过（BYPASS）、保护（PROTECT）

SPD必须对那些提供了IPsec保护和那些允许绕过IPsec的流量进行区分。这适用于发送方应用的IPsec保护和接收方必须具备的IPsec保护。对于任何出站或入站数据报，有三种处理选择：丢弃（DISCARD）、绕过IPsec（BYPASS）或使用IPsec进行保护（PROTECT）。第一种选择适用于不允许穿越IPsec边界的流量（在指定的方向上）。第二种选择适用于允许不经过IPsec保护而穿越IPsec边界的流量。第三种选择适用于提供IPsec保护的流量，对于这种流量，SPD必须指定要使用的安全协议、模式、安全服务选项和密码算法。

SPD-S, SPD-I, SPD-O

SPD-S, SPD-I, SPD-O 分别是安全策略数据库（SPD）的三个逻辑部分。

SPD-S（secure traffic）包含了所有需要进行 IPsec 保护的流量的条目。

SPD-O（outbound）包含了所有需要绕过(bypassed)或丢弃(discarded)的出站流量的条目。

SPD-I（inbound）应用于需要绕过或丢弃的入站流量。

这三个部分可以进行解耦，以便进行缓存。如果一个 IPsec 实现只支持一个 SPD，则该 SPD 包含了这三个部分。如果支持多个 SPD，则其中一些可能是部分的，例如某些 SPD 可能只包含 SPD-I 条目，用于基于每个接口控制入站绕过的流量。这种拆分允许在不必查阅 SPD-S 的情况下咨询 SPD-I，用于处理这种流量。由于 SPD-I 只是 SPD 的一部分，如果在 SPD-I 中没有找到与要查找的数据包相匹配的条目，则该数据包必须被丢弃。

需要注意的是，对于出站流量，如果在 SPD-S 中没有找到匹配项，则必须检查 SPD-O 来确定是否绕过该流量。同样地，如果首先检查了 SPD-O 并没有找到匹配项，则必须检查 SPD-S。在有序的、非解耦的 SPD 中，SPD-S、SPD-I 和 SPD-O 的条目是交叉的。因此，在 SPD 中只需要进行一次查找操作。

SPD 条目

每个 SPD 条目指定数据包的处理方式，可以是绕过（BYPASS）、丢弃（DISCARD）或保护（PROTECT）。该条目由一个或多个选择器的列表作为键进行标识。SPD 包含一个有序的条目列表。所需的选择器类型在4.4.1.1节中定义。这些选择器用于定义根据出站数据包或对等方的建议创建的安全关联（SA）的粒度。SPD 条目的详细结构在4.4.1.2节中描述。每个 SPD 应该有一个命名的最终条目，用于匹配任何未匹配的数据包并将其丢弃。

SPD 必须允许用户或管理员按以下方式指定策略条目：

SPD-I：对于需要绕过或丢弃的入站流量，条目由适用于要绕过或丢弃的流量的选择器的值组成。
SPD-O：对于需要绕过或丢弃的出站流量，条目由适用于要绕过或丢弃的流量的选择器的值组成。
SPD-S：对于需要使用 IPsec 保护的流量，条目由适用于通过 AH 或 ESP 进行保护的流量的选择器的值、基于这些选择器创建 SA 的控制以及实现此保护所需的参数（例如，算法、模式等）组成。注意，SPD-S 条目还包含信息如“从数据包填充”（PFP：populate from packet）标志（参见下文有关“如何导出 SAD 条目的值”的段落）和指示 SA 查询是否使用本地和远程 IP 地址以及 SPI 的位（参见 AH [Ken05b] 或 ESP [Ken05a] 规范）。

SPD 条目中表示流量的方向

对于受 IPsec 保护的流量，SPD 条目中的本地地址、远程地址和端口会被交换以表示流量的方向性，这与 IKE 约定一致。一般来说，IPsec 处理的协议通常需要具有对称的 SA，并且本地/远程 IP 地址会被翻转。然而，对于 ICMP，通常不存在这种双向授权要求。尽管如此，为了保持统一和简化，ICMP 的 SPD 条目与其他协议的规范方式相同。此外，对于 ICMP、Mobility Header和non-initial fragments，这些数据包中没有端口字段。ICMP 有消息类型和代码，Mobility Header有移动头类型。因此，SPD 条目具备适用于这些协议的访问控制规定，用来替代普通的端口字段控制。对于绕过或丢弃的流量，支持单独的入站和出站条目，例如，如果需要允许单向流则可以使用这些条目。

OPAQUE and ANY在 SPD 条目中的每个选择器中，除了定义匹配的字面值之外，还有两个特殊值：ANY 和 OPAQUE。ANY 是一个通配符，可以匹配数据包相应字段中的任何值，或者匹配字段不存在或被模糊化的数据包。OPAQUE 表示相应的选择器字段不可用于检查，因为它可能在片段中不存在，在给定的下一层协议中不存在，或者之前应用的 IPsec 可能已经加密了该值。ANY 值包括 OPAQUE 值。因此，只有在需要区分字段是否有值时，才需要使用OPAQUE，以区分字段是否没有值或不可用(例如，由于加密)。

如何获取SAD条目的值

对于 SPD 条目中的每个选择器，该条目指定如何从 SPD 和数据包中派生相应的值，以创建新的 SA 数据库（SAD）条目。目标是允许根据数据包中的特定选择器值或匹配的 SPD 条目来创建 SAD 条目和 SPD 缓存条目。对于出站流量，有 SPD-S 缓存条目和 SPD-O 缓存条目。对于未受 IPsec 保护的入站流量，有 SPD-I 缓存条目和 SAD，它表示入站受 IPsec 保护流量的缓存。如果为条目指定了 IPsec 处理，则可以对 SPD 条目中的一个或多个选择器（Local IP address;Remote IP address; Next Layer Protocol; and, depending on Next Layer Protocol, Local port and Remote port, or ICMP type/code, or Mobility Header type）断言“从数据包填充”（PFP）标志。如果对于给定的选择器 X 断言了该标志，则表示创建的 SA 应该从数据包中的 X 选择器的值中取值。否则，SA 应该从 SPD 条目中的 X 选择器的值中取值。注意：在非-PFP 情况下，由 SA 管理协议（例如 IKEv2）协商的选择器值可能是 SPD 条目中的子集，取决于对等方的 SPD 策略。此外，用于源端口、ICMP 类型/代码和移动性头（MH）类型的标志是使用单个标志还是分别使用标志是由本地决定的事项。

下面的示例说明了在安全网关或BITS/BITW实现中使用PFP标志的情况。

考虑一个SPD条目，其中远程地址的允许值是一个IPv4地址范围：192.0.2.1到192.0.2.10。假设一个出站数据包的目标地址是192.0.2.3，并且不存在用于传输此数据包的SA。根据SPD条目对选择器值源的定义，用于传输此数据包的SA的值可能是下面两个值中的任意一个：

请注意，如果上面的SPD项对远程地址有ANY值，那么对于case (b)， SAD选择器的值必须是ANY，但对于case (a)仍然是如图所示的值。因此，可以使用PFP标志来禁止共享SA，即使是在匹配相同SPD项的分组之间。

管理接口

对于每个IPsec实现，都必须有一个管理接口（management interface），允许用户或系统管理员管理SPD。该接口必须允许用户（或管理员）指定应用于每个穿越IPsec边界的数据包的安全处理。在使用套接字接口的本地主机IPsec实现中，可能不需要按数据包进行每个数据包的SPD查询，如第4.4.1.1节末尾和第5节所述。SPD的管理接口必须允许创建与第4.4.1.1节中定义的选择器一致的条目，并且必须支持通过此接口查看这些条目的（总体）排序。SPD条目的选择器类似于在无状态防火墙或数据包过滤路由器中常见的ACL或数据包过滤器，目前通过此方式进行管理。

在主机系统中，应用程序可以被允许创建SPD条目。（将此类请求传递给IPsec实现的方法超出了本标准的范围。）但是，系统管理员必须能够指定用户或应用程序是否可以覆盖（默认）系统策略。本文档未指定管理接口的形式，并且主机与安全网关之间可能有所不同，在主机中，套接字基础和BITS实现之间的接口可能会有所不同。但是，本文档确实指定了所有IPsec实现必须支持的标准SPD元素集。

解耦（Decorrelation）

本文档中描述的处理模型假定能够将重叠的SPD条目解耦以允许缓存，这使得能够在安全网关和BITS/BITW实现中更有效地处理出站流量。解耦[CoSa04]只是一种提高性能和简化处理描述的手段。该RFC不需要兼容的实现来使用解耦。例如，本机主机实现通常隐式地利用缓存，因为它们将SAs绑定到套接字接口，因此不需要能够在这些实现中解除SPD条目的关联。

注意：除非另有限定，否则“SPD”的使用指的是有序或解耦（无序）状态下的策略信息体。附录B提供了一个可用于解耦SPD条目的算法，但可以使用任何产生等效输出的算法。请注意，当一个SPD条目解耦后，所有产生的条目都必须链接在一起，以便同一组派生自一个单独的SPD条目（在解耦之前）的成员都可以同时放入缓存和SAD中。例如，假设从有序SPD开始获得一个条目A，在解耦后，会产生条目A1、A2和A3。当一个匹配A2的数据包出现时，触发创建一个SA，SA管理协议（如IKEv2）将协商A。并且所有3个解耦的条目A1、A2和A3都将放置在适当的SPD-S缓存中，并链接到SA。旨在使用解耦的SPD不会创建比使用非解耦SPD更多的SA。

如果使用了解耦的 SPD，向对等方通过 SA 管理协议（例如 IKE）发送的内容有三个选项。一种选择是发送从 SPD 中选择的完整一组链接的解耦条目，这样对等方可以获得最佳信息，以便在其端选择适当的 SPD 条目，尤其是如果对等方也解耦了其 SPD。然而，如果链接了大量解耦的条目，这可能会导致用于 SA 协商的数据包变得很大，并且可能引发 SA 管理协议的分段问题。

另一种选择是保留来自关联的 SPD 的原始条目，并将其传递给 SA 管理协议。传递关联的 SPD 条目可以使使用解耦的 SPD 成为一个本地问题，对对等方不可见，并避免可能的分段问题，尽管对于匹配响应方的 SPD 来说，提供的信息相对较少。

一种中间方法是发送完整一组链接的解耦 SPD 条目的子集。这种方法可以避免上述提到的分段问题，同时提供比原始的关联条目更好的信息。这种方法的主要缺点是，它可能导致以后创建额外的 SA，因为只向对等方发送了链接的解耦条目的子集。实现者可以自由选择以上任何一种方法。

响应方使用通过 SA 管理协议收到的流量选择器提案来选择其 SPD 中的适当条目。匹配的目的是选择一个 SPD 条目并创建一个最能符合发起方意图的 SA，以使通过所得的 SA 的流量在两端都被接受。如果响应方使用了解耦的 SPD，则应使用解耦的 SPD 条目进行匹配，因为这通常会导致创建更容易符合双方意图的 SA。如果响应方有关联的 SPD，则应对提案与关联条目进行匹配。对于 IKEv2，使用解耦的 SPD 为响应方提供了生成“缩小”的响应的最佳机会。

在所有情况下，当解耦（decorrelated）的 SPD 可用时，解耦的条目用于填充 SPD-S 缓存。如果 SPD 没有解耦，不允许缓存，并且必须执行 SPD 的有序搜索以验证到达 SA 上的入站流量是否与 SPD 中表达的访问控制策略一致。

在系统运行时处理SPD的更改

如果在系统运行时对SPD进行了更改，则应检查此更改对存在的SA的影响。实施应该检查SPD更改对现存SA的影响，并应该为用户/管理员提供一种配置操作的机制，例如删除受影响的SA，允许受影响的SA继续保持不变等。

4.4.1.1 选择器（Selectors）

一种安全关联（Security Association，SA）可以细粒度或粗粒度，这取决于用于定义该SA的流量集合的选择器。例如，两个主机之间的所有流量可以通过单个SA进行传输，并提供统一的安全服务。另一方面，取决于所使用的应用程序（由下一层协议和相关字段定义，例如端口），一对主机之间的流量可能分布在多个SA上，不同的SA提供不同的安全服务。类似地，一对安全网关之间的所有流量可以通过单个SA进行传输，或者每个通信主机对可以分配一个SA。为了便于控制SA的粒度，所有IPsec实现都必须支持以下选择器参数。请注意，本地地址和远程地址应该是IPv4或IPv6，而不是地址类型混合。另外，请注意，本地/远程端口选择器（以及ICMP message type and code, and Mobility Header type）可能被标记为OPAQUE，以适应由于报文分段而无法访问这些字段的情况。

远程IP地址（IPv4或IPv6）：这是一个IP地址范围（单播，广播（仅限IPv4））的列表。该结构允许表达单个IP地址（通过一个简单的范围），或者一组地址（每个都是一个简单的范围），或者一组地址（包括低值和高值），以及最通用形式的范围列表。地址范围用于支持多个共享相同SA的远程系统，例如，在安全网关后面。
本地IP地址（IPv4或IPv6）：这是一个IP地址范围（单播，广播（仅限IPv4））的列表。该结构允许表达单个IP地址（通过一个简单的范围），或者一组地址（每个都是一个简单的范围），或者一组地址（包括低值和高值在内），以及最通用形式的范围列表。地址范围用于支持多个共享相同SA的源系统，例如，在安全网关后面。本地指的是由此实现（或策略条目）保护的地址。

注意：SPD不包括对多播地址条目的支持。为了支持多播SA，实现应该使用在[RFC3740]中定义的组策略数据库（GSPD：Group SPD）。GSPD条目需要不同的结构，即在多播环境中不能使用与单播SA中本地和远程地址值相关的对称关系。具体而言，对于在SA上定向到多播地址的出站流量，不会在多播地址作为源的伴随入站SA上接收到。
下一层协议（Next Layer Protocol）：从IPv4的"Protocol"字段或IPv6的"Next Header"字段获得。这是一个独立的协议号，可以是ANY，或者只适用于IPv6的OPAQUE。下一层协议是出现在任何存在的IP扩展头后面的内容。为了简化查找下一层协议，应该有一种机制来配置要跳过的IPv6扩展头。默认配置应该包括跳过以下协议：0 (Hop-by-hop options), 43 (Routing Header), 44 (Fragmentation Header), and 60 (Destination Options)。注意：默认列表不包括51（AH）或50（ESP）。对于选择器查找来说，IPsec将AH和ESP视为下一层协议。

还有一些额外的选择器依赖于下一层协议的值：
- SPD缓存条目中的本地地址
- 出站SAD条目中的本地地址
- 入站SAD条目中的远程地址
- Name：这不是与上面的其他选择器一样。它不是从数据包中获取的。名称可以用作IPsec本地或远程地址的符号标识符。命名的SPD条目有两种使用方式：
  
  SPD条目可以同时包含名称（或名称列表）和本地或远程IP地址的值。对于响应方（案例1），命名的SPD条目中使用的标识符是以下四种类型之一：
  
  a. 完全限定的用户名称字符串（电子邮件），例如，mozart@foo.example.com（这相当于IKEv2中的ID_RFC822_ADDR）
  
  b. 完全限定的DNS名称，例如，foo.example.com（这相当于IKEv2中的ID_FQDN）
  
  c. X.500可分辨名称，例如，[WaKiHo97]，CN = Stephen T. Kent，O = BBN Technologies，SP = MA，C = US（在解码后，这相当于IKEv2中的ID_DER_ASN1_DN）
  
  d. 字节字符串（这相当于IKEv2中的Key_ID）
  
  对于发起方（案例2），命名的SPD条目中使用的标识符是字节字符串类型。它们可能是Unix UID、Windows安全ID或类似的内容，但也可能是用户名称或账户名称。无论哪种情况，此标识符仅在本地关注，不会被传输。
- 如果下一层协议使用两个端口（例如TCP、UDP、SCTP等），则有本地端口和远程端口选择器。每个选择器都有一个值范围列表。请注意，在接收到分段数据包的情况下，本地端口和远程端口可能不可用，或者如果端口字段受IPsec保护（加密），那么必须支持OPAQUE的值。注意：在非初始分段中，端口值将不可用。如果端口选择器指定的值不是ANY或OPAQUE，则不能匹配非初始分段的数据包。如果SA需要端口值而不是ANY或OPAQUE，则必须丢弃没有端口的到达分段数据包（请参阅第7节“处理分段”）。
- 如果下一层协议是Mobility Header，则有一个IPv6 Mobility Header消息类型（MH type）选择器[Mobip]。这是一个8位的值，用于标识特定的移动性消息。请注意，在接收到分段数据包的情况下，可能无法使用MH类型（请参阅第7节“处理分段”）。对于IKE，IPv6 Mobility Header消息类型（MH type）放置在16位本地“端口”选择器的最高8位中。
- 如果下一层协议值是ICMP，则有一个16位的选择器用于ICMP消息类型和代码。消息类型是一个8位值，它定义了ICMP消息的类型，或者是ANY。ICMP代码是一个8位值，为ICMP消息定义了一个特定的子类型。对于IKE，消息类型放置在16位选择器的最高8位中，代码放置在最低8位中。这个16位选择器可以包含单个类型和代码范围、单个类型和任意代码，以及任意类型和任意代码。假设有一个范围为类型(T-start到T-end)和代码(C-start到C-end)的策略条目，以及一个具有类型t和代码c的ICMP数据包，请实施时必须使用下面的规则进行匹配测试：
  
  (T-start256) + C-start <= (t256) + c <= (T-end*256) + C-end
  
  请注意，在接收到分片数据包的情况下，ICMP消息类型和代码可能不可用（请参阅第7节“处理分片”）。
1. 一种命名的SPD条目被响应方（而不是发起方）用于支持访问控制，当IP地址对于远程IP地址选择器不合适时，例如对于“road warriors”。用于匹配此字段的名称是在IKE协商期间通过ID载荷进行通信的。在此上下文中，发起方的源IP地址（隧道模式下的内部IP头）将绑定到由IKE协商创建的SAD条目中的远程IP地址上。当以此方式选择了SPD条目时，此地址将覆盖SPD中的远程IP地址值。所有IPsec实现都必须支持这种名称的使用方式。
2. 发起方可以使用命名的SPD条目来识别将为其创建IPsec SA的用户（或绕过其流量的用户）。发起方的IP源地址（来自隧道模式下的内部IP头）将用于在创建以下内容时替换它们：
  
  对于多用户本机主机实现，支持此用途是可选的，对于其他实现则不适用。请注意，此名称仅在本地使用；它不是通过密钥管理协议进行通信的。此外，在发起方上下文中适用于除响应方（用于案例1）以外的其他名称形式（请参见下文）。

IPsec实现的上下文决定了选择器的使用方式。例如，本地主机实现通常会使用套接字接口。当建立新连接时，可以查询SPD并将SA绑定到套接字上。因此，通过该套接字发送的流量不需要对SPD（SPD-O和SPD-S）缓存进行额外的查找。相比之下，BITS、BITW或安全网关实现需要检查每个数据包，并根据选择器执行SPD-O/SPD-S缓存查找。

4.4.1.2. SPD条目结构

本节包含了对一个SPD项的简单描述。此外，附录C提供了SPD项的ASN.1定义的示例。

该文本以一种旨在直接映射到IKE有效负载的方式描述了SPD，以确保通过IKE可以协商到SPD条目所需的策略。不幸的是，与本文同时发布的IKEv2版本[Kau05]的语义与SPD的定义并不完全一致。具体而言，IKEv2不支持协商将多对本地和远程地址和端口绑定到单个SA的单一SA。相反，当针对一个SA协商多个本地和远程地址和端口时，IKEv2将其视为（无序）的本地和远程值集合，可以任意匹配组合。除非访问控制意图与IKE的"混合和匹配"语义一致，否则在单个SPD条目中，用户不得包含多个选择器集合，直到IKE提供了传达通过选择器集合表达的SPD语义的功能（如下所述）。如果用户创建了具有多个选择器集合的SPD条目，并且其语法表明可能与当前IKE语义存在冲突，实现可以向用户发出警告，提醒他们这个问题。

管理GUI可以为用户提供其他形式的数据输入和显示，例如使用地址前缀、符号名称代替协议、端口等。请注意，管理界面中使用符号名称与SPD选择器中的“名称”选项不要混淆。请注意，Remote/Local仅适用于IP地址和端口，而不适用于ICMP消息类型/代码或Mobility Header类型。此外，如果给定选择器类型使用了保留的符号选择器值OPAQUE或ANY，则该选择器列表中只能出现该值，并且该值只能在该选择器的列表中出现一次。请注意，ANY和OPAQUE是本地语法约定 - IKEv2通过下面指示的范围协商这些值：

ANY: 	start = 0 		end = <max>
OPAQUE: start = <max> 	end = 0

SPD是一个有序的条目列表，每个条目包含以下字段。

Name -- 一个ID列表。这个伪选择器是可选的。必须支持的形式在上面的章节4.4.1.1中以“Name”为标题进行了描述。
PFP flags -- 每个流量选择器一个。给定的标志(例如，用于下一层协议的标志)适用于SPD项中包含的所有“选择器集”(见下文)的相关选择器。在创建SA时，每个标志为相应的流量选择器指定了是从触发SA创建的分组中的相应字段实例化选择器，还是从相应SPD条目中的值实例化选择器(参见4.4.1节，“如何获取SAD条目的值”)。例如，源端口、ICMP类型/代码和MH类型是使用一个标志，还是分别使用一个标志，这是一个本地问题。有以下PFP标志:
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
- Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
一个到N选择器集，对应于应用特定IPsec操作的“条件”。每个选择器集包含以下内容：

注意：在选择器集条目中，“next protocol”选择器是一个单独的值（不像本地和远程IP地址）。这与IKEv2协商SA的流量选择器（TS：Traffic Selector）值的方式保持一致。这也是有道理的，因为可能需要将不同的端口字段与不同的协议关联起来。通过为该SA指定多个选择器集，可以将多个协议（和端口）与单个SA关联起来。
- Local Address
- Remote Address
- Next Layer Protocol
- Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
- Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
处理信息 - 需要哪种操作 - PROTECT、BYPASS或DISCARD。每个选择器集只有一个与之对应的操作，而不是每个集合都有一个单独的操作。如果所需的处理是PROTECT，该条目包含以下信息：
- IPsec模式——隧道模式或传输模式
- （如果是隧道模式）本地隧道地址 —— 对于非移动主机，如果只有一个接口，这很直接；如果有多个接口，则必须静态配置。对于移动主机，指定本地地址的规范是由IPsec外部处理的。
- （如果是隧道模式）远程隧道地址 —— 没有标准的确定方法。请参见4.5.3节“查找安全网关”。
- 扩展序号——该SA是否使用扩展序号（extended sequence numbers）？
- 状态分片检查 —— 该SA是否使用状态分片检查？（有关详细信息，请参见第7节。）
- 绕过DF位（T/F）—— 适用于隧道模式SA
- 绕过DSCP（T/F）或映射到未受保护的DSCP值（数组），如果需要限制绕过的DSCP值 —— 适用于隧道模式SA
- IPsec协议——AH或ESP
- 算法——AH使用哪些算法，ESP使用哪些算法，组合模式使用哪些算法，按优先级递减顺序排序

当SPD（安全策略数据库）发生更改时，关于处理现有SA（安全关联）的信息是本地事务。

4.4.1.3. 关于与下一层协议相关的字段的更多信息

附加选择器通常与下一层协议头（Next Layer Protocol header）中的字段相关联。特定的下一层协议可能有零个、一个或两个选择器。可能存在这样的情况，即与下一层协议相关的字段没有本地和远程选择器。IPv6 Mobility Header只有一个Mobility Header消息类型。AH和ESP没有进一步的选择器字段。系统可能愿意发送不想接收的ICMP消息类型和代码。在下面的描述中，“端口”用于表示与下一层协议相关的字段。

A. 如果下一层协议没有“端口”选择器，那么在相关的SPD条目中，本地和远程的“端口”选择器设置为OPAQUE，例如：

Local’s
next layer protocol = AH
"port" selector = OPAQUE

Remote’s
next layer protocol = AH
"port" selector = OPAQUE

B. 即使下一层协议只有一个选择器，例如Mobility Header类型，本地和远程的“端口”选择器也用于指示系统是否愿意发送和/或接收具有指定“端口”值的流量。例如，如果允许通过SA发送和接收指定类型的Mobility Header，则相应的SPD条目将设置如下：

Local’s
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

Remote’s
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

如果允许通过SA发送但不接收指定类型的Mobility Headers，则相应的SPD条目将设置如下：
Local’s
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

Remote’s
next layer protocol = Mobility Header
"port" selector = OPAQUE

如果允许通过SA接收但不发送指定类型的Mobility Headers，则相应的SPD条目将设置如下：
Local’s
next layer protocol = Mobility Header
"port" selector = OPAQUE

Remote’s
next layer protocol = Mobility Header
"port" selector = Mobility Header message type

C. 如果系统愿意发送具有特定“端口”值的流量，但不愿意接收该类型端口值的流量，则系统的流量选择器在相关的SPD条目中设置如下：

Local’s
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>

Remote’s
next layer protocol = ICMP
"port" selector = OPAQUE

D. 为指示系统愿意接收具有特定“端口”值的流量，但不愿意发送该类型流量，系统的流量选择器在相关的SPD条目中设置如下：

Local’s
next layer protocol = ICMP
"port" selector = OPAQUE

Remote’s
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>

例如，如果安全网关愿意允许其后面的系统发送 ICMP traceroutes，但不愿意让外部系统对其后面的系统进行 ICMP traceroutes，则安全网关的流量选择器在相关的 SPD 条目中设置如下：

Local’s
next layer protocol = 1 (ICMPv4)
"port" selector = 30 (traceroute)

Remote’s
next layer protocol = 1 (ICMPv4)
"port" selector = OPAQUE

4.4.2. 安全关联数据库（SAD）

在每个IPsec实现中，都有一个名义上的安全关联数据库(Security Association Database, SAD)，其中每个条目定义了与一个SA相关联的参数。每个SA在SAD中都有一个条目。对于出站处理，每个SAD项都由SPD- s部分的SPD- s项指向。对于入站处理，对于单播SA, SPI要么单独用于查找SA，要么与IPsec协议类型一起使用。如果IPsec实现支持组播，则使用SPI +目的地址或SPI +目的地址和源地址来查找安全联盟。(入站IPsec数据报映射到SAs时必须使用的算法请参见4.1节。)以下参数与SAD中的每个条目相关联。它们都应该存在，除非另有说明，例如AH认证算法。本描述并不是一个MIB，只是一个在IPsec实现中支持SA所需的最小数据项的规范。

根据第4.4.1.1节中定义的选择器，SAD中入站SA的条目必须使用创建SA时协商的值进行初始填充。（有关在系统运行时处理SPD更改对现有SA的影响的指导，请参阅第4.4.1节中“处理SPD更改时的影响”一段。）对于接收者，这些值用于检查入站数据包（经过IPsec处理后）的头字段是否与为SA协商的选择器值匹配。因此，SAD用作检查到达SA的入站流量的选择器的缓存。对于接收者，这是验证到达SA的数据包是否与SA的策略一致的一部分。（有关ICMP消息的规则，请参阅第6节。）这些字段可以采用特定值、范围、ANY或OPAQUE的形式，如第4.4.1.1节“选择器”中所述。还要注意，有几种情况下，SAD可以具有没有对应SPD条目的SA的条目。由于本文档没有要求在更改SPD时选择性地清除SAD，因此当更改或删除创建它们的SPD条目时，SAD条目可以保留。此外，如果创建了手动密钥的SA，则可能存在与该SA对应的SAD条目，但没有相应的SPD条目。

注意：如果手动配置，SAD可以支持组播SA。出站组播SA的结构与单播SA相同。源地址是发送者的地址，目的地址是组播组地址。入站组播SA必须配置每个已被授权向该组播SA传输数据的对等方的源地址。组播SA的SPI值由组播组控制器提供，而不是像单播SA一样由接收方提供。由于一个SAD条目可能需要容纳多个单独的IP源地址，这些地址是SPD条目的一部分（用于单播SA），因此入站组播SA所需的设施是IPsec实现中已经存在的功能。但是，由于SPD没有为容纳组播条目提供保障，因此本文档没有指定自动创建入站组播SA的SAD条目的方式。只能手动配置SAD条目以容纳入站组播流量。

实施指南：本文档未指定SPD-S条目如何引用相应的SAD条目，因为这是与实现相关的细节。然而，已知某些实现（基于RFC 2401的经验）在这方面存在问题。特别是，仅仅将（远程隧道头部IP地址，远程SPI）对存储在SPD缓存中是不够的，因为该对并不总是唯一标识单个SAD条目。例如，两个位于同一NAT后面的主机可能选择相同的SPI值。如果某个主机被分配了之前某个其他主机使用过的IP地址（例如通过DHCP），而旧主机关联的SA尚未通过 dead peer 检测机制进行删除，也可能出现这种情况。这可能导致数据包通过错误的SA发送，或者如果密钥管理确保该对是唯一的，拒绝创建其他有效的SA。因此，实施者应该以一种不会引发此类问题的方式在SPD缓存和SAD之间建立连接。

4.4.2.1. SAD中的数据项

SAD必须包含以下数据项:

安全参数索引（Security Parameter Index，SPI）: 32位的值，由SA的接收端选择用于唯一标识该SA。在SAD条目中，对于一个出站SA，SPI用于构建数据包的AH或ESP头。对于一个入站SA的SAD条目，SPI用于将流量映射到相应的SA（请参见第4.1节中关于单播/组播的内容）。
序列号计数器（Sequence Number Counter）: 一个64位计数器，用于生成AH或ESP头中的序列号字段。默认情况下使用64位序列号，但如果经协商也支持32位序列号。
序列计数器溢出（Sequence Counter Overflow）: 一个标志，计表示序号计数器溢出是否产生可审计事件，并阻止SA上传输额外数据包，或者是否允许滚转。此事件的审计日志条目应该包括SPI值、当前日期/时间、本地地址、远程地址和来自相关SAD条目的选择器。
反重放窗口（Anti-Replay Window）: 一个64位计数器和位图（或等效物）用于确定入站AH或ESP数据包是否为重放。注意: 如果接收方已为一个SA禁用了反重放功能，例如在手动键入的SA的情况下，那么对于该SA，将忽略反重放窗口。默认情况下使用64位序列号，但该计数器大小也支持32位序列号。
AH身份验证算法、密钥等。仅在支持AH时才需要提供这些信息。
ESP加密算法、密钥、模式、初始化矢量等。如果使用了组合模式算法，则这些字段将不适用。
ESP完整性算法、密钥等。如果未选择完整性服务，则这些字段将不适用。如果使用了组合模式算法，则这些字段将不适用。
ESP组合模式算法、密钥等。当使用ESP的组合模式（加密和完整性）算法时，使用这些数据。如果未使用组合模式算法，则这些字段不适用。
SA的生存期（Lifetime of this SA）：在此时间间隔后，必须使用新的SA（和新的SPI）替换或终止此SA，并指示应执行哪种操作。可以将其表示为时间或字节计数，或者同时使用两者，以即将到期的生存期优先。符合规范的实现必须支持这两种生存期类型，并且必须支持同时使用两者。如果选择时间作为生存期，并且在IKE中使用X.509证书进行SA建立，SA的生存期必须受证书的有效期限和在IKE交换中用于SA的证书吊销列表（CRLs）的NextIssueDate的限制。发起方和响应方都有责任以这种方式限制SA的生存期。注意：当SA过期时如何处理密钥更新的详细方法是一个本地事务。然而，一个合理的方法是：
- (a) 如果使用字节计数，那么实现应该计算应用了IPsec加密算法的字节数。对于ESP来说，这是加密算法（包括Null加密），对于AH来说，这是认证算法。这包括填充字节等。请注意，实现必须能够处理SA两端的计数器不同步的情况，例如由于数据包丢失或由于SA两端的实现方式不同。
- (b) 应该有两种生存期——一个软生存期，在此期间实现应该发出警告并采取行动，例如建立替代的SA；另一个是硬生存期，表示当前的SA到期并被销毁。
- (c) 如果整个数据包在SA的生存期内无法传递，则应该丢弃该数据包。
IPsec协议模式：隧道或传输。指示在此SA上应用AH或ESP的哪种模式。
状态性片段检查标志（Stateful fragment checking flag）。指示是否应用状态性片段检查于此SA。
Bypass DF bit (T/F)——适用于隧道模式下内部和外部头都为IPv4的SA。
DSCP值——允许通过此SA传输的数据包使用的一组DSCP值。如果未指定任何值，则不应用特定于DSCP的过滤。如果指定了一个或多个值，则用于在多个与出站数据包的流量选择器匹配的SA中选择一个。请注意，这些值不会与到达SA的入站流量进行检查。
Bypass DSCP (T/F)或将其映射为未保护的DSCP值（数组），以限制绕过DSCP值的情况——适用于隧道模式的SA。此功能将内部头的DSCP值映射到外部头的值，例如，以解决隐蔽信道信号的问题。
路径MTU：任何观察到的路径MTU和老化变量。
隧道头部的IP源地址和目标地址——这两个地址必须是IPv4或IPv6地址。版本决定要使用的IP头类型。仅在IPsec协议模式为隧道时使用。

4.4.2.2. SPD、PFP标志、数据包和SAD之间的关系

对于每个选择器，下表显示了SPD中的值、PFP标志、触发数据包中的值以及SAD中的结果值之间的关系。请注意，IPsec的管理界面可以使用各种语法选项，使管理员更轻松地输入规则。例如，虽然IKEv2发送的是一个范围的列表，但用户输入单个IP地址或IP地址前缀可能更清晰且更少出错。

如果协议需要两个端口，那么就需要分别设定本地端口和远程端口的选择器。

如果协议是移动性头（mobility header），那么就需要设置mh类型的选择器。

如果协议是ICMP，那么就需要一个 16 位的选择器来设置 ICMP 类型和 ICMP 代码。请注意，类型和代码是相互绑定的，即代码适用于特定类型。这个 16 位的选择器可以包含单个类型和一系列代码、单个类型和任意代码以及任意类型和任意代码。

如果使用名称选择器：

4.4.3. 对等授权数据库 (PAD)

对等授权数据库 (PAD:Peer Authorization Database) 提供了安全策略数据库 (SPD) 和诸如 IKE 这样的安全关联管理协议之间的链接。它具有几个关键功能：

标识被授权与此 IPsec 实体进行通信的对等方或对等方组。
指定用于对每个对等方进行身份验证的协议和方法。
提供每个对等方的身份验证数据。
限制对等方在创建子安全关联时可以断言的 ID 类型和值，以确保对等方不会在创建子安全关联时为 SPD 中未被授权代表的身份进行查找断言。
可以包括已知存在于安全网关“后方”的对等方的对等网关位置信息，例如 IP 地址或 DNS 名称。

当对等方作为发起方或响应方时，PAD为IKE对等方提供这些功能。

为了实现这些功能，PAD中包含每个要与IPsec实体通信的对等方或对等方组的条目。条目可以命名一个单独的对等方（用户、终端系统或安全网关），或者指定一组对等方（使用下面定义的ID匹配规则）。条目指定所使用的身份验证协议（例如，IKEv1、IKEv2、KINK）方法（例如，证书或预共享密钥）和身份验证数据（例如，预共享密钥或与对等方的证书进行验证的信任锚点）。对于基于证书的身份验证，条目还可以提供信息以帮助验证对等方的吊销状态，例如指向CRL存储库的指针或与对等方或与对等方相关的信任锚点相关的在线证书状态协议（OCSP）服务器的名称。

每个条目还指定了是否将使用IKE ID有效载荷作为SPD查找的符号名称，或者在创建子SA时是否将使用在流量选择器有效载荷中提供的远程IP地址进行SPD查找。

请注意，PAD信息可以用于支持在两个对等方之间同时创建多个隧道模式SA，例如，保护相同地址/主机的两个隧道，但具有不同的隧道端点。

4.4.3.1. PAD条目ID和匹配规则

PAD是一个有序的数据库，其中的顺序由管理员（或在单用户终端系统的情况下是用户）定义。通常，同一个管理员将负责PAD和SPD，因为这两个数据库必须进行协调。PAD的排序要求出现的原因与SPD相同，即由于使用“star name”条目可能导致IKE ID集合中的重叠，因此需要排序。

PPAD中支持六种类型的ID，与用于标识SPD条目的符号名称类型和IP地址保持一致。每个条目的ID充当PAD的索引，即用于选择一个条目的值。所有这些ID类型都可用于匹配IKE ID有效载荷类型。这六种类型为：

DNS名称（特定或部分）
区分名称（完整或子树约束）
RFC 822电子邮件地址（完整或部分限定）
IPv4地址（范围）
IPv6地址（范围）
密钥ID（仅精确匹配）

前三种名称类型可以容纳子树匹配和精确匹配。DNS名称可能是完全限定的，因此准确匹配一个名称，例如foo.example.com。或者，名称可以通过部分指定来包含一组对等方，例如字符串“.example.com”可用于匹配以这两个域名组件结尾的任何DNS名称。

同样地，区分名称（Distinguished Name）可以指定一个完整的区分名称来准确匹配一个条目，例如CN = Stephen, O = BBN Technologies, SP = MA, C = US。或者，一个条目可以通过指定一个子树来包含一组对等方。例如，形式为C = US, SP = MA的条目可以用来匹配包含这两个属性作为顶部两个相对区分名称（Relative Distinguished Name，简称RDN）的所有区分名称。

对于RFC 822电子邮件地址，同样存在相同的选项。一个完整的地址，例如foo@example.com，匹配一个实体，但一个子树名称，例如@example.com，可以用来匹配所有以@右边的这两个域名为结尾的实体。

用于适应区分名称、域名或RFC 822电子邮件地址的子树匹配的具体语法是本地问题。但是，至少必须支持上述描述的子树匹配方式。（可以支持区分名称、域名或RFC 822地址内的子字符串匹配，但不是必需的。）

对于IPv4和IPv6地址，必须支持用于SPD条目的同一地址范围语法。这允许通过微不足道的范围来指定单个地址（通过微不足道的范围），通过选择遵循无类别域间路由（CIDR）样式前缀的范围来指定地址前缀，或者指定任意地址范围。

密钥ID字段在IKE中被定义为一个八位字节字符串。对于此名称类型，只必须支持完全匹配的语法（因为对于此ID类型没有明确的结构）。可以支持此ID类型的附加匹配功能。

4.4.3.2. IKE对等方认证数据

在基于ID字段匹配的PAD顺序搜索中找到条目后，需要验证所声明的身份，即验证所声明的ID。对于每个PAD条目，都有指示要执行的认证类型。本文档要求支持两种所需的认证数据类型：

X.509证书
预共享密钥

对于基于X.509证书的认证，PAD条目包含一个信任锚点，通过该锚点，必须能够验证对等方的终端实体（EE:end entity）证书，可以直接验证，或者通过证书路径验证。有关信任锚点的定义，请参见RFC 3280。与基于证书的认证一起使用的条目可以包括额外的数据，以便于证书吊销状态，例如适当的OCSP响应者或CRL存储库列表，以及相关的认证数据。对于基于预共享(pre-shared)密钥的认证，PAD包含用于IKE的预共享密钥。

本文档并不要求由对等方断言的 IKE ID 在语法上与用于验证对等方身份的终端实体证书中的特定字段相关联。然而，在许多情况下，施加这样的要求是合适的，例如，当单个条目代表一组可能具有不同SPD条目的对等方时。因此，实现必须提供一种管理员可以要求断言的IKE ID与证书中的主题名称或主题备用名称匹配的方法。前者适用于以可分辨名称表示的IKE ID；后者适用于DNS名称、RFC 822电子邮件地址和IP地址。由于密钥ID旨在用于识别通过预共享密钥进行身份验证的对等方，因此无需将此ID类型与证书字段进行匹配。

有关IKE如何使用证书或预共享密钥执行对等方认证的详细信息，请参阅IKEv1 [HarCar98]和IKEv2 [Kau05]。

本文档不强制要求支持任何其他认证方法，尽管可以使用此类方法。

4.4.3.3. 子安全关联（Child SA）授权数据

一旦通过身份验证了IKE对等方，就可以创建子SA。每个PAD条目包含的数据用于限制可以由IKE对等方断言的ID集合，以进行与SPD的匹配。每个PAD条目指示是否要将IKE ID用作SPD匹配的符号名称，或者是否要使用在流量选择器有效负载中断言的IP地址。

如果条目指示要使用IKE ID，则PAD条目ID字段定义了授权的ID集合。如果条目指示要使用子SA的流量选择器，则需要额外的数据元素，以IPv4和/或IPv6地址范围的形式提供。（对等方可能同时被授权使用两种地址类型，因此必须提供v4和v6地址范围的设置。）

4.4.3.4. PAD的使用方式

在初始的IKE交换过程中，发起方和响应方都通过 IKE ID 载荷声明自己的身份，并发送 AUTH 载荷以验证声明的身份。可能会传输一个或多个 CERT 负载以促进每个声明身份的验证。当 IKE 实体接收到 IKE ID 载荷时，它使用所断言的 ID 来定位 PAD 中的条目，使用上述匹配规则进行匹配。该 PAD 条目指定要用于标识对等方的认证方法，这确保了对于每个对等方都使用正确的方法，并且可以为不同的对等方使用不同的方法。该条目还指定将用于验证声明身份的认证数据。在创建任何 CHILD SAs 之前，此数据与指定的方法一起用于验证对等方的身份。

当IKE实体接收到IKE ID载荷时，它使用所断言的ID来定位PAD中的条目，使用上述匹配规则进行匹配。该PAD条目指定要用于标识对等方的认证方法，这确保了对于每个对等方都使用正确的方法，并且可以为不同的对等方使用不同的方法。该条目还指定将用于验证声明身份的认证数据。在创建任何CHILD SAs之前，此数据与指定的方法一起用于验证对等方的身份。

基于流量选择器(traffic selector)载荷的交换，可以在初始IKE交换的结束时或后续的CREATE_CHILD_SA交换中创建Child SAs。现在经过身份验证的IKE对等方的PAD条目用于限制Child SAs的创建；具体来说，PAD条目指定了如何使用来自对等方的流量选择器提案来搜索SPD。有两种选择：一种是使用对等方断言的IKE ID通过其符号名称找到SPD条目，另一种是使用在流量选择器载荷中断言的对等方IP地址基于SPD条目的远程IP地址字段部分进行SPD查找。必须对创建Child SAs施加这些约束，以防止经过验证的对等方伪造与其他合法对等方关联的ID。

请注意，由于在搜索SPD条目之前会检查PAD条目，这种保护措施可以防止发起者受到伪造攻击。例如，假设IKE A收到一个传输到IP地址X的出站数据包，X是由安全网关提供服务的主机。RFC 2401 [RFC2401]和本文档未指定A如何确定为X提供服务的IKE对等方的地址。但是，任何由A联系的对等方都必须在PAD中注册，以允许进行IKE交换的身份验证。此外，当经过身份验证的对等方断言其在流量选择器交换中代表X时，将参考PAD来确定该对等方是否被授权代表X。因此，PAD将地址范围（或名称子空间）与对等方进行绑定，以对抗此类攻击。

4.5. SA and Key Management

所有的IPsec实现都必须支持手动和自动的SA和密码密钥管理。IPsec协议（AH和ESP）在很大程度上与关联的SA管理技术无关，尽管所涉及的技术确实会影响协议所提供的一些安全服务。例如，AH和ESP可选的反重放攻击服务需要自动的SA管理。此外，IPsec所采用的密钥分发的细粒度决定了所提供的认证的细粒度。通常情况下，AH和ESP中的数据源认证受制于完整性算法使用的密钥（或通过创建此类密钥的密钥管理协议）在多个可能的源之间共享的程度。

以下文字描述了两种类型的SA管理的最低要求。

4.5.1. 手动技术(Manual Techniques)

管理的最简单形式是手动管理，其中一个人手动配置每个系统的密钥材料和与其他系统进行安全通信相关的SA管理数据。手动技术在小型、静态的环境中是实用的，但不适合扩展。例如，一家公司可以在几个站点的安全网关中使用IPsec创建一个虚拟私人网络（VPN）。如果站点的数量很少，并且所有站点都在一个管理域的范围内，这可能是手动管理技术适用的环境。在这种情况下，安全网关可以使用手动配置的密钥选择性地保护组织内部与其他站点之间的通信，而不对其他目标的通信进行保护。当只需要对选定的通信进行保护时，手动管理也可能是适当的。类似的论点可能适用于仅在组织内部对少数主机和/或网关使用IPsec。手动管理技术通常使用静态配置的对称密钥，但也存在其他选项。

4.5.2. 自动化的SA和密钥管理

广泛部署和使用IPsec需要一个互联网标准、可扩展且自动化的SA管理协议。这样的支持是为了方便使用AH和ESP的反重放功能，并适应按需创建SA的需求，例如用户和会话导向的密钥配置。（请注意，“更新SA”实际上意味着创建一个具有新SPI的新SA，这个过程通常需要使用自动化的SA/密钥管理协议。）

默认选择用于IPsec的自动化密钥管理协议是IKEv2 [Kau05]。本文档假定密钥管理协议提供了一些IKEv1不支持的功能。也可以使用其他自动化SA管理协议。

当使用自动化的SA/密钥管理协议时，该协议的输出用于为单个SA生成多个密钥。这也是因为IKE创建的两个SA各使用不同的密钥。如果同时使用完整性和机密性，则至少需要四个密钥。此外，一些加密算法可能需要多个密钥，例如3DES算法。

密钥管理系统可以为每个密钥提供一个单独的比特串，也可以从一个比特串中生成所有密钥。如果提供了一个单一的比特串，则需要注意，将比特串映射到所需的密钥的系统部件在SA的两端以相同方式执行。为确保SA每端的IPsec实现在相同的密钥上使用相同的比特串，无论系统的哪个部分将比特串分成单个密钥，加密密钥必须取自第一个（最左侧，高位）比特，完整性密钥必须取自剩余的比特。每个密钥的比特数在相应的加密算法规范RFC中定义。在存在多个加密密钥或多个完整性密钥的情况下，加密算法的规范必须指定它们从单个比特串中选择的顺序。

4.5.3. 定位安全网关(Locating a Security Gateway)

本节讨论与主机如何了解相关安全网关的存在以及一旦主机与这些安全网关进行联系后，如何知道这些正确的安全网关相关的问题。所需信息存储的详细细节是件本地事情，但在第4.4节中描述的对等授权数据库（PAD）是最有可能的候选者。（注意：S*表示正在运行IPsec的系统，例如下面的SH1和SG2。）

考虑这样一种情况：远程主机（SH1）正在使用互联网来访问服务器或其他机器（H2），并且有一个安全网关（SG2），例如防火墙，通过这个安全网关必须经过 H1 的流量。这种情况的一个例子是移动主机穿过互联网到达他所在的组织的防火墙（SG2）。这种情况引出了几个问题：

SH1 如何知道/了解安全网关 SG2 的存在？
它如何认证 SG2，一旦认证了 SG2，它如何确认 SG2 被授权代表 H2？
SG2 如何认证 SH1，并验证 SH1 有权限联系 H2？
SH1 如何知道/了解任何提供到达 H2 的备用路径的其他网关？

为了解决这些问题，支持IPsec的主机或安全网关必须具有管理界面，允许用户/管理员配置一个或多个安全网关的地址，以适应需要使用它们的目标地址范围。这包括配置信息以定位和认证一个或多个安全网关，并验证这些网关是否被授权代表目标主机（授权功能在PAD中隐含）。本文档不涉及如何自动发现/验证安全网关的问题。

4.6. SAs和组播

SA的接收方向意味着，在单播流量的情况下，目的系统将选择SPI值。通过让目标选择SPI值，可以避免手动配置的SA与自动配置的（例如通过密钥管理协议）SA冲突，也可以避免来自多个源的SA彼此冲突。对于组播流量，一个SA关联多个目标系统。因此，某个系统或个人需要在所有组播组之间协调，为每个组播组代表性地选择一个或多个SPI，并通过此处未定义的机制向该组播组的所有合法成员传达该组的IPsec信息。

当使用对称密钥加密或完整性算法时，多个发送者向一个组播组发送的数据应使用单个安全关联（因此采用单个SPI）。在这种情况下，接收方只知道消息来自拥有该组播组密钥的系统。在此情况下，接收方通常无法验证哪个系统发送了组播流量。其他更一般的组播方法的规范由IETF组播安全工作组处理。

5. IP流量处理

如第4.4.1节“安全策略数据库（SPD）”中提到的那样，在处理所有跨越IPsec保护边界的流量时，包括IPsec管理流量，必须查询SPD（或相关缓存）。如果在SPD中找不到与数据包匹配的策略（无论是入站还是出站流量），则必须丢弃该数据包。为了简化处理，并允许非常快速地进行SA查找（针对SG/BITS/BITW），本文档引入了针对所有出站流量的SPD缓存（包括SPD-O和SPD-S），以及针对入站非IPsec保护流量的缓存（SPD-I）。（正如前面提到的，SAD充当缓存，用于检查到达SA的入站IPsec保护流量的选择器。）名义上每个SPD对应一个缓存。根据本规范的目的，假设每个缓存条目将映射到一个SA。然而，请注意，当使用多个SA传递不同优先级（例如，由不同的DSCP值指示）的流量，但选择器相同时，可能存在例外情况。还要注意的是，SAD可能有一些条目与SPD中没有对应条目的SA相关联。由于本文档不要求在更改SPD时有选择性地清除SAD，因此当更改或删除创建它们的SPD条目时，SAD条目可能会保留。此外，如果创建了手动密钥的SA，则可能存在与任何SPD条目都不对应的SAD条目。

由于SPD条目可能重叠，通常不能安全地缓存这些条目。简单的缓存可能会导致与缓存条目匹配，而有序的SPD搜索则会导致与不同条目匹配。但是，如果首先对SPD条目进行解耦(decorrelated)，则可以安全地缓存生成的条目。每个缓存条目将指示应适当地绕过或丢弃匹配的流量。（注意：由于PFP而产生的可能导致原始SPD条目产生多个SA。）除非另有说明，下面所有对“SPD”或“SPD缓存”或“缓存”的引用都是指解耦的SPD（SPD-I，SPD-O，SPD-S）或包含解耦的SPD条目的SPD缓存。

注意：在基于套接字的主机IPsec实现中，每当创建一个新的套接字时，都会查询SPD以确定将应用于在该套接字上流动的流量的IPsec处理情况（如果有）。这提供了一种隐式的缓存机制，在此类实现中，可以忽略讨论中涉及缓存的部分。

注意：假设首先使用关联的SPD，因为用户和管理员习惯于管理此类访问控制列表或防火墙过滤规则。然后应用解耦算法以构建可缓存的SPD条目列表。解耦在管理界面上是不可见的。

对于入站的IPsec流量，通过SPI选择的SAD条目作为缓存，用于与到达的IPsec数据包进行匹配的选择器，该匹配是在执行完AH或ESP处理之后进行的。

5.1. 发出的IP流量处理（保护到未保护）

首先考虑通过实现受保护接口进入的流量，然后通过未受保护接口退出的路径。

当处理出站数据包时，IPsec必须执行以下步骤：

当数据包从用户（受保护）接口到达时，调用SPD选择函数，获取选择适当SPD所需要的SPD-ID。（如果实现只使用一个SPD，则此步骤不执行任何操作。）
将数据包头与来自步骤1中指定的SPD-ID的缓存进行匹配。请注意，此缓存包含来自SPD-O和SPD-S的条目。

3a. 如果存在匹配项，则按照匹配的缓存条目进行处理，即使用AH或ESP的BYPASS、DISCARD或PROTECT进行处理。如果应用了IPsec处理，则从SPD缓存条目到相关的SAD条目之间存在链接（指定了模式、加密算法、密钥、SPI、PMTU等）。IPsec处理的方式如之前定义的，对于隧道模式或传输模式以及AH或ESP，都在各自的RFC中进行了规定。请注意，SA的PMTU值加上状态片段检查标志（以及出站数据包的IP标头中的DF位）确定数据包在IPsec处理之前或之后是否需要分段，或者是否必须丢弃并发送一个ICMP PMTU消息。

3b. 如果在缓存中找不到匹配项，则搜索由SPD-ID指定的SPD（SPD-S和SPD-O部分）。如果SPD条目要求BYPASS或DISCARD，则创建一个或多个新的出站SPD缓存条目，如果是BYPASS，则创建一个或多个新的入站SPD缓存条目。（可能会创建多个缓存条目，因为可能将装饰性SPD条目链接到作为装饰性过程的副作用而创建的其他条目。）如果SPD条目要求PROTECT，即创建一个SA，则会调用密钥管理机制（例如IKEv2）来创建SA。如果SA的创建成功，则会创建一个新的出站（SPD-S）缓存条目，以及出站和入站的SAD条目，否则数据包将被丢弃。（如果数据包触发了SPD查找，实现可以丢弃该数据包，或者如果创建了一个新的缓存条目，则可以对其进行处理。）由于SA是成对创建的，相应的入站SA也会创建一个SAD条目，其中包含从SPD条目（以及数据包，如果有任何PFP标志为“真”）派生的选择器值，用于检查通过SA传递的入站流量。

将数据包传递给出站转发函数（在IPsec实现之外运行），选择将数据包定向到的接口。该函数可能导致数据包被传回IPsec边界进行额外的IPsec处理，例如支持嵌套SA。如果是这样的话，SPD-I数据库中必须有条目允许数据包的入站绕过，否则数据包将被丢弃。如果有必要，即如果有多个SPD-I，则被回送的流量可以标记为来自此内部接口。这样，如果需要的话，可以区分“真正的”外部流量与回送流量使用不同的SPD-I。

注意：除了IPv4和IPv6传输模式外，SG、BITS或BITW实现可以在应用IPsec之前对数据包进行分段。（这仅适用于IPv4。对于IPv6数据包，只允许发起者对其进行分段。）设备应该具有一个配置设置来禁用此功能。生成的片段将按照正常方式与SPD进行评估。因此，不包含端口号（或ICMP消息类型和代码，或移动性头类型）的片段只会与具有OPAQUE或ANY选择器的规则匹配。（有关更多详细信息，请参见第7节。）

注意：关于确定和执行SA的PMTU，IPsec系统必须遵循第8.2节中描述的步骤。

5.1.1. 处理必须丢弃的出站数据包

如果IPsec系统收到一个必须丢弃的出站数据包，它应该能够生成并发送一个ICMP消息，以向出站数据包的发送方指示该数据包已被丢弃。ICMP消息的类型和代码将取决于丢弃数据包的原因，如下所示。应该在审计日志中记录原因。此事件的审计日志条目应包括原因、当前日期/时间和数据包的选择器值。

a. 数据包的选择器匹配了要求丢弃该数据包的SPD条目。IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited)

IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited)

b1. IPsec系统成功地与远程对方建立连接，但由于某些原因无法协商与匹配数据包的SPD条目所需的SA。例如，远程对方在管理上禁止与发起方通信，发起方无法对远程对方进行身份验证，远程对方无法对发起方进行身份验证，或者远程对方的SPD没有合适的条目。

IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited)

IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited)

b2. IPsec系统无法建立与匹配数据包的SPD条目所需的SA，因为无法联系到交换另一端的IPsec对等体。IPv4 Type = 3 (destination unreachable) Code = 1 (host unreachable) IPv6 Type = 1 (destination unreachable) Code = 3 (address unreachable)

请注意，在安全网关后面的攻击者可能会发送带有伪造源地址W.X.Y.Z的数据包给一个IPsec实体，导致它向W.X.Y.Z发送ICMP消息。这为安全网关后面的主机之间创建了拒绝服务（DoS）攻击的机会。为了解决这个问题，一个安全网关应该包含一个管理控制，允许管理员在这种情况下配置IPsec实现是否发送ICMP消息，并且如果选择了此功能，则限制传输这种ICMP响应的速率。

5.1.2. 隧道模式下的报头构造

本节描述了关于 AH 和 ESP 隧道的内部和外部 IP 头、extension headers以及选项的处理，涉及出站流量处理。这包括如何构建封装（外部）IP 头，如何处理内部 IP 头中的字段，以及对于出站隧道模式流量应采取的其他操作。这里描述的通用处理过程是基于 RFC 2003 “IP Encapsulation within IP” [Per96] 的模型设计的。

外部 IP 标头的源地址和目标地址标识了隧道的“端点”（封装程序和解封装程序）。内部 IP 标头的源地址和目标地址标识了数据报的原始发送者和接收者（从本隧道的角度来看）。（有关封装源 IP 地址的更多详细信息，请参见5.1.2.1中表格后的脚注3。）
内部IP头除了下面指出的TTL（或Hop Limit）和DS/ECN字段外，不会发生任何更改。传递到隧道出口点时，内部IP头原样保持不变。
在通过隧道传递封装的数据报期间，内部头中的IP选项或extension headers不会发生任何更改。

注意：IPsec隧道模式与IP-in-IP隧道（RFC 2003 [Per96]）在几个方面有所不同：

IPsec提供了一些控制措施，供安全管理员管理隐藏信道（这在通常情况下不是隧道的问题），并确保接收者按照访问控制的要求检查接收到的数据包的正确部分。IPsec实现可以通过配置方式处理传输数据包的外部DS字段。对于出站流量，外部DS字段的一个配置设置将按照下面有关IPsec隧道的IPv4和IPv6头处理的部分进行操作。另一个配置设置将允许将外部DS字段映射到固定值，这可以基于每个安全关联（SA）进行配置。（这个值对于从设备发出的所有出站流量可能确实是固定的，但也可以根据SA进行粒度化配置。）这个配置选项允许本地管理员决定复制这些位提供的隐藏信道是否超过了复制带来的好处。
IPsec描述了如何处理ECN或DS，并提供了控制在受保护和未受保护域之间传播这些字段更改的能力。一般来说，从受保护到未受保护域的传播是一个隐藏信道，因此提供了控制来管理该信道的带宽。在另一个方向上，ECN值的传播受到控制，只有合法的ECN更改（指示隧道端点之间出现拥塞）会被传播。默认情况下，不允许从未受保护域到受保护域的DS传播。然而，如果发送者和接收者不共享相同的DS代码空间，并且接收者无法学习如何在两个空间之间进行映射，则可能需要偏离默认设置。具体而言，IPsec实现可以在接收数据包的隧道模式下对如何处理外部DS字段进行配置。它可以配置为丢弃外部DS值（默认设置）或用外部DS字段覆盖内部DS字段。如果提供，丢弃与覆盖行为可以基于每个SA进行配置。这个配置选项允许本地管理员决定复制这些位带来的漏洞是否超过了复制的好处。有关何时使用这些行为以及可能需要在IPsec处理（包括隧道解封装）之前或之后对diffserv流量进行调整的进一步信息，请参阅[RFC2983]。
IPsec允许封装头的IP版本与内部头的IP版本不同。

下面几节中的表展示了对不同header/option字段的处理（"constructed"表示外部字段的值是独立于内部字段的值构造的）。

5.1.2.1. IPv4: 隧道模式下的头部构造

注意：(1) 封装头中的IP版本可以与内部头中的值不同。(2) 在转发之前，封装器会减少内部头中的TTL值，解封装器在转发数据包时也会减少该值。（当TTL改变时，IPv4 checksum也会改变。）注意：减少TTL值是转发数据包的正常过程。因此，与封装器来自同一节点的数据包不会减少其TTL值，因为发送节点是原始数据包的来源，而不是转发它。这适用于主机和路由器中的BITS和本机IPsec实现。然而，IPsec处理模型包括外部转发能力。TTL处理可用于在此处理模型的上下文中防止数据包出现环路，例如由于配置错误造成的。

(3) 本地地址和远程地址取决于SA（安全关联），用于确定远程地址，进而确定用于转发数据包的本地地址（网络接口）。注意：对于多播流量，可能需要目标地址或源地址和目标地址进行分解。在这种情况下，重要的是要确保SA的生命周期内保持一致性，即确保出现在封装隧道头部的源地址与在SA建立过程中进行协商的源地址相同。有一个例外，即移动IPsec实现将随着其移动而更新其源地址。

(4) 配置决定是从内部头部（仅限IPv4），清除还是设置DF(Don't Fragment)标志。

(5) 如果数据包将立即进入一个不适合外部头部中的DSCP值的域，那么该值必须映射到该域的适当值[NiBlBaBL98]。详细信息请参见RFC 2475 [BBCDWW98]。

(6) 如果内部头部的ECN字段设置为ECT(0)或ECT(1)，其中ECT表示拥塞可探测传输（ECT：ECN-Capable Transport），并且外部头部的ECN字段设置为拥塞经历（CE：Congestion Experienced），则将内部头部中的ECN字段设置为CE；否则，不对内部头部的ECN字段进行更改。（当ECN更改时，IPv4校验和也会更改。）

注意：IPsec不会将内部头部中的选项复制到外部头部，并且IPsec也不会构建外部头部中的选项。但是，post-IPsec代码可能会在外部头部中插入/构建选项。

5.1.2.2. IPv6: 隧道模式下的头部构造

注释：（1）-（6）请参阅第5.1.2.1节。

（7）IPsec不会将内部数据包的扩展头复制到外部头，也不会在外部头中构建扩展头。但是，post-IPsec代码可能会在外部头中插入/构建扩展头。

（8）参见[RaCoCaDe04]。仅对于终端系统而言，复制是可以接受的，而不能对SG进行复制。如果SG从内部头复制流标签到外部头，可能会导致冲突。

（9）在按SA为基础接收隧道模式的数据包方面，实现可以选择提供将DS值从外部头传递到内部头的功能。提供此功能的动机是为了适应接收方的DS代码空间与发送方不同且接收方无法知道如何从发送方的空间进行转换的情况。将此值从外部头复制到内部头存在风险，因为它使得攻击者能够修改外部的DSCP值，可能会对接收方的其他流量产生不利影响。因此，IPsec实现的默认行为是不允许进行这样的复制操作。

5.2. 处理入站IP流量（unprotected-to-protected）

入站处理与出站处理有些不同，因为使用spi将受ipsec保护的流量映射到SAs。入站SPD- i (inbound SPD- i)只应用于旁路或丢弃的流量。如果到达的分组似乎是来自未受保护接口的IPsec分片，则在IPsec处理之前进行重组。对于任何SPD缓存，其目的都是将未能匹配任何项的分组引用到对应的SPD。。每个SPD应该有一个名义上的最终条目，用于捕获任何不匹配的内容，并将其丢弃。这样一来，到达的流量如果没有匹配任何SPD-I表项，未受ipsec保护的流量就会被丢弃。

（*）= 在这里显示了缓存。如果缓存未命中，则检查SPD。如果缓存未命中，实现不需要缓冲数据包。

（**）= 这个处理过程包括使用数据包的SPI等来在SAD中查找SA，SAD形成了入站数据包的SPD缓存（除了4.4.2节和5节中提到的情况）。请参见下面的步骤3a。

（***）= 此SAD检查指的是下面的步骤4。

在执行AH或ESP处理之前，通过未保护的接口到达的任何IP片段都会被（由IP层）重组。将应用IPsec处理的每个入站IP数据报都通过IP Next Protocol字段中出现的AH或ESP值（或在IPv6环境中作为next layer protocol的AH或ESP值）进行识别。

IPsec必须执行以下步骤：

当一个数据包到达时，如果必要的话，它可以用到达的接口（物理或虚拟）的ID标记。以支持多个SPD以及相关的SPD-I缓存。（接口ID映射到相应的SPD-ID。）
对数据包进行检查，并将其分为两类：

如果数据包看起来是受IPsec保护的，并且它的地址指向该设备，则会尝试通过SAD将其映射到一个活跃的SA。请注意，设备可能有多个IP地址用于SAD查找，例如SCTP这样的协议。
不寻址到该设备或寻址到该设备但不是AH或ESP的流量将被导向到SPD-I查找。（这意味着IKE流量必须在SPD中具有显式的BYPASS条目。）如果采用多个SPD，则在步骤1中分配给数据包的标记将用于选择适当的SPD-I（和缓存）进行查找。SPD-I查找确定操作是否为丢弃或绕过。

3 a. 如果该数据包被寻址到了IPsec设备且指定了AH或ESP协议，则将会在SAD中进行查找。对于单播流量，仅使用SPI（或SPI加协议）。对于多播流量，使用SPI加目标地址或SPI加目标和源地址，如4.1节所述。无论是单播还是多播情况下，如果没有匹配项，将丢弃该流量。这是可审计的事件。此事件的审计日志条目应该包括当前的日期/时间、SPI、数据包的源和目标地址、IPsec协议以及数据包中任何可用的其他选择器值。如果在SAD中找到该数据包，则相应地进行处理（参见步骤4）。

3b. 如果数据包不是寻址到该设备，或者被寻址到这个设备但不是AH或ESP，则在（适当的）SPD-I缓存中查找数据包头。如果有匹配项且要将数据包丢弃或绕过，则执行相应操作。如果没有缓存匹配项，则在相应的SPD-I中查找该数据包，并根据需要创建缓存条目。（接收到需要IPsec保护的数据包时，不会为其创建任何SA；只有通过或丢弃的缓存条目可以用此方式创建。）如果没有匹配项，则丢弃该流量。这是一个可以审计的事件。该事件的审计日志条目应包括当前日期/时间、如果可用的话SPI、可用的IPsec协议、数据包的源和目的地，以及可用的数据包选择器值。

3c. ICMP消息的处理被认为发生在IPsec边界的未保护侧。未保护的ICMP消息会被检查，并应用本地策略来决定是接受还是拒绝这些消息，并且如果接受了，采取什么行动作为结果。例如，如果收到一个ICMP不可达消息，实现必须决定是否对其采取行动、拒绝它，或在有限制条件下对其采取行动。（参见第6节。）

如步骤3a所选的SAD条目规定的那样应用AH或ESP处理。然后将数据包与SAD条目识别的入站选择器进行匹配，以验证接收到的数据包是否适合通过它接收到的SA。
如果IPsec系统在SA上接收到入站数据包，但数据包的头域与SA的选择器不一致，则必须丢弃该数据包。这是一个可审计的事件。该事件的审计日志条目应包括当前日期/时间、SPI、IPsec协议、数据包的源和目的地、数据包的任何其他可用选择器值以及相关SAD条目的选择器值。系统还应该能够生成并发送一个IKE通知告诉发送者（IPsec对等方）选择器无效，表示由于未能通过选择器检查而丢弃接收到的数据包。

为了最小化DoS攻击或配置错误的对等方的影响，IPsec系统应该包括一个管理控制功能，允许管理员配置IPsec实现是否发送此IKE通知，并且如果选择了该功能，还可以限制发送此类通知的传输速率。

在经过IPsec旁路或处理后，流量被交给入站转发功能进行处理。这个功能可能会导致数据包被发送（出站）穿越IPsec边界进行额外的入站IPsec处理，例如支持嵌套SA。如果是这样的话，那么像所有要旁路的出站流量一样，数据包必须与一个SPD-O条目进行匹配。最终，数据包应该被转发到目标主机或进程进行处理。

6.ICMP处理

本节描述了IPsec对ICMP流量的处理。有两类ICMP流量：错误消息（例如，type = destination unreachable）和非错误消息（例如，type = echo）。本节专门适用于错误消息。非错误的ICMP消息（不针对IPsec实现本身）的处理必须使用SPD条目进行明确说明。

本节讨论适用于ICMPv6和ICMPv4。此外，应提供一种机制，以允许管理员将ICMP错误消息（选择的、全部或无）记录下来，以辅助问题诊断。

6.1. 处理指向IPsec实现的ICMP错误消息

6.1.1. 在未受保护边界的一侧接收到的ICMP错误消息

第5.2节中的图3显示了一个独立的ICMP处理模块，在IPsec边界的未保护侧上，用于处理发送给IPsec设备且未通过AH或ESP保护的ICMP消息（错误或其他）。这种类型的ICMP消息未经身份验证，其处理可能会导致拒绝服务或服务质量下降。这表明，通常最好忽略这些消息。然而，许多ICMP消息将由主机或安全网关从未经身份验证的源接收，例如公共互联网中的路由器。忽略这些ICMP消息可能会降低服务质量，例如由于无法处理PMTU消息和重定向消息而导致的问题。因此，也有动机接受未经身份验证的ICMP消息并对其进行操作。

为了适应这个问题的两个方面，符合要求的IPsec实现必须允许本地管理员配置IPsec实现以接受或拒绝未经身份验证的ICMP流量。这种控制必须以ICMP类型的粒度执行，也可以以ICMP类型和代码的粒度执行。此外，实现应该包含处理此类流量的机制和参数。例如，可以建立对于流量的最低PMTU（基于每个目的地）以防止未经身份验证的ICMP将PMTU设置为极小值。

如果一个ICMP PMTU消息通过了上述检查，并且系统被配置为接受它，那么有两种可能性。如果实现在边界的密文端应用了分段，则接受的PMTU信息将传递给转发模块（在IPsec实现之外），该模块将使用该信息来管理出站数据包的分段。如果实现被配置为在明文端进行分段，则PMTU信息将传递给明文端并按照第8.2节中描述的方式进行处理。

6.1.2. 接收到的在保护边界的受保护侧的ICMP错误消息

这些ICMP消息没有进行身份验证，但它们来自于IPsec边界的保护侧的源。因此，这些消息通常被认为比来自于边界未保护侧的源的消息更加“可信”。主要的安全关注点在于，一个被入侵的主机或路由器可能会发送错误的ICMP错误消息，导致其他设备在安全网关“后方”的服务降级，甚至可能导致保密性违规。例如，如果一个虚假的ICMP重定向被安全网关接受，它可能会修改边界保护侧的转发表，将流量传递到不恰当的目标“后方”网关。因此，实施者必须提供控制措施，允许本地管理员限制在保护边界接收并针对IPsec实现的ICMP错误消息的处理。这些控制措施与在未保护侧所使用的控制措施相同，如第6.1.1节中所述。

6.2. 处理受保护的传输ICMP错误消息

当通过安全关联（SA）将ICMP错误消息传输到IPsec实现“后方”的设备时，需要从访问控制的角度对ICMP消息的有效载荷和头部进行检查。如果将其中一条消息转发到安全网关后面的主机，接收主机的IP实现将根据有效载荷（即被称为引发错误响应的数据包的头部）做出决策。因此，IPsec实现必须可配置以检查此有效载荷头信息与到达的SA是否一致（这意味着有效载荷头部，包括源地址、目标地址和端口字段反转，与SA的流量选择器匹配）。如果不执行此类检查，那么例如，与接收IPsec系统（A）拥有活动SA的任何人都可以发送一个指向A当前正在通信的任何主机/网络的ICMP目标不可达消息，从而实现对与A的其他对等体的高效DoS攻击。通常的IPsec接收处理流程无法防止此类攻击。然而，并非所有的情景都需要执行这样的检查，因此还需要允许本地管理员对实现进行配置，以使其不执行此类检查。

为了适应两种策略，采用以下约定。如果管理员想允许ICMP错误消息通过SA传递而无需检查有效载荷，则配置一个明确允许传递此类流量的SPD条目。如果管理员希望IPsec检查ICMP错误消息的有效载荷一致性，则不要创建任何SPD条目，以适应基于ICMP数据包头的传输此类流量。这个约定促进了以下处理描述。

通过SA发送和接收的ICMP错误消息，IPsec发送者和接收者必须支持以下处理。

如果存在一个适应出站ICMP错误消息的SA，那么该消息将映射到SA，并且只有在接收时检查IP和ICMP头部，就像对其他流量的处理一样。如果不存在与ICMP错误消息相关联的流量选择器匹配的SA，则会搜索SPD以确定是否可以创建这样一个SA。如果可以，将创建该SA，并通过该SA传输ICMP错误消息。在接收时，该消息将受到接收方通常的流量选择器检查。这个处理过程与普通流量的处理过程完全相同，并不代表对ICMP错误消息的特殊处理。

如果不存在一个SA可以携带出站ICMP消息，并且没有任何SPD条目允许携带此出站ICMP错误消息，那么IPsec实现必须将该消息映射到将携带触发ICMP错误消息的数据包相关的返回流量的SA上。这要求IPsec实现能够检测到映射到不存在的SA或SPD条目的出站ICMP错误消息，并在SA的创建和查找方面对其进行特殊处理。实现会提取触发错误的数据包的头部（从ICMP消息负载中提取），反转源和目的IP地址字段，提取协议字段，并反转端口字段（如果可访问）。然后，它使用提取的信息来定位一个合适且有效的出站SA，并通过该SA传输错误消息。如果不存在这样的SA，将不会创建SA，这将记录为一个可审核的事件。

如果IPsec实现在一个SA上接收到入站的ICMP错误消息，且该消息的IP和ICMP头部与该SA的流量选择器不匹配，接收方必须以特殊方式处理接收到的消息。具体而言，接收方必须从ICMP负载中提取触发数据包的头部，并按照上述描述的方式反转字段，以确定该数据包是否与接收到ICMP错误消息的SA的选择器一致。如果数据包未通过此检查，IPsec实现不能将ICMP消息转发到目的地。这是一个可审核的事件。

7. 处理分片（在IPsec边界的保护侧）

本文档的早期部分描述了在应用IPsec处理后将出站报文进行分片，并在接收方进行IPsec处理前重新组装报文的机制，以及处理从IPsec边界的未保护侧接收的入站分片的机制。本节描述了一个实现应如何处理在IPsec边界的保护侧的出站明文分片的处理方式（请参阅附录D“分片处理原理”）。特别是，它涉及以下方面：

将出站非初始分片（non-initial fragment）映射到正确的SA（或找到正确的SPD条目）
验证接收到的非初始分片是否经过授权，以通过其接收到的SA进行传输
将出站和入站非初始分片映射到正确的SPD-O/SPD-I条目或相关缓存条目，用于BYPASS/DISCARD流量。

注意：在第4.1节中，已定义传输模式SA不能携带（IPv4或IPv6）分片。另请注意，在第4.4.1节中，为选择器定义了两个特殊值ANY和OPAQUE，并且ANY包括OPAQUE。术语“非平凡”用于表示选择器具有除OPAQUE或ANY之外的值。

注意：这里使用术语“non-initial fragment”来指示不包含所有可能需要用于访问控制的选择器值的分片。如第4.4.1节所述，根据下一层协议，在非初始分片中除端口外，ICMP消息类型/代码或移动性标头（Mobility Header）类型可能也会丢失。此外，对于IPv6，即使是第一个片段也可能不包含下一层协议或端口（或ICMP消息类型/代码或移动性标头类型），这取决于存在的扩展头的类型和数量。如果非初始分片包含端口（或ICMP类型和代码或移动性标头类型），但不包含下一层协议，则除非针对相关的本地/远程地址有可用于下一层协议和端口（或ICMP类型和代码或移动标头类型）的ANY SPD条目，否则该分片将不包含访问控制所需的所有选择器信息。

为解决上述问题，定义了三种方法：

负载隧道模式的SA，可以携带初始和非初始分片（参见第7.1节）。
针对非初始分片的单独负载隧道模式的SA（参见第7.2节）。
有状态的分片检查（参见第7.3节）。

7.1. 携带初始（Initial）和非初始分片（Non-Initial Fragments）的隧道模式SA

所有实现都必须支持配置为忽略端口字段（或ICMP类型/代码或移动性标头类型）值而传递流量的隧道模式SA。如果SA将传输指定协议的流量，则SA的选择器集必须将端口字段（或ICMP类型/代码或移动性标头类型）指定为ANY。使用这种方式定义的SA将携带所有流量，包括所指示的本地/远程地址和指定的下一层协议的初始和非初始分片。如果SA将传输不考虑特定协议值的流量（即，ANY被指定为（下一层）协议选择器的值），则端口字段的值未定义，并且必须设置为ANY。（正如第4.4.1节中所指出的，ANY包括OPAQUE以及所有特定的值。）

7.2. 针对非初始分片的单独负载隧道模式SA（Separate Tunnel Mode SAs for Non-Initial Fragments）

一种实现可以支持仅携带非初始分片的隧道模式SA，与非分片数据包和初始分片分开。使用OPAQUE值来指定用于携带这些分片的SA的端口（或ICMP类型/代码或移动性标头类型）字段选择器。当使用此类SA时，接收方必须对IPv4（非初始）分片进行最小偏移检查，以防止重叠分片攻击。由于无法对IPv6非初始分片执行此类检查，建议用户和管理员注意携带这些分片可能存在危险，并且实现者可以选择不支持IPv6流量的此类SA。此外，此类SA将携带与指定的本地/远程地址对和协议值匹配的所有非初始分片，即，携带在此SA上的分片属于如果未分片的数据包可能将分别属于不同安全级别的SA。因此，建议用户和管理员使用ESP（带有完整性）和在双方之间使用的“最强大”的完整性和加密算法来保护此类流量。（确定“最强大”的算法需要对可用算法进行排序，这是发起SA的发起者自行决定的本地决策。）

将使用特定的端口（或ICMP类型/代码或移动性标头类型）选择器值来定义携带初始分片和非分片数据包的SA。如果用户或管理员想要在相同的本地/远程地址之间创建一个或多个隧道模式的SA，并根据端口（或ICMP类型/代码或移动性标头类型）字段进行区分，则可以使用此方法。这些SA必须具有非平凡的协议选择器值，否则必须使用上述＃1方法。

注意：一般情况下，对于本节中描述的方法，只需要在两个实现之间建立一个SA来携带所有非初始分片。但是，如果选择在两个实现之间建立多个SA以实现QoS区分，则可能还希望针对每个支持的QoS类别建立多个用于携带无端口分片的SA。由于通过不同的SA实现QoS是一个本地问题，并不由本文档强制要求，因此选择建立多个SA来携带非初始分片的决策也应该是本地的。

7.3. 有状态的片段检查

针对具有非平凡端口（或ICMP类型/代码或MH类型）字段值（非ANY或OPAQUE）的隧道模式SA，实现可以支持某种形式的状态分片检查。如果一个实现将在使用非平凡端口（或ICMP类型/代码或MH类型）选择器的隧道模式SA上传输非初始分片，必须通过IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO负载通知对等方。

如果对等方不接受在此上下文中接收非初始分片，则对等方必须拒绝此建议。如果某个实现不能成功协商传输此类SA的非初始分片，则不能通过该SA发送此类分片。本标准未指定对等方在发送端或接收端如何处理此类分片，例如通过重组或其他方式。然而，除非此功能已经协商，否则接收端必须丢弃在具有非平凡端口（或ICMP类型/代码或MH类型）选择器值的SA中到达的非初始分片。此外，接收端必须丢弃不符合应用于整个数据包的安全策略的非初始分片。丢弃此类数据包是可审计的事件。请注意，如果数据包的分片可能通过不同的安全网关或BITW实现之间发送或接收，那么跟踪分片的状态策略可能会失败。

7.4. BYPASS/DISCARD 流量

所有实现都必须使用正常的SPD数据包分类机制支持丢弃片段。所有实现都必须支持有状态的片段检查，以适应指定了非平凡端口范围的旁路流量。担心的是，旁路明文、非初始片段到达IPsec实现可能会破坏针对同一目的地的IPsec保护流量的安全性。例如，考虑一个配置了SPD条目的IPsec实现，该条目要求在特定的源/目的地地址对之间进行IPsec保护，以及特定的协议和目的地端口，例如端口23（Telnet）上的TCP流量。假设该实现也允许从同一源/目的地地址对和协议中旁路流量通过，但是目标端口不同，例如端口119（NNTP）。攻击者可以发送一个非初始片段（带有伪造的源地址），如果该片段被旁路处理，它可能会重叠IPsec保护流量来自同一源头，从而破坏IPsec保护流量的完整性。要求对于指定了非平凡端口范围的旁路规则进行有状态的片段检查，可以防止此类攻击。正如上面所提到的，在分段数据包可能通过不同的安全网关或BITW实现发送或接收的网络配置中，跟踪分段的状态策略可能会失败。

8. 路径 MTU/DF 处理

对于一个出站数据包，如果应用了AH或ESP协议，会增加数据包的大小，这可能导致数据包超过其要经过的传输安全关联的最大传输单元（PMTU）。此外，IPsec实现也可能会收到未受保护的 ICMP PMTU 消息，如果它选择对此消息作出反应，结果将影响出站流量处理。本节描述了IPsec实现需要处理这两个PMTU问题所需的过程。

8.1. DF 位

所有的IPsec实现都必须支持在通过隧道模式SA传输流量时，从出站数据包中复制DF位到它发出的隧道模式头部。这意味着必须能够为每个SA配置实现对DF位的处理方式（设置、清除、从内部头部复制）。这适用于内部和外部头部都是IPv4的SA。

8.2. 路径 MTU（PMTU）发现

本节讨论未保护 Path MTU 发现消息的 IPsec 处理。这里使用 ICMP PMTU 来指代 ICMP 消息:

8.2.1. PMTU 的传播

当 IPsec 实现接收到未经验证的 PMTU 消息，并且已配置为处理（而不是忽略）此类消息时，它将该消息映射到相应的 SA。该映射是通过从 PMTU 消息的有效载荷中提取头信息并应用第 5.2 节中描述的过程来实现的。由此消息确定的 PMTU 用于更新 SAD 的 PMTU 字段，考虑将应用的 AH 或 ESP 标头的大小、加密同步数据以及隧道模式 SA 的情况下附加的 IP 标头的开销。

在本地主机实现中，可以以与未保护通信相同的粒度维护 PMTU 数据，因此不会失去功能。PMTU 信息的信令是在主机内部进行的。对于所有其他 IPsec 实现选项，必须通过合成的 ICMP PMTU 传播 PMTU 数据。在这些情况下，IPsec 实现应等待将出站流量映射到 SAD 条目。当此类流量到达时，如果该流量超出了更新的 PMTU 值，则必须按以下方式处理该流量：

情况 1：原始（明文）数据包是 IPv4 数据包，且具有设置 DF 位。实现应丢弃该数据包并发送 PMTU ICMP 消息。
情况 2：原始（明文）数据包是 IPv4 数据包，且 DF 位被清除。实现应该对数据包进行分段（在加密之前或之后，根据其配置），然后转发分段数据包。它不应发送 PMTU ICMP 消息。
情况 3：原始（明文）数据包是 IPv6 数据包。实现应丢弃该数据包并发送 PMTU ICMP 消息。

8.2.2 PMTU 老化

在所有的 IPsec 实现中，与安全关联（SA）相关的 PMTU 必须进行 "老化"，并且需要一些机制及时更新 PMTU，特别是用于发现当前网络条件下 PMTU 是否小于所需值。给定的 PMTU 必须保持足够长的时间，以便数据包能够从 SA 的源端到达对等端，并在当前 PMTU 过大时传播 ICMP 错误消息。

实现应使用《路径 MTU 发现》文档（RFC 1191 [MD90]，第 6.3 节）中描述的方法，该方法建议周期性地将 PMTU 重置为首跳数据链路 MTU，然后让正常的 PMTU 发现过程根据需要更新 PMTU。这个周期应该是可配置的。

9. 审计

IPsec实现不要求支持审计。在很大程度上，审计的细粒度是一种本地问题。然而，在本文档中识别了几个可审计事件，并为每个事件定义了应包含在审计日志中的最低信息集。对于每个这些事件，审计日志中还可以包含其他信息，并且还可以导致未在此规范中明确指出的其他事件的审计日志条目。接收方没有义务对检测到的可审计事件向所谓的发件人发送任何消息，因为这样的行动可能导致拒绝服务。

10. 一致性要求

所有IPv4 IPsec实现必须符合本文档的所有要求。所有IPv6实现必须符合本文档的所有要求。

11. 安全考虑

本文档的重点是安全性，因此安全考虑贯穿本规范。

IPsec对跨越IPsec障碍物的IP头数据的绕过施加了严格的限制，特别是当使用隧道模式SA时。某些限制是绝对的，而另一些则受制于本地管理控制，通常是基于每个SA的。对于出站流量，这些限制旨在限制隐蔽通道带宽。对于入站流量，这些限制旨在防止有能力篡改未受保护的IPsec障碍物一侧的数据流的对手对其他数据流（在障碍物保护的一侧）产生不利影响。第5节中处理隧道模式SA的DSCP值的讨论说明了这种担忧。

如果配置了IPsec实现以基于ICMP头字段的值通过SA传递ICMP错误消息，而不检查ICMP消息负载中的头信息，可能会导致严重的漏洞。考虑一个场景，其中几个站点（A、B和C）通过ESP保护的隧道相互连接：A-B、A-C和B-C。还假设每个隧道的流量选择器为协议和端口字段指定了ANY，并且IP源/目的地址范围涵盖了为每个站点提供服务的安全网关后面的系统地址范围。这将允许站点B的主机向站点A的任何主机发送ICMP目的地不可达的消息，宣布站点C的所有主机都不可访问。这是一种非常有效的拒绝服务（DoS）攻击，如果ICMP错误消息受到IPsec提供的检查的约束，并且如果SPD是适当配置的，如第6.2节所述，这种攻击本来可以被防止。

12. IANA考虑事项。

IANA已经为asn1-modules注册表分配了值（3），并为SPD模块分配了对象标识符1.3.6.1.5.8.3.1。请参见附录C，“SPD条目的ASN.1”。

13. 与RFC 2401的不同之处。

这份架构文档在细节和组织上与RFC 2401 [RFC2401]有很大不同，但基本概念保持不变。

处理模型已经进行了修订，以应对新的IPsec场景，提高性能并简化实现。这包括转发（路由）和SPD选择之间的分离，多个SPD更改，以及添加用于绕过或丢弃流量的出站SPD缓存和入站SPD缓存。还有一个新的数据库，即对等方授权数据库（PAD）。它提供了SA管理协议（如IKE）和SPD之间的链接。
不再需要支持嵌套SA或"SA束"。相反，可以通过SPD和转发表配置来实现此功能。附录E中已添加配置示例。
SPD条目已重新定义，以提供更大的灵活性。现在每个SPD条目包含1到N个选择器集，其中每个选择器集包含一个协议，并且现在可以为本地IP地址、远程IP地址以及与下一层协议相关的字段（如果有的话）指定"范围列表"。选择器的单个值通过一个平凡的范围来表示，而ANY则通过涵盖选择器所有值的范围来表示。附录C中包含了一个ASN.1描述的示例。
TOS（IPv4）和Traffic Class（IPv6）已被DSCP和ECN取代。隧道部分已经更新，以解释如何处理DSCP和ECN位。
对于隧道模式的SA，现在允许在应用IPsec之前对数据包进行分片，可采用SG、BITS或BITW实现。这仅适用于IPv4。对于IPv6数据包，只允许发起者进行分片。
当在路径上的两个中间系统之间或在中间系统与终端系统之间需要安全性时，现在可以在安全网关之间和安全网关与主机之间使用传输模式。
本文档明确指出，对于跨越IPsec边界的所有流量，包括IPsec管理流量，必须查阅SPD或相关缓存。
本文档定义了如何处理一个具有多个订阅者并需要单独IPsec上下文的安全网关的情况。
添加了保留SPI的定义。
添加了说明为什么必须检查所有IP数据包的文本--IPsec包括最低限度的防火墙功能，以支持在IP层进行访问控制。
隧道部分已经更新，以澄清在构建外部标题时如何处理IP选项字段和IPv6扩展标头。
更新了入站流量的SA映射，以与AH和ESP中为单播和组播SA提供支持的更改保持一致。
添加了有关如何处理在隧道模式下通过将DSCP值复制到外部标题创建的隐蔽信道的指导方针。
不再要求在IPv4和IPv6中支持AH。
更新了PMTU处理。已删除有关PMTU / DF / 分片的附录。
为在IPsec边界的受保护侧处理明文分片添加了三种方法。附录D详细说明了它们的理由。
添加了重新描述如何为SA派生选择器值的文本（从SPD条目或数据包等）。
添加了一个新表，描述了在SPD条目中的选择器值、PFP标志以及相应的SAD条目中的结果选择器值之间的关系。
添加了附录B，以描述装饰的方法。
添加了描述必须丢弃的出站数据包的文本。
添加了描述如何处理“已丢弃的”入站数据包（即与其到达的SA不匹配的数据包）的文本。
将IPv6移动头作为可能的下一层协议添加。添加了IPv6移动头消息类型作为选择器。
添加了ICMP消息类型和代码作为选择器。
删除了“数据敏感级别”选择器，以简化事务处理。
更新了关于处理ICMP错误消息的说明文本。已删除有关“ICMP消息分类”的附录。
更新和澄清了选择器名称的文本。
进一步解释了“下一层协议”，并添加了一个默认的协议列表，在查找下一层协议时可以跳过这些协议。
修改的文本中明确说明了该文档假定使用IKEv2或具有类似功能的SA管理协议。
添加了澄清的文本，以在存在组播SA时将入站IPsec数据报映射到SA的算法。
删除了附录“序列空间窗口代码示例”。
关于IP地址和端口，策略规则使用“本地”和“远程”术语（取代源和目的地）。“本地”指的是受IPsec实施保护的实体，即出站数据包的“源”地址/端口或入站数据包的“目的地”地址/端口。“远程”指的是对等实体。“源”和“目的地”术语仍然用于数据包头字段中。

14. 致谢

作者们感谢Ran Atkinson的贡献，在最初的IPsec活动中扮演了关键角色，并撰写了IPsec标准的第一批系列文件：RFC 1825-1827；还要感谢Charlie Lynn在第二批IPsec标准（RFC 2401、2402和2406）以及当前版本中对IPv6问题做出的重要贡献。作者们还要感谢IPsec和MSEC工作组的成员对该协议规范的发展做出的贡献。

附录 A：术语表

附录 B: Decorrelation

本附录是由Luis Sanchez、Matt Condell和John Zao在IP安全策略工作组中进行的政策缓存工作。

如果两个SPD条目的相应选择器的值存在非空交集，则这两个条目是相关的。缓存相关的SPD条目可能导致错误的策略执行。解决这个问题的方法是保留缓存功能的同时去除不明确性，通过去相关化来重写SPD条目。也就是说，必须通过重新定义SPD条目，使得每个条目都存在一个选择器，在该选择器的值中，两个条目之间有一个空交集。一旦条目被去相关化，就不再需要依赖它们的顺序，因为只有一个条目会匹配任何查找。接下来的章节将更详细地描述去相关化，并提供一个可实现去相关化的算法。

附录 C：用于SPD条目的ASN.1

附录 D：分片处理原理

附录 E：通过SPD和转发表条目支持嵌套SA的示例

本附录提供了一个示例，展示如何配置SPD和转发表以支持嵌套的SA对，与新的处理模型一致。为了简单起见，本示例假设只有一个SPD-I。

这个示例的目标是支持从 A 到 C 的传输模式 SA，通过从 A 到 B 的隧道模式 SA 进行传输。例如，A 可能是连接到公共互联网的笔记本电脑，B 可能是保护企业网络的防火墙，而 C 可能是企业网络上需要对 A 的流量进行端到端认证的服务器。

A 的 SPD 中包含以下形式的条目：

A 的未受保护侧转发表被设置为将发送到 C 的出站数据包回环到受保护侧。A 的受保护侧转发表被设置为将入站 ESP 数据包回环到未受保护侧。A 的转发表包含以下形式的条目：

从 A 到 C 的出站 TCP 数据包将匹配 SPD 规则 3，并应用传输模式下的 ESP。未受保护侧转发表将回环该数据包。数据包将与 SPD-I（见图2）进行比较，匹配 SPD 规则 1，因此将被绕过（BYPASS）。数据包被视为出站数据包，并再次与 SPD 进行比较。这一次，它匹配 SPD 规则 2，因此将以隧道模式下的 ESP 进行处理。这一次，转发表不会回环该数据包，因为外部目的地址是 B，所以数据包将发送到线路上。

从 C 到 A 的入站 TCP 数据包被包裹在两个 ESP 头部中；外部头部（ESP 隧道模式）显示 B 为源地址，而内部头部（ESP 传输模式）显示 C 为源地址。到达 A 后，根据 SPI，数据包将被映射到一个 SA，外部头部将被移除，并进行解密和完整性检查。然后，它将与该 SA 的 SAD 选择器进行匹配，这些选择器由 SPD 规则 2 指定，源地址为 C，目标地址为 A。受保护侧的转发功能将根据地址和下一层协议（ESP）将其发送回未受保护侧，表示嵌套。它与 SPD-O（见图 3）进行比较，并发现匹配 SPD 规则 1，因此将被绕过（BYPASS）。数据包根据 SPI 进行映射到一个 SA，进行完整性检查，并与由 SPD 规则 3 得到的 SAD 选择器进行比较。然后，转发功能将其传递给下一层，因为它不是一个 ESP 数据包。