可视化网站开发平台,网站建设和风险分析,黄岛网站建设多少钱,给你网站你会怎么做1. 引言
1.1. 文档内容摘要
本文档规定了符合IPsec标准的系统的基本架构。它描述了如何为IP层的流量提供一组安全服务#xff0c;同时适用于IPv4 [Pos81a] 和 IPv6 [DH98] 环境。本文档描述了实现IPsec的系统的要求#xff0c;这些系统的基本元素以及如何将这些元素结合起来…1. 引言
1.1. 文档内容摘要
本文档规定了符合IPsec标准的系统的基本架构。它描述了如何为IP层的流量提供一组安全服务同时适用于IPv4 [Pos81a] 和 IPv6 [DH98] 环境。本文档描述了实现IPsec的系统的要求这些系统的基本元素以及如何将这些元素结合起来并融入IP环境中。它还描述了IPsec协议所提供的安全服务以及这些服务如何在IP环境中使用。本文档没有涉及IPsec架构的所有方面。其他文档涉及专门环境下的其他架构细节例如在网络地址转换NAT环境中使用IPsec以及对IP组播的更全面支持。IPsec安全架构的基本组件根据其所需的底层功能进行讨论。其他RFC文档参见第1.3节的指明的其他文档定义了以下协议
a. 安全协议 - 身份验证头AHAuthentication Header和封装安全载荷ESP:Encapsulating Security Payload
b. 安全关联Security Associations - 它们是什么以及如何工作如何管理关联处理
c. 密钥管理 - 手动和自动Internet密钥交换IKEInternet 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实施可以作为主机、安全网关 (SGsecurity gateway) 或独立设备运行为IP流量提供保护。安全网关是实施了IPsec的中间系统例如已启用IPsec的防火墙或路由器。对这些实现类别的更详细说明将在第3.3节中提供。IPsec所提供的保护是基于由用户或系统管理员建立和维护的安全策略数据库 (SPDSecurity Policy Database) 所定义的要求或者是由受上述任一方约束的应用程序所实施的。通常来说根据IP和下一层头信息选择器Selectors第4.4.1.1节数据包根据与SPD条目匹配而被选择执行三种处理操作中的一种。每个数据包根据选择器所识别的适用SPD策略要么使用IPsec安全服务进行保护要么被丢弃要么被允许绕过IPsec保护。
3.1. IPsec 提供的功能
IPsec在主机或网络中创建了一个未受保护和受保护接口之间的边界见下图。穿越该边界的流量按照由负责IPsec配置的用户或管理员指定的访问控制进行限制。这些控制指示数据包是畅通无阻地穿越边界还是通过AH或ESP获得安全服务或者被丢弃。
IPsec安全服务通过选择合适的安全协议、密码算法和加密密钥在IP层提供。IPsec可用于保护一个或多个路径
(a) 一对主机之间
(b) 一对安全网关之间或
(c) 安全网关与主机之间。
符合要求的主机实现必须支持(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 HeaderAH和封装安全负载Encapsulating Security PayloadESP。这两个协议在各自的RFC文件中有详细描述[Ken05bKen05a]。IPsec的实现必须支持ESP并可以支持AH由于经验表明在很少的情况下ESP无法提供所需的安全服务因此对AH的支持已降级为可选。请注意ESP可以用于仅提供完整性而无需保密性在大多数情况下与AH类似。 IP认证头AH[Ken05b]提供完整性和数据源身份验证接收方可以选择自行决定使用抗重放特性。 封装安全负载ESP协议[Ken05a]提供相同的服务并且还提供机密性。不推荐使用ESP仅提供机密性而不提供完整性。当启用了机密性的ESP时可以通过特殊的措施来限制流量的机密性例如隐藏数据包长度和便于生成和丢弃虚拟数据包。这种能力主要适用于虚拟私有网络VPN和叠加网络的上下文中。 AH和ESP都提供访问控制通过分发加密密钥并根据安全策略数据库Security Policy DatabaseSPD第4.4.1节管理流量流动来执行。
这些协议可以单独应用或者相互结合以提供IPv4和IPv6安全服务。然而大多数安全需求可以通过单独使用ESP来满足。每个协议都支持两种使用模式传输模式transport mode和隧道模式tunnel mode。在传输模式下AH和ESP主要为下一层协议提供保护在隧道模式下AH和ESP应用于隧道化的IP数据包。这两种模式之间的区别在第4.1节中讨论。
IPsec允许用户或系统管理员控制安全服务提供的粒度。例如可以创建一个单一的加密隧道来承载两个安全网关之间的所有流量或者可以为每对跨越这些网关进行通信的主机之间的每个TCP连接创建一个单独的加密隧道。通过SPDSecurity 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仅仅使用安全参数索引SPISecurity 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数据库(SADSA 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条目可以排序使其成为链表中的最后几个条目。基于硬件的实现可以使用通用的三态内容寻址存储器TCAMTernary Content-Addressable Memory功能来实现最长匹配搜索。
指示是否需要通过源地址和目标地址匹配来将入站IPsec流量映射到SA必须是手动SA配置的副作用之一或者通过使用SA管理协议如IKE或组域解释GDOIGroup Domain of Interpretation[RFC3547]进行协商而设置的。通常源特定组播SSMSource-Specific Multicast[HC03]组使用由SPI、目标组播地址和源地址组成的3元组SA标识符。任意源组播组的SA仅需要SPI和目标组播地址作为标识符。
如果在同一个SA上发送不同类别的流量通过区分服务代码点DSCPDifferentiated Services Code Point位[NiBlBaBL98][Gro02]进行区分并且接收器正在使用AH和ESP中可用的可选的反重放功能这可能导致由于该功能使用的窗口机制而不适当地丢弃低优先级的数据包。因此发送方应该将不同类别但具有相同选择器值的流量放置在不同的SA上以适当支持服务质量QoSQuality of Service。为了实现这一点IPsec实现必须允许在给定的发送方和接收方之间建立和维护多个具有相同选择器的SA。在这些并行SA之间分配流量以支持QoS是由发送方在本地决定的并且不是通过IKE进行协商。接收方必须无偏见地处理来自不同SA的数据包。这些要求适用于传输模式和隧道模式的SA。在隧道模式SA的情况下有问题的DSCP值出现在内部IP头中。在传输模式下DSCP值可能在传输过程中发生变化但这不应该对IPsec处理产生问题因为该值不用于SA选择并且在SA/数据包验证的过程中不得进行检查。然而如果在一个SA中发生了显著的数据包重排序例如由于在传输过程中对DSCP值的更改这可能会触发接收器通过应用反重放机制来丢弃数据包。
讨论尽管差分服务代码点(DSCP)[NiBlBaBL98Gro02]和显式拥塞通知(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则只对隧道内的数据包进行保护而不包括外部头部。
总结一下
aIPsec的主机实现必须同时支持传输模式和隧道模式。这对于主机的原生、BITS和BITW实现都是适用的。
b安全网关必须支持隧道模式可以支持传输模式。如果支持传输模式那只应该在安全网关充当主机例如用于网络管理或为路径上的两个中间系统之间提供安全性时使用。
4.2. SA功能
SA提供的安全服务取决于所选的安全协议、SA模式、SA的端点以及协议内的可选服务选择。
例如AH和ESP都提供完整性和认证服务但每个协议的覆盖范围不同并且在传输模式和隧道模式下也不同。如果在发送方和接收方之间必须保护IPv4选项或IPv6扩展头的完整性AH可以提供此服务但不能保护可能以发送方无法预测的方式更改的IP或扩展头。
然而在某些情况下通过将ESP应用到承载数据包的隧道中可以实现相同的安全性。
提供的访问控制粒度取决于定义每个SA的选择器的选择。此外IPsec对等方在创建IKEvs. childSA时使用的认证方式也会影响提供的访问控制的粒度。
如果选择了保密性则两个安全网关之间的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流量处理的一般模型以支持这些互操作性和功能性目标。下面描述的模型是名义上的实现不需要与所提供的模型细节匹配但是实现的外部行为必须符合模型的外部观察特征以便符合规范。
这个模型有三个名义上的数据库安全策略数据库SPDSecurity Policy Database、安全关联数据库SADSecurity Association Database和对等授权数据库PADPeer 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、绕过IPsecBYPASS或使用IPsec进行保护PROTECT。第一种选择适用于不允许穿越IPsec边界的流量在指定的方向上。第二种选择适用于允许不经过IPsec保护而穿越IPsec边界的流量。第三种选择适用于提供IPsec保护的流量对于这种流量SPD必须指定要使用的安全协议、模式、安全服务选项和密码算法。
SPD-S, SPD-I, SPD-O
SPD-S, SPD-I, SPD-O 分别是安全策略数据库SPD的三个逻辑部分。
SPD-Ssecure traffic包含了所有需要进行 IPsec 保护的流量的条目。
SPD-Ooutbound包含了所有需要绕过(bypassed)或丢弃(discarded)的出站流量的条目。
SPD-Iinbound应用于需要绕过或丢弃的入站流量。
这三个部分可以进行解耦以便进行缓存。如果一个 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 条目还包含信息如“从数据包填充”PFPpopulate 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的数据包出现时触发创建一个SASA管理协议如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 AssociationSA可以细粒度或粗粒度这取决于用于定义该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]中定义的组策略数据库GSPDGroup 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)。注意默认列表不包括51AH或50ESP。对于选择器查找来说IPsec将AH和ESP视为下一层协议。 还有一些额外的选择器依赖于下一层协议的值 SPD缓存条目中的本地地址 出站SAD条目中的本地地址 入站SAD条目中的远程地址 Name这不是与上面的其他选择器一样。它不是从数据包中获取的。名称可以用作IPsec本地或远程地址的符号标识符。命名的SPD条目有两种使用方式 SPD条目可以同时包含名称或名称列表和本地或远程IP地址的值。对于响应方案例1命名的SPD条目中使用的标识符是以下四种类型之一 a. 完全限定的用户名称字符串电子邮件例如mozartfoo.example.com这相当于IKEv2中的ID_RFC822_ADDR b. 完全限定的DNS名称例如foo.example.com这相当于IKEv2中的ID_FQDN c. X.500可分辨名称例如[WaKiHo97]CN Stephen T. KentO BBN TechnologiesSP MAC 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节“处理分段”。对于IKEIPv6 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节“处理分片”。 一种命名的SPD条目被响应方而不是发起方用于支持访问控制当IP地址对于远程IP地址选择器不合适时例如对于“road warriors”。用于匹配此字段的名称是在IKE协商期间通过ID载荷进行通信的。在此上下文中发起方的源IP地址隧道模式下的内部IP头将绑定到由IKE协商创建的SAD条目中的远程IP地址上。当以此方式选择了SPD条目时此地址将覆盖SPD中的远程IP地址值。所有IPsec实现都必须支持这种名称的使用方式。 发起方可以使用命名的SPD条目来识别将为其创建IPsec SA的用户或绕过其流量的用户。发起方的IP源地址来自隧道模式下的内部IP头将用于在创建以下内容时替换它们 对于多用户本机主机实现支持此用途是可选的对于其他实现则不适用。请注意此名称仅在本地使用它不是通过密钥管理协议进行通信的。此外在发起方上下文中适用于除响应方用于案例1以外的其他名称形式请参见下文。
IPsec实现的上下文决定了选择器的使用方式。例如本地主机实现通常会使用套接字接口。当建立新连接时可以查询SPD并将SA绑定到套接字上。因此通过该套接字发送的流量不需要对SPDSPD-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 0SPD是一个有序的条目列表每个条目包含以下字段。 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的流量选择器TSTraffic 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 绕过DSCPT/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 OPAQUERemote’s
next layer protocol AH
port selector OPAQUEB. 即使下一层协议只有一个选择器例如Mobility Header类型本地和远程的“端口”选择器也用于指示系统是否愿意发送和/或接收具有指定“端口”值的流量。例如如果允许通过SA发送和接收指定类型的Mobility Header则相应的SPD条目将设置如下
Local’s
next layer protocol Mobility Header
port selector Mobility Header message typeRemote’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 typeRemote’s
next layer protocol Mobility Header
port selector OPAQUE如果允许通过SA接收但不发送指定类型的Mobility Headers则相应的SPD条目将设置如下
Local’s
next layer protocol Mobility Header
port selector OPAQUERemote’s
next layer protocol Mobility Header
port selector Mobility Header message typeC. 如果系统愿意发送具有特定“端口”值的流量但不愿意接收该类型端口值的流量则系统的流量选择器在相关的SPD条目中设置如下
Local’s
next layer protocol ICMP
port selector specific ICMP type codeRemote’s
next layer protocol ICMP
port selector OPAQUED. 为指示系统愿意接收具有特定“端口”值的流量但不愿意发送该类型流量系统的流量选择器在相关的SPD条目中设置如下
Local’s
next layer protocol ICMP
port selector OPAQUERemote’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 OPAQUE4.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 IndexSPI: 32位的值由SA的接收端选择用于唯一标识该SA。在SAD条目中对于一个出站SASPI用于构建数据包的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电子邮件地址同样存在相同的选项。一个完整的地址例如fooexample.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缓存”或“缓存”的引用都是指解耦的SPDSPD-ISPD-OSPD-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指定的SPDSPD-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的PMTUIPsec系统必须遵循第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(Dont Fragment)标志。
(5) 如果数据包将立即进入一个不适合外部头部中的DSCP值的域那么该值必须映射到该域的适当值[NiBlBaBL98]。详细信息请参见RFC 2475 [BBCDWW98]。
(6) 如果内部头部的ECN字段设置为ECT(0)或ECT(1)其中ECT表示拥塞可探测传输ECTECN-Capable Transport并且外部头部的ECN字段设置为拥塞经历CECongestion Experienced则将内部头部中的ECN字段设置为CE否则不对内部头部的ECN字段进行更改。当ECN更改时IPv4校验和也会更改。
注意IPsec不会将内部头部中的选项复制到外部头部并且IPsec也不会构建外部头部中的选项。但是post-IPsec代码可能会在外部头部中插入/构建选项。
5.1.2.2. IPv6: 隧道模式下的头部构造 注释1-6请参阅第5.1.2.1节。
7IPsec不会将内部数据包的扩展头复制到外部头也不会在外部头中构建扩展头。但是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中查找SASAD形成了入站数据包的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. 针对非初始分片的单独负载隧道模式SASeparate 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保护以及特定的协议和目的地端口例如端口23Telnet上的TCP流量。假设该实现也允许从同一源/目的地地址对和协议中旁路流量通过但是目标端口不同例如端口119NNTP。攻击者可以发送一个非初始片段带有伪造的源地址如果该片段被旁路处理它可能会重叠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. 路径 MTUPMTU发现
本节讨论未保护 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描述的示例。 TOSIPv4和Traffic ClassIPv6已被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 数据包。
参考资料
