跳到主要内容

4.1. 定义和范围

安全关联（SA）是一条单工的“连接”，为其所承载的流量提供安全服务。SA 通过采用 AH 或 ESP（但不能同时采用两者）来提供安全服务。如果对一个数据流同时应用 AH 和 ESP 保护，则必须创建并协调两个 SA，通过反复应用安全协议来实现保护。为了保护两个启用了 IPsec 的系统之间典型的双向通信，需要一对 SA（每个方向一个）。IKE 会显式地创建 SA 对，正是为了适应这种常见的使用需求。

SA 标识​

对于用于承载单播流量的 SA，仅凭安全参数索引（SPI）就足以指明一个 SA。（有关 SPI 的信息，请参见附录 A 以及 AH 和 ESP 规范 [Ken05b, Ken05a]。）不过，作为一种本地实现选择，实现也可以将 SPI 与 IPsec 协议类型（AH 或 ESP）结合使用来进行 SA 标识。如果某个 IPsec 实现支持多播，那么它必须采用下述算法来支持多播 SA，以便将入站的 IPsec 数据报映射到 SA。仅支持单播流量的实现则无需实现这种解复用算法。

多播 SA 的考虑​

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

SA 数据库（SAD）（第 4.4.2 节）中的每条条目都必须指明，SA 查找除了使用 SPI 之外，是否还使用目的 IP 地址，或者同时使用目的地址和源 IP 地址。对于多播 SA，协议字段不用于 SA 查找。对于每一个入站的、受 IPsec 保护的包，实现必须检索 SAD，找到与“最长”SA 标识符相匹配的条目。在此语境下，如果两个或更多 SAD 条目基于 SPI 值匹配，那么同时还基于目的地址、或基于目的地址和源地址（如 SAD 条目所示）匹配的条目即构成“最长”匹配。这意味着 SAD 检索在逻辑上应按以下顺序进行：

  1. 在 SAD 中检索 SPI、目的地址和源地址三者的组合匹配项。 如果存在 SAD 条目匹配，则使用该匹配条目处理入站包。否则，进入步骤 2。

  2. 在 SAD 中检索 SPI 与目的地址二者的匹配项。 如果存在 SAD 条目匹配，则使用该匹配条目处理入站包。否则，进入步骤 3。

  3. 如果接收方选择为 AH 和 ESP 维护单一的 SPI 空间，则仅在 SAD 中检索基于 SPI 的匹配项；否则检索基于 SPI 和协议的匹配项。如果存在 SAD 条目匹配，则使用该匹配条目处理入站包。否则，丢弃该包并记录一个可审计事件。

在实践中，实现可以选择任何方法（或完全不选择任何方法）来加速该检索，但其对外可见的行为必须在功能上等价于按上述顺序检索 SAD。例如，基于软件的实现可以通过 SPI 索引到一张散列表。每个散列表桶（bucket）的链表中的 SAD 条目可以保持有序，使 SA 标识符最长的 SAD 条目排在该链表的最前面。SA 标识符最短的 SAD 条目则可以排在链表的最后。基于硬件的实现或许能够利用常见的三态内容可寻址存储器（TCAM）特性，从本质上实现最长匹配检索。

是否需要源地址和目的地址匹配才能将入站 IPsec 流量映射到 SA，这一指示必须作为手动 SA 配置的副作用、或通过 SA 管理协议（例如 IKE 或组解释域（GDOI）[RFC3547]）协商来设置。通常，特定源多播（SSM）[HC03] 组使用的 3 元组 SA 标识符由 SPI、目的多播地址和源地址组成。任意源多播组 SA 只需要 SPI 和目的多播地址作为标识符。

服务质量（QoS）与多个 SA​

如果不同类别的流量（由区分服务代码点（DSCP）位 [NiBlBaBL98]、[Gro02] 区分）被发送到同一个 SA 上，并且接收方启用了 AH 和 ESP 均可提供的可选防重放功能，那么由于该功能所使用的窗口机制，可能导致较低优先级的包被不恰当地丢弃。因此，为了恰当地支持服务质量（QoS），发送方应当把类别不同但选择器取值相同的流量放到不同的 SA 上。为此，IPsec 实现必须允许在给定的发送方与接收方之间，以相同的选择器建立并维护多个 SA。在这些并行 SA 之间为支持 QoS 而进行的流量分配，由发送方在本地决定，不由 IKE 协商。接收方必须一视同仁地处理来自不同 SA 的包。这些要求同时适用于传输模式和隧道模式的 SA。对于隧道模式 SA，相关的 DSCP 值出现在内层 IP 头中。在传输模式下，DSCP 值可能在途中改变，但这不应给 IPsec 处理造成问题，因为该值不用于 SA 选择，并且不得作为 SA/包验证的一部分被检查。但是，如果某个 SA 中发生了显著的包重排序（例如由于 DSCP 值在途中变化所致），则可能触发接收方因应用防重放机制而丢弃包。

讨论： 尽管 DSCP [NiBlBaBL98, Gro02] 和显式拥塞通知（ECN）[RaFlBl01] 字段不是本架构所用术语中的“选择器”，但发送方仍需要某种机制，将具有给定 DSCP 值（或一组值）的包导向合适的 SA。这种机制可以称为“分类器”。

传输模式与隧道模式​

如上所述，本文定义了两类 SA：传输模式和隧道模式。IKE 创建的是 SA 对，因此为了简化，我们选择要求一对 SA 中的两个 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 逐跳扩展头或 IPv6 目的扩展头中）。有关 AH 所提供覆盖范围的更多细节，请参见 AH 规范 [Ken05b]。

隧道模式 SA​

隧道模式 SA 本质上就是应用于一条 IP 隧道的 SA，访问控制应用于隧道内部流量的头部。两个主机之间可以建立隧道模式 SA。除以下两个例外之外，只要某个安全关联的任一端是安全网关，该 SA 就必须是隧道模式。因此，两个安全网关之间的 SA 通常是隧道模式 SA，主机与安全网关之间的 SA 也是如此。两个例外如下。

  • 当流量以安全网关为目的地时， 例如简单网络管理协议（SNMP）命令，此时安全网关是作为主机在行动，因此允许使用传输模式。在这种情况下，SA 终止于安全网关内部的主机（管理）功能，因而应当区别对待。

  • 如上所述， 安全网关可以支持传输模式 SA，以便为路径上两个中间系统之间的 IP 流量（例如主机与安全网关之间，或两个安全网关之间）提供安全。

若干因素促使在涉及安全网关的 SA 中使用隧道模式。例如，如果到达安全网关后方同一目的地存在多条路径（例如经由不同的安全网关），那么将 IPsec 包发送到与之协商了 SA 的那个安全网关就非常重要。类似地，可能在途中被分片的包，其所有分片都必须交付给同一个 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 的主机实现必须同时支持传输模式和隧道模式。 这对主机的原生（native）、BITS 和 BITW 实现都成立。

b) 安全网关必须支持隧道模式，并且可以支持传输模式。 如果支持传输模式，则仅应在安全网关作为主机行动时使用，例如用于网络管理，或用于为路径上两个中间系统之间提供安全。

最后于 更新