这是我×××书中的GET×××的第一部分,现在还处于草稿阶段,可能还会有些问题,希望大家多多提出意见,我会陆续发布我书中的重要部分,希望大家对我新书的关注与支持。谢谢!

第八章:组加密传输×××(GET×××)
Group Encrypted Transport ×××(GET×××)是Cisco在12.4T以后提出的一个全新IPSec ×××技术。这个技术和本书前面介绍的所有IPSec ×××技术不同,它主要运用在全局可路由的网络,也就是一个公司内部网络或者即将会大量部署的IPv6网络。任何一个技术都有它出现的理由,现在我们就来讨论一下在一个大型公司内部部署IPSec ×××技术会遇到什么问题,然后我们再让GET×××来解决这些问题。下面就是这个大型公司的网络示意图。
图8-1 大型公司网络示意图
 



 
图8-1是一个大型公司的内部网络示意图,这个公司有很多部门,并且使用MPLS ×××技术进行联网。MPLS ×××是一个运营商的×××技术,能够通过运营商的网络把客户(公司)虚拟的连接在一起,就像一个内部网络一样。这个技术的主要问题就是不提供数据安全。设计GET×××的一个主要目标就是协助MPLS ×××实现数据安全。现在我们就开始讨论在这个网络内部使用传统的IPSec ×××技术会遇到哪些问题,我们的GET×××又有哪些特性能够克服这些问题。
问题一 : 影响 Qos
图8-2 企业网内部QoS部署
 



 
图8-2 体现了我们在企业网内部部署QoS的一般方法,首先我们在流量进入网络的路由器上,为不同流量打上DSCP标记。然后在中间承载网络根据DSCP标记运用相应的QoS技术,在图8-2中,我们为FTP数据打上了DSCP=af11的标记,然后在部门二的路由器上根据DSCP=af11这个标记配置限速策略(Police)。并且为语音的RTP流量打上了DSCP=ef的标记,并且在部门二的路由器上根据DSCP=ef配置了优先队列(Priority)。这样的QoS部署在没有IPSec ×××加密的网络内工作是完全没有问题的。但是如果使用IPSec ×××对流量进行加密就会出现如图8-3所示的问题。
图8-3 IPSec ×××对QoS的影响
 

在图8-3中,我们使用IPSec ×××技术加密部门一到部门三和部门六的流量,由于加密点不等于通讯点,所以将采用隧道模式进行加密,这种加密方式会把整个原始数据进行加密,并且增加一个全新的IP头部。这种加密后的数据在穿越中间QoS路由器(部门二路由器)时,由于新增加的IP头部内的DSCP=0,QoS路由器无法对加密前的FTP和RTP流量进行QoS处理,影响了QoS的正常工作。
问题二 : 点对点 IPSec SA 造成的问题
图8-4 点对点安全关联造成的问题



 

传统的IPSec安全关联有两个明显的特点,一个是点对点,另一个就是单向。也就是说如果在部门一路由器和部门三路由器之间建立IPSec ×××,一共会产生两个点对点的安全关联,如图所示,部门一路由器使用安全关联一加密的数据只能够被送到部门三路由器才能解密,同理部门三路由器使用安全关联二加密的数据只能送到部门一路由器才能解密。很明显使用安全关联一加密的数据送到部门六肯定是无法解密的,因为部门六路由器没有安全关联一。也就是说传统的IPSec技术无法实现“任意到任意”的连接,没有办法让一台路由器加密的数据被网络内部的任何一台路由器解密。也就是因为这个原因传统的IPSec ×××技术无法对组播进行加密。并且传统点对点IPSec ×××配置复杂,并且不能实现即时连接,所谓的不能实现即时连接,也就是说如果一个语音流量抵达路由器需要被加密,但是路由器不能立即加密数据,而是需要经过传统IKE协商,产生IPSec SA后才能够加密数据,这样就大大增加了语音流量的延时。综上所述传统的点对点IPSec SA存在如下四个方面的问题:
1. 配置复杂
2. 无法实现“任意到任意”(Any to Any)通讯
3. 无法加密组播流量
4. 无法实现即时连接
问题三 : 覆盖路由( Overlay routing )问题
图8-5 覆盖路由(overlay routing)问题
 

 

 

本书前半部分讲过SVTIGRE Over IPSec等等隧道技术,我们配置隧道,并且在隧道上运行动态路由协议,这样确实会降低配置复杂度。但是如果我们把这种隧道技术运用在公司内部网络,就出现了覆盖路由问题,增加了路由的复杂程度。何谓覆盖路由呢?在一个企业网内部,为了能够实现全网可路由,肯定会配置原生路由(Native routing),在图8-5中,原生路由为OSPF。如果我们又在内部网络采用IPSec的隧道技术,并且在隧道上运行动态路由协议EIGRP,这样隧道上的EIGRP就覆盖在OSPF上,出现了覆盖路由。这样的覆盖路由设计增加了内部网络路由的复杂程度。

GET××× 技术介绍
8-6 GET×××特点示意图
 

 

 

从图8-6我们可以了解GET×××的三大特点,第一是任意到任意连接,第二是高扩展性,第三是实时连接。当然这是最基本的三大特点,下面我们就对GET×××的特点进行一个总结:
1.基于原生路由架构的透传解决方案。
2.IP Header Preservation技术,实现原始IP头部保留。
2.不影响QOS,不增加网络开销和复杂度。
4.基于Trusted Group Members的概念,在Group内的Router使用相同的安全策略,比点对点×××管理更简单。
5.Group内成员预先协商安全参数(IPSec SA),实现任意到任意(any-to-any)连接。
6.即时连接,减少类似于语音流量的延时。
7.支持对单播和组播的加密。
8.是一个WAN解决方案,需要全局可路由,不适合在IPv4的互联网部署。
由于GET×××拥有这些特点,所以他能够很好的解决传统IPSec技术在企业网内部部署时出现的三大问题,下面我们就详细介绍一下GET×××是如何解决这三大问题的。
解决问题一 : 影响 QoS
在介绍GET×××如何解决QoS问题之前,我们需要先介绍一下GET×××所采用的IP头部保留(IP Header Preservation)技术,图8-7展示了这个技术的工作特点。
图8-7 GET××× IP头部预留技术示意图
 



 
GET×××所采用的IP头部预留技术,如图8-7所示拷贝原始IP头部到外层头部并且在两个IP头部中间插入ESP头部,并对内部的原始IP数据包进行加密。采用这种技术能够很有效的保护企业网内部原有的QoS部署。图8-8详细的说明了这一问题。
图8-8 IP头部预留技术解决QoS问题
 

我们从图8-8中可以看到,由于采用了IP头部预留技术,加密后的数据包,外层头部是原始IP头部的一个拷贝,也就是说在原始IP头部内的DSCP值被完好的保留了下来。这样中间的路由器,就可以根据DSCP标识来执行QoS。
解决问题二 : 点对点 IPSec SA 问题
图8-9 GET×××单一SA示意图
 

 

GET×××组加密传输 ×××,何谓组加密,关键就在于 GET×××使用了一个全新的技术架构,这就是信任组成员( Trust Group Members)的概念。所有参与加密的企业内部路由器都需要加入一个 GET×××组,成为这个组的组成员( Group Member)。并且每一个组中至少存在一个密钥服务器( Key Server),它的主要任务就是认证组成员,并且接受他们的注册,而且还要产生并且分发安全关联给注册的组成员。这样所有的组成员一旦注册成功,就会拥有一个相同的安全关联。这个安全关联同时被用于加解密数据。由于所有的加密路由器都拥有相同的安全关联,所以可以这么说,一台路由器加密的数据包,能够被相同组内的任何一个组成员路由器进行解密。这样就能够实现任意到任意的通讯,并且能够加密组播流量。而且安全关联并不是出现感兴趣流后才产生的,而是组成员注册成功后就会由密钥服务器所发放,所以消除了协商安全关联所造成的延时,实现了即时通讯。
解决问题三 : 覆盖路由( Overlay routing )问题
8-10 GET×××使用原生路由
 

从图8-10中可以看出,由于GET×××使用了IP头部预留技术,所以GET×××是一个典型的无隧道类型的IPSec ×××,只需要企业内部的原生路由即能正常工作,所以消除了配置隧道类型IPSec ×××所造成的覆盖路由问题。
GET××× 与传统 IPSec ××× 技术的比较
表8-1 GET×××与传统IPSec ×××技术比较表
 


GET××× 三大组成部分
图8-11 GET×××三大组成部分示意图

 

1. 组控制器与密钥服务器( Group Controller/Key Server
<GCKS是一个为组维护策略,创建和维护密钥的路由器。当一个组成员注册的时候,密钥服务器发送策略和密钥到这个组成员。密钥服务器也会在密钥超时前更新密钥。服务器会发送两种类型的密钥,加密流量的密钥(TEK)和加密密钥的密钥(KEK)。TEK会成为IPSec SA,这个SA用于相同组内成员之间的通讯。TEK是一个本质的组密钥,它共享给所有的组成员,并且加密组成员之间的流量。KEK用于加密更新密钥信息,每一个组成员也用它来解密从密钥服务器发送过来的更新密钥信息。>
2. 组成员( Group Member
<组成员是一台路由器,他在密钥服务器上注册,并且从密钥服务器获取IPSec SA,使用这个SA与属于这个组的其它设备通讯,组成员在密钥服务器上注册并且提供了一个组ID,并从服务器获取用于这个组的安全策略和密钥。>
3. Group Domain of Interpretation GDOI
<GDOI协议用于在组成员和组控制器/密钥服务器(GCKS)之间建立安全关联,实现安全的Group内通讯,GDOI协议使用UDP/848!>
GET××× 工作流程图
图8-12 GET×××工作流程图

 

当组成员路由器启动,或者把crypto map调用到接口后(两种触发条件),组成员和密钥服务器之间进行IKE第一阶段的协商。密钥服务器通过IKE来认证组成员,并且建立IKE安全关联。并且通过IKE安全关联来保护整个GDOI注册过程。注册是一个“拉”策略的过程,一共包含如下4个内容的交换。
第一:组成员向密钥服务器提供组ID(Group-ID)
第二:密钥服务器根据组ID提供安全关联策略
第三:组成员对收到的安全关联进行确认
第四:密钥服务器向组成员提供密钥资源(TEK,KEK)
通过这个过程,组成员把密钥服务器上的安全关联策略和密钥“拉”到了本地。当组成员获取了安全关联和密钥之后,就可以在组成员之间加解密数据了。并且还会从密钥服务器获取密钥更新安全关联(rekey SA),使用这个关联能够在密钥超期以后,加密由密钥服务器发送给所有组成员的密钥更新信息(rekey message),密钥更新信息是密钥服务器把策略“推”给组成员的一个方式。如果不出现任何问题,所有组成员会周期性的收到源自于密钥服务器的密钥更新信息。如果组成员在密钥超期之前还没有收到密钥更新信息,密钥超时以后,组成员会重新向密钥服务器发起一次注册,把策略“拉”过来。