[发明专利]一种IKE协商处理方法及装置

说明书

技术领域

本发明涉及网络技术，尤其涉及一种IKE协商处理方法及装置。

背景技术

VPN（Virtual Private Network：虚拟专用网）被定义为通过一个公用网络（通常是因特网）建立一个临时的、安全的连接，是一条穿过混乱的公用网络的安全、稳定的隧道。虚拟专用网是对企业公司分支机构、商业伙伴及供应商同公司的内部网建立可信的安全连接，并保证数据的安全传输。

IPSec（Internet Protocol Security，Internet协议安全性）是一种开放标准的框架结构，通过使用加密的安全服务以确保在IP网络上进行保密而安全的通讯。IPSec协议不是一个单独的协议，它给出了应用于IP层上网络数据安全的一整套体系结构，包括网络认证协议Authentication Header（AH）、封装安全载荷协议Encapsulating Security Payload（ESP）、密钥管理协议Internet Key Exchange（IKE）和用于网络认证及加密的一些算法等。IPSec规定了如何在对等层之间选择安全协议、确定安全算法和密钥交换，向上提供了访问控制、数据源认证、数据加密等网络安全服务。

现有的RFC标准规定采用UDP方式，通过知名端口号500和4500进行IKE（互联网密钥交换协议）协商，协商采用的报文格式是ISAKMP（Internet Security Association and Key Management Protocol，互联网安全关联和密钥管理协议）。其中IKE协议负责密钥管理，定义了通信实体间进行身份认证、协商加密算法以及生成共享的会话密钥的方法。IKE将密钥协商的结果保留在安全联盟（SA）中，供AH（Authentication Header，认证头）和ESP（Encapsulating Security Payload，封装安全载荷）以后通信时使用。

IKE协商过程分为两个阶段，其中第一阶段又有两种模式：主模式和积极模式(也称为野蛮模式)，第一阶段协商的目的建立IKE SA，建立验证过的密钥是其他交换的前提条件。第二阶段为快速模式，为IPSec协商安全服务，建立IPSec SA，为真正的应用数据通信提供保护。实际使用中，大多数情况是采用主模式和快速模式来进行IKE协商的，而这样协商一次的过程，对于发起方和响应方，至少需要9个UDP报文来才能完成，其中第一阶段主模式需要6个UDP报文，第二阶段快速模式需要3个UDP报文。在现有的计算机程序实现方案中，实现IKE协商通常是使用套接口编程，通过创建UDP数据报类型的套接口监听端口500和端口4500，接收和发送IKE协商各阶段的报文，实现IPSec VPN功能。

然而UDP套接口编程，在现有的IKE实现中，一般都是只有单个进程来收发IKE协商报文。作为协商的双方，本端和对端都是单个进程，既要收发报文，还对报文进行具体的操作处理等。如前所述，一个完整的主模式和快速模式协商至少需要9个UDP报文，全部都由单个进程来处理。在双方之间配置的连接数比较少的情况下，单个进程还是可以胜任。

但是如果在大中型的网络中，IKE组网也大多是星型组网，由一个中心网关和多个分支网关来组成星型拓扑结构。每个分支和中心之间又可能会按业务需要，建立多条隧道。为了保证隧道的安全，IKE还有超时机制，每过几个小时重新协商新的隧道等。处于中心网关位置的IPSec，其性能要求必须非常高，IKE协商速度要快，协商后的加解密速度也要快，才能保证整个网络中通信数据的安全可靠。而分支越多，由单个进程在中心来处理IKE协商的弊端性也将越凸显。此外，在IPSec VPN的C/S模式下，即用户通过在PC或者手机等移动设备上的IPSec VPN客户端连接中心网关，当大量用户在某些时间段因为工作原因都几乎同时连接进来的时候，IPSec VPN中心面临IKE协商的高峰，如果协商速度不够快，将直接影响用户工作使用和体验。

发明内容

有鉴于此，本发明提供一种IKE协商处理装置，应用于网络设备上，包括监听收发单元以及多个IKE处理单元；其中：

监听收发单元，用于侦听预定的UDP接收端口以获取IKE对端发送的IKE协商报文，并用于将IKE处理单元需要发送的IKE协商报文发送给IKE对端；

IKE处理单元，用于对接收到的IKE报文进行IKE协商处理，并在需要发送IKE协商报文时，将待发送的IKE协商报文提交给监听收发单元;