IPSEC场景的应用分析.docVIP

IPSEC场景的应用分析 　　摘要 本文提出一种在多IPSEC隧道场景下查询SA的方法,并且与常见的方法进行效率对比,供技术感兴趣者和相关领域者参考。 　　关键词 IPSEC;加密;IPSEC SA 　　中图分类号TP39 文献标识码A 文章编号 1674-6708(2010)30-0222-02 　　随着IP技术的普及,特别是在移动通信,银行系统等对安全要求比较高的领域,IPSEC加密技术成为运营商或者厂家的首选。IPSEC技术包含IKE协议、加密和认证技术等,这些相关技术基本上都是标准组织在协议或者草案已经定义好的,但是实际在各种应用场景下还是会出现很多可扩展性的技术,以适应各种IPSEC应用场景。 　　1 IPSEC应用的网络结构分类 　　“Internet 协议安全性 (IPSec)”是一种开放标准的框架结构,通过使用加密的安全服务以确保在 Internet 协议 (IP) 网络上进行保密而安全的通讯。IPSEC技术常见的网络部署场景一般有对称型网络和不对称型网络两种。 　　对称型网络一般适用于企业的分部之间或者企业与企业之间,在互联网络上两台安全网关协商IPSEC隧道,用于加密所有流经的机密数据;不对称型网络一般适用于远端接入,例如经常在外的企业人员需要访问企业内部的网络,可以随时在网络上向安全网关发起ISPEC隧道协商,协商加密隧道后,访问企业内部网络。两种网络结构,最大的不同点在于对称型网络中两侧的客户端不需要具有IPSEC功能,而不对称型网络中要求接入侧的客户端具有IPSEC功能。本文主要讲解不对称型网络在IPSEC应用中的各种技术点的分析。 　　2 实际网络部署带来的问题 　　2.1 IPSEC的隧道模式 　　隧道模式,顾名思能义是双层IP地址的应用类型,即外层IP地址用于路由转发,内层IP报文是真正的用户数据报文。如下图所示,当客户端需要发出加密数据时: 　　第一步,首先生成需要加密的数据,其中Inner IP是指客户端的内部逻辑IP,用于与对端客户端交互的IP(注:对端客户端在企业内部,不需要具有IPSEC功能); 　　第二步,使用外部IP地址进行封装,同时加上ESP头对第一步生成的数据进行加密 　　第三步,网络对加密数据报文进行转发,其中转发的依据是外部IP目的地址是安全网关; 　　第四步,安全网关收到数据后,对报文“剔除”外层IP头以及ESP头,对加密数据进行解密后恢复原始数据; 　　第五步,网络原始数据报文进行转发,转发的依据是内层IP目的地址是企业内部的各个客户端。 　　对于安全网关来说,需要接入成千上万的IPSEC客户端,如何来区分各个IPSEC客户端呢,使用各自的加密和认证算法进行加密和解密呢? 　　2.2 为什么要区分IPSEC客户端 　　每一个客户端接入安全网关都需要协商以下参数才能建立IPSEC隧道: 　　1)加密和认证算法,例如3DES,ASE128以及认证算法MD5,SHA1等; 　　2)需要加解密的数据流,也就是IPSEC ACl,源IP目的IP; 　　3)加密密钥和认证密钥,每一个IPSEC的隧道密钥必然不同。 　　以上数据的合集在IPSEC技术框架中的术语叫IPSEC SA(),即IPSEC安全联盟,每一个IPSEC SA代表需要加密的那份数据需要的参数。如果安全网关无法区分客户端,下行数据流就无法正确发到客户端或者加解密失败。 　　2.3 基于ACL查询的IPSEC场景 　　IKE协议交互分为两个阶段,第一阶段为IKE SA的建立,第二阶段为IPSEC SA的建立.IPSEC SA建立在IKE SA的基础上,IPSEC SA主要目的是建立后续业务数据需要加密的密钥以及哪些数据需要加密.如下图所示,TSi(Traffic Selector Initiator)和TSr为Traffic Selector Responser,发起者的流量范围与接收者的流量范围两者相与,便可以获取需要加密的数据acl. 　　例如上述IPSEC客户端之间的IPSEC协商时,TS为必选参数。 　　TSi为192.168.1.0/24-192.168.2.0/27 　　TSr为192.168.1.0/27-192.168.2.0/24 　　那么最终协商的traffic selector为192.168.1.0/27-192.168.2.0/27 　　根据IKE协议交互我们得知,IKE协商时traffic selector是一个非常重要的参数,如果客户端与安全网关不一致时,隧道是无法协商成功的,我们一般称traffic selector为IPSEC ACL。 　　根据以上分析得知,当安全网关收到需要加密的数据时,可以根据内层的数据自动匹配IPSE