正文共：32277字 31图，预估阅读时间：50 分钟
本备忘录规定了 IPsec 兼容系统的基本架构。该架构的目的是在 IPv4 和 IPv6 环境中为 IP 层的流量提供各种安全服务。本文档描述了此类系统的目的、它们的组件以及它们如何相互配合以及如何融入 IP 环境，它还描述了 IPsec 协议提供的安全服务，以及如何在 IP 环境中使用这些服务。本文档并未涉及 IPsec 体系结构的所有方面，后续文档将解决更高级的其他架构细节，例如，在 NAT 环境中使用 IPsec 以及对 IP 多播的更完整支持。以下 IPsec 安全体系结构的基本组件将根据它们的底层所需功能进行讨论。其他 RFC（参见第 1.3 节以获取指向其他文档的指针）定义了 （A）、（C）和（D） 中的协议。
A. 安全协议——认证报文头（Authentication Header，AH） 和封装安全载荷 （Encapsulating Security Payload，ESP）
B. 安全联盟——它们是什么以及它们如何工作、它们如何管理、相关处理
C. 密钥管理——手动和自动，互联网密钥交换（Internet Key Exchange，IKE）
D. 认证和加密算法
本文档不是 Internet 的整体安全架构；它仅在 IP 层解决安全问题，通过使用密码和协议安全机制的组合提供。
关键字 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY 和 OPTIONAL 在本文档中出现时，应按照 RFC 2119 [Bra97] 中的描述进行解释。
本文档的目的读者包括此 IP 安全技术的实施者和其他有兴趣了解此系统的一般背景知识的人。特别是，这项技术的潜在用户（最终用户或系统管理员）是目的受众的一部分。词汇表作为附录提供，以帮助填补背景/词汇方面的空白。本文档假设读者熟悉 Internet 协议、相关网络技术以及一般安全术语和概念。
如上所述，其他文档提供了 IPsec 的某些组件及其相互关系的详细定义。
它们包括关于以下主题的 RFC：
A. “IP安全文档路线图”[TDG97] ——为描述该系统中使用的加密和认证算法的规范提供指导的文档。
B. 安全协议——描述认证报文头 （Authentication Header ，AH） [KA98a] 和封装安全载荷（Encapsulating Security Payload ，ESP） [KA98b] 协议的 RFC。
C. 用于身份验证和加密的算法——每个算法都有一个单独的 RFC。
D. 自动密钥管理——关于“互联网密钥交换（Internet Key Exchange，IKE）”[HC98]、“互联网安全联盟和密钥管理协议（Internet Security Association and Key Management Protocol，ISAKMP）”[MSST97]、“OAKLEY 密钥确定协议”[Orm97] 和“ISAKMP 解释的 Internet IP 安全域”[Pip98]。
IPsec 旨在为 IPv4 和 IPv6 提供可互操作、高质量、基于密码的安全性。提供的一组安全服务包括访问控制、无连接完整性、数据源身份验证、重放保护（部分序列完整性的一种形式）、机密性（加密）和有限的流量流机密性，这些服务在 IP 层提供，为 IP层 和/或上层协议提供保护。
这些目的是通过使用两种流量安全协议-认证头 （AH） 和封装安全载荷 （ESP），以及通过使用加密密钥管理程序和协议来实现的。在任何场景中使用的 IPsec 协议集及其使用方式将由用户、应用程序和/或站点/组织的安全性和系统要求决定。
当这些机制被正确实施和部署时，它们不应该对没有使用这些安全机制来保护其流量的用户、主机和其他 Internet 组件产生不利影响。这些机制也被设计为与算法无关。这种模块化允许在不影响实现的其他部分的情况下选择不同的算法集。例如，如果需要，不同的用户社区可以选择不同的算法集（创建派系）。
指定了一组标准的默认算法以促进全球互联网中的互操作性。将这些算法与 IPsec 流量保护和密钥管理协议结合使用，旨在允许系统和应用程序开发人员部署高质量的网络层加密安全技术。
IPsec协议套件和相关的默认算法旨在为 Internet 流量提供高质量的安全性。但是，使用这些协议提供的安全性最终取决于它们的实现质量，这超出了这组标准的范围。此外，计算机系统或网络的安全性是许多因素的函数，包括人员、物理、程序、妥协下发和计算机安全实践。因此，IPsec只是整个系统安全架构的一部分。
最后，使用 IPsec 所提供的安全性严重依赖于执行 IPsec 实施的操作环境的许多方面。例如，操作系统安全性的缺陷、随机数源的质量差、杂乱的系统管理协议和操作等都会降低 IPsec 提供的安全性。如上所述，这些环境属性均不在此或其他 IPsec 标准的范围内。
本节对 IPsec 的工作原理、系统组件以及它们如何组合在一起以提供上述安全服务进行了高级描述。本说明的目的是使读者能够“想象”整个过程/系统，了解它如何适应 IP 环境，并为本文档的后面部分提供环境，这些部分更详细地描述了每个组件。
IPsec 实施在主机或安全网关环境中运行，为 IP 流量提供保护。提供的保护基于由用户或系统管理员建立和维护的安全策略数据库（Security Policy Database，SPD） 定义的要求，或者由在上述任一者建立的约束内运行的应用程序定义。通常，根据与数据库 （SPD） 中的条目匹配的 IP 和传输层报头信息（选择器，第 4.4.2 节），为三种处理模式之一选择数据包。根据选择器识别的适用数据库策略，每个数据包要么被提供 IPsec 安全服务，要么被丢弃，要么被允许绕过 IPsec。
IPsec 通过使系统能够选择所需的安全协议、确定用于服务的算法以及放置提供所请求的服务所需的任何加密密钥，在 IP 层提供安全服务。 IPsec 可用于保护一对主机之间、一对安全网关之间或安全网关与主机之间的一个或多个“路径”。 （在整个 IPsec 文档中使用的术语“安全网关”是指实现 IPsec 协议的中间系统。例如，实现 IPsec 的路由器或防火墙就是安全网关。）
IPsec 可以提供的一组安全服务包括访问控制、无连接完整性、数据源身份验证、重放数据包的拒绝（部分序列完整性的一种形式）、机密性（加密）和有限的流量流机密性。因为这些服务是在 IP 层提供的，所以它们可以被任何高层协议使用，例如 TCP、UDP、ICMP、BGP 等。
IPsec DOI 还支持 IP 压缩的协商 [SMPT98]，部分原因是观察到当在 IPsec 中使用加密时，它会阻止较低协议层的有效压缩。
IPsec 使用两种协议来提供流量安全——认证报文头 （Authentication Header，AH） 和封装安全载荷 （Encapsulating Security Payload，ESP）。这两种协议在它们各自的 RFC [KA98a, KA98b] 中有更详细的描述。
* IP认证报文头（AH） [KA98a] 提供无连接完整性、数据源身份验证和可选的抗重播服务。
* 封装安全载荷（ESP）协议 [KA98b] 可以提供机密性（加密）和有限的流量流机密性。它还可以提供无连接完整性、数据源身份验证和抗重放服务。（无论何时调用 ESP，都必须应用这些安全服务中的一组或另一组。）
* AH 和 ESP 都是访问控制的工具，基于加密密钥的分配和与这些安全协议相关的流量管理。
这些协议可以单独应用或相互组合应用，以提供一组所需的 IPv4 和 IPv6 安全服务。
每个协议支持两种使用模式：传输模式和隧道模式。在传输模式中，协议主要为上层协议提供保护；在隧道模式下，这些协议适用于隧道传输的 IP 数据包。两种模式之间的差异在第 4 节中讨论。
IPsec 允许用户（或系统管理员）控制提供安全服务的粒度。例如，可以创建单个加密隧道来承载两个安全网关之间的所有流量，或者可以为通过这些网关进行通信的每对主机之间的每个 TCP 连接创建单独的加密隧道。IPsec 管理必须包含用于指定的设施：
* 使用哪些安全服务以及使用哪些组合
* 应用应该给定安全保护的粒度
* 用于实现基于密码的安全性的算法
因为这些安全服务使用共享的秘密值（加密密钥），所以 IPsec 依赖于一套单独的机制来放置这些密钥。（密钥用于身份验证/完整性和加密服务。）本文档要求支持手动和自动分配密钥。它指定了一种特定的基于公钥的方法（IKE——[MSST97，Orm97，HC98]）用于自动密钥管理，但可以使用其他自动密钥分发技术。例如，可以使用基于 KDC 的系统（如 Kerberos）和其他公钥系统（如 SKIP）。
IPsec 可以通过多种方式在主机中实现，或者与路由器或防火墙结合使用（以创建安全网关）。下面提供了几个常见的例子：
A. 将 IPsec 集成到本地 IP 实现，这需要访问 IP 源代码，并且适用于主机和安全网关。
B. “Bump-in-the-stack” （BITS） 实现，IPsec在本地 IP 和本地网络驱动程序之间的 IP 协议栈的现有实现之下实现。在这种情况下不需要 IP 堆栈的源代码访问，这使得这种实现方法适用于遗留系统。当采用这种方法时，通常在主机中使用。
C. 外置加密处理器的使用是军方使用的网络安全系统以及一些商业系统的常见设计特征。它有时被称为“Bump-in-the-wire”（BITW）实现。此类实现可以设计为服务于主机或网关（或两者）。通常 BITW 设备是 IP 可寻址的。在支持单个主机时，它可能非常类似于 BITS 实现，但在支持路由器或防火墙时，它必须像安全网关一样运行。
本节定义了所有 IPv6 实现和那些实现 AH、ESP 或两者的 IPv4 实现的安全联盟管理要求。“安全联盟”（Security Association，SA） 的概念是 IPsec 的基础。 AH 和 ESP 都使用 SA，而 IKE 的一个主要功能是安全联盟的建立和维护，AH 或 ESP 的所有实现都必须支持安全联盟的概念，如下所述。本节的其余部分描述安全联盟管理的各个方面，定义 SA 策略管理、流量处理和 SA 管理技术所需的特征。
安全联盟 （SA） 是一个单一的“连接”，为其承载的流量提供安全服务。安全服务通过使用 AH 或 ESP 提供给 SA，但两者不能同时使用。如果对流量的流应用 AH 和 ESP 保护，则应创建两个（或更多）SA 以提供对流量流的保护。为了保护两个主机之间或两个安全网关之间的典型双向通信，需要两个安全联盟（每个方向一个）。
安全联盟由安全参数索引（Security Parameter Index ，SPI）、IP 目的地址和安全协议（AH 或 ESP）标识符组成的三元组唯一标识。原则上，目的地址可以是单播地址、IP广播地址或组播组地址。然而，IPsec SA 管理机制目前仅针对单播 SA 定义。因此，在接下来的讨论中，将在点对点通信的场景中描述 SA，即使该概念也适用于点对多点情况。
如上所述，定义了两种类型的 SA：传输模式和隧道模式。传输模式 SA 是两个主机之间的安全联盟。在 IPv4 中，传输模式安全协议头紧跟在 IP 头和任何选项之后，在任何更高层协议（例如 TCP 或 UDP）之前。在 IPv6 中，安全协议头出现在基本 IP 头和扩展之后，但可能出现在目的地选项之前或之后，以及更高层协议之前。在 ESP 的情况下，传输模式 SA 仅为这些更高层协议提供安全服务，而不是为 IP 标头或 ESP 标头之前的任何扩展标头提供安全服务。在 AH 的情况下，保护还扩展到 IP 标头的选定部分、扩展标头的选定部分和选定的选项（包含在 IPv4 标头、IPv6 Hop-by-Hop 扩展标头或 IPv6 Destination 扩展标头中）。有关 AH 提供的覆盖范围的更多详细信息，请参阅 AH 规范 [KA98a]。
隧道模式SA本质上是应用于IP隧道的SA。每当安全联盟的任一端是安全网关时，SA 必须是隧道模式。因此，两个安全网关之间的 SA 始终是隧道模式 SA，主机和安全网关之间的 SA 也是如此。请注意，对于流量以安全网关为目的地的情况，例如 SNMP 命令，安全网关充当主机并且允许传输模式。但在这种情况下，安全网关不充当网关，即不传输流量。两台主机可以在它们之间建立隧道模式 SA。由于需要避免与 IPsec 数据包的分段和重组有关的潜在问题，以及在多个路径（例如，通过不同的安全网关的情况下，需要将涉及安全网关的任何（传输流量）SA 要求为隧道 SA ） 存在于安全网关后面的同一目的地。
对于隧道模式 SA，有一个“外部”IP 标头指定 IPsec 处理目的地，加上一个“内部”IP 标头，指定数据包的（表面）最终目的地。安全协议头出现在外部 IP 头之后，内部 IP 头之前。如果在隧道模式下使用 AH，则外部 IP 报头的部分将受到保护（如上所述），以及所有隧道传输的 IP 数据包（即，所有内部 IP 报头都受到保护，以及更高层协议）。如果采用 ESP，则仅对隧道数据包提供保护，而不对外部报头提供保护。
总之，
a） 主机必须同时支持传输和隧道模式。
b） 要求安全网关仅支持隧道模式。如果它支持传输模式，则应仅在安全网关充当主机（例如，用于网络管理）时使用。
SA 提供的安全服务集取决于所选的安全协议、SA 模式、SA 的端点以及协议中可选服务的选择。例如，AH 为 IP 数据报提供数据源认证和无连接完整性（以下简称“认证”）。认证服务的“精度”是和使用 AH 的安全联盟的粒度相关，如第 4.4.2 节“选择器”中所述。
AH 还根据接收方的判断提供抗重放（部分序列完整性）服务，以帮助对抗拒绝服务攻击。当不需要保密（或不允许，例如，由于政府限制使用加密）时，AH 是一种合适的协议。 AH 还为 IP 报头的选定部分提供身份验证，这在某些情况下可能是必要的。例如，如果必须在发送方和接收方之间的路由中保护 IPv4 选项或 IPv6 扩展标头的完整性，AH 可以提供此服务（IP 标头中不可预测但可变的部分除外）。
ESP 可选择为流量提供机密性。（机密性服务的强度部分取决于所采用的加密算法。）ESP 还可以可选地提供身份验证（如上定义）。如果为 ESP SA 协商了身份验证，则接收方还可以选择执行具有与 AH 抗重放服务相同功能的抗重放服务。 ESP 提供的认证范围比 AH 小，即 ESP 标头“外部”的 IP 标头不受保护。如果只需要对上层协议进行身份验证，那么 ESP 身份验证是一个合适的选择，并且比使用 AH 封装 ESP 更节省空间。请注意，尽管机密性和身份验证都是可选的，但不能同时省略，必须至少选择其中之一。
如果选择机密性服务，则两个安全网关之间的 ESP（隧道模式）SA 可以提供部分流量流机密性。隧道模式的使用允许对内部 IP 报头进行加密，从而隐藏（最终）流量源和目的地的身份。此外，还可以调用 ESP 有效载荷填充来隐藏数据包的大小，进一步隐藏流量的外部特征。当移动用户在拨号场景中被分配动态 IP 地址并建立到公司防火墙（充当安全网关）的（隧道模式）ESP SA 时，可以提供类似的流量保密服务。请注意，细粒度 SA 通常比承载来自许多租户的流量的粗粒度 SA 更容易受到流量分析的影响。
通过单个 SA 传输的 IP 数据报仅由一种安全协议（AH 或 ESP）提供保护，但不能同时使用两者。有时，安全策略可能需要针对特定流量流的服务组合，这是单个 SA 无法实现的。在这种情况下，有必要使用多个 SA 来实施所需的安全策略。术语“安全联盟捆绑”或“SA 捆绑”适用于必须通过其处理流量以满足安全策略的 SA 序列。序列的顺序由策略定义。（请注意，组成捆绑的 SA 可能终止于不同的端点。例如，一个 SA 可能会在移动主机和安全网关之间扩展，而第二个嵌套的 SA 可能会扩展到网关后面的主机。）
安全联盟可以通过两种方式组合成捆绑：传输邻接和迭代隧道。
* 传输邻接是指将多个安全协议应用于同一个 IP 数据报，而不调用隧道。这种将 AH 和 ESP 结合起来的方法只允许一种水平的结合；进一步嵌套不会产生额外的好处（假设在每个协议中使用足够强大的算法），因为处理是在（最终）目的地的一个 IPsec 实例上执行的。
* 迭代隧道是指通过 IP 隧道应用多层安全协议。 这种方法允许多级嵌套，因为每个隧道可以沿路径在不同的 IPsec 站点发起或终止。除了可以通过适当的 SPD 条目指定的内容外，预计不会对中间安全网关的 ISAKMP 流量进行特殊处理（请参阅第 4.5 节中的案例 3）
迭代隧道有 3 种基本情况——仅对情况 2 和 3 需要支持：
1. SA 的两个端点是相同的——内部和外部隧道都可以是 AH 或 ESP，尽管主机 1 不太可能将两者指定为相同，即 AH 在 AH 内或 ESP 在 ESP内。
2. SA 的一个端点是相同的——内部隧道和外部隧道都可以是 AH 或 ESP。
3. 两个端点都不相同——内部和外部隧道都可以是 AH 或 ESP。
这两种方法也可以组合，例如，可以从一个隧道模式 SA 和一个或两个传输模式 SA 构建一个 SA捆绑，依次应用。 （请参阅第 4.5 节“安全联盟的基本组合”。）请注意，嵌套隧道也可能发生在任何隧道的源端点和目的端点都不相同的情况下。在这种情况下，将没有主机或安全网关具有与嵌套隧道对应的捆绑包。
对于传输模式 SA，似乎只有一种安全协议排序是合适的。AH 应用于上层协议和（部分）IP 报头。因此，如果 AH 用于传输模式，与 ESP 一起使用，AH 应该作为 IP 之后的第一个标头出现，在 ESP 出现之前。在这种情况下，AH 应用于 ESP 的密文输出。相比之下，对于隧道模式 SA，可以想象 AH 和 ESP 的各种排序用途。第 4.5 节描述了兼容 IPsec 实现必须支持的 SA 捆绑类型集。
在 IPsec 实现中与处理 IP 流量相关的许多细节主要是本地事务，不受标准化的约束。但是，处理的某些外部方面必须标准化，以确保互操作性并提供对 IPsec 的有效使用必不可少的最低管理能力。本节描述处理与安全联盟相关的 IP 流量的通用模型，以支持这些互操作性和功能目的。下面描述的模型是名义上的；兼容的实现不需要匹配这个模型的细节，但是这种实现的外部行为必须可以映射到这个模型的外部可观察特征。
该模型中有两个名义数据库：安全策略数据库和安全联盟数据库。前者指定了确定从主机、安全网关或 BITS 或 BITW IPsec 实现入站或出站的所有 IP 流量的处置的策略。后一个数据库包含与每个（活动的）安全联盟相关联的参数。本节还定义了选择器的概念，安全策略数据库使用一组 IP 和上层协议字段值将流量映射到策略，即 SA（或 SA捆绑）。
由于用作选择器的许多字段的方向性，启用了 IPsec 的每个接口都需要名义上独立的入站数据库和出站数据库（SAD 和 SPD）。通常只有一个这样的接口，用于主机或安全网关（security gateway，SG）。请注意，SG 始终至少有 2 个接口，但连接到公司网络的“内部”接口通常不会启用 IPsec，因此只需要一对 SAD 和一对 SPD。另一方面，如果主机有多个接口或 SG 有多个外部接口，则可能需要为每个接口使用单独的 SAD 和 SPD 对。
归根结底，安全联盟是一种管理结构，用于在 IPsec 环境中实施安全策略。因此，SA 处理的一个基本要素是一个底层安全策略数据库（SPD），它指定将向 IP 数据报提供哪些服务以及以何种方式提供。数据库的形式及其接口不在本规范的范围内。但是，本部分确实指定了必须提供的某些最低管理功能，以允许用户或系统管理员控制如何将 IPsec 应用于主机或通过安全网关传输或接收的流量。
在处理所有流量（入站和出站）期间必须查询SPD，包括非 IPsec 流量。为了支持这一点，SPD 需要为入站和出站流量提供不同的条目。可以将其视为单独的 SPD（入站与出站）。此外，必须为每个启用 IPsec 的接口提供名义上独立的 SPD。
SPD 必须区分提供 IPsec 保护的流量和允许绕过 IPsec 的流量。这适用于发送方应用的 IPsec 保护和接收方必须提供的 IPsec 保护。对于任何出站或入站数据报，可能有三种处理选择：丢弃、绕过 IPsec 或应用 IPsec。第一种选择是指不允许离开主机、穿越安全网关或根本不允许传送到应用程序的流量。第二种选择是指无需额外 IPsec 保护就允许通过的流量。第三种选择是指提供 IPsec 保护的流量，对于此类流量，SPD 必须指定要提供的安全服务、要使用的协议、要使用的算法等。
对于每个 IPsec 实现，必须有一个管理界面，允许用户或系统管理员管理 SPD。具体来说，每个入站或出站数据包都由 IPsec 处理，并且 SPD 必须指定在每种情况下将采取的操作。因此，管理界面必须允许用户（或系统管理员）逐个数据包指定要应用于进入或退出系统的任何数据包的安全处理。（在使用套接字接口的主机 IPsec 实现中，可能不需要在每个数据包的基础上查询SPD，但效果仍然相同。）SPD 的管理接口必须允许创建与选择器在第 4.4.2 节中定义，并且必须支持这些条目的（总）排序。预计通过在各种选择器字段中使用通配符，并且由于单个 UDP 或 TCP 连接上的所有数据包将倾向于匹配单个 SPD 条目，因此该要求不会强加不合理的详细级别的SPD规范。选择器类似于无状态防火墙或过滤路由器中的选择器，目前可以通过这种方式进行管理。
在主机系统中，可以允许应用程序选择对它们生成和消耗的流量应用什么安全处理。（向 IPsec 实现发送此类请求的方法超出了本标准的范围。）然而，系统管理员必须能够指定用户或应用程序是否可以覆盖（默认）系统策略。请注意，应用程序指定的策略可能满足系统要求，因此系统可能不需要进行超出满足应用程序要求所需的额外 IPsec 处理。本文档未指定管理接口的形式，并且可能因主机与安全网关而异，并且在主机内，基于套接字与 BITS 实现的接口可能不同。但是，本文档确实指定了所有 IPsec 实现必须支持的标准 SPD 元素集。
SPD 包含一个有序的策略条目列表。每个策略条目都由一个或多个选择器作为键，这些选择器定义了该策略条目包含的一组 IP 流量，（所需的选择器类型在第 4.4.2 节中定义。）这些定义了策略或 SA 的粒度。每个条目都包含与此策略匹配的流量是否将被绕过、丢弃或接受 IPsec 处理的指示。如果要应用 IPsec 处理，则该条目包括 SA（或 SA 捆绑）规范，列出要采用的 IPsec 协议、模式和算法，包括任何嵌套要求。例如，一个条目可能要求所有匹配的流量在传输模式下由 ESP 保护，使用 3DES-CBC 和显式 IV，使用 HMAC/SHA-1 在隧道模式下嵌套在 AH 内部。对于每个选择器，策略条目指定如何从 SPD 和数据包中的值中为新的安全联盟数据库（SAD，参见第 4.4.3 节）条目导出相应的值（请注意，目前，范围仅支持 IP地址；但可以为所有选择器表示通配符）：
A. 使用数据包本身的值——这会将 SA 的使用限制为那些具有该数据包的选择器值的数据包，即使策略条目的选择器具有允许值范围或此选择器的通配符。
B. 使用与策略条目关联的值——如果这只是一个值，那么 （B） 和 （A） 之间将没有区别。但是，如果选择器的允许值是一个范围（对于 IP 地址）或通配符，那么在范围的情况下，（B） 将允许任何具有该范围内选择器值的数据包使用 SA，而不仅仅是通过具有触发 SA 创建的数据包的选择器值的数据包。在通配符的情况下，（B）将允许具有此选择器的任何值的数据包使用 SA。
例如，假设有一个 SPD 条目，其中源地址的允许值是主机范围（192.168.2.1 到 192.168.2.10）中的任何一个。假设要发送一个源地址为 192.168.2.3 的数据包。用于 SA 的值可以是以下任何示例值，具体取决于此选择器的策略条目所说的是选择器值的来源：
请注意，如果 SPD 条目的源地址允许使用通配符值，则 SAD 选择器值可以是通配符（任何主机）。情况（A）可用于禁止共享，即使在匹配相同 SPD 条目的数据包之间也是如此。
如下文第 4.4.3 节所述，选择器可能包含“通配符”条目，因此两个条目的选择器可能会重叠。（这类似于路由器或包过滤防火墙中的 ACL 或过滤器条目出现的重叠。）因此，为了确保一致的、可预测的处理，必须对 SPD 条目进行排序，并且必须始终以相同的顺序搜索 SPD，以便始终选择第一个匹配条目。（此要求是必要的，因为根据 SPD 条目处理流量的影响必须是确定性的，但由于某些选择器使用通配符，因此无法规范化 SPD 条目。）有关数据包与 SPD 条目匹配的更多详细信息，请参阅第5节。
请注意，如果指定了 ESP，则可以省略（但不是两者）身份验证或加密。因此必须可以将认证或加密算法的 SPD 值配置为“NULL”。但是，必须至少选择这些服务中的一个，即不能将它们都配置为“NULL”。
SPD 可用于将流量映射到特定的 SA 或 SA捆绑。因此，它既可以用作安全策略的参考数据库，也可以用作到现有 SA（或 SA捆绑）的映射。（为了适应上面引用的绕过和丢弃策略，SPD 还必须提供一种将流量映射到这些功能的方法，即使它们本身不处理IPsec。）SPD 的运行方式对于入站和入站是不同的. 出站流量，它也可能因主机与安全网关、BITS 和 BITW 实现而异。第 5.1 节和第 5.2 节分别描述了 SPD 用于出站和入站处理的使用。
由于安全策略可能要求将多个 SA 应用于指定的一组流量，因此按特定顺序，SPD 中的策略条目必须保留这些顺序要求（如果存在）。因此，IPsec 实现必须能够确定必须通过一系列 SA 来处理出站或入站数据包。从概念上讲，对于出站处理，人们可能会想象从一个 SPD 条目的链接（到 SAD），其中有活动 SA，每个条目将由单个 SA 或组成 SA捆绑的 SA 有序列表组成。当数据包与 SPD 条目匹配并且存在可用于承载流量的现有 SA 或 SA捆绑时，该数据包的处理由列表中的 SA 或 SA捆绑条目控制。对于要应用多个 IPsec SA 的入站 IPsec 数据包，基于目的地址、IPsec 协议和 SPI 的查找应识别单个 SA。
SPD 用于控制通过 IPsec 系统的所有流量，包括来自/去往安全网关后面实体的安全和密钥管理流量（例如，ISAKMP）。这意味着 ISAKMP 流量必须在 SPD 中明确说明，否则将被丢弃。请注意，安全网关可以通过各种方式禁止加密数据包的遍历，例如，在 SPD 中为 ESP 数据包设置一个 DISCARD 条目或提供代理密钥交换。在后一种情况下，流量将在内部路由到安全网关中的密钥管理模块。
SA（或 SA捆绑）可以是细粒度的或粗粒度的，具体取决于用于定义 SA 流量集的选择器。例如，两个主机之间的所有流量都可以通过单个 SA 承载，并提供一组统一的安全服务。或者，一对主机之间的流量可能分布在多个 SA 上，这取决于正在使用的应用程序（由 Next Protocol 和 Port 字段定义），不同 SA 提供不同的安全服务。类似地，一对安全网关之间的所有流量都可以在单个 SA 上承载，或者可以为每个通信主机对分配一个 SA。SA 管理必须支持以下选择器参数，以便于控制 SA 粒度。请注意，在接收带有 ESP 标头的数据包的情况下，例如，在封装安全网关或 BITW 实现中，传输层协议、源/目的端口和名称（如果存在）可能是“OPAQUE”，即，由于加密或碎片而无法访问。另请注意，源地址和目的地址均应为 IPv4 或 IPv6。
- 目的IP 地址（IPv4 或 IPv6）：这可能是单个 IP 地址（单播、任播、广播【仅限 IPv4】或多播组）、地址范围（高值和低值【含】）、地址 + 掩码、或通配符地址。后三个用于支持多个共享相同 SA 的目的系统（例如，在安全网关后面）。请注意，此选择器在概念上与用于唯一标识一个SA的<目的IP地址，IPsec协议，SPI>三元组中的“Destination IP Address”字段不同，当一个隧道包到达隧道端点时，它的SPI/Destination address/Protocol用于在SAD中查找这个包的SA，这个目的地址来来自封装的 IP 标头。
一旦数据包根据隧道 SA 被处理并离开隧道，它的选择器就会在入站 SPD 中“查找”。入站 SPD 有一个称为目的地址的选择器。此 IP 目的地址是内部（封装的）IP 标头中的地址。在传输数据包的情况下，将只有一个 IP 报头并且这种歧义不存在。 [所有实现都需要]
- 源 IP 地址（IPv4 或 IPv6）：这可能是单个 IP 地址（单播、任播、广播【仅限 IPv4】或多播组）、地址范围（包括高值和低值）、地址 + 掩码，或通配符地址。最后三个用于支持共享相同 SA 的多个源系统（例如，在安全网关后面或在多宿主主机中）。[所有实现都需要]
- 名称：有 2 种情况（请注意，IPsec DOI 支持这些名称形式。）
1. 用户名
A. 完全限定的用户名字符串 （DNS），例如 mozart@foo.bar.com
B. X.500 专有名称，例如，C = US，SP = MA，O = GTE Internetworking，CN = Stephen T. Kent。
2. 系统名称（主机、安全网关等）
A. 完全限定的 DNS 名称，例如 foo.bar.com
B. X.500 专有名称
C. X.500 通用名称
注意：此选择器的可能值之一是“OPAQUE”。
[以下情况需要。请注意，手动键入的 SA 不需要支持除地址以外的名称形式。
* 用户身份
- 本地主机实现
- BITW 和 BITS 实现充当只有一个用户的 HOSTS
- 用于入站处理的安全网关实现。
* 系统名称——所有实现]
- 数据敏感度级别：（IPSO/CIPSO 标签）
[根据第 8 节提供信息流安全的所有系统是必需的，对于所有其他系统是可选的。]
- 传输层协议：从 IPv4“协议”或 IPv6“下一个报头”字段获得。这可能是一个单独的协议编号。由于存在 IP 扩展标头，例如路由标头、AH、ESP、分段标头、目的地选项、逐跳选项等，这些数据包字段可能不包含传输协议。请注意，传输协议可能不包含在收到带有 ESP 报头的数据包的情况下可用，因此应支持“OPAQUE”值。[所有实现都需要]
注意：要定位传输协议，系统必须通过检查“协议”或“下一个标头”字段的数据包标头进行链接，直到遇到它识别为传输协议的一个，或者直到它遇到一个未启用的传输协议它的扩展头列表，或者直到它遇到一个使传输协议不透明的 ESP 头。
- 源和目的（例如 TCP/UDP）端口：这些可能是单独的 UDP 或 TCP 端口值或通配符端口。（使用下一个协议字段和源和/或目的端口字段（结合源和/或目的地址字段）作为 SA 选择器有时被称为“面向会话的键控”）。请注意，在收到带有 ESP 标头的数据包的情况下，源端口和目的端口可能不可用，因此应支持“OPAQUE”值。
下表总结了数据包和 SPD 中的“Next Header”值与 SPD 和 SAD 的派生端口选择器值之间的关系。
如果数据包已被分段，则当前分段中可能没有端口信息。如果是，则丢弃该片段。应该为第一个片段发送一个 ICMP PMTU，它将包含端口信息。[可能支持]
IPsec 实现场景决定了如何使用选择器。例如，集成到堆栈中的主机实现可以使用套接字接口。当建立新连接时，可以查询 SPD 并将 SA（或 SA捆绑）绑定到套接字。因此，通过该套接字发送的流量不需要对 SPD/SAD 进行额外的查找。相比之下，BITS、BITW 或安全网关实现需要查看每个数据包并根据选择器执行 SPD/SAD 查找。选择器字段的允许值因流量、安全联盟和安全策略而异。
下表总结了需要能够在 SPD 和 SAD 中表达的条目类型，它显示了它们与受 IPsec 筛选的数据流量领域的关系。
（注意：src 和 dst 地址的“wild”或“wildcard”条目包括掩码、范围等）
* 这些字段的 SAD 和 SPD 条目可能是“OPAQUE”，因为流量值是加密的。
注意：原则上，SPD 中可以有选择器和/或选择器值，这些值不能为 SA 或 SA捆绑协商。
示例可能包括用于选择流量以进行丢弃或枚举列表的选择器值，这会导致为列表中的每个项目创建单独的 SA。目前，这留给本文档的未来版本使用，并且 SPD 和 SAD 所需的选择器和选择器值的列表是相同的。然而，拥有一个支持使用无法协商的选择器值的管理界面是可以接受的，前提是它不会误导用户相信它正在使用这些选择器值创建 SA。例如，界面可能允许用户指定枚举值列表，但会导致为列表中的每个项目创建单独的策略和 SA。供应商可能支持这样的接口，以使其客户更容易指定清晰简洁的策略规范。
在每个 IPsec 实现中，都有一个名义上的安全联盟数据库，其中每个条目定义与一个 SA 联盟的参数。每个 SA 在 SAD 中都有一个条目。对于出站处理，SPD 中的条目指向条目。请注意，如果 SPD 条目当前未指向适合该数据包的 SA，则实现会创建一个合适的 SA（或 SA捆绑）并将 SPD 条目链接到 SAD 条目（参见第 5.1.1 节）。对于入站处理，SAD 中的每个条目都按目的IP 地址、IPsec 协议类型和 SPI 进行索引。以下参数与 SAD 中的每个条目相关联。此描述并不声称是 MIB，而只是对在 IPsec 实现中支持 SA 所需的最少数据项的规范。
对于入站处理：以下数据包字段用于在 SAD 中查找 SA：
* Outer Header 的目的IP 地址：IPv4 或 IPv6 目的地址。
[所有实现都需要]
* IPsec 协议：AH 或 ESP，用作此数据库中 SA 查找的索引。指定要应用于此 SA 上的流量的 IPsec 协议。
[所有实现都需要]
* SPI：32 位值，用于区分在同一目的地终止并使用相同 IPsec 协议的不同 SA。
[所有实现都需要]
对于第 4.4.2 节中定义的每个选择器，SAD 中的 SA 条目必须包含在创建 SA 时协商的一个或多个值。对于发送方，这些值用于决定给定的 SA 是否适合与出站数据包一起使用。这是检查是否存在可以使用的现有 SA 的一部分。对于接收方，这些值用于检查入站数据包中的选择器值是否与 SA 的值匹配（从而间接匹配匹配策略的值）。对于接收方，这是验证 SA 是否适合该数据包的一部分。 （有关 ICMP 消息的规则，请参阅第 6 节。）这些字段可以具有特定值、范围、通配符或“OPAQUE”的形式，如第 4.4.2 节“选择器”中所述。请注意，对于 ESP SA，加密算法或身份验证算法可以是“NULL”。然而，它们不能都是“NULL”。
以下 SAD 字段用于进行 IPsec 处理：
* 序列号计数器：一个 32 位的值，用于在 AH 或 ESP 头中生成序列号字段。
[所有实现都需要，但仅用于出站流量。]
* 序列计数器溢出：指示序列号计数器溢出是否应生成可审计事件并防止在 SA 上传输额外数据包的标志。
[所有实现都需要，但仅用于出站流量。]
* 抗重放窗口：一个 32 位计数器和一个位图（或等效的）用于确定入站 AH 或 ESP 数据包是否是重放。
[所有实现都需要，但仅用于入站流量。注意：如果接收器已禁用抗重放，例如，在手动键入 SA 的情况下，则不使用抗重放窗口。]
* AH 认证算法、密钥等
[AH 实现需要]
* ESP 加密算法、密钥、IV 模式、IV 等。
[ESP 实施需要]
* ESP 认证算法、密钥等。如果未选择认证服务，此字段将为空。
[ESP 实施需要]
* 此安全联盟的生命周期：SA 必须用新 SA（和新 SPI）替换或终止之前的时间间隔，以及应发生哪些操作的指示。这可以表示为时间或字节计数，或同时使用两者，第一个到期的生命周期优先。一个兼容的实现必须支持两种类型的生命周期，并且必须支持同时使用两者。如果使用时间，并且如果 IKE 使用 X.509 证书来建立 SA，则 SA 生存期必须受证书的有效间隔以及 SA 的 IKE 交换中使用的 CRL 的 NextIssueDate 的约束。发起者和响应者都负责以这种方式限制 SA 生存期。
[所有实现都需要]
注意：SA 过期时如何处理密钥刷新的细节是本地问题。但是，一种合理的方法是：
（A） 如果使用字节计数，那么实现应该计算应用 IPsec 算法的字节数。对于ESP，这是加密算法（包括Null 加密），对于AH，这是认证算法。这包括填充字节等。请注意，实现应该能够处理 SA 末端的计数器不同步的情况，例如，由于数据包丢失或因为 SA 两端的实现不做任何事情一样的方法。
（B） 应该有两种生命周期——软生命周期，它警告实现启动诸如设置替换 SA 之类的操作，以及当前 SA 结束时的硬生命周期。
（C） 如果整个数据包在 SA 生命周期内没有被传递，则该数据包应该被丢弃。
* IPsec 协议模式：隧道、传输或通配符。
该SA上的流量应用AH模式还是ESP模式。请注意，如果此字段在 SA 的发送端是“通配符”，则应用程序必须指定 IPsec 实现的模式。通配符的这种使用允许在每个数据包的基础上（例如，通过不同的套接字）将相同的 SA 用于隧道或传输模式流量。接收方无需知道模式即可正确处理数据包的 IPsec 标头。
[要求如下，除非由场景隐式定义：
- 主机实现必须支持所有模式
- 网关实现必须支持隧道模式]
注意：对入站 SA 的协议模式使用通配符可能会增加接收器（仅限主机）情况的复杂性。由于此类 SA 上的数据包可以以隧道或传输模式传递，因此传入数据包的安全性可能部分取决于使用哪种模式传递它。因此，如果应用程序关心给定数据包的 SA 模式，则应用程序将需要一种机制来获取此模式信息。
* 路径 MTU：任何观察到的路径 MTU 和老化变量。见第 6.1.2.4 节
[所有实现都需要，但仅用于出站流量]
本节描述了兼容 IPsec 主机或安全网关必须支持的安全联盟组合的四个示例。隧道和/或传输模式中的 AH 和/或 ESP 的附加组合可以由实施者自行决定支持。兼容的实现必须能够生成这四种组合并在接收时处理它们，但应该能够接收和处理任何组合。下面的图表和文字描述了基本情况。图表的图例是：
==== = 一个或多个安全联盟（AH 或 ESP、传输或隧道）
---- = 连通性（或如果标记为行政边界）
Hx = 主机 x
SGx = 安全网关 x
X* = X 支持 IPsec
注意：下面的安全联盟可以是 AH 或 ESP。模式（隧道与传输）由端点的性质决定。对于主机到主机 SA，模式可以是传输或隧道。
案例 1，通过 Internet（或 Intranet）在 2 台主机之间提供端到端安全的案例。
请注意，主机可以选择传输模式或隧道模式。因此，H1 和 H2 之间的数据包中的标头可能如下所示：
请注意，没有要求支持通用嵌套，但在传输模式下，AH 和 ESP 都可以应用于数据包。在这种情况下，SA 建立过程必须确保首先 ESP，然后是 AH 应用于数据包。
案例 2，此案例说明了简单的虚拟专用网络支持。
这里只需要隧道模式。因此，SG1 和 SG2 之间的数据包中的标头可能如下所示：
案例 3，本案例结合了案例 1 和案例 2，在发送和接收主机之间增加了端到端的安全性。它对主机或安全网关没有任何新要求，只是要求安全网关可配置为为其后面的主机传递 IPsec 流量（包括 ISAKMP 流量）。
案例 4，这包括远程主机 （H1） 使用 Internet 到达组织的防火墙 （SG2） 然后访问某些服务器或其他机器 （H2） 的情况。远程主机可以是移动主机（H1）拨号到 Internet 上的本地 PPP/ARA 服务器（未显示），然后穿过 Internet 到达归属组织的防火墙（SG2）等。支持这种情况的详细信息,（H1 如何定位 SG2，对其进行身份验证，并验证其代表 H2 的授权）在第 4.6.3 节“定位安全网关”中讨论。
H1和SG2之间只需要隧道模式。因此，H1 和 SG2 之间的 SA 选择将是情况 2 中的选择之一。 H1 和 H2 之间的 SA 选择将是情况 1 中的选择之一。
请注意，在这种情况下，发送方必须在隧道头之前应用传输头。因此，管理界面的SPD的IPsec实现必须支持的配置和SAD保证的IPsec头应用这种排序。
如上所述，对 AH 和 ESP 的其他组合的支持是可选的。使用其他可选组合可能会对互操作性产生不利影响。
IPsec 要求支持手动和自动 SA 和加密密钥管理。 IPsec 协议 AH 和 ESP 在很大程度上独立于相关的 SA 管理技术，尽管所涉及的技术确实会影响这些协议提供的某些安全服务。例如，可用于 AH 和 ESP 的可选抗重放服务需要自动化 SA 管理。此外，与 IPsec 一起使用的密钥分发粒度决定了提供的身份验证的粒度。 （另请参阅第 4.7 节中对此问题的讨论。）一般而言，AH 和 ESP 中的数据源身份验证受到身份验证算法（或创建此类机密的密钥管理协议）使用的机密共享程度的限制在多个可能的来源中。
以下文本描述了这两种 SA 管理的最低要求。
最简单的管理形式是手动管理，其中一个人用与其他系统的安全通信相关的密钥材料和安全联盟管理数据手动配置每个系统。手工配置在小型静态环境中很实用，但它们不能很好地扩展。例如，公司可以在多个站点的安全网关中使用 IPsec 创建虚拟专用网络（VPN）。如果站点数量很少，并且由于所有站点都在单个管理域的范围内，这可能是手动管理技术的可行场景。在这种情况下，安全网关可能会使用手动配置的密钥有选择地保护进出组织内其他站点的流量，而不保护其他目的地的流量。当只需要保护选定的通信时，它也可能是合适的。类似的论点可能适用于完全在组织内为少量主机和/或网关使用 IPsec。手动管理技术通常采用静态配置的对称密钥，但也存在其他选项。
IPsec 的广泛部署和使用需要符合 Internet 标准的、可扩展的、自动化的 SA 管理协议。 需要这种支持来促进 AH 和 ESP 的抗重放功能的使用，并适应 SA 的按需创建，例如，用于面向用户和会话的密钥。（请注意，“重新加密”SA 的概念实际上意味着使用新 SPI 创建新 SA，该过程通常意味着使用自动化 SA/密钥管理协议。）
选择用于 IPsec 的默认自动密钥管理协议是 IPsec 解释域 [Pip98] 下的 IKE [MSST97、Orm97、HC98]。可以采用其他自动化 SA 管理协议。
当采用自动化 SA/密钥管理协议时，该协议的输出可用于生成多个密钥，例如，用于单个 ESP SA。这可能是因为：
* 加密算法使用多个密钥（例如，三重 DES）
* 认证算法使用多个密钥
* 采用加密和认证算法
密钥管理系统可以为每个密钥提供一个单独的位串，或者它可以生成一个位串，从中提取所有这些位。如果提供单个位串，则需要注意确保将位串映射到所需密钥的系统部分在 SA 的两端以相同的方式执行此操作。为了确保 SA 每一端的 IPsec 实现对相同的密钥使用相同的比特，并且不管系统的哪个部分将比特串分成单独的密钥，加密密钥必须从第一个（最左边的，高阶）位和认证密钥必须从其余位中取出。每个密钥的位数在相关算法规范 RFC 中定义。在多个加密密钥或多个认证密钥的情况下，算法规范必须指定从提供给算法的单个位串中选择它们的顺序。
本节讨论与主机如何了解相关安全网关的存在以及主机联系这些安全网关后如何知道这些是正确的安全网关的相关问题。所需信息存储位置的详细信息是本地事务。
考虑这样一种情况，其中远程主机 （H1） 正在使用 Internet 访问服务器或其他机器 （H2），并且存在安全网关 （SG2），例如防火墙，H1 的流量必须通过该网关。这种情况的一个例子是移动主机 （Road Warrior） 穿过 Internet 到达家庭组织的防火墙 （SG2）。 （请参阅 4.5 安全联盟的基本组合部分中的案例 4。）这种情况引发了几个问题：
1、H1如何知道/获知安全网关SG2的存在？
2、它如何验证SG2，一旦验证了SG2，它如何确认SG2已被授权代表H2？
3、SG2 如何验证 H1 并验证 H1 是否有权联系 H2？
4、H1 如何知道/了解为 H2 提供备用路径的备用网关？
为了解决这些问题，主机或安全网关必须有一个管理接口，允许用户/管理员为任何需要使用的目的地址集配置安全网关的地址。这包括配置的能力：
* 用于定位和验证安全网关以及验证其代表目的主机的授权的必要信息。
* 用于定位和验证任何备份网关并验证其代表目的主机的授权的必要信息。
假设 SPD 还配置了策略信息，该信息涵盖了到安全网关和目的主机的路径的任何其他 IPsec 要求。
本文档不解决如何自动发现/验证安全网关的问题。
安全联盟的接收方导向意味着，在单播流量的情况下，目的系统通常会选择 SPI 值。通过让目的地选择 SPI 值，手动配置的安全联盟不会与自动配置的（例如，通过密钥管理协议）安全联盟或来自多个来源的安全联盟相互冲突。对于多播流量，每个多播组有多个目的系统。因此，某些系统或个人需要在所有多播组之间进行协调，以代表每个多播组选择一个或多个 SPI，然后通过此处未定义的机制将该组的 IPsec 信息传达给该多播组的所有合法成员。
当采用对称密钥加密或认证算法时，多播组的多个发送者应该为该组的所有流量使用单个安全联盟（以及安全参数索引）。在这种情况下，接收者只知道消息来自拥有该组播组密钥的系统。在这种情况下，接收者通常无法验证哪个系统发送了多播流量。其他更一般的多播情况的规范推迟到以后的 IPsec 文档中。
在本规范发布时，用于多播密钥分发的自动化协议还没有被认为足够成熟以进行标准化。对于成员相对较少的多播组，手动密钥分发或多次使用现有的单播密钥分发算法（例如修改后的 Diffie-Hellman）似乎是可行的。对于非常大的群体，将需要新的可扩展技术。该领域当前工作的一个例子是组密钥管理协议（GKMP）[HM97]。
如第 4.4.1 节“安全策略数据库 （SPD）”所述，在处理所有流量（入站和出站）期间必须查询 SPD，包括非 IPsec 流量。如果在 SPD 中找不到匹配数据包的策略（对于入站或出站流量），则必须丢弃该数据包。
注意：IPsec 中使用的所有加密算法都期望它们以规范网络字节顺序输入（参见 RFC 791 中的附录），并以规范网络字节顺序生成它们的输出。 IP 数据包也按网络字节顺序传输。
在安全网关或 BITW 实现中（以及在许多 BITS 实现中），每个出站数据包都与 SPD 进行比较，以确定数据包需要进行哪些处理。如果要丢弃数据包，则这是一个可审计事件。如果允许流量绕过 IPsec 处理，则数据包将继续通过 IPsec 处理所在环境的“正常”处理。如果需要 IPsec 处理，则将数据包映射到现有 SA（或 SA捆绑），或为数据包创建新的 SA（或 SA捆绑）。由于数据包的选择器可能匹配多个策略或多个现存的 SA，并且 SPD 是有序的，但 SAD 不是，IPsec 必须：
1. 将数据包的选择器字段与 SPD 中的出站策略进行匹配，以定位第一个合适的策略，该策略将指向 SAD 中的零个或多个 SA捆绑。
2. 将数据包的选择器字段与 （1） 中找到的 SA捆绑中的字段进行匹配，以定位第一个匹配的 SA捆绑。如果未找到 SA 或没有匹配项，则创建适当的 SA捆绑并将 SPD 条目链接到 SAD 条目。如果未找到密钥管理实体，则丢弃该数据包。
3. 使用在 （2） 中找到/创建的 SA捆绑进行所需的 IPsec 处理，例如，验证和加密。
在基于套接字的主机 IPsec 实现中，每当创建新套接字时都会咨询 SPD，以确定将应用什么 IPsec 处理（如果有的话）将在该套接字上流动的流量。
注意：一个兼容的实现必须不允许实例化一个使用 NULL 加密和一个 NULL 认证算法的 ESP SA。尝试协商这样的 SA 是一个可审计的事件。
本节描述了内部和外部 IP 报头、扩展报头以及 AH 和 ESP 隧道选项的处理。这包括如何构造封装（外部）IP 头，如何处理内部IP 头中的字段，以及应采取哪些其他操作。总体思路是根据 RFC 2003“IP 封装与 IP”中使用的思路建模的：
* 外部 IP 标头 Source Address 和 Destination Address 标识隧道的“端点”（封装器和解封装器）。内部 IP 标头 Source Address 和 Destination Addresses 分别标识数据报的原始发送方和接收方（从该隧道的角度来看）。 （有关封装源IP地址的更多详细信息，请参见5.1.2.1表后的脚注3。）
* 内部 IP 报头不会改变，除非如下所述减少 TTL，并且在其传送到隧道出口点期间保持不变。
* 在通过隧道传送封装数据报期间，内部报头中的 IP 选项或扩展报头不会发生变化。
* 如果需要，可以在外层 IP 头和内层 IP 头之间插入其他协议头，例如 IP 认证头。
以下小节中的表格显示了对不同标头/选项字段的处理（构造 = 外部字段中的值独立于内部字段中的值构造）。
1. 封装头中的 IP 版本可以与内部头中的值不同。
2. 内部报头中的 TTL 在转发之前由封装器递减，如果它转发数据包，则由解封装器递减。（当 TTL 改变时，校验和也会改变。）
注意：TTL 的递减是转发数据包时发生的常见操作之一。来自与封装器相同节点的数据包不会递减它们的 TTL，因为发送节点是原始数据包而不是转发它。
3. src 和 dest 地址取决于 SA，SA 用于确定 dest 地址，而 dest 地址又决定使用哪个 src 地址（网络接口）来转发数据包。
注意：原则上，封装 IP 源地址可以是封装器的任何接口地址，甚至可以是与封装器的任何 IP 地址不同的地址（例如，如果它充当 NAT 盒），只要该地址可通过来自数据包发送到的环境中的封装器。这不会导致问题，因为 IPsec 当前没有任何涉及封装 IP 标头的源地址的 INBOUND 处理要求。因此，当接收隧道端点查看封装 IP 标头中的目的地址时，它只查看内部（封装的）IP 标头中的源地址。
4. 配置决定是否从内层头部复制（仅限IPv4）、清除或设置DF。
5. 如果 Inner Hdr 是 IPv4 （Protocol = 4），复制 TOS。如果内部 Hdr 是 IPv6（协议 = 41），则将类映射到 TOS。
有关由（脚注编号）指示的注释 1-5，请参阅前一节 5.1.2。
6. 如果 Inner Hdr 是 IPv6（Next Header = 41），复制class。如果 Inner Hdr 是 IPv4（Next Header = 4），则将 TOS 映射到 Class。
在执行 AH 或 ESP 处理之前，重新组装所有 IP 片段。将应用 IPsec 处理的每个入站 IP 数据报都通过 IP 下一协议字段中的 AH 或 ESP 值（或作为 IPv6 场景中的扩展头的 AH 或 ESP）来标识。
注意：附录 C 包含用于实现抗重放服务的 32 个数据包窗口的位掩码检查示例代码。
由于 AH 或 ESP 标头中存在 SPI，因此可以简化将 IP 数据报映射到适当的 SA。请注意，选择器检查是针对内部标头而不是外部（隧道）标头进行的。接下来的步骤是：
1. 使用数据包的目的地址（外层 IP 头）、IPsec 协议和 SPI 在 SAD 中查找 SA。如果 SA 查找失败，则丢弃数据包并记录/报告错误。
2. 使用（1）中找到的 SA 进行 IPsec 处理，例如认证和解密。此步骤包括将数据包的（内部报头，如果是隧道）选择器与 SA 中的选择器相匹配。本地策略确定 SA 选择器的特殊性（单个值、列表、范围、通配符）。通常，数据包的源地址必须与 SA 选择器值匹配。但是，在隧道模式 SA 上接收的 ICMP 数据包可能具有与绑定到 SA 的源地址不同的源地址，因此应允许此类数据包作为此检查的例外。对于 ICMP 数据包，应根据 SA 的选择器检查包含的问题数据包中的选择器（应交换源地址和目的地址以及端口）。请注意，由于 ICMP 数据包允许携带的问题数据包的位数限制或由于加密，这些选择器中的一些或全部可能无法访问。见第 6 节。
对每个 IPsec 标头执行 （1） 和 （2），直到遇到不适合该系统的传输协议标头或 IP 标头。跟踪使用了哪些 SA 及其应用顺序。
3. 在 SPD 中找到与数据包匹配的传入策略。例如，这可以通过使用从 SA 到 SPD 的反向指针或通过将数据包的选择器（如果是隧道内的内部报头）与 SPD 中的策略条目的选择器进行匹配来完成。
4. 检查是否应用了所需的 IPsec 处理，即验证在 （1） 和 （2） 中找到的 SA 与在 （3） 中找到的策略所需的 SA 的种类和顺序相匹配。
注意：正确的“匹配”策略不一定是找到的第一个入站策略。如果检查（4）失败，则重复步骤（3）和（4），直到检查完所有策略条目或直到检查成功。
在这些步骤结束时，将生成的数据包传递到传输层或转发数据包。请注意，在这些步骤中处理的任何 IPsec 标头可能已被删除，但后续 IPsec 或防火墙处理可能需要此信息，即使用的 SA 及其应用程序的顺序。
请注意，在安全网关的情况下，如果转发导致数据包通过启用 IPsec 的接口退出，则可能会应用额外的 IPsec 处理。
AH 和 ESP 隧道的内部和外部 IP 报头、扩展报头和选项的处理应按照第 5.1 节中的表格所述执行。
本节的重点是处理 ICMP 错误消息。其他 ICMP 流量，例如 Echo/Reply，应该像其他流量一样对待，并且可以以通常的方式使用 SA 在端到端的基础上进行保护。
由 AH 或 ESP 保护并由路由器生成的 ICMP 错误消息应该在隧道模式 SA 中处理和转发。本地策略决定它是否受到隧道目的端路由器的源地址检查。请注意，如果隧道始发端的路由器正在转发来自另一台路由器的 ICMP 错误消息，则源地址检查将失败。由 AH 或 ESP 保护并由路由器生成的 ICMP 消息不得在传输模式 SA 上转发（除非已为充当主机的路由器建立了 SA，例如，用于管理路由器的 Telnet 连接）。主机生成的 ICMP 消息应该根据与消息到达的 SA 绑定的源 IP 地址选择器进行检查。请注意，即使 ICMP 错误消息的来源经过身份验证，返回的 IP 标头也可能无效。因此，IP 报头中的选择器值也应该被检查以确保它们与接收 ICMP 消息的 SA 的选择器一致。
附录 D 中的表格将 ICMP 消息描述为主机生成、路由器生成、未知/未分配。落入最后两类的 ICMP 消息应根据接收方的策略进行处理。
不受 AH 或 ESP 保护的 ICMP 消息未经身份验证，其处理和/或转发可能会导致拒绝服务。这表明，一般而言，最好忽略此类消息。但是，预计许多路由器（相对于安全网关）不会为传输流量实现 IPsec，因此严格遵守此规则会导致许多 ICMP 消息被丢弃。结果是一些关键的 IP 功能将丢失，例如重定向和 PMTU 处理。因此，必须能够根据本地安全策略配置 IPsec 实现以接受或拒绝（路由器）ICMP 流量。
本节的其余部分讨论如何在主机和安全网关上执行 PMTU 处理。它解决了经过身份验证和未经身份验证的 ICMP PMTU 消息的处理。然而，如上所述，未认证的 ICMP 消息可能会根据本地策略被丢弃。
在系统（主机或网关）添加封装头（ESP 隧道或 AH 隧道）的情况下，它必须支持将 DF 位从原始数据包复制到封装头（并处理 ICMP PMTU 消息）的选项。这意味着必须可以为每个接口配置系统对 DF 位的处理（设置、清除、从封装头复制）。（有关基本原理，请参阅附录 B。）
本节讨论对路径 MTU 发现消息的 IPsec 处理。此处使用 ICMP PMTU 来指代 ICMP 消息，用于：
IPv4 （RFC 792）：
- 类型 = 3（目的不可达）
- 代码 = 4（需要分段和 DF 集）
- ICMP 报头第二个字的低 16 位中的 Next-Hop MTU（在 RFC 792 中标记为“未使用”），高 16 位设置为零
IPv6 （RFC 1885）：
- 类型 = 2（数据包太大）
- 代码 = 0（需要分段）
- ICMP6 消息的 32 位 MTU 字段中的下一跳 MTU
与 ICMP PMTU 消息（IPv4 或 IPv6）一起返回的信息量是有限的，这会影响哪些选择器可用于进一步传播 PMTU 信息。 （有关此主题的更详细讨论，请参见附录 B。）
* 带有 64 位 IPsec 标头的 PMTU 消息——如果 ICMP PMTU 消息仅包含 64 位 IPsec 标头（IPv4 的最小值），那么安全网关必须在每个 SPI/SA 基础上支持以下选项：
A. 如果可以确定始发主机（或将可能的来源缩小到可管理的数量），则将 PM 信息发送到所有可能的始发主机。
B. 如果无法确定始发主机，则将 PMTU 与 SA 一起存储，并等待下一个数据包从相关安全联盟的始发主机到达。如果数据包大于 PMTU，则丢弃数据包，并用新数据包和更新的 PMTU 组成 ICMP PMTU 消息，并发送有关问题的 ICMP 消息到原始主机。保留可能随后到达的任何消息的 PMTU 信息（参见第 6.1.2.4 节，“PMTU 老化”）。
* PMTU 消息的 IPsec 标头大于 64 位——如果 ICMP 消息包含来自原始数据包的更多信息，那么可能有足够的非不透明信息来立即确定将 ICMP/PMTU 消息传播到哪个主机并提供该系统使用 5 个字段（源地址、目的地址、源端口、目的端口、传输协议）来确定存储/更新 PMTU 的位置。在这种情况下，安全网关必须在接收到来自更远路径的 ICMP PMTU 后立即生成 ICMP PMTU 消息。
* 将 PMTU 分配到传输层——如 RFC 1191（路径 MTU 发现）中指定的那样，将更新的 PMTU 获取到传输层的主机机制没有改变。
从 ICMP PMTU 计算 PMTU 必须考虑添加任何 IPsec 标头：AH 传输、ESP 传输、AH/ESP 传输、ESP 隧道、AH 隧道。（有关实施问题的讨论，请参见附录 B。）
注意：在某些情况下，添加 IPsec 标头可能会导致有效 PMTU（如主机或应用程序所见）小得无法接受。为了避免这个问题，实现可以建立一个阈值，低于该阈值它不会报告减少的 PMTU。在这种情况下，实现将应用 IPsec，然后根据 PMTU 对结果数据包进行分段。这将导致更有效地使用可用带宽。
在主机中，ICMP PMTU 处理的粒度因实现情况而异。查看主机，有 3 种与 PMTU 问题相关的情况（有关此主题的更多详细信息，请参见附录 B）：
A. 将 IPsec 集成到本地 IP 实施中
B. Bump-in-the-stack 实现，其中 IPsec 在 TCP/IP 协议栈的现有实现的“下层”实现，在本地 IP 和本地网络驱动程序之间
C. 无 IPsec 实施——包括这种情况，因为它与安全网关将 PMTU 信息发送回主机的情况相关。
只有在 （A） 情况下，PMTU 数据才能以与通信联盟相同的粒度进行维护。在 （B） 和 （C） 中，IP 层将只能以源和目的IP 地址（以及可选的 TOS）的粒度维护 PMTU 数据，如 RFC 1191 中所述。这是一个重要的区别，因为超过一个通信联盟可能映射到相同的源和目的IP 地址，并且每个通信联盟可能具有不同数量的 IPsec 标头开销（例如，由于使用不同的转换或不同的算法）。
在各个通信联盟的粒度上实现 PMTU 的计算和对 PMTU 的支持是本地事务。然而，主机中基于套接字的 IPsec 实现应该在每个套接字的基础上维护信息。在针对这些系统添加的任何 IPsec 标头开销对其进行调整后，堆栈中的 Bump 系统必须将 ICMP PMTU 传递给主机 IP 实现。开销的计算应该通过对 SPI 和返回的 ICMP PMTU 消息中存在的任何其他选择器信息的分析来确定。
在所有实现 IPsec 和维护 PMTU 信息的系统（主机或网关）中，与安全联盟（传输或隧道）相关联的 PMTU 必须“老化”，并且必须采取某种机制来及时更新 PMTU，尤其是为了发现如果 PMTU 比它需要的小。给定的 PMTU 必须保持足够长的时间，以便数据包从安全联盟的源端到达安全联盟另一端的系统，并在当前 PMTU 太大时传播回 ICMP 错误消息。请注意，如果存在嵌套隧道，则可能需要多个数据包和往返时间才能将 ICMP 消息返回到封装器或始发主机。
系统应该使用路径 MTU 发现文档（RFC 1191，第 6.3 节）中描述的方法，该方法建议定期将 PMTU 重置为第一跳数据链路 MTU，然后让正常的 PMTU 发现过程根据需要更新 PMTU。周期应该是可配置的。
并非所有实施 IPsec 的系统都会实施审计。在大多数情况下，审计的粒度是局部问题。但是，AH 和 ESP 规范中确定了几个可审计事件，并且对于这些事件中的每一个，定义了应该包含在审计日志中的最小信息集。附加信息也可能包含在每个这些事件的审计日志中，并且本规范中没有明确指出的附加事件也可能导致审计日志条目。接收器不需要向所谓的发送器发送任何消息以响应检测到可审计事件，因为通过此类操作可能导致拒绝服务。
可以通过单个网络承载各种敏感度级别的信息。信息标签（例如，未分类、公司专有、机密）[DoD85、DoD87] 通常用于区分此类信息。标签的使用促进了信息的隔离，以支持信息流安全模型，例如 Bell-LaPadula 模型 [BL73]。此类模型和相应的支持技术旨在防止未经授权的敏感信息流动，即使面对特洛伊木马攻击也是如此。传统的自主访问控制 （discretionary access control ，DAC） 机制，例如，基于访问控制列表，通常不足以支持此类策略，因此诸如 SPD 之类的设施在此类环境中是不够的。
在军事背景下，支持此类模型的技术通常称为多级安全（multi-level security ，MLS）。如果计算机和网络支持标记数据的分离以及信息流安全策略，则它们通常被指定为“多级安全”。尽管此类技术的适用范围不仅限于军事应用，但本文档使用首字母缩略词“MLS”来表示该技术，这与许多现存文献一致。
IPsec 机制可以轻松支持 MLS 组网。MLS 网络需要使用强大的强制访问控制 （Mandatory Access Controls ，MAC），非特权用户或非特权进程无法控制或违反。本节仅涉及在 MLS（信息流安全策略）环境中使用这些 IP 安全机制。本节中的任何内容均不适用于未声称提供 MLS 的系统。
本节中使用的“灵敏度信息”可能包括实现定义的层次级别、类别和/或可发布性信息。
AH 可用于提供强身份验证以支持 MLS 环境中的强制访问控制决策。如果使用明确的 IP 敏感信息（例如 IPSO [Ken91]）并且在特定操作环境中认为不需要保密，则可以使用 AH 来验证 IP 标头中的敏感标签与 IP 有效载荷（包括用户数据）之间的绑定）。这是对敏感信息可信的标记 IPv4 网络的重大改进，即使信息没有身份验证或加密绑定到 IP 标头和用户数据。 IPv4 网络可能使用也可能不使用显式标签。 IPv6 通常会使用作为 IPsec 安全联盟一部分但不随每个数据包传输的隐式敏感信息，而不是使用显式敏感信息。所有显式 IP 灵敏度信息必须使用 ESP、AH 或两者进行身份验证。
即使所有主机都在受保护的环境中（例如，在防火墙后面或与任何外部连接脱节），加密很有用并且可能是可取的。ESP 可以与适当的密钥管理和加密算法结合使用，以支持 DAC 和 MAC。（加密和认证算法的选择，以及 IPsec 实施的保证级别将决定实施可能被认为足以满足 MLS 要求的环境。）密钥管理可以利用敏感信息来提供 MAC。声称提供 MLS 的系统上的 IPsec 实现应该能够使用 IPsec 为基于 IP 的通信提供 MAC。
封装安全有效载荷和认证头都可以与适当的安全联盟策略相结合，以提供多级安全网络。在这种情况下，每个 SA（或 SA捆绑）通常仅用于单个敏感信息实例。例如，“PROPRIETARY - Internet Engineering”必须与与“PROPRIETARY - Finance”不同的 SA（或 SA捆绑）相关联。
MLS 实现（主机和路由器）可以将敏感信息或敏感信息范围与接口或配置的 IP 地址与其关联的前缀（后者有时称为逻辑接口或接口别名）相关联.如果存在这样的属性，则实现应该将与数据包关联的敏感信息与与数据包到达或离开的接口或地址/前缀关联的敏感信息进行比较。此检查将验证敏感度是否匹配，或数据包的敏感度是否在接口或地址/前缀的范围内。检查应该对入站和出站处理进行。
第 4.4 节讨论了两个安全联盟数据库（安全策略数据库 （SPD） 和安全联盟数据库 （SAD））以及相关的策略选择器和 SA 属性。 MLS 网络引入了一个额外的选择器/属性：
- 灵敏度信息。
灵敏度信息有助于选择适当的算法和密钥强度，以便流量获得与其重要性或灵敏度相适应的保护级别，如第 8.1 节所述。灵敏度信息的确切语法是实现定义的。
在入站数据包通过 IPsec 处理后，MLS 实现应该首先检查数据包的灵敏度（由用于数据包的 SA（或 SA 捆绑）定义）与接口或地址/前缀，如第 8.2 节所述，然后再交付数据报到上层协议或转发它。
MLS 系统必须保留在受 IPsec 保护的数据包中接收到的数据与用于处理的 SA 或 SA 中的灵敏度信息之间的绑定，因此在将数据报传送到应用程序或转发引擎时可以做出适当的策略决定。维护此绑定的方法是特定于实现的。
除了第 5.1.1 节中详述的正常步骤之外，IPsec 的 MLS 实现必须执行两个额外的检查。当查阅SPD或者SAD以寻找出站安全联盟，MLS实现必须使用数据的灵敏度选择出站SA或SA捆绑适当的。第二个检查是在将数据包转发到目的地之前进行的，是第 8.2 节中描述的灵敏度一致性检查。
MLS 安全网关必须遵循前面提到的入站和出站处理规则，并执行一些特定于 MLS 环境中数据包中间保护的附加处理。
安全网关可以充当出站代理，为 MLS 系统创建 SA，这些系统发起网关转发的数据包。这些 MLS 系统可能会明确标记要转发的数据包，或者整个发起网络可能具有与之相关的敏感特性。安全网关必须为 AH、ESP 或两者创建和使用适当的 SA，以保护它转发的此类流量。
类似地，这样的网关应该接受和处理入站 AH 和/或 ESP 数据包并适当地转发，使用显式数据包标记，或依赖于目的网络的敏感特性。
IPsec 的使用给实现这些协议的主机或安全网关带来了计算性能成本。这些成本与 IPsec 代码和数据结构所需的内存、完整性校验值的计算、加密和解密以及增加的每个数据包处理相关。每个数据包的计算成本将表现为延迟增加，并且可能会降低整个数据包。 SA/密钥管理协议的使用，尤其是那些采用公钥加密的协议，也会增加使用 IPsec 的计算性能成本。这些每个联盟的计算成本将表现为关联建立中延迟的增加。对于许多主机，预计基于软件的加密不会明显降低吞吐量，但安全网关（因为它们代表聚合点）和某些主机可能需要硬件。
IPsec 的使用还会对 Internet 基础设施的传输、交换和路由组件（未实现 IPsec 的组件）施加带宽使用成本。这是由于添加 AH 和/或 ESP 标头、AH 和 ESP 隧道（添加第二个 IP 标头）导致数据包大小增加，以及与关键管理协议相关的数据包流量增加。预计在大多数情况下，
这种增加的带宽需求不会显着影响互联网基础设施。但是，在某些情况下，影响可能很大，例如，通过拨号链接传输 ESP 加密流量，可能会压缩流量。
注意：初始 SA 建立开销将在第一个数据包中感受到。这种延迟可能会影响传输层和应用程序。例如，它可能导致 TCP 在 ISAKMP 交换完成之前重新传输 SYN。延迟对 UDP 的影响将与 TCP 不同，因为在建立连接之前，TCP 不应传输除 SYN 以外的任何内容，而 UDP 将继续传输超出第一个数据包的数据。
注意：如前所述，仍然可以在 IP 之上的层使用压缩。有一个 IETF 工作组（IP 有效载荷压缩协议【IP Payload Compression Protocol ，ippcp】）致力于“协议规范，该规范可以在有效载荷被加密协议处理之前对单个有效载荷执行无损压缩。这些规范将允许压缩操作在通过 IPsec 协议加密有效载荷之前执行。”
所有声称实现 IPsec 的 IPv4 系统必须符合安全架构文档的所有要求。所有 IPv6 系统必须符合安全架构文档的所有要求。
本文档的重点是安全性；因此，安全考虑贯穿于本规范中。
该架构文档在细节和组织上与 RFC 1825 有很大不同，但基本概念没有变化。本文档在合规性规范方面提供了相当多的额外细节。它介绍了 SPD 和 SAD，以及 SA 选择器的概念。它与 AH 和 ESP 的新版本保持一致，它们也不同于它们的前辈。新增了对支持的 AH 和 ESP 组合的特定要求，以及 PMTU 管理的详细信息。
本节提供了本文档中使用的几个关键术语的定义。其他文件提供了与该技术相关的附加定义和背景信息，例如 [VK83, HA94]。本词汇表中包括通用安全服务和安全机制术语，以及特定于 IPsec 的术语。
访问控制是一种安全服务，可防止未经授权使用资源，包括防止以未经授权的方式使用资源。在 IPsec 场景中，访问被控制的资源通常是：
* 用于主机、计算周期或数据
* 对于安全网关，网关后面的网络或该网络上的带宽。
[见下面的“完整性”]
该术语非正式地用于指代两个名义上不同的安全服务、数据源身份验证和无连接完整性的组合。请参阅以下各项服务的定义。
可用性，当被视为一种安全服务时，解决了对拒绝或降低服务的网络的攻击所引起的安全问题。例如，在 IPsec 场景中，在 AH 和 ESP 中使用反重播机制支持可用性。
机密性是保护数据免遭未经授权泄露的安全服务。在大多数情况下，主要的保密问题是未经授权的应用程序级数据的公开，但在某些情况下，通信的外部特征的公开也可能是一个问题。流量机密性是通过隐藏源地址和目的地址、消息长度或通信频率来解决后一个问题的服务。在 IPsec 场景中，在隧道模式下使用 ESP，尤其是在安全网关中，可以提供某种级别的流量机密性。（另请参阅下面的流量分析。）
加密是一种安全机制，用于将数据从可理解的形式（明文）转换为不可理解的形式（密文），以提供机密性。逆变换过程称为“解密”。有时，术语“加密”用于泛指这两个过程。
数据源身份验证是一种安全服务，用于验证声明的数据源的身份。此服务通常与无连接完整性服务捆绑在一起。
完整性是一种安全服务，可确保可以检测到对数据的修改。Integrity 具有多种风格，可满足应用程序要求。 IPsec 支持两种形式的完整性：无连接形式和一种部分序列完整性形式。无连接完整性是一种检测单个 IP 数据报修改的服务，不考虑数据报在流量流中的顺序。 IPsec 中提供的部分序列完整性的形式称为抗重放完整性，它检测重复 IP 数据报的到达（在受限窗口内）。这与面向连接的完整性形成对比，后者对流量施加了更严格的排序要求，例如，能够检测丢失或重新排序的消息。尽管身份验证和完整性服务通常被单独引用，但实际上它们是密切相关的，并且几乎总是同时提供。
出于安全目的而创建的单工（单向）逻辑连接。为通过 SA 的所有流量提供相同的安全处理。在 IPsec 中，SA 是通过使用 AH 或 ESP 实现的 Internet 层抽象。
安全网关是一个中间系统，充当两个网络之间的通信接口。安全网关外部的一组主机（和网络）被视为不受信任（或不太受信任），而内部的网络和主机则被视为受信任（或更受信任）。由安全网关服务的内部子网和主机由于共享公共的本地安全管理而被推定为受信任的。（请参阅下面的“可信子网”。）在 IPsec 场景中，安全网关是实现 AH 和/或 ESP 以便为一组内部主机提供服务的点，当这些主机与外部通信时为这些主机提供安全服务主机也使用 IPsec（直接或通过另一个安全网关）。
“安全参数索引，Security Parameters Index”的缩写。目的地址、安全协议和 SPI 的组合唯一标识安全联盟（SA，见上文）。 SPI 承载在AH 和ESP 协议中，使接收系统能够选择对接收的数据包进行处理的SA。 SPI 仅具有本地意义，由 SA 的创建者（通常是携带 SPI 的数据包的接收者）定义；因此，SPI 通常被视为一个不透明的位串。但是，SA 的创建者可以选择解释 SPI 中的位以促进本地处理。
分析网络流量，以推导出对攻击者有用的信息。此类信息的示例包括传输频率、通话方的身份、数据包大小、流标识符等。 [Sch94]
包含相互信任不会进行主动或被动攻击的主机和路由器的子网。还假设底层通信通道（例如 LAN 或 CAN）没有受到其他方式的攻击。
在系统（主机或网关）添加封装标头（例如 ESP 隧道）的情况下，是否应该/必须将原始数据包中的 DF 位复制到封装标头？
在某些情况下，分段似乎是正确的，例如，通过具有非常小的 MTU 的网络（例如，分组无线电网络或移动电话跳到移动节点）对数据包进行分段可能是合适的，而不是传播回非常小的 PMTU 以用于在路径的其余部分使用。在其他情况下，设置 DF 位可能是合适的，以便从后面的路由器获得有关需要分段的 PMTU 约束的反馈。这两种情况的存在都支持系统决定是否通过特定网络“链接”进行分段，即要求实现能够复制 DF 位（并处理 ICMP PMTU 消息），但使其成为基于每个界面选择的选项。换句话说，管理员应该能够为每个接口配置路由器对 DF 位的处理（设置、清除、从封装报头复制）。
注意：如果 IPsec 堆栈中的碰撞实现尝试基于源/目的端口应用不同的 IPsec 算法，则将难以应用路径 MTU 调整。
如果需要，IP 分段会在 IPsec 实现中的 IPsec 处理之后发生。因此，传输模式 AH 或 ESP 仅适用于整个 IP 数据报（而不适用于 IP 片段）。已应用 AH 或 ESP 的 IP 数据包本身可能会在路由途中被路由器分段，并且必须在接收方的 IPsec 处理之前重新组装这些分段。在隧道模式下，AH或ESP应用于IP数据包，其有效载荷可能是分段的IP数据包。例如，安全网关、“堆栈中编码”（BITS） 或“线路中编码”（BITW） IPsec 实现可以将隧道模式AH 应用于此类片段。请注意，BITS 或 BITW 实现是主机 IPsec 实现可能接收要应用隧道模式的片段的示例。然而，如果要应用传输模式，那么这些实现必须在应用 IPsec 之前重新组装片段。
注意：IPsec 始终必须弄清楚封装的 IP 标头字段是什么。这与您插入 IPsec 的位置无关，并且是 IPsec 定义所固有的。因此，任何未集成到 IP 实现中的 IPsec 实现都必须包含构建必要 IP 标头（例如 IP2）的代码：
* AH-隧道--> IP2-AH-IP1-传输-数据
* ESP-隧道 --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer
总体而言，上述碎片化/重组方法适用于所有检查的情况。
* 如果密码处理器系统有自己的 IP 地址，则它包含在安全网关案例中。此框接收来自主机的数据包并执行 IPsec 处理。它必须能够处理与安全网关必须处理的相同的 AH、ESP 和相关 IPv4/IPv6 隧道处理。如果它没有自己的地址，那么它类似于 IP 和网络驱动程序之间的堆栈实现。
以下分析假设：
1. 在给定系统的堆栈中只有一个 IPsec 模块。没有 IPsec 模块 A（添加 ESP/加密，因此）对 IPsec 模块 B 隐藏传输协议、SRC 端口和 DEST 端口。
2. 有几个地方可以实现IPsec（如上表所示）。
A. 将 IPsec 集成到本机 IP 实施中的主机。实施者有权访问堆栈的源代码。
B. 具有堆栈中的编码实现的主机，其中 IPsec 在 IP 和本地网络驱动程序之间实现。堆栈的源访问不可用；但是有一些定义明确的接口允许将 IPsec 代码合并到系统中。
C. 将 IPsec 集成到堆栈中的安全网关和外置加密处理器。
3. 并非所有上述方法都适用于所有主机。但是假设对于每种方法，都有一些主机对该方法是可行的。
对于上述 3 个类别中的每一个，有 IPv4 和 IPv6、AH 传输和隧道模式以及 ESP 传输和隧道模式——总共 24 种情况（3 x 2 x 4）。
为了便于参考，此处列出了一些标题字段和接口字段——它们不按标题顺序排列，而是列出以允许在列之间进行比较。（* = AH 身份验证未涵盖。ESP 身份验证不涵盖其之前的任何标头。）
? = AH 涵盖 Option-Type 和 Option-Length，但可能不涵盖 Option-Data。
下面显示了 20 种情况中每一种情况的结果（“works”= 如果系统碎片在出站 IPsec 处理之后重新组装，则在入站 IPsec 处理之前重新组装）。注释表示实施问题。
A. 主机（集成到 IP 堆栈中）
B. Hosts （Bump-in-the-stack）——将 IPsec 置于 IP 层和网络驱动程序之间。在这种情况下，IPsec 模块必须执行以下操作之一以进行分段和重组。
- 自己进行分段/重组工作，并直接向/从网络层发送/接收数据包。在 AH 或 ESP 传输模式下，这很好。在隧道末端位于最终目的地的 AH 或 ESP 隧道模式下，这很好。但在 AH 或 ESP 隧道模式中，隧道端与最终目的地不同且源主机是多宿主的，这种方法可能导致次优路由，因为 IPsec 模块可能无法获得所需的信息（LAN接口和下一跳网关）将数据包定向到适当的网络接口。如果最终目的地和隧道端的接口和下一跳网关相同，这不是问题。但如果它们不同，则 IPsec 将需要知道隧道末端的 LAN 接口和下一跳网关。 （注意：隧道端（安全网关）很可能位于通向最终目的地的常规路径上。但也可能有多个到达目的地的路径，例如，主机可能位于具有 2 个防火墙的组织中。并且正在使用的路径可能涉及不太常用的防火墙。）
或者
- 将 IPsec 的数据包传回 IP 层，在那里额外的 IP 标头最终会被预先挂起，IPsec 模块必须检查并让 IPsec 的片段通过。
或者
- 将数据包内容以某种形式传递给 IP 层，以便 IP 层重新创建适当的 IP 报头
在网络层，IPsec 模块可以访问数据包中的以下选择器——SRC 地址、DST 地址、下一个协议，如果有传输层标头——> SRC 端口和 DST 端口。不能假设 IPsec 可以访问该名称。假设可用的选择器信息足以找出相关的安全策略条目和安全联盟。
C. 安全网关——将 IPsec 集成到 IP 堆栈中
注意：IPsec 模块可以访问数据包中的以下选择器——SRC 地址、DST 地址、下一个协议，如果有传输层报头——> SRC 端口和 DST 端口。它无法访问用户 ID（只有主机可以访问用户 ID 信息。）与某些 Bump-in-the-stack 实现不同，安全网关可能能够在 DNS 中查找源地址以提供系统名称，例如，在涉及使用动态分配的 IP 地址以及动态更新的 DNS 条目的情况下。如果有 ESP 标头，或者它不是分段消息的第一个片段，它也将无法访问传输层信息。假定可用的选择器信息足以找出相关的安全策略条目和安全联盟。
如前所述，“ICMP PMTU”是指用于路径 MTU 发现的 ICMP 消息。
B.3.1 和 B.3.3（但不是 B.3.2）中下图的图例是：
==== = 安全联盟（AH 或 ESP、传输或隧道）
----- = 连通性（或如果标记为行政边界）
.... = ICMP 消息（以下称为 ICMP PMTU）用于
IPv4：
- 类型 = 3（目的不可达）
- 代码 = 4（需要分段和 DF 集）
- ICMP 报头第二个字的低 16 位中的 Next-Hop MTU（在 RFC 792 中标记为未使用），高 16 位设置为零
IPv6 （RFC 1885）：
- 类型 = 2（数据包太大）
- 代码 = 0（需要分段和 DF 集）
- ICMP6 的 32 位 MTU 字段中的下一跳 MTU
Hx = 主机 x
Rx = 路由器 x
SGx = 安全网关 x
X* = X 支持 IPsec
与 ICMP 消息一起返回的信息量是有限的，这会影响哪些选择器可用于识别安全联盟、始发主机等，以用于进一步传播 PMTU 信息。
简而言之：ICMP 消息必须包含来自“违规”数据包的以下信息：
- IPv4 （RFC 792）-- IP 报头加上至少 64 位
因此，在 IPv4 场景中，ICMP PMTU 可能仅标识第一个（最外层）安全联盟。这是因为 ICMP PMTU 可能只包含 IP 标头之外的“违规”数据包的 64 位，这将仅捕获来自 AH 或 ESP 的第一个 SPI。在 IPv6 场景中，ICMP PMTU 可能会在 IP 标头中提供所有 SPI 和选择器，但可能不会提供 SRC/DST 端口（在传输标头中）或封装的（TCP、UDP 等）协议。此外，如果使用 ESP，传输端口和协议选择器可能会被加密。
查看下图的安全网关隧道（如其他地方所述，安全网关不使用传输模式）...
假设 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 消息的流量。
（*） 64 位将包含足够的 ESP（或 AH）标头以包含 SPI。
- ESP -- SPI（32 位），序列号（32 位）
- AH -- 下一个头部（8 位），有效载荷长度（8 位），保留（16 位）、SPI（32 位）
对与 ICMP 消息一起返回的信息量的这种限制在识别数据包的始发主机（以便知道在哪里进一步传播 ICMP PMTU 信息）方面产生了问题。如果 ICMP 消息仅包含 64 位 IPsec 标头（IPv4 的最小值），则 IPsec 选择器（例如，源和目的地址、下一个协议、源和目的端口等）将丢失。但 ICMP 错误消息仍会为 SG1 提供 SPI、PMTU 信息以及相关安全联盟的源和目的网关。
目的安全网关和 SPI 唯一地定义了一个安全联盟，该联盟又定义了一组可能的原始主机。此时，SG1 可以：
A. 将 PMTU 信息发送到所有可能的发起主机。如果主机列表是一个通配符，或者如果许多/大多数主机没有发送到 SG1，这将无法正常工作；但是如果 SPI/destination/etc 仅映射到一个或少数主机，它可能会起作用。
B. 使用 SPI/etc 存储 PMTU，并等待下一个数据包从相关安全联盟的始发主机到达。如果它/它们大于 PMTU，则丢弃数据包，并用新的数据包和更新的 PMTU 组成 ICMP PMTU 消息，并向始发主机发送 ICMP 消息） 关于问题。这涉及通知始发主机的延迟，但避免了 （A） 的问题。
因为只有后一种方法在所有情况下都是可行的，安全网关必须提供这种支持，作为一种选择。但是，如果 ICMP 消息包含来自原始数据包的更多信息，那么可能有足够的信息来立即确定将 ICMP/PMTU 消息传播到哪个主机并向该系统提供 5 个字段（源地址、目的地址、源端口、目的端口和传输协议）来确定存储/更新 PMTU 的位置。在这种情况下，安全网关必须在接收到来自更远路径的 ICMP PMTU 后立即生成 ICMP PMTU 消息。注意：下一个协议字段可能不包含在 ICMP 消息中，并且使用 ESP 加密可能会隐藏已加密的选择器字段。
从 ICMP PMTU 计算 PMTU 必须考虑通过 H1 添加的任何 IPsec 标头——AH 和/或 ESP 传输，或 ESP 或 AH 隧道。在单个主机内，多个应用程序可能共享一个 SPI，并且可能发生安全联盟的嵌套。 （有关必须支持的组合的描述，请参阅第 4.5 节安全联盟的基本组合）。下图说明了一对主机之间的安全联盟示例（从其中一个主机的角度来看。）（ESPx 或 AHx = 传输模式）
为了找出映射到 SPI-B 的每个套接字的 PMTU，有必要从 SPI-B 到通向它的 2 条路径中的每一条的反向指针——套接字 1 和套接字 2/SPI-A。
在主机中，可进行 PMTU ICMP 处理的粒度因实施情况而异。看看主机，在 PMTU 问题方面有以下三种情况值得关注：
A. 将 IPsec 集成到本地 IP 实施中
B. Bump-in-the-stack 实现，其中 IPsec 在 TCP/IP 协议栈的现有实现的“下层”实现，在本地 IP 和本地网络驱动程序之间
C. 无 IPsec 实施——包括这种情况，因为它与安全网关将 PMTU 信息发送回主机的情况相关。
只有在（A）情况下，PMTU 数据才能以与通信联盟相同的粒度进行维护。在其他情况下，IP 层将以源和目的IP 地址（以及可选的 TOS/类别）的粒度维护 PMTU 数据，如 RFC 1191 中所述。这是一个重要的区别，因为多个通信联盟可能映射到相同的源和目的IP 地址，并且每个通信联盟可能具有不同数量的 IPsec 标头开销（例如，由于使用不同的转换或不同的算法）。下面的例子说明了这一点。
在情况 （A） 和 （B） 中，假设您有以下情况。 H1 正在向 H2 发送，并且要从 R1 发送到 R2 的数据包超过了它们之间网络跃点的 PMTU。
如果 R1 配置为不对用户流量进行分段，则 R1 会向 H1 发送带有适当 PMTU 的 ICMP PMTU 消息，H1 的处理会随着实现的性质而变化。 在情况 （A）（本地 IP）中，安全服务绑定到套接字或等效物。 这里 H1 中的 IP/IPsec 实现可以存储/更新联盟套接字的 PMTU。 在情况 （B） 中，H1 中的 IP 层可以存储/更新 PMTU，但只能以源和目的地址的粒度以及可能的 TOS/类为单位，如上所述。 因此，结果可能是次优的，因为给定 SRC/DST/TOS/Class 的 PMTU 将减去用于给定源和目的地之间的任何通信联盟的最大数量的 IPsec 标头。
在情况 （C） 中，必须有一个安全网关才能进行任何 IPsec 处理。 所以假设你有以下情况，H1 正在向 H2 发送，并且要从 SG1 发送到 R 的数据包超过了它们之间网络跃点的 PMTU。
如上文针对情况 （B） 所述，H1 中的 IP 层可以存储/更新 PMTU，但只能以源和目的地址的粒度，以及可能的 TOS/类别。因此结果可能是次优的，因为给定 SRC/DST/TOS/Class 的 PMTU 将减去用于给定源和目的地之间的任何通信联盟的最大数量的 IPsec 标头。
PMTU 计算的实现（B.3.2 节）和在单个“通信联盟”的粒度（B.3.3 节）对 PMTU 的支持是本地问题。然而，主机中基于套接字的 IPsec 实现应该在每个套接字的基础上维护信息。在针对这些系统添加的任何 IPsec 标头开销对其进行调整后，堆栈中的 Bump 系统必须将 ICMP PMTU 传递给主机 IP 实现。开销的确定应该通过对 SPI 和返回的 ICMP PMTU 消息中存在的任何其他选择器信息的分析来确定。
如 RFC 1191（路径 MTU 发现）中指定的那样，用于将更新的 PMTU 发送到传输层的主机机制没有改变。
此主题在第 6.1.2.4 节中介绍。
本附录包含一个例程，用于对 32 个数据包窗口执行位掩码检查。它由 James Hughes （jim_hughes@stortek.com） 和 Harry Varnis （hgv@anubis.network.com） 提供，旨在作为一个实现示例。请注意，此代码既检查重放又更新窗口。因此，如图所示，只应在数据包经过身份验证后调用该算法。实现者可能希望在计算 ICV 之前考虑拆分代码以检查重放。如果数据包不是重放，则代码将计算 ICV，（丢弃任何坏数据包），如果数据包正常，则更新窗口。
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
enum {
ReplayWindowSize = 32
};
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）;
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 */
}
char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof（string_buffer）
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"）;
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;
}
下表将 ICMP 消息表征为主机生成、路由器生成、未分配/未知。 第一组是 IPv4。 第二组是 IPv6。
[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.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[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.
[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.
[HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange （IKE）", RFC 2409, November 1998.
[HM97] Harney, H., and C. Muckenhirn, "Group Key Management Protocol （GKMP） Architecture", RFC 2094, July 1997.
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
[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.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio
[KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload （ESP）", RFC 2406, November 1998.
[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, November 1991.
[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol （ISAKMP）", RFC 2408, November 1998.
[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 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.
[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol （IPComp）", RFC 2393, August 1998.
[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
本文档中表达的观点和规范是作者的观点和规范，不一定是其雇主的观点和规范。对于因正确或不正确实施或使用此设计而引起的任何问题，作者及其雇主明确表示不承担任何责任。
本文件及其译文可能会被复制和提供给他人，并且可以全部或部分地准备、复制、出版和分发对其进行评论或以其他方式解释或协助其实施的衍生作品，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文档本身，例如通过删除版权声明或对 Internet 协会或其他 Internet 组织的引用，除非出于制定 Internet 标准的需要，在这种情况下，版权程序定义在必须遵循 Internet 标准流程，或按照要求将其翻译成英语以外的语言。
上述授予的有限权限是永久性的，不会被互联网协会或其继任者或受让人撤销。
推荐本站淘宝优惠价购买喜欢的宝贝:
本文链接：https://hqyman.cn/post/9916.html 非本站原创文章欢迎转载，原创文章需保留本站地址！
微信支付宝扫一扫，打赏作者吧～休息一下~~
萌ICP备20248119号
