4.1. 定义和范围 (Definition and Scope)

SA 是一个单工 (simplex) "连接",为其承载的流量提供安全服务。通过使用 AH 或 ESP 为 SA 提供安全服务,但不能同时使用两者。如果将 AH 和 ESP 保护同时应用于流量流,则必须创建两个 SA 并进行协调,通过迭代应用安全协议来实现保护。为了保护两个启用 IPsec 的系统之间的典型双向通信,需要一对 SA(每个方向一个)。IKE 明确创建 SA 对,以识别这种常见的使用要求。

SA 标识

对于用于承载单播流量的 SA,安全参数索引 (Security Parameters Index, SPI) 本身足以指定 SA。(有关 SPI 的信息,请参见附录 A 以及 AH 和 ESP 规范 [Ken05b, Ken05a]。)但是,作为本地事项,实现可以选择将 SPI 与 IPsec 协议类型 (AH 或 ESP) 结合使用来进行 SA 标识。如果 IPsec 实现支持多播,则必须 (MUST) 使用以下算法支持多播 SA,以便将入站 IPsec 数据报映射到 SA。仅支持单播流量的实现不需要实现此去复用算法。

多播 SA 注意事项

在许多安全多播架构中,例如 [RFC3740],中央组控制器/密钥服务器 (Group Controller/Key Server) 单方面分配组安全关联 (Group Security Association, GSA) 的 SPI。此 SPI 分配不与驻留在构成组的各个终端系统中的密钥管理 (例如 IKE) 子系统进行协商或协调。因此,GSA 和单播 SA 可能同时使用相同的 SPI。支持多播的 IPsec 实现必须 (MUST) 正确地去复用入站流量,即使在 SPI 冲突的情况下也是如此。

SA 数据库 (SA Database, SAD)(第 4.4.2 节) 中的每个条目必须指示 SA 查找除了使用 SPI 外,是否还使用目标 IP 地址,或目标和源 IP 地址。对于多播 SA,协议字段不用于 SA 查找。对于每个入站的、受 IPsec 保护的数据包,实现必须对 SAD 进行搜索,以便找到与"最长"SA 标识符匹配的条目。在此上下文中,如果两个或更多 SAD 条目基于 SPI 值匹配,则还基于目标地址或目标和源地址(如 SAD 条目中所示)匹配的条目是"最长"匹配。这意味着 SAD 搜索的逻辑顺序如下:

1. 在 SAD 中搜索 SPI、目标地址和源地址的组合匹配。 如果 SAD 条目匹配,则使用该匹配的 SAD 条目处理入站数据包。否则,继续执行步骤 2。

2. 在 SAD 中搜索 SPI 和目标地址的匹配。 如果 SAD 条目匹配,则使用该匹配的 SAD 条目处理入站数据包。否则,继续执行步骤 3。

3. 在 SAD 中搜索仅 SPI 的匹配(如果接收方选择为 AH 和 ESP 维护单个 SPI 空间),否则同时搜索 SPI 和协议。如果 SAD 条目匹配,则使用该匹配的 SAD 条目处理入站数据包。否则,丢弃数据包并记录可审计事件。

在实践中,实现可以选择任何方法(或根本不选择)来加速此搜索,尽管其外部可见行为必须 (MUST) 在功能上等同于按上述顺序搜索 SAD。例如,基于软件的实现可以通过 SPI 索引到哈希表中。每个哈希表桶的链表中的 SAD 条目可以保持排序,使具有最长 SA 标识符的 SAD 条目首先出现在该链表中。具有最短 SA 标识符的 SAD 条目可以排序,使它们成为链表中的最后条目。基于硬件的实现可以使用通常可用的三态内容可寻址存储器 (Ternary Content-Addressable Memory, TCAM) 功能本质上实现最长匹配搜索。

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

QoS 和多个 SA

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

讨论: 尽管 DSCP [NiBlBaBL98, Gro02] 和显式拥塞通知 (Explicit Congestion Notification, ECN) [RaFlBl01] 字段不是此架构中使用的术语"选择器",但发送方需要一种机制将具有给定(一组)DSCP 值的数据包定向到适当的 SA。此机制可能被称为"分类器 (classifier)"。

传输模式 vs 隧道模式

如上所述,定义了两种类型的 SA:传输模式和隧道模式。IKE 创建 SA 对,因此为了简单起见,我们选择要求对中的两个 SA 都是相同的模式,传输模式或隧道模式。

传输模式 SA

传输模式 SA 是通常在一对主机之间使用以提供端到端安全服务的 SA。当在路径上的两个中间系统之间(相对于 IPsec 的端到端使用)需要安全性时,可以 (MAY) 在安全网关之间或在安全网关和主机之间使用传输模式。在传输模式用于安全网关之间或安全网关和主机之间的情况下,传输模式可用于支持通过传输模式 SA 进行的 IP 内隧道(例如,IP-in-IP [Per96] 或通用路由封装 (Generic Routing Encapsulation, GRE) 隧道 [FaLiHaMeTr00] 或动态路由 [ToEgWa04])。需要澄清的是,中间系统(例如,安全网关)使用传输模式仅在应用于其源地址(对于出站数据包)或目标地址(对于入站数据包)是属于中间系统本身的地址的数据包时才被允许。作为 IPsec 重要部分的访问控制功能在此上下文中受到显著限制,因为它们不能应用于以这种方式穿越传输模式 SA 的数据包的端到端头部。因此,在特定上下文中使用之前,应仔细评估以这种方式使用传输模式。

在 IPv4 中,传输模式安全协议头部紧接在 IP 头部和任何选项之后出现,并在任何下一层协议(例如,TCP 或 UDP)之前。在 IPv6 中,安全协议头部出现在基本 IP 头部和选定的扩展头部之后,但可能出现在目标选项之前或之后; 它必须 (MUST) 出现在下一层协议(例如,TCP、UDP、流控制传输协议 (Stream Control Transmission Protocol, SCTP))之前。在 ESP 的情况下,传输模式 SA 仅为这些下一层协议提供安全服务,而不为 IP 头部或 ESP 头部之前的任何扩展头部提供安全服务。在 AH 的情况下,保护还扩展到其前面的 IP 头部的选定部分、扩展头部的选定部分以及选定的选项(包含在 IPv4 头部、IPv6 逐跳扩展头部或 IPv6 目标扩展头部中)。有关 AH 提供的覆盖范围的更多详细信息,请参见 AH 规范 [Ken05b]。

隧道模式 SA

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

• 流量目的地为安全网关时, 例如,简单网络管理协议 (Simple Network Management Protocol, SNMP) 命令,安全网关充当主机,允许使用传输模式。在这种情况下,SA 终止于安全网关内的主机(管理)功能,因此值得不同的处理。

• 如上所述, 安全网关可以 (MAY) 支持传输模式 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 实现必须 (MUST) 支持传输模式和隧道模式。 这对于主机的原生、BITS 和 BITW 实现都是如此。

b) 安全网关必须 (MUST) 支持隧道模式,可以 (MAY) 支持传输模式。 如果它支持传输模式,则应仅在安全网关充当主机时使用,例如,用于网络管理,或在路径上的两个中间系统之间提供安全性。