[发明专利]一种实现IPSEC抗重放攻击的方法

说明书

技术领域

本发明涉及网络通讯技术，特别涉及一种在多核架构下实现IPSEC抗重放攻击的方法。

背景技术

IPSec(IP Security)协议是一种工业标准网络安全协议，为IP网络通信提供透明的安全服务，保护传输控制协议(Transmission Control Protocol，TCP)/IP通信免遭窃听和篡改，可以有效抵御网络攻击，同时保持易用性。IPSec在网络层发挥作用，保护和认证IP报文，并与标准算法独立的开放框架，提供数据的机密性、数据完整性和源认证功能。IPSec作为一种实施于网络层的安全协议，具有保证数据来源可靠、保护数据完整、保证数据机密性、防止重放攻击和完美向前保密(PFS)等诸多优点。

但是重放攻击会导致提供IPSec服务的接收方，为验证数据来源的真实性、数据的完整性以及保证内容的机密性，而消耗大量的系统资源，对正常的数据流产生“拒绝服务”(Dos)。

为了抵抗人恶意地发起重放攻击，IPSec报文专门使用了一个序列号(无符号32比特)，以及一个“滑动”的接收窗口。在每个IPSec报文头内，都包含了一个独一无二且单调递增的序列号。由密钥交换(Internet Key Exchange，IKE)服务自动协商或手工创建好一个安全关联(Security Association，SA)后，序列号便会初始化为零，并在进行IPSec输出处理前，令这个值递增。IPSec服务本身并不提供“重传”功能，如果在同一个安全关联SA“存活”期间，收到序列号相同的报文，便认为是攻击包，提供IPSec服务的接收方，就会丢弃这个报文。

现有的实现方案一般的是使用RFC2401维护一个“滑动”窗口。如图1所示，为现有的32位抗重放“滑动”窗口示意图。窗口最左端对应于窗口起始位置的序列号，而最右端对应于将来的第“窗口长度”个报文。接收到的报文必须是新的，且必须落在窗口内部，或靠在窗口右侧。否则，便将其丢弃。而判断一个报文是否是“新”的，是依据其是否在窗口内出现过，如果其在窗口内从从未出现过，则认为是新的。如果收到的一个报文靠在窗口右侧，那么只要其未能通过真实性测试，也会将其丢弃。如通通过了真实性检查，窗口便会向右移动，将那个报文包括进来。

需要说明的是，虽然报文的接收顺序可能被打乱，但仍会得到正确的处理。此外，还需注意的是那些接收迟的报文，即在一个有效的报文之后接收，但其序列号大于窗口的长度，这种报文会被丢弃，所以适当的设置“滑动”窗口的大小很重要。

以下，举一个例子进行说明：

如图1所示，窗口最左端的序列号为S，最右端的序列号为S+31。编号为S、S+2、S+9、S+10和S+13等报文尚未收到。

如果最近收到的报文S+33通过了真实性检查，窗口便会向右滑动2个位置，使窗口左侧变成S+2，右侧变成S+33。这样便会造成报文S无可挽回地丢弃，因为其现在变成靠在滑动接收窗口的左侧。但需要注意的是，报文S+2如果通过了真实性检查，S+2这个包仍会被收到。如果再次收到S+3的报文，根据“滑动”窗口中相应的位图(bitmap)，就可以“鉴别”出是攻击包。

但是，上述方法存在如下缺点：

单个“滑动”窗口技术方案，在单处理单元(CPU)架构下，不需要使用同步原语，就能保证保存的序列号最大(用于和收到的序列号比较，设置“滑动”窗口相应的位图)，重放窗口也总是沿着正确的方向的“滑动”，从而很好的防止重放攻击，也不会导致性能的下降。但是，在多核架构、且需要提供高性能IPSec服务的情况下，如何保证在性能不受影响，还能保证能有效检测重放攻击，当前的这种方案就遇到挑战。

考虑以下“场景”：

当接收到的报文因网络延迟等原因顺序被打乱，或者接收到延迟的报文，每个核或者处理单元处理的任务和负载不一致：

多核如果使用同一个“滑动”的接收窗口，来检查是否是重放的报文，为了保证滑动窗口及序列号的一致性，必须使用同步原语，例如其中一个处理单元滑动“窗口”时，现在大部分实现方案都是利用锁机制这种同步原语，防止其他的处理单元也来滑动同一个窗口，避免使“滑动”窗口中相应的bit位的“错位”这样的情况发生。因为根据“错位”的位图来“鉴别”报文是否为重放攻击，可能会导致丢弃正常的报文。