CN103888450B - 一种Windows平台IPSec处理方法 - Google Patents

Abstract

本发明涉及一种Windows平台IPSec处理方法。方法包括：IP数据包的获取；判断所获取的IP数据包是否需要进行IPSec处理；对需要进行IPSec处理的IP数据包进行ESP隧道模式处理，其中的加解密处理使用AES‑NI技术对IP数据包进行加解密处理。本发明主要在Windows平台基于AES‑NI技术实现高速IPSec处理方法，满足千兆网络环境主机‑网关模式下的IPSec VPN需求。本发明使用大数据包拆分、ESP分片数据包重组与修改TCP协议MSS的方式解决了基于NDIS IM框架实现的IPSec处理方法中常见的MTU与大数据包分片问题，并且本发明针对NT6.x版本操作系统实现的IPSec处理方法解决了现有方案在新版本操作系统上不兼容的问题。

Description

一种Windows平台IPSec处理方法

技术领域

本发明属于网络安全技术领域，更进一步涉及Windows平台IPSec(IPSecurityVirtual Private Network)高速处理的方法。

背景技术

李芝棠等人在文献“李芝棠，孙诚，‘多卡并行加密VPN的性能分析’[J]，华中科技大学学报，33(5)，1671-4512（2005）”提出了基于多卡并行加密的VPN性能提升方法。该方法主要是将VPN处理的流程分为两部分，一部分为IP数据包封装预处理；另一部分为数据包加解密。

由于目前VPN性能的瓶颈依然由加解密的耗时因素而引起，因此上述文献提出的方法是将IP数据包预处理部分交由CPU进行，而将加解密操作交由多个硬件加密卡进行。CPU在数据包预处理完成之后将预处理后的数据包交由缓存队列，其自身直接进行对下一个数据包的操作而不等待加解密操作的完成，多个加密卡依次从缓存队列中取出待加解密的数据包进行单纯加解密操作。

上述方案确实能够对VPN通道的性能进行相应提升，并且同时降低了CPU的利用率，但该方案的实施需要多个硬件加密卡，且需要对Linux源码进行相应修改，因此适合在VPN网关上进行方案的实施，不适合移植到安装Windows操作系统的普通PC机使用。

现有Windows平台IPSec处理方法大部分基于NDIS IM（Network DriverInterface Specification Intermediate，网络驱动接口规范中间层）框架实现，通过注册一个NDIS IM网络过滤驱动获取操作系统发送与接收的所有IP数据包，对每一个IP数据包提取其头部相应信息查询SPDB（Security Policy Database，安全策略数据库）判断其是否需要进行IPSec处理，对于需要进行IPSec处理的数据包，将其按照IPSec SA（SecurityAssociation，安全关联）中指定的加密算法及密钥、数据完整性验证算法及密钥等信息对IP数据包进行相应的IPSec处理。

虽然基于NDIS IM框架的IPSec处理方案能够运行于NT6.x版本的Windows操作系统当中，其可能会导致相应的兼容性与稳定性问题，且在NDISIM框架中实现IPSec不可避免的会遇见MTU（Maximum Transmission Unit，最大传输单元）与大数据包分片问题。

发明内容

针对现有技术的缺陷或不足，本发明的目的在于提供一种Windows平台IPSec处理方法。

为此，本发明提供的Windows平台IPSec处理方法包括：

（1）IP数据包的获取，包括获取发送IP数据包和接收IP数据包；

（2）判断所获取的IP数据包是否需要进行IPSec处理；

（3）对需要进行IPSec处理的IP数据包进行ESP隧道模式处理，对于发送的数据包，ESP隧道模式处理包括加密，消息验证码计算和数据包封装；对于接收的数据包，ESP隧道模式处理包括消息验证码校验、数据包解封装与解密。所述加密处理和解密处理均使用AES-NI（AES New Instruction，AES新指令集）实现的AES算法对IP数据包进行处理。

优选的，所述IP数据包的获取是采用基于NDIS IM框架的方法获取发送IP数据包和接收IP数据包。

优选的，在对需要进行IPSec处理的IP数据包进行ESP隧道模式处理之前，对需要进行IPSec处理的IP数据包进行预处理，预处理包括IP头部校验和计算、对于TCP数据包进行MSS值的修改以及TCP头部校验和计算，将TCP数据包头部中的MSS值修改为：[原MSS值-76]；对于非分片的UDP数据包进行UDP头部校验和计算。

优选的，判断所获取的IP数据包是否需要进行IPSec处理时，对于发送的数据包，提取其IP数据包头部特征信息、查询安全策略数据库（SPDB），如果查询结果不为空，则该IP数据包需进行IPSec处理；

对于接收的IP数据包：

①首先判断其是否是ESP类型的数据包，若为ESP类型数据包，转②，否则不对该IP数据包进行处理；

②对于ESP类型数据包，根据其IP头部判断该数据包是否是由已经建立的VPN通道的对端发来的IP数据包，若满足条件则转③，否则不对该IP数据包进行处理；

③对于从已建立VPN通道对端发来的IP数据包，根据其IP头部分片信息判断其是否为一个ESP分片数据包，若为ESP分片数据包则转④，否则直接提取该IP数据包的IP头部与ESP头部信息查询安全策略数据库，若查询结果不为空，则该IP数据包需要进行IPSec处理；

④对于ESP分片数据包，将ESP分片数据包放入IP数据包重组模块，待所有ESP分片数据包放入IP数据包重组模块中后，将IP数据包重组模块中所有的ESP分片数据包恢复为一个完整的大数据包，再提取恢复后大数据包的IP头部与ESP头部相关信息查询安全策略数据库（SPDB），判断其是否需要进行IPSec处理，若查询结果不为空，则该IP数据包需要进行IPSec处理；

对于发送的非TCP协议IP数据包，若经过ESP隧道模式处理后生成的ESP数据包长度超过了（MTU_以太网–18字节），则对生成的ESP数据包进行拆分操作，其中MTU_以太网为以太网的MTU值。

优选的，所述IP数据包的获取采用基于NDIS FILTER框架或WFP框架实现的方法获取发送IP数据包和接收IP数据包。

优选的，所述IP数据包的获取采用基于WFP框架的方法获取发送IP数据包和接收IP数据包，且在WFP框架下，在FWPS_LAYER_OUTBOUND_TRANSPORT_V4层或FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取待发送的数据包，FWPS_LAYER_INBOUND_IPPACKET_V4层获取接收的数据包；

优选的，所述IP数据包的获取采用基于WFP框架的方法获取发送IP数据包和接收IP数据包，在WFP框架下，在FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取发送IP数据包，在FWPS_LAYER_INBOUND_IPPACKET_V4层获取接收IP数据包。

优选的，所述加解密处理采用Intel IPP函数库对数据对IP数据包进行加解密处理。

与现有技术相比，本发明的优点在于：

（1）本发明主要在Windows平台基于AES-NI技术实现高速IPSec处理方法，满足千兆网络环境主机-网关模式下的IPSec需求，填补了Windows平台高速IPSec处理方法的空白。

（2）使用AES-NI技术只需要一个支持AES-NI的CPU即可，不需要额外的硬件加密卡等设备，因此便于使用，尤其适合不能安装相应加密卡的笔记本型计算机使用；

（3）本发明使用大数据包拆分、ESP分片数据包重组与修改TCP协议MSS的方式解决了基于NDIS IM框架实现的IPSec处理方法中常见的MTU与大数据包分片问题。

（4）本发明针对NT6.x版本操作系统实现的IPSec处理方法解决了现有方案在新版本操作系统上不兼容的问题。

附图说明

图1为ESP封装格式示意图；

图2为openswan对大数据包的IPSec处理示意图；

图3为实施例1大数据包ping操作连通性示意图；

图4为实施例1使用AES-NI技术时对接收TCP数据包的IPSec处理性能，其中纵坐标为TCP的接收速率，横坐标为时间；

图5为实施例2未使用AES-NI技术时对接收TCP数据包的IPSec处理性能；

图6为实施例3大数据包ping操作连通性示意图；

图7为实施例3使用AES-NI技术时对接收TCP数据包的IPSec处理性能。

具体实施方式

本发明针对当前Windows平台IPSec处理方法在千兆网络环境下效率低下与不兼容新版本Windows操作系统的缺点，提出了基于AES-NI技术的IPSec高速处理方法，同时解决了IPSec实现方案中常见的MTU与大数据包分片等问题。也就是说，为解决现有Windows平台IPSec处理方法性能不高、MTU与大数据包分片、操作系统兼容性等问题。本发明使用Windows内核网络过滤驱动程序截获操作系统所有发送与接收的IP数据包，并根据获取到IP数据包头部判断其是否需要进行IPSec处理，针对需要进行IPSec处理的IP数据包使用AES-NI技术提升对其进行加解密的速度，提升了客户端IPSec的处理性能，同时解决了MTU（Maximum Transmission Unit，最大传输单元）与大数据包分片等问题。

对IP数据包的ESP隧道模式处理主要包括数据包加解密、消息验证码计算与数据包封装。其中加解密操作是三者中最耗费CPU时间的一项操作，因此提升加解密操作的效率则可以提升IPSec的整体性能。本发明针对现阶段IPSec VPN通道中最常用的AES加密算法，使用AES-NI技术对其进行大幅度加速，从而大幅提升整体IPSec的处理性能。关于本发明的基于AES-NI的高速IPSec处理解释如下：

ESP隧道模式处理主要是对发送IP数据包进行加密、消息验证码计算与封装三部分，对接收的ESP数据包进行消息验证码校验、解封装与解密三部分。其中，就计算的复杂度而言，加解密计算最耗费CPU时间，因此若能大幅度的提升加解密的效率则能够提升客户端对IP数据包的IPSec处理性能。本发明针对现阶段IPSec VPN通道中最常用的AES加密算法，使用AES-NI技术对其进行加速。

（1）对发送数据包的IPSec处理

从安全策略数据库中查询到的IPSec SA中获取之前IKE协议协商生成的SPI、加密算法（AES）、加密密钥、数据完整性验证算法与数据完整性验证算法密钥。根据获取到的相应信息，按照如图1所示的ESP数据包格式对原始IP数据包进行处理。

对发送的IP数据包进行IPSec处理的具体处理流程如下：

①按照图1所示的ESP数据包格式首先构造相应的ESP数据包；

②使用AES-NI技术对ESP数据包中的待加密部分（载荷数据、填充域、填充长度域与下一个头域）进行高速加密处理；

③对经过步骤①与步骤②的数据包进行数据完整性验证计算，计算范围覆盖ESP包中出去ICV的所有部分，最终将计算结果写入ESP数据包ICV域中。

④将ESP数据包构造成一个新的IP数据包。

经过以上①②③④步处理之后，已经将原始的IP数据包封装为ESP数据包，此时可将构造的新IP数据包交由Windows网络协议栈进行后续处理。

（2）对接收数据包的IPSec处理

从安全策略数据库中查询到的IPSec SA中获取之前IKE协议协商生成的SPI、解密算法（AES）、解密密钥、数据完整性验证算法与数据完整性验证算法密钥。根据获取到的相应信息，按照如下流程进行处理：

①首先对接收到的ESP数据包进行数据完整性验证计算，并将计算结果与ESP数据包尾部的ICV值进行比对，当两者一致时表示数据包在传输过程中未被篡改，可以进行进一步处理。如果比对结果不一致，则表明数据包在传输过程中已被篡改，需要将数据包直接丢弃；

②使用AES-NI技术对ESP数据包中的加密部分进行解密；

③根据IPSec处理的结果恢复出原始IP数据包。

经过以上①②③步处理之后，已经从ESP数据包中恢复出响应的原始IP数据包，此时需要对恢复出的原始IP数据包内容进行相应校验（包括长度、协议类型等），校验合格后再交由Windows网络协议栈进行后续处理。

由于对发送的IP数据包进行IPSec处理需要增加IP数据包的长度，因此经过IPSec处理后的数据包有可能会超过网卡的MTU值从而造成发送失败。本发明通过对大数据包拆分与ESP分片数据包重组，以及修改TCP协议MSS两种方案解决了NDIS IM框架实现IPSec方案中常见的MTU与大数据包分片问题。本发明关于MTU问题与大数据包分片问题的解决具体解释如下：

以太网卡在发送以太网帧时对帧长度有一个最大的限制，即网卡的MTU（MTU_网卡）值，该值是由以太网的电气属性所决定，对于现阶段广泛使用的以太网其值为1518字节，其中包括14字节的以太网帧头、1500字节的网络数据包与4字节的尾部CRC校验值，对于超过该值的以太网帧将会造成发送失败的情况。

Windows操作系统网络协议栈内部同样维护了一个MTU值（MTU_协议栈），该值主要是网络层驱动程序对大IP数据包进行拆分时使用，该MTU值是根据MTU_网卡计算而来，目的是确保经过网络层与数据链路层处理后的以太网帧长不超过MTU_网卡。

在正常以太网环境中，Windows操作系统的MTU_协议栈为1500，当待发送的IP数据包长度（不包括以太网帧头）超过1500字节时，网络协议栈将对相应的网络数据包进行分片处理，确保每一个分片后的IP数据包长度不超过1500字节。

本发明需要对IP数据包进行IPSec处理，结合具体应用需求，需要对IP数据包进行ESP处理。而对IP数据包的ESP封装会明显的增大原始IP数据包的长度，其在原始IP数据包的基础上增加了新的IP头部、ESP头部、加密填充区域与ICV等区域。若原始IP数据包长度为1500字节，或很接近1500字节时，经过发明人IPSec处理模块进行ESP处理后新生成的ESP数据包其长度必然超过1500字节，导致后续生成的以太网帧长超过MTU_网卡，造成数据包发送失败。

本发明为Windows平台IPSec处理方法，经本发明处理后的ESP数据包主要与安装了openswan软件或strongswan软件的IPSec网关进行交互。Openswan实现的IPSec协议栈位于网络层之上（在IP数据包分片之前），因此当安全子网内的主机向客户端方向发送一个大型数据包时（超过以太网MTU），openswan会首先将该IP数据包重组、恢复出原始的IP数据，其次再对重组后的IP数据包进行ESP隧道模式封装，最终对封装的结果根据主机MTU情况进行分片。其处理的示意图如图2示。

对于NDIS IM框架，本发明实现的网络过滤驱动程序获取到的接收数据包仅仅经过了数据链路层的处理，并未交由网络层进行重组等操作，因此若openswan将长度超过MTU值的ESP进行分片发送，则发明的IPSec高速处理模块每次仅能处理一个分片ESP数据包。但是由于openswan端是先ESP处理、再分片，因此其ESP载荷的加密与ICV值的计算均是针对整个ESP数据包，发明人仅通过单个分片的ESP数据包是无法对其进行正确的解密与数据完整性验证工作，造成了ESP数据包解封装失败、丢包的问题。

在NDIS IM框架中，本发明采取了以下两种方案解决了相应的MTU与大数据包分片问题。

（1）大数据包拆分与ESP分片数据包重组

当一个IP数据包经过本发明进行ESP隧道模式封装后生成的ESP数据包长度超过了[以太网的MTU值MTU_以太网–18（14字节以太网头，4字节以太网帧尾CRC校验）]字节，则本发明首先对该ESP数据包进行分片处理，将其分为两个ESP分片数据包，确保每一个ESP分片数据包长度均未超过MTU_以太网–18字节，确保数据包发送成功,现阶段MTU_以太网常见为1518字节。

对于IPSec网关发来的ESP分片数据包，由于无法对单个ESP分片数据包进行解密与数据完整性验证等操作，因此需要对接收到的ESP分片数据包进行缓存、重组，当所有的ESP分片重组成一个完整的ESP数据包后再对该完整的ESP数据包进行后续IPSec处理。

（2）修改TCP协议的MSS

MSS（Maximum Segmentation Size，最大分片单元）是TCP协议中的一个概念，其目的是确保TCP数据包在传输过程中尽量不被分片，是由TCP连接双方在建立TCP连接或在连接的过程中动态协商的数值。在TCP三次握手建立连接时，连接双方各自在发送的SYN数据包TCP头部后的可选区域内加入了MSS值，该MSS值代表本机所能够接收到的最大TCP数据包大小。当TCP连接正常建立后，该连接的MSS值为连接双方协商的MSS值中的较小值，此后双方收发的TCP数据包长度均不能够超过该值，从而确保TCP数据包在传输的过程中不被分片。

本发明借助TCP协议的该特性，通过修改TCP协议的MSS值确保VPN通道的TCP数据包在本机发送时经过IPSec处理后长度不会超过MTU网卡，在接收时不会接收到分片的数据包。本发明主要对数据包进行ESP封装处理，当使用AES128_CBC加密算法与HMAC_MD5消息认证算法时，经过ESP数据包处理后原始IP数据包的长度增长量为：新IP头部（20字节）、ESP头部（4字节SPI、8字节序列号、16字节IV）、加密填充（不超过16字节）、尾部ICV（12字节），其总和必然不会超过76字节。因此，当本发明对TCP数据包进行IPSec处理时，会判断其TCP可选头部中是否包含MSS字段，若包含该字段则直接将其值修改为原始值减去76。通过该种方式处理，对于本机发出去的TCP数据包，由于其头部MSS值被修改，因此接收端后续发往本机的TCP数据包定小于改值，经过IPSec网关处理后的ESP数据包也不会超过MTU_网卡，这样本机就不用对接收到的ESP数据包进行重组；对于接收的TCP数据包，Windows TCP协议接收到的MSS值已经被修改，因此其会认为该MSS值是另一端的期望值，后续发往另一端的TCP数据包长度均不会超过该MSS值，从而确保发明人对后续的TCP数据包进行ESP处理后其长度定不会超过MTU_网卡，不用进行数据包拆分等操作。

本发明的方法具体解释如下：

（1）IP数据包的获取，可采用传统的方法获取发送IP数据包和接收IP数据包，其中传统的方法包括NDIS IM、TDI与Firewall-Hook等，优选NDIS IM方法，该方法能够直接获取到完整的数据包，位于传输层之下，可以对IP数据包进行各种处理，做到对传输层与上层应用的透明。

（2）判断所获取的IP数据包是否需要进行IPSec处理，采用传统的方法判断所获取的IP数据包是否需要进行IPSec处理；包括对发送IP数据包的判断和对接收IP数据包的判断；包括提取IP数据包头部特征信息、查询安全策略数据库（SPDB），如果查询结果不为空，则该IP数据包需进行IPSec处理；具体为：

对于发送的数据包，提取其IP数据包头部特征信息、查询安全策略数据库，如果查询结果不为空，则该IP数据包需进行IPSec处理；

对于接收的IP数据包：

①首先判断其是否是ESP类型的数据包，若为ESP类型数据包，转②，否则不对该IP数据包进行处理。

②对于ESP类型数据包，根据其IP头部判断该数据包是否是由已经建立的VPN通道的对端发来的IP数据包，若满足条件则转③，否则不对该IP数据包进行处理。

③对于从已建立VPN通道对端发来的IP数据包，根据其IP头部分片信息判断其是否为一个ESP分片数据包，若为ESP分片数据包则转④，否则直接提取该IP数据包的IP头部与ESP头部相关信息查询安全策略数据库（SPDB），若查询结果不为空，则该IP数据包需要进行IPSec处理。

④对于ESP分片数据包，将该数据包放入IP数据包重组模块，待凑齐后续其余分片数据包后，将所有的分片数据包恢复为一个完整的大数据包，再提取恢复后大数据包的IP头部与ESP头部相关信息查询安全策略数据库（SPDB），判断其是否需要进行IPSec处理，若查询结果不为空，则该IP数据包需要进行IPSec处理。

（3）对需要进行IPSec处理的IP数据包进行预处理：包括IP头部校验和计算、对于TCP数据包进行MSS值的修改以及TCP头部校验和计算，将TCP协议的数据包头部中的MSS（Maximum Segment Size）值修改为（原MSS值-76）；对于非分片的UDP数据包进行UDP的头部校验和计算；对数据包头部校验和的计算是为了解决当主机网卡TCP/IP ChecksumOffload属性开启后对IP数据包进行ESP隧道模式处理时内部封装的数据包头部校验和错误的问题，确保经过本发明处理后的ESP数据包在接收端能够正常恢复出原始、正确的IP数据包，不会因为恢复出的IP数据包头部校验和错误从而导致IP数据包被丢弃。

对TCP数据包进行MSS值修改是为了确保相应TCP连接后续传递的TCP数据包在经过ESP隧道模式处理之后其长度不会超过以太网的MTU，从而解决了TCP协议数据包经过IPSec处理后MTU与大数据包分片问题。

（4）对需要进行IPSec处理的IP数据进行ESP隧道模式处理：根据查询得到的安全关联（IPSec SA）对相应的需要进行IPSec处理的IP数据包进行ESP隧道模式处理（加解密处理、消息验证码计算和封装处理），加解密处理使用AES-NI技术或Intel IPP函数库对数据进行加解密处理。

AES-NI技术是CPU的一种特殊指令集，其主要在硬件层面对AES算法的实现进行优化，从而能够大幅度提升AES算法的运算速度。

Intel IPP是一套跨平台的软件函数库，提供了广泛的多媒体功能和加密机制，库中提供的大部分函数均由Intel官方在实现过程中进行相应的优化，其性能比通常情况下使用的函数性能优异。

本发明在对数据进行加解密时，对于AES算法优选AES-NI技术，其对AES算法的性能提升作用最为明显，使得本发明在千兆网络环境下的处理性能达到500Mbps左右；对于其余算法，优选Intel IPP技术。

对于发送的非TCP协议IP数据包（包括UDP协议、ICMP协议等），若经过IPSec处理之后的IP数据包构造的以太网帧长度超过了以太网最大帧长（MTU），则需要对该IP数据包进行拆分操作，确保其每一个分片的长度均不超过MTU，防止数据包发送失败。

对于NT6.X（包括Windows Vista、Windows7、Windows8）系统，本发明优选以下方法：

（1）IP数据包的获取；可选用基于NDIS IM框架、NDIS FILTER框架或WFP框架实现的方法获取发送IP数据包和接收IP数据包。NDIS IM框架是微软在NT5.x版本操作系统上推荐的网络过滤开发框架，但是其在NT6.x版本操作系统上运行会存在相应兼容性的问题，因此微软已经不推荐在NT6.x版本操作系统之上继续使用NDIS IM框架。

本发明优选基于WFP框架的方法获取发送IP数据包和接收IP数据包，在WFP框架下，可以选择FWPS_LAYER_OUTBOUND_TRANSPORT_V4层或FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取待发送的数据包，FWPS_LAYER_INBOUND_IPPACKET_V4层获取接收的数据包；优选在FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取发送IP数据包，在FWPS_LAYER_INBOUND_IPPACKET_V4层获取接收IP数据包；

在FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取到的数据包为完整的IP数据包，其已经具有了IP头部信息，方便发明人提取头部进行进行判断；在FWPS_LAYER_OUTBOUND_TRANSPORT_V4层获取的发送数据包仅有传输层协议头部，并不具有IP头部，在对数据包进行判断与处理时，需要自行构造IP头部，相对于FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取的IP数据包其处理更加复杂。

在FWPS_LAYER_INBOUND_IPPACKET_V4层获取到的数据包已经经过了系统网络层的处理，去除了IP头部，但是发明人可以很方便的恢复出其IP头部，提取信息进行判断。

（2）判断所获取的IP数据包是否需要进行IPSec处理；

（3）对需要进行IPSec处理的IP数据包进行ESP隧道模式处理，

现有的Windows平台IPSec处理方法通常情况下均基于NDIS IM框架，而微软已经明确声明在NT6.x版本的操作系统上不建议继续使用NDIS IM框架。本发明针对NT6.x版本的Windows操作系统，基于WFP框架实现了一个IPSec处理方法。

在Windows NT6.x（包括Windows Vista、Windows Server2008、Windows7、Windows8等）家族的操作系统之上，本发明优选WFP类型的网络过滤驱动程序过滤所有的网络数据包。在WFP框架中，Windows提供了多种过滤层次供开发人员进行选择，在不同的过滤层次可以获取到不同类型的网络数据包。

本发明需要对IP数据包进行过滤与处理，且由于IPSec处理的特殊性，需要解决前述的MTU与大数据包分片等问题，因此本发明基于WFP框架实现的IPSec处理方法优选FWPM_LAYER_OUTBOUND_IPPACKET_V4作为发送数据包的过滤层次，选择FWPM_LAYER_INBOUND_IPPACKET_V4作为接收数据包的过滤层次。

在FWPM_LAYER_OUTBOUND_IPPACKET_V4过滤层次，发明人获取到的发送数据包已经经过了网络层的初步处理，加上了IP头部，但是并未进行分片处理，因此在此层次即使对IP数据包进行ESP处理之后其长度超过了MTU_网卡，Windows操作系统也会按照自身维护的MTU_协议栈对IP数据包进行拆分，确保通过网卡发送出去的数据包长度均不超过MTU_网卡。

对于接收的数据包，在WFP框架中一个分片的IP数据包可以三次被在本发明选用的FWPM_LAYER_INBOUND_IPPACKET_V4接收数据包过滤层次所获取，第一次为IP Packet、第二次为IP Fragment而第三次为重组数据包的一部分，发明人可以在注册Filter时通过设置相应的FWP_CONDITION_FLAG_IS_FRAGMENT否定标志确保发明人仅收到第一次的IPPacket与第三次重组完成后的数据包，再在相应的接收数据包处理函数中通过检测IP头部的分片标志位确保发明人仅处理重组后的IP数据包，从而免去了发明人自己实现ESP分片数据包重组的操作，解决了ESP大数据包分片的问题。

以下是发明人提供的具体实施例，以对本发明的技术方案作进一步解释说明。

实施例1：

遵循本发明的技术方案，该实施例中的具体方案是：在Windows XP系统上基于NDIS IM框架实现IPSec处理方法，其中使用基于AES-NI实现的AES算法对相应的数据进行加解密处理。对该实施例的方案进行如下实验：

实验1，对本发明中使用AES-NI技术提升IPSec处理性能的实验。

实验1的实验条件是在一个主机-网关模式下的千兆网络环境中进行，其中客户端主机CPU为支持AES-NI技术的Intel(R)Core(TM)i7-2600，网络适配器为Intel(R)82579LMGigabit Network Connection，安装的操作系统为Windows XP SP3，测速软件为IxCharoit。实验时客户端主机上首先安装基于本发明实现的NDIS IM网络过滤驱动程序，其次通过IKE协商模块与目标IPSec网关协商建立IPSec VPN通道，其中使用AES128_CBC作为VPN通道数据加密算法、使用HMAC_MD5算法作为消息验证算法，并将协商生成的IPSec SA与IPSec SP信息写入内核安全策略数据库中。

在IPSec VPN通道建立之后，在客户端主机使用ping命令测试与安全子网内主机的大数据包连通性，图3所示为大数据包ping测试的结果，由图3显示结果可知，本发明基于NDIS IM框架的实施例解决了MTU与大数据包分片问题。

除上述测试之外，使用IxCharoit软件对此实施例的IPSec处理性能进行测试。在对VPN通道中的IP数据包进行ESP隧道模式处理时，使用基于AES-NI技术实现的AES算法对相应数据进行加解密处理；对TCP数据包进行处理时，使用本发明中说明的修改MSS的方法对TCP数据包中的MSS值进行修改。

图4所示为IxCharoit软件对客户端主机IPSec VPN通道TCP接收速率测试结果，由图4可知在此实施例下对TCP接收数据包的IPSec处理速度为610Mbps左右。

实施例2：

遵循本发明的技术方案，该实施例中的具体方案是：在Windows XP系统上基于NDIS IM框架实现IPSec处理方法，其中使用普通汇编语言实现的AES算法对相应的数据进行加解密处理。对该实施例的方案进行如下实验：

实验2，对使用普通AES算法实现的IPSec处理方法进行性能测试。

实验2的实验环境与实验1相同，实验时客户端主机上首先安装基于本发明实现的NDIS IM网络过滤驱动程序，其次通过IKE协商模块与目标IPSec网关协商建立IPSec VPN通道，其中使用AES128_CBC作为VPN通道数据加密算法、使用HMAC_MD5算法作为消息验证算法，并将协商生成的IPSec SA与IPSec SP信息写入内核安全策略数据库中。

在IPSec VPN通道建立之后，使用IxCharoit软件对此实施例的IPSec处理性能进行测试。在对VPN通道中的IP数据包进行ESP隧道模式处理时，使用普通汇编语言实现的AES算法对相应数据进行加解密处理；对TCP数据包进行处理时，使用本发明中说明的修改MSS的方法对TCP数据包中的MSS值进行修改。

图5所示为IxCharoit软件对客户端主机IPSec VPN通道TCP接收速率测试结果，由图5可知在此实施例下对TCP接收数据包的IPSec处理速度为440Mbps左右。

实施例3：

遵循本发明的技术方案，该实施例中的具体方案是：在Windows7系统上基于WFP框架实现IPSec处理方法，其中使用基于AES-NI实现的AES算法对相应的数据进行加解密处理。对该实施例的方案进行如下实验：

实验3，对本发明中基于WFP框架实现的IPSec处理方法进行实验。

实验3中使用的客户端主机安装的操作系统为Windows7，其余实验条件与实验1相同。实验时客户端主机上首先安装基于本发明实现的WFP网络过滤驱动程序，其次通过IKE协商模块与目标IPSec网关协商建立IPSec VPN通道，其中使用AES128_CBC作为VPN通道数据加密算法、使用HMAC_MD5算法作为消息验证算法，并将协商生成的IPSec SA与IPSec SP信息写入内核安全策略数据库中。

在IPSec VPN通道建立之后，在客户端主机使用ping命令测试与安全子网内主机的大数据包连通性，并且使用IxCharoit软件对此实施例的IPSec处理性能进行测试。

图6所示为大数据包ping测试的结果，由图6显示结果可知，本发明基于WFP框架的实施例解决了MTU与大数据包分片问题。

图7所示为IxCharoit软件对客户端主机IPSec VPN通道TCP接收速率测试结果，由图7可知在此实施例下对TCP接收数据包的IPSec处理速度为470Mbps左右。

Claims (6)

1.一种Windows平台IPSec处理方法，其特征在于，该方法包括：

(1)IP数据包的获取，包括获取发送IP数据包和接收IP数据包，所述IP数据包的获取是采用基于NDIS IM框架的方法获取发送IP数据包和接收IP数据包；

(2)判断所获取的IP数据包是否需要进行IPSec处理，判断所获取的IP数据包是否需要进行IPSec处理时，对于发送的数据包，提取其IP数据包头部特征信息查询安全策略数据库，如果查询结果不为空，则该IP数据包需进行IPSec处理；

对于接收的IP数据包：

①首先判断其是否是ESP类型的数据包，若为ESP类型数据包，转②，否则不对该IP数据包进行处理；

②对于ESP类型数据包，根据其IP头部判断该数据包是否是由已经建立的VPN通道的对端发来的IP数据包，若满足条件则转③，否则不对该IP数据包进行处理；

③对于从已建立VPN通道对端发来的IP数据包，根据其IP头部分片信息判断其是否为一个ESP分片数据包，若为ESP分片数据包则转④，否则直接提取该IP数据包的IP头部与ESP头部信息查询安全策略数据库，若查询结果不为空，则该IP数据包需要进行IPSec处理；

④对于ESP分片数据包，将ESP分片数据包放入IP数据包重组模块，待所有ESP分片数据包放入IP数据包重组模块中后，将IP数据包重组模块中所有的ESP分片数据包恢复为一个完整的大数据包，再提取恢复后大数据包的IP头部与ESP头部相关信息查询安全策略数据库，判断其是否需要进行IPSec处理，若查询结果不为空，则该IP数据包需要进行IPSec处理；

对于发送的非TCP协议IP数据包，若经过ESP隧道模式处理后生成的ESP数据包长度超过(MTU_以太网–18字节)，则对生成的ESP数据包进行拆分操作，其中MTU_以太网为以太网的MTU值；

(3)对需要进行IPSec处理的IP数据包进行ESP隧道模式处理，对于发送IP数据包，ESP隧道模式处理包括加密处理，消息验证码计算和数据包封装；对于接收IP数据包，ESP隧道模式处理包括消息验证码校验、数据包解封装与解密处理；所述加密处理和解密处理均使用AES-NI实现的AES算法对IP数据包进行处理。

2.如权利要求1所述的Windows平台IPSec处理方法，其特征在于，在对需要进行IPSec处理的IP数据包进行ESP隧道模式处理之前，对需要进行IPSec处理的IP数据包进行预处理，预处理包括IP头部校验和计算、对于TCP数据包进行MSS值的修改以及TCP头部校验和计算，将TCP数据包头部中的MSS值修改为：(原MSS值-76)；对于非分片的UDP数据包进行UDP头部校验和计算。

3.如权利要求1所述的Windows平台IPSec处理方法，其特征在于，所述IP数据包的获取采用基于NDIS FILTER框架或WFP框架实现的方法获取发送IP数据包和接收IP数据包。

4.如权利要求1所述的Windows平台IPSec处理方法，其特征在于，所述IP数据包的获取采用基于WFP框架的方法获取发送IP数据包和接收IP数据包，且在WFP框架下，在FWPS_LAYER_OUTBOUND_TRANSPORT_V4层或FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取待发送的数据包，FWPS_LAYER_INBOUND_IPPACKET_V4层获取接收的数据包。

5.如权利要求1所述的Windows平台IPSec处理方法，其特征在于，所述IP数据包的获取采用基于WFP框架的方法获取发送IP数据包和接收IP数据包，且在WFP框架下，在FWPS_LAYER_OUTBOUND_IPPACKET_V4层获取发送IP数据包，在FWPS_LAYER_INBOUND_IPPACKET_V4层获取接收IP数据包。

6.如权利要求1所述的Windows平台IPSec处理方法，其特征在于，所述加解密处理采用Intel IPP函数库对数据对IP数据包进行加解密处理。