RFC4301 IP安全架构2005

RFC4301 IP安全架构-2005

RFC4301 IP安全架构

2005

第1页/共77页

RFC4301 IP安全架构-2005

该备忘录状态：

本文档为Internet社区指定了Internet标准跟踪协议，并请求讨论和提出改进建议。请参阅当前版本的”Internet官方协议标准”（STD 1）了解此协议的标准化状态。该备忘录的分发是不受限制的。

概述：

本文档描述新版IP安全架构，安全架构的目标是为IP层之上的数据流量提供安全服务。本文档废弃了RFC2401(1998)。

修订记录

第2页/共77页

RFC4301 IP安全架构-2005

目录

目录 (3)

1引言 (6)

1.1总览 (6)

1.2读者 (6)

1.3相关文档 (7)

2设计目标 (7)

2.1目标/目的/需求/问题描述 (7)

2.2注意事项和假定 (8)

3系统概览 (8)

3.1IPsec做什么 (9)

3.2IPsec如何做 (10)

3.3IPsec实现在哪里 (11)

4安全关联 (12)

4.1范围和定义 (12)

4.2SA功能 (15)

4.3组合SA (16)

4.4主要的IPsec数据库 (16)

4.4.1安全策略数据库（SPD） (17)

4.4.2安全关联数据库（SAD） (28)

4.4.3对端认证数据库（PAD） (34)

4.5SA和密钥管理 (38)

4.5.1手动技术 (38)

4.5.2自动SA和密钥管理 (38)

4.5.3定位安全网关 (39)

4.6SA和多播 (39)

5IP流量处理 (40)

第3页/共77页

RFC4301 IP安全架构-2005

5.1出站IP流量处理（由受保护到不受保护） (41)

5.1.1必须丢弃的出站封包的处理 (42)

5.1.2隧道模式下IP头构造 (43)

5.2入站IP流量处理（由不受保护到受保护） (46)

6ICMP处理 (49)

6.1处理定向到IPsec实现的ICMP错误类消息 (49)

6.1.1从不受保护侧收到的ICMP错误类消息 (49)

6.1.2从受保护侧收到的ICMP错误类消息 (50)

6.2处理受保护的传输ICMP错误类型消息 (50)

7分片处理（在IPsec边界受保护侧） (51)

7.1承载初始和非初始分片的隧道模式SA (52)

7.2为非初始分片分离出隧道模式SA (52)

7.3有状态分片检查 (53)

7.4BYPASS/DISCARD流量 (53)

8路径MTU/DF处理 (53)

8.1DF位 (54)

8.2路径MTU(PMTU)发现 (54)

8.2.1PMTU的传播 (54)

8.2.2PMTU的老化 (55)

9审计 (55)

10一致性要求 (55)

11安全考虑 (55)

12IANA考虑 (56)

13与RFC2401的差异 (56)

14致谢 (58)

附录A 词汇表 (58)

附录B 解相关 (60)

B.1 解相关算法 (61)

附录C SPD条目的ASN.1格式 (63)

附录D 分片处理原理 (68)

第4页/共77页

RFC4301 IP安全架构-2005

D.1 传输模式和分片 (68)

D.2 隧道模式和分片 (69)

D.3 非初始分片的问题 (70)

D.4 BYPASS/DISCARD流量 (71)

D.5 只是对端口说不 (72)

D.6 其他建议方案 (72)

D.7 一致性 (73)

D.8 总结 (73)

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

参考文档 (75)

Normative References (75)

Informative References (76)

第5页/共77页

RFC4301 IP安全架构-2005

1引言

1.1总览

本文档描述了兼容IPsec系统的基础架构，描述如何为IP之上的数据流提供一系列的安全服务，包括IPv4[Pos81a]和IPv6[DH98]环境。本文档描述实现IPSec的系统的需求，这类系统的基础元素，以及这些元素如何组合、集成到IP环境中。它同样描述了IPSec协议提供的安全服务，并且如何将这些服务部署到IP环境中。本文档不包括IPsec架构的方方面面，其他文档为特定的环境定义了架构的细节信息，比如在NAT环境上使用IPsec，以及对IP组播的全面支持。IPsec安全架构的基础组件以必选的底层功能方式讨论。其他RFC文档（参考1.3章节指出的文件链接）定义了（a）、（b）和（d）。

a.安全协议--认证头（AH）和封装安全载荷协议（ESP）

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

c.密钥管理--手动或自动（Internet密钥交换协议（IKE））

d.密码学算法--认证和加密的密码学算法

本文档不是关于整个Internet的安全架构，而只聚焦于通过组合使用密码学和协议安全机制实现IP层的安全。

“IPsec”被用于本文档以及其他相关IPsec标准，所有的其他IPSec的大小写形式（比如IPSEC、IPSec、ipsec）全部废弃。然而，”IPsec”的任何其他大小写形式都应该被认为是在引用IPsec协议。

本文档中出现的关键字MUST（必须）、MUST NOT（不得）、REQUIRED（必选的）、SHALL（将要）、SHALL NOT（将不会）、SHOULD（应该）、SHOULD NOT（不应该）、RECOMMENDED（推荐）、MAY （可能）、和OPTIONAL（可选），其含义参考RFC2119规范。

1.2读者

本文档的目标读者主要是实现本规范定义的IP安全技术的个人或者使用本技术搭建系统的个人，本技术的熟练用户（终端或者系统管理员）也是目标受众人群。附录A提供了词汇表，以帮助填补背景或术语上的空白。本文档假定读者熟悉IP协议，熟悉相关的网络技术，以及熟悉通用的系统安全术语和概念。

第6页/共77页

RFC4301 IP安全架构-2005

1.3相关文档

参考上文，其他文档提供了IPsec相关组件的详细定义以及它们间的关系，这些文档如下：

a.安全协议–描述认证头(AH)[Ken05b]和封装安全载荷(ESP)[Ken05a]的RFC文档

b.完整性和加密密码学算法 --一个RFC定义了用于AH和ESP的强制默认算法[Eas05]，一个类

似的RFC定义了用于IKEv2的强制算法[Sch05]以及用于每个加密算法的单独RFC。

c.自动化密钥管理 --关于”Internet密钥交换（IKEv2）协议”[Kau05]和”因特网密钥交换版本

2（IKEv2）中使用的加密算法”的[Sch05]

2设计目标

2.1目标/目的/需求/问题描述

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

IPsec为包含一个较小的防火墙功能，因为这是IP层访问控制的一个必要的组成。具体的IPsec 实现可以自由地提供更加复杂的防火墙机制，并且使用这些功能实现（覆盖）IPsec强制要求的功能（需要注意的是，如果在业务流量上施加额外的约束不能基于本规范定义的流量选择器功能和IKEv2进行协商，则会降低互操作性）。IPsec防火墙功能使用为所有IPsec流量提供的强制加密认证和完整性保护，比单独使用一个防火墙（一个不专用于IPsec内部参数的防火墙）外加单独的加密机制，将提供更好的访问控制能力。

大部分的安全服务功能通过两个安全协议，认证协议（AH）和封装安全载荷（ESP），以及通过使用密钥管理协议和流程来提供。IPsec协议集的部署上下文，以及它们的部署方式，由上下文中的用户/管理员决定。IPsec架构的目标是，保证兼容的实现，包括服务和管理接口，能满足广大用户的安全需求。

当IPsec被正确的实现和部署后，它不能对那些不使用IPsec进行流量保护的主机、用户以及其他Internet组件产生不利的影响。IPsec安全协议（AH和ESP，以及IKE的较小可扩展部分）被设计为密钥算法相对独立。这种模块化设计有利于不同密码算法集合的选择，而不会影响到实现的其它组成部分。比如，不同的用户社区可以根据具体需要选择不同的密码算法集合（创建强制的密码算法集）。

第7页/共77页

RFC4301 IP安全架构-2005

为了促进全球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）或者一个独立的设备，为IP流量提供保护（安全网关是实现IPsec的中间系统，比如一个使能IPsec功能的防火墙或者路由器）。关于实现IPsec 设备分类的详细信息将在下文第3.3章节进一步描述。IPsec提供的保护基于用户或者系统管理员建立和维护的安全策略数据库所定义的需求，或由在上述任一项建立的约束内运行的应用程序定义的需求。通常来说，封包将会依据封包的IP和下一层头部信息（”Selectors”选择器参考章节4.4.1.1）与SPD 中的条目进行匹配后，从三个处理动作中选择一个执行。每个封包基于选择器标识的可用的SPD策略，最终的处理动作是使用IPsec安全服务进行保护（PROTECTed）、丢弃（DISCARDed）或者是旁路（BYPASS）。

第8页/共77页

RFC4301 IP 安全架构-2005

第9页/共77页

3.1 IPsec 做什么

IPsec 为主机或者网络（见图1），在unprotected 和protected 接口间创建了一个边界。穿越边界的流量由负责IPsec 配置的用户或者管理员指定的访问控制策略支配。这些控制策略指示封包是否不受阻挡的穿越边界、通过AH 或ESP 的安全服务进行保护，或者被丢弃。

IPsec 安全服务在IP 层通过选择合适的安全协议、密码算法以及密钥，IPsec 可以保护一条或多条路径（path ）：

(a) 在一对主机间

(b) 在一对安全网关间

(c) 在一个安全网关和主机间

兼容主机的实现必须支持(a)和(c)， 并且兼容的安全网关必须支持上述三种形式的连接，因为在特定的情况下，安全网关本省也是一台主机。 Discard

IKE Discard

AH/ESP

B y p a

s

s IPsec Boundary Protected

Unprotected

图1： IPsec 处理模型的顶层视图 在本图中，"unprotected"可以描述为"black"或者"密文"的接口，而"protected"可以描述为"red"或者"明文"的接口（译者注：protected 侧指的是要受IPsec 保护的一侧，比如隧道模式下，安全网关的LAN 侧）。上边提及的被保护的接口可以在系统内部，比如在实现IPsec 的主机上，被保护的接口可以链接到操作系统的socket 层接口。在本文档中，术语入站（"inbound"）指的是通过不受保护的接口进入IPsec 的实现，或者由不受保护的边界侧的实现直接发往受保护的接口。术语出站（"outbound"）指的是通过受保护的接口进入IPsec 实现的流量，或者是由受保护的边界侧的实现直接发往不受保护的接口。IPsec 实现在边界的一侧或两侧可以支持多个接口。

RFC4301 IP安全架构-2005

请注意上图中在IPsec边界两侧丢弃流量的设施、允许流量不加密码学保护的穿越边界的BYPASS 设施、以及作为保护侧密钥和安全管理功能的IKE设施。

IPsec可选的支持协商IP压缩[SMPT01]，其部分目的是观察到，当在IPsec内部采用加密时，将阻止底层协议的有效压缩。

3.2IPsec如何做

IPsec使用两个协议来提供流量安全服务—认证头协议(AH)和封装安全载荷协议(ESP)。两个协议分别在其标准文档中详述[Ken05b,Ken05a]。IPsec实现必须支持ESP协议，可选支持AH协议（AH协议降级为可选，因为过去的经验表明，只有在极少数的情况下ESP不能提供必要的安全服务。需要注意的是，ESP只用作完整性保护，而不考虑加密时，在大多数情况下其与AH协议是等价的）。

o IP认证头协议AH[Ken05b]提供完整性和数据源认证，以及可选的（由接收方决定）防重放特性。

o 封装安全载荷ESP协议除提供AH协议功能外，同时支持机密性。不推荐使用ESP机密性而不使用其完整性保护特性。当在启用保密性的情况下使用ESP时，对有限的业务流机密性存在规定，比如隐藏封包长度的规定，促进有效生成和丢弃伪包的规定。这个特性更多是在虚拟专用网(VPN)和叠加网络场景下生效（隧道模式）。

o AH和ESP均提供访问控制，其通过密码学密钥的分发和安全数据库（SPD）规定的业务流管理功能实现。

这两个协议可以各自单独或组合在一起使用，为IPv4和IPv6提供安全服务。但是，大多数的需求可以通过单独使用ESP来满足。每个协议支持两个使用模型：传输模式（transport mode）和隧道模式（tunnel mode）。在传输模式下，AH和ESP主要为下一层协议提供保护；在隧道模式下，AH和ESP 被用于保护隧道内的IP封包。这两个传输模式的不同将在4.1章节进一步探讨。

IPsec允许用户（或系统管理员）控制提供安全服务的粒度。比如，可以创建一个单独的加密隧道承载两个安全网关间的所有流量，或者为两个网关之后的一对主机之间的每个TCP连接创建一个单独的隧道。IPsec通过SPD可以指定：

o 采用哪个安全协议（AH或ESP），传输模式（transport或tunnel），安全服务选项，使用什么样的加密算法，使用什么样的特定协议和服务的组合，以及

o 应用保护的粒度

由于IPsec提供的大多数安全服务需要使用加密密钥，IPsec依赖单独的获取密钥的机制（可以有多种），本文档要求必须支持密钥的手动和自动两种分发机制，本文档为自动密钥分发指定了一种特定的

第10页/共77页

RFC4301 IP安全架构-2005

基于公钥的方法（IKEv2 [Kau05]）,但是也可以使用其他的密钥自动分发技术。

注意：本文档要求强制一些在IKEv2支持但是IKEv1不存在的特性，比如描述本地和远程端口范围的SA的协商、或者使用同一选择器的多个SA的协商。因此，本文档假定使用IKEv2或者具有类似功能的SA管理系统。

3.3IPsec实现在哪里

IPsec有多种实现方式，可以在主机上实现，或者与路由器和防火漆一起创建安全网关，或者作为独立的安全设备，具体如下：

a.IPsec可以直接集成进本地IP协议栈。这需要访问IP源代码，并且适用于主机和安全网关，当

然本机主机实现从该策略中受益最大，如后文所述（第4.4.1节，第6段；第4.4.1.1节，最后一段）。

b.在一个BITS（"bump-in-the-stack"）实现里，IPsec在现有IP协议栈实现的“下方”实现，

位于在本地IP和本地网络驱动层之间。在此场景下，因为不需要访问IP协议栈的源码，使得这种实现手段适合于老旧系统，通常在主机上采用此实现方法。

c.常见于军方使用的系统以及某些商业系统采用专用的嵌入式安全协议处理器实现IPsec，这有时

被称为BITW（”bump-in-the-wire”）实现，这种实现通常服务于主机或者网关。通常来说，BITW设备本身是可寻址的。当支持单个主机时，它可能与BITS实现非常相似，但是在支持路由器或者防火墙时，它必须像安全网关一样运行。

本文档通常以主机或安全网关使用IPsec进行讨论，而不关注实现方式是native、BITS或者BITW。当这些实现之间的差异足够大时，本文档才会提到特定的实现手段。

IPsec的主机实现可能出现在可能不被视为“主机”的设备中，比如，一个路由器也许使用IPsec 去保护路由协议（比如BGP）和管理功能（比如Telnet），而不影响租户（subscriber）流量穿越路由器。安全网关也许会使用不同的IPsec实现去保护它的管理流量和用户的流量。本文档中描述的架构非常具有弹性（灵活）。比如，具有全功能、兼容的、操作系统原生的IPsec实现应该能够配置为不仅能够保护本机应用程序的流量，也可以为通过计算机的流量提供安全保护。这些配置将使用转发表和第5.1和5.2章节描述的SPD选择功能。

第11页/共77页

RFC4301 IP安全架构-2005

4安全关联（SA）

本章为所有的IPv6实现和支持AH、ESP或者两者都支持的IPv4实现，定义安全关联管理需求。安全关联(SA，也可翻译成安全联盟)的概念是IPsec的基础，AH和ESP都使用SA，并且建立和维护SA 是IKE的主要功能。AH或ESP的所有实现必须支持下边描述的SA概念，本章节的其余部分都描述SA 管理的各个方面，并定义SA策略管理和SA管理技术必须支持的特性。

4.1范围和定义

SA是一个简单的“连接”，并为其承载的流量提供安全服务。SA通过使用AH或者ESP提供安全服务，但是不能同时使用两者（译者注：指的是AH和ESP使用两个独立的SA），如果AH和ESP同时应用于一个业务流，则必须创建两个SA，并且协调两者叠加起来提供安全服务。为了保护典型双向通信的安全，需要一对SA（每个方向一个SA），IKE显式地创建SA对，以满足这种常见的使用需求。

对于用来承载单向流量的SA，SPI（安全参数索引）足够用来指定（匹配）一个SA（对于SPI，参考附录A与AH和ESP规范[Ken05b, Ken05a]）。然而，作为一个本地事务，实现可以使用SPI连同IPsec协议类型（AH或ESP）作为SA的标识。如果IPsec实现支持组播，则它必须支持组播SA，并使用下边描述的映射入站封包到SA的算法，对于只支持单播封包的IPsec实现，不需要支持这个解复用机制。

在许多安全组播架构中，比如[RFC3740]，一个集中式的组控制器/密钥服务器单方面的分配组安全关联（GSA）的SPI，这种SPI的分配不与运行于各个独立的终端系统（正是由这些终端系统构成了组）上的密钥管理系统（比如IKE）进行协商或者协调。结果是，GSA和单播SA可能同时使用相同的SPI,具备组播能力的IPsec实现必须正确解复用入站流量，即使在SPI冲突的上下文环境中。

SAD（SA数据库）中的每条记录必须指示SA查找除了使用SPI外，是否使用目的IP地址，或者目的和源IP地址。对于组播SA，协议字段不用于SA查找。对于每个受IPsec保护的入站封包，IPsec 实现必须进行SAD搜索，以找到“最长”匹配的SA标识符。在这个上下文中，如果基于SPI查找到两个或多个SAD条目，则进一步根据目的地址，或者目的地址和源地址，进一步匹配得到“最长”匹配。这表示SAD搜索的顺序如下：

1.以同时匹配SPI、目的地址和源地址的组合搜索SAD，如果找到这样的条目，则使用匹配的SAD

条目处理入站封包，否则转步骤2；

2.以同时匹配SPI和目的地址的组合查找SAD，如果找到，则使用匹配到的SAD条目处理入站封包，

否则转步骤3；

第12页/共77页

RFC4301 IP安全架构-2005

3.如果接收方已经选择为AH和ESP，或者为SPI和协议，维护一个统一的SPI空间，则只以SPI

为key查找SAD，如果找到，则按照匹配的SAD条目处理入站封包，如果未找到，则丢弃封包并记录可审计的事件。

实现可以选择任何（甚至没有）加速搜索的方式，然而其外在行为必须从功能上等价于上述顺序搜索SAD的结果。比如，基于软件的实现可以通过SPI索引一个HASH表。每个哈希表存储桶的链接列表中的SAD条目可以保持排序，以使那些SAD标识符最长的SAD条目在该链接列表中排在最前面，可以对具有最短SA标识符的SAD条目进行排序，以使它们成为链表中的最后一个条目。基于硬件的实现，通过使用三进制可寻址内存（TCAM）特性，可以从本质上实现最长匹配。

是否使用目的和源地址作为映射入站IPsec封包到SA的指示，必须通过手动SA配置的副作用设置，或者通过SA管理协议协商方式进行设置，比如IKE或者组域解释协议（GDOI）[RFC3547]。通常，特定源组播（SSM）[HC03]使用由SPI、目的组播地址和源地址三元组组成SA的标识符，而任意源组播组SA只需要SPI和目的组播地址作为标识符。

如果不同类别（通过差分服务码（DSCP）标识）流量通过同一SA发送，并且如果接收方在AH和ESP 上都采用了可选的防重放功能，这将导致低优先级封包会由于防重放功能的窗口机制，被不适当的丢弃。因此，发送方发送不同类别的流量时，应该使用相同的选择器，从而在不同的SA上支持合适的服务质量（QoS）。为了达到此目的，IPsec实现必须允许在发送方和接收方建立和维护多个使用相同选择器的SA。在这些并行的SA上分发流量以支持不同的QoS，由本地的发送方决定，而不是通过IKE进行协商，接收方必须能够在没有预判的情况下处理来自不同SA的封包。此要求适用于传输模式和隧道模式SA。在隧道模式下，DSCP取值出现在内部IP头中，在传输模式下，DSCP取值也许会在路由过程中被修改，但是这不应该产生问题，因为在IPsec处理时，DSCP取值不会参与SA选择，并且也不得作为SA/封包有效性的一部分。但是，如果SA中发生显著的封包重新排序时，比如由于路由中DSCP值的改变，这将触发封包由于防重放机制的应用而被丢弃。

讨论：尽管DSCP [NiBlBaBL98, Gro02]和显式拥塞通知(ECN)[RaFlB101]字段不是“选择器”（selector），正如本架构文档中使用的术语，发送方需要一种将指定QoS的封包定向到合适的SA的机制，这种机制可以被称为“分类器”（classifier）。

如上文描述，定义了两种类型的SA：传输模式和隧道模式。IKE创建SA对，简单起见，我们要求一对中的两个SA必须是同一模式：传输模式或者隧道模式。

传输模式通常用于为一对主机之间提供端到端的安全服务。当沿着路径上的两个中间系统之间（相对于端到端使用IPsec）需要安全性时，传输模式在两个安全网关之间或者在安全网关和主机之间使用。当传输模式用于安全网关或安全网关和主机之间场景时，传输模式可以用于支持in-IP隧道（比如

第13页/共77页

RFC4301 IP安全架构-2005

IP-in-IP[Per96]或通用路由封装（GRE）[FaLiHaMeTr00]或者动态路由[ToEgWa04]）over传输模式SA。作为澄清，仅当应用于封包的源地址（对于出站封包）或者目的地址（对于入站封包）属于中间系统自身时，才允许中间系统（比如安全网关）使用传输模式。作为IPsec重要组成部分的访问控制功能在此应用场景将受到巨大的限制，因为它们不能用于以这种方式穿越传输模式SA的封包的端到端的头。因此，在这种特定上下文中使用传输模式时，要自己评估。译者注：不推荐传输模式承载ip实现隧道，应该直接使用隧道模式。

在IPv4中，传输模式安全协议头出现在IP头和IP选项之后，并且在任何下一层协议（比如TCP 或UDP）之前。在IPv6中，传输模式安全协议头在基本IP头和特定扩展头之后，但是可以出现在目的选项之前或之后，它必须出现在下一层协议前（TCP、UDP或STCP）。在ESP情况下，传输模式SA只为下一层协议提供安全服务，不包含IP头或在ESP头之前的任何扩展头。在AH情况下，安全保护扩展到AH报头前的IP头的特定部分，扩展头的特定部分，和特定选项（包含在IPv4头、IPv6 Hop-by-Hop 扩展头或者IPv6目的地扩展头）。AH安全服务覆盖范围的更多细节，参考AH规范[Ken05b]。

隧道模式SA是应用于IP隧道的必要SA，且访问控制应用于隧道内部流量的头部。两个主机可以在它们之间创建隧道模式SA。除了以下两个例外，只要安全关联的任一端是安全网关，则SA务必为隧道模式。因此，两个安全网关之间的SA通常是隧道模式SA，主机与安全网关之间的SA也是如此。两个例外如下：

o 流量的最终目的地是安全网关自身（比如，简单网络管理协议（SNMP）命令），安全网关的行为和普通主机一样，此时允许使用传输模式。在此场景下，SA终结于安全网关内部的主机（管理）功能，因此值得区别对待；

o 如上所述，安全网关可以支持使用传输模式为沿路径上的两个中间系统的IP流量提供安全服务，比如在主机和安全网关或两个安全网关中间。译者注：就是上面提到的ip over传输模式实现隧道功能。

涉及安全网关的隧道模式SA的使用引起了一些关注，比如，如果去往一个安全网关后边的同一目的地存在多个路径（经过不同的安全网关），则将IPsec封包发往与其协商SA的安全网关非常重要。同样地，一个封包由于路由分片成的多个片段必须交付到相同的IPsec实例，以便进行加密处理前的重组操作。并且，当片段由IPsec处理并传输，然后在传输过程中进行分段时，至关重要的是，必须有内部和外部标头来保留IPsec处理之前和之后的数据包分片的状态数据。所以，当SA任一端是安全网关时，采用隧道模式有多个理由（将IP-in-IP隧道和传输模式结合使用，也可以解决分配问题，但是，其限制了IPsec对流量实施访问控制策略的能力）。

注意：AH和ESP不能使用传输模式应用于IPv4数据包的分片，只有隧道模式可以应用于这种场景。对于IPv6，在传输模式SA上承载明文分段是可行的，但是，为了简单起见，该限制同样适用于IPv6封

第14页/共77页

RFC4301 IP安全架构-2005

包。有关在IPsec边界的受保护一侧处理明文分段的更多细节信息，请参考第7章。

对于隧道模式SA，存在“外部”IP头，其指定了IPsec处理的源和目的，外加“内部”IP头，其指定了封包的最终源和目的地。安全协议头出现在外部IP头之后，内部IP头之前。如果在隧道模式采用AH，外部IP头的一部分收到保护（见上），同时整个隧道内IP包将会收到保护（比如整个内部IP 头和下一层协议）。如果采用ESP，保护应用于隧道内封包，而不是外部头。总结如下：

a)IPsec的主机实现必须支持传输和隧道模式，不论其实现方式是natvie、BITS还是BITW。

b)安全网关必须支持隧道模式，可选支持传输模式。如果它支持传输模式，只能应用于保护安全网

关作为主机的功能，比如用于网络管理或者为沿路径上的两个中间系统提供安全性。

译者注：规范未禁止安全网关使用IP in IP over传输模式实现隧道。

4.2SA功能

SA提供的安全服务集取决于选择的安全协议、SA模式、SA端点以及协议中可选服务的选项等多个因素。

比如，AH和ESP都提供完整性保护和认证服务，但是覆盖的范围因每个协议以及传输模式和隧道模式不同而不同。除了那些可能会以发送方无法预测的方式被修改的IP头和扩展头，如果要在发送和接收方路由过程中保护IPv4选项或IPv6扩展头，AH可以提供此服务。但是，相同的安全性在特定上下文中可以通过应用ESP封装隧道隧道封包达成。

访问控制的粒度由定义SA的选择器决定。进一步地，IPsec对端选择的认证方式（比如，在创建IKE （相对子） SA期间）也影响提供的访问控制的粒度。

如果选择机密性，则两个安全网关之间的的ESP（隧道模式）SA能提供部分业务流机密性。使用隧道模式允许加密内部IP头，隐藏业务流最终的源和目的地。进一步地，ESP载荷填充也可以隐藏封包的尺寸，从而隐藏流量的外部特性。同样的业务流机密性可以服务于在拨号上下文中，一个移动用户被分配动态IP地址，并与公司防火墙（充当安全网关）建立一个隧道模式的ESP SA的场景。需要注意的是，细粒度的SA通常比承载多个订阅客户的流量的粗粒度的SA，更容易受到流量分析的攻击。

注意：兼容的IPsec实现不允许存在加密算法和完整性算法同时为NULL的ESP SA的实例。尝试协商这样的SA对于发起者和应答者都是一个可审计的事件，这个事件的审计日志应该包含当前日期/时间、本地IKE的IP地址，和对端IKE IP地址，发起方应该同时记录相关的SPD条目。

第15页/共77页

RFC4301 IP安全架构-2005

4.3组合SA

本文档不要求支持嵌套的安全关联或者RFC2401定义的"SA bundles"。这些功能仍然可以通过对SPD和本地转发功能（对于入站和出站流量）两者的适当配置实现，但是该功能不在IPsec模块的范围内，因此，与RFC 2401所隐含的模型相比，嵌套/捆绑SA的管理可能更加复杂且不确定。支持嵌套SA 的IPsec实现应该提供一个管理界面，使得用户或者管理员可以表达嵌套需求，从而创建合适的SPD条目和转发表以实现所要的处理（参考附录E中关于如何配置嵌套SA的实例）。

4.4主要的IPsec数据库

IPsec实现中关于如何处理IP流的许多细节大多是本地问题，不受标准的支配。然而，这些处理的外在结果必须被标准化，以保证互操作性并提供IPsec产品化所需要的最小管理能力（译者注：怎么做协议不管，但是做什么要遵从协议）。本章节为IPsec功能如何处理相关的IP流描述一个通用的模型，以支持互操作性和功能性目标。下边描述的模型是名义上的，具体实现不需要与该模型所呈现的细节相匹配，但是具体实现的外部行为必须与该模型的外部可观察特征相对应，以便兼容。

在这个模型中存在三个名义上的数据库：安全策略数据库（SPD）、安全关联数据库（SAD）和对端认证数据库（PAD）。第一个指定了主机或安全网关（参考4.4.1）所有入站、出站IP流量的如何处置的策略。第二个数据库包含了每个被建立的（keyed）SA（章节4.4.2）的相关参数。第三个数据库，PAD，为SA管理协议（如IKE）和SPD（章节4.4.3）提供了连接。

多个独立的IPsec上下文：

如果IPsec实现作为多个租户的安全网关，它可以实现多个单独的IPsec上下文。每个上下文可以有并且可以使用完整地独立的标识、策略、密钥管理SA、和/或IPsec SA。这其中的大部分由本地具体实现确定。然而，需要一种将入站SA关联到本地上下文的方式。为此，如果使用的密钥管理协议支持，上下文标识可以通过信令消息从发起者传递给应答方，从而创建一个绑定到特定上下文的IPsec SA。比如，为多个客户提供VPN服务的安全网关可以关联每个客户的流量到正确的VPN。

转发vs安全决策：

此处描述的IPsec模型体现了转发（路由）和安全决策间的明确区分，以满足IPsec可能广泛部署的各种上下文环境。转发也许是简单的，比如只存在两个接口的设备，或者是复杂的，实现IPsec的上下文使用复杂的转发功能。IPsec只假设通过IPsec处理的出站和入站流量以与IPsec实现所在的上下文一致的方式转发。嵌套SA是可选的，如果需要，它要求转发表和SPD

第16页/共77页

RFC4301 IP安全架构-2005

条目间的协调以使封包多次穿越IPsec边界。

"Local" vs "Remote"：

本文档中，相对于IP地址和端口，术语"Local"和"Remote"用于策略规则。"Local"指的是被Ipsec实现保护的实体，比如，出站封包的“源”地址/端口或者入站封包的“目的”地址/端口。"Remote"指的是对端实体或对端实体集，术语“源”和“目的”用于表示封包头中的字段。

"Non-initial" vs "Initial":

在本文档中，短语“非初始分片”用于表示可能不包含访问控制需要的所有选择器值的分片（比如，它们可能不包含下一层协议、源和目的端口、ICMP类型/代码、移动头类型）。短语“初始片段”用于表示包含用于访问控制的所有选择器值的片段。但是，需要注意的是对于IPv6，其分片包含下一层协议和端口（或者ICMP消息类型/代码或者移动头类型[Mobip]），将取决于出现的扩展头的类型和数目。在这个上下文中，“初始片段”也许不是第一个分片。

4.4.1安全策略数据库（SPD）

SA是为穿越IPsec边界的流量实施安全保护策略的管理结构，因此，SA处理的关键元素是底层的安全策略数据库（SPD），它指出了给IP包提供何种以及以何种方式提供服务。SPD的格式和接口超出了本规范的范围，但是，本章指出了必须提供的最小管理功能，使得用户或系统管理员控制IPsec是否并且如何应用到出入主机或安全网关的流量。在处理所有出站、入站流量，包括不受IPsec保护的流量但穿越IPsec边界的流量，都需要查找SPD或者相关缓存，这包括诸如IKE的IPsec管理流。IPsec 实现必须至少存在一个SPD，并且可以支持多个SPD，如果其适合IPsec实现所在的上下文。无需像RFC2401中所指定的那样在每个接口的基础上维护SPD，但是，如果IPsec实现支持多个SPD，则它必须包含显式的SPD选择功能，用于为出站流量处理选择合适的SPD。该功能的输入是出站封包和任何影响SPD选择的本地元数据（比如封包到达的接口），该功能的输出是SPD标识符（SPD-ID）。

SPD是一个有序数据库，与访问控制列表或者防火墙、路由器中的封包过滤器的使用保持一致。出现排序要求的原因是，由于选择器取值范围经常存在重叠。因此，用户或者管理员必须能够排序条目以表达期望的访问控制策略。由于允许对选择器值使用通配符，而且不同类型的选择器没有层次关系，因此无法对SPD项的施加通用的、规范的顺序。

处理选项：丢弃（DISCARD）、旁路（BYPASS）、保护（PROTECT）

SPD必须能够在流量间区分需要IPsec保护和允许旁路IPsec处理的流量。这适用于要由发送方决定的IPsec保护，也适用于必须存在于接收方的IPsec保护。对于任何出站和入站的数据

第17页/共77页

RFC4301 IP安全架构-2005

报文，存在三个可能的IPsec流量处理选项：DISCARD、BYPASS或PROTCT。第一个选项是指不允许穿过IPsec边界（在指定的方向上）的流量；第二个选项指的是允许不经IPsec保护穿越IPsec边界的流量；第三个指的是受IPsec保护的流量，并且必须为这些流量的SPD指定采用的安全协议、模式、安全服务选项，以及使用的加密算法。

SPD-S、SPD-I、SPD-O

SPD从逻辑上可以分为三部分。SPD-S（安全流量）包含所有受IPsec保护的流量的条目；SPD-O （出站）包含所有旁路或丢弃的出站流量的条目；SPD-I（入站）应用于旁路或丢弃的入站流量。

所有这三个部分都可以解（去）相关（除了上文提到的本地主机实现这个例外外）以便于缓存。

如果一个IPsec实现只支持一个SPD，则该SPD包含所有三个部分。如果支持多个SPD，它们中的一些可以是整个SPD的一部分，比如一些SPD可以只包含SPD-I条目，以接口为单位控制入站旁路的流量，分隔使得这些流量只需访问SPD-I而不必咨询SPD-S。因为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）标志（参考下边“如何派生SAD条目的值”段落），以及指示出使用SPI外（参考AH和ESP规范）是否使用本地或远端地址进行SA查找的BIT位。

第18页/共77页

RFC4301 IP安全架构-2005

SPD条目的方向性

对于IPsec保护的流量，通过交换SPD条目中的本地/远端地址和端口以表示方向性，这与IKE 的约定一致。一般来说，IPsec处理的协议要具有翻转本地/对端IP地址的对称SA的属性（比如TCP/UDP通信双方地址/端口是对称的）。然而，对于ICMP，通常没有这种双向认证需求。

不论如何，为了统一和简单起见，ICMP的SPD条目也以其他协议相同的方式进行指定。而对于ICMP、可移动头以及非初始分段，还需要注意的是，这些封包中没有端口字段，但ICMP存在消息类型和代码，可以存在可移动头类型。因此，SPD条目具有表示适用于这些协议的访问控制的规定，以代替常规用端口字段控制。对于旁路或丢弃的流量，支持分离的入站和出站条目，比如如果需要允许单向流。

OPAQUE和ANY

对于SPD条目中的每个选择器，除了定义匹配的字面取值之外，还有两个特殊取值：ANY和OPAQUE。ANY是一个通配符，它可以匹配封包中相应字段的任何取值，可以匹配没有对应字段的封包、也可以匹配对应字段被隐藏的封包。OPAQUE指示相应的选择器字段是不可用的，包括对应字段没有出现在分段中，指定的下一层协议并不存在、以及前边的IPsec应用加密了该字段等场景。ANY值的范围包括了OPAQUE情况，因此，仅在需要对字段的任何允许值的情况与字段的不存在或不可用性（例如，由于加密）之间进行区分时，才需要使用OPAQUE。

如何生成SAD条目的值

对于SPD条目中每个选择器，指定了如何从SPD的条目和封包中生成新的SAD条目的对应选择器的取值。目标是基于封包或者匹配的SPD条目中特定的选择器的值，去创建SAD条目和SPD 缓存条目。对于出站流量，存在SPD-S和SPD-O缓存条目；对于不受IPsec保护的入站流量，存在SPD-I缓存条目以及存在用于受IPsec保护的入站流量（参考4.4.2章节）的SAD缓存。

如果条目指定需要进行IPsec处理，则SPD条目中一个或多个选择器（本地IP地址、远端IP 地址、下一层协议、并且依赖于下一层协议的本地和远端端口或者ICMP类型/代码、或者移动动头类型）可能被“从封包填充”标志（PFP）断言为真。如果给定的选择器X断言为真，则表示被创建的SA中的X应该从封包中取值，否则，SA应该为X从SPD条目中取值。注意：在非PFP情况下，被SA管理协议（比如IKEv2）协商的选择器的值可以是对应SPD条目中对应选择器取值范围的子集，这依赖于对端SPD的策略。同样，使用单独一个标志，比如源端口、ICMP 类型/代码和可移动头（MH）类型共用一个PFP标志，或者每个选择器使用一个标志，由本地实现决定。

如下的例子解释了在安全网关或BITS/BITW实现中PFP标志的使用。假设一个SPD条目其允许的

第19页/共77页

RFC4301 IP安全架构-2005

远端IPv4地址范围内是192.0.2.1到192.0.2.10，假定一个目的地址为192.0.2.3的出站封包到达，并且当前没有现存的SA承载这个封包，则用于传输这个封包而新建的SA中的目的地址的取值取决于SPD条目中对应选择器以哪个作为取值的源：

注意，如果SPD条目中对于远端地址选择器的取值为ANY，则SAD选择器的取值，在情况b中必须是ANY，但是保持情况a下取值不变；因此，PFP标志可以用来禁止SA的共享，即使在匹配相同SPD条目的封包之间。

管理接口

对于每个IPsec实现，都必须为用户或系统管理员提供SPD的管理接口。这个管理接口必须允许用户（或管理员）为每个穿越IPsec边界的封包指定需要应用的安全处理（在本地主机IPsec实现中使用套接字接口，就像在第4.4.1.1和第5章节中提到的一样，不需每个封包都需要咨询SPD）。SPD的管理接口必须允许创建与第4.4.1.1章节中定义的选择器相一致的条目，并且必须支持这些条目的（整体）排序，如同从该接口看到的一样。SPD条目的选择器就如同ACL或者常见于无状态防火墙中的分组过滤器，或者路由器中的分组过滤器一样的方式进行管理。

在主机系统中，应用程序可以创建SPD条目（这种到IPsec实现请求的信令的含义超出了本文档的范围）。但是，系统管理员必须能够指定是否允许用户或应用程序是否能够覆盖（默认的）系统策略，本文档不指定管理接口的形式，该接口形式可能因主机或者安全网关而不同，因主机使用基于socket的接口和BITS实现方式而不同。然而，本文档指定了所有IPsec实现都必须支持的SPD元素的标准集。

解相关（Decorrelation）

本文档中描述模型假定具备对重叠的SPD条目进行解相关以允许缓存，从而可以使得安全网关和BITS/BITW实现更有效率的处理出站流量。解相关[CoSa04]只是提高性能和简化处理描述的一种手段。本文档不强制要求兼容的实现利用解相关手段。比如本地主机实现通常利用隐式缓存，因为它们将SA绑定到了socket接口，因此，在这种实现方式下就没有解关联SPD条目的需求。

注意：除非特别限定，”SPD”指的是处于有序或解关联（无序）状态的策略信息体。附录B中提供了用于解关联SPD条目的算法，但是可以使用任何其他能够到达相同输出结果的算法。注意，当一个SPD 条目解关联后，所有产生的条目必须被链接到一起，以便从一个个体派生出的一个组的所有组员、SPD条目（解关联之前）都可以同时放入缓存和SAD中。比如，假定从条目A（来自一个有序的SPD）开始解关联，产生了条目A1、A2和A3。当出现匹配的封包时，比如说A2，触发了SA的创建，则SA管理协议（比

第20页/共77页

RFC4301 IP安全架构-2005

如IKEv2）协商A，并且所有3个解关联的条目，A1、A2和A3都被放入到合适的SPD-S缓存，并连接到SA。目的是，使用解相关的SPD不应该比使用非解相关的SPD创建更多的SA。

如果使用了解相关的SPD，则有三个发起者通过SA管理协议（比如IKE）选项发送给对方。通过发送完整选自SPD的链接的、非相关的条目的集合，为对端选择合适的SPD条目提供了最可能的信息，尤其当对端也存在解相关的SPD时。然而，如果链接了大量的解相关条目，这将在SA协商时创建较大的封包，并因此产生SA管理协议的分片问题。

可选地，来自（关联的）SPD的原始的条目可以保存下来，并发送给SA管理协议。传递关联的（correlated）SPD条目保证了本地使用解关联的SPD的方式，而对对端不可见，并且避免了可能的分片问题，然而，这为对端匹配其应答的SPD提供了较少的精确的信息。

一个折中的方案是发送完整的链接在一起的解相关的SPD条目的集合的子集。这个解决方案可以避免上文提到的分片问题，并比原始的、未解相关的SPD条目提供了更好的信息。这个方案的主要不足是，也会会在稍后创建额外的SA，因为只有链接的、非解相关的条目的子集发送到了对端。实现着可以自由的选择上面提到的各种手段。

应答方使用从SA管理协议接收到的流量选择器建议，从本地SPD中选择合适的条目，匹配的目的是选择一个SPD条目并创建SA，该SA最接近发起方的意图，使得穿越该SA的流量最大程度被双方都接受。如果应答方选择了解关联的SPD，它应该使用解相关的SPD条目进行匹配，通常情况下会创建一个更加匹配双方意图的SA。如果应答方有一个相关的SPD，它将使用相关的条目匹配发送的建议。对于IPv2，使用解相关的SPD为应答方提供了生成“缩小”响应的最佳机会。

在所有的情况下，当解关联的SPD可用时，则使用解相关的条目填充SPD-S缓存。如果SPD不是解相关的，则不允许进行缓存，并且必须对SPD进行有序搜索，以验证该SA的入站流量与SPD表达的访问控制策略是一致的。

在系统运行过程中处理SPD的变化

如果在系统运行中，SPD发生变化，则需要检查此变化对现存的SA的影响。实现应该检查SPD的修改对现存的SA的影响，并且应该为用户/管理员提供一个机制，用于配置应该执行的处理，比如删除受影响的SA、允许受影响的SA继续保持不变等等。

4.4.1.1 选择器

SA可以是细粒度的也可以是粗粒度的，具体取决于用于定义SA流量集的选择器。例如，两个主机之间的所有流量都可以通过单个SA承载，并提供统一的安全服务集。可选地，一对主机间的流量可以分布于多个SA，取决于正在使用的应用（被下一层协议和相关字段，比如端口决定），使用不同SA提供不

第21页/共77页

本文来源：https://www.bwwdw.com/article/bn2l.html