背景技术
在现有技术中,IPsec SA通常使用互联网密钥交换协议(IKE)协商获得。IKE协商分为两个阶段,阶段1协商IKE SA,该IKE SA用于保护阶段2的协商过程;阶段2协商IPsec SA,该SA用于保护用户的IP流量。在IPsecSA的协商过程中,通信双方为保护不同的IP流量,会针对每个需要保护的IP流量进行IPsec SA的协商。这里,用于保护阶段2协商过程的IKE SA,也可以看作是保护阶段2的IP流量的SA。在本文的介绍如无特殊说明,SA表示IKE SA或IPsec SA。
一个SA协商过程,无论是IKE SA协商过程或是IPsec SA协商过程通常可以由SA所要保护的IP流量的分类信息唯一标识。这里,SA分类信息包括四个参数,分别为:发起端的源IP地址、响应端的目的IP地址、协议号和传输层信息。其中,当使用的协议为TCP/UDP协议时,传输层信息包含:发起端端口、响应端端口。
IKE SA的协商过程和IPsec SA协商过程基本相同,在主模式下通信双方通过IKE协议的协商,生成IKE SA或IPsec SA的基本过程如图1所示。在此,假设通信双方为通信方A和通信方B,通信方A为发起方、通信方B为响应方。
步骤101:通信方A向通信方B发送多个SA参数建议,向通信方B发起SA的协商过程。
步骤102:通信方B向通信方A返回自身选中的SA参数。
步骤103~104:通信方A发起与通信方B之间的密钥协商,通信方A和通信方B协商确定SA中使用的密钥;并且,在通信方A发起密钥协商的同时,发起通信方B的网络地址转换(NAT)检测,通信方B通过NAT检测获得通信双方的私有网络信息;通信方B在响应密钥协商时,发起通信方A的NAT检测,通信方A通过NAT检测获得通信双方的私有网络信息。这里,通信双方通过获得的私有网络信息能够获知通信双方是否在私有网络内部,以及关于私有网络一些其他信息。
步骤105:通信方A向通信方B发送自身的身份证明信息。
步骤106:通信方B在收到通信方A发送的身份证明信息后,对通信方A的身份证明信息进行验证,在成功验证后,通信方B则生成SA,并向通信方A发送自身的身份证明信息;通信方A收到通信方B发送的身份证明后,对通信方A的身份进行验证,在成功验证后生成SA。
在本文的介绍中,称步骤101对应的通信方A向通信方B发送的消息为SA协商请求消息;称步骤106对应的通信方B发送给通信方A的消息为SA协商结束消息,将步骤101~106整个过程,称为SA协商过程。同时,称由通信方A通过发送SA协商请求消息发起的SA协商过程称为SA协商过程A,相应的,通信方A发起SA协商过程的SA协商请求消息称为SA协商请求消息A,通信方B发送的结束SA协商过程的SA协商结束消息称为SA协商结束消息A。
使用IKE协议参与SA协商的通信双方都可以发起协商,但对于保护相同IP流量的SA在通信双方只能存在一个。
当通信双方几乎在相同的时间向对端发送SA协商请求时,假设通信双方为通信方A和通信方B,此时通信双方则会在发送了协商请求消息之后,在未收到对端返回的响应之前,就收到对端发送的SA协商请求消息,这样就会造成通信双方针对保护同一个IP流量分别发起了两个协商过程。按照现有技术,通信双方分别发起的SA协商均会正常执行,并且两个SA协商过程均分别协商出SA。由于,保护相同IP流量的SA在通信方只能存在一个,因此当通信方A和通信方B在协商生成第二个SA之后,则会用在后生成的SA替换在先生成的SA。
但是,由于通信双方几乎在相同的时间内发起SA协商过程,因此就不能保证同一SA协商过程协商出的SA均晚于另一SA协商过程协商出的SA,而使通信双方最后保留的SA不为同一SA协商过程协商出的SA,具体情况如图2所示。
为了更加清晰的描绘两个SA的替换过程,在图2中只给协商过程所使用的SA协商请求消息和SA协商结束消息,省略了SA协商过程中的其他消息。
在图2中,通信方A先向通信方B发送了SA协商请求消息,在之后几个毫秒之内,也就是几乎同时,通信方B向通信方A发送了SA协商请求消息。此时,在通信方A和通信方B之间则存在两个协商过程:通信方A发起的SA协商过程A和通信方B发起的SA协商过程B。如图2所示,由于通信方A先于通信方B发起SA协商过程,因此通信方B也先于通信方A返回SA协商结束消息。但是,由于通信方A和通信方B几乎同时发起SA协商过程,因此通信方B和通信方A也几乎在同时返回SA协商结束消息。这样使得在通信方A端,如图2所示,通信方A先生成了SA协商过程B的SA-B,接着用SA协商过程A生成的SA-A替换了SA-B;在通信方B端,通信方B先生成了SA协商过程A的SA-A,接着用SA协商过程B生成的SA-B替换了SA-A。这样就导致了通信双方最终保留的SA不是匹配的SA,使通信双方为保护同一IP流量而协商生成了两个IKE SA或两个IPsec SA,造成通信双方SA协商过程不成功,严重影响了业务的正常运行、造成了网络资源的极度浪费。
发明内容
有鉴于此,本发明的主要目的在于提供一种协商SA的方法,应用该方法能够避免由于通信双方同时发起SA协商而保留不同SA的情况,保障业务的正常运行。
为达到上述目的,本发明的技术方案是这样实现的:
一种协商安全联盟的方法,设置选择规则,并在确定两安全联盟SA协商过程存在冲突时,执行以下步骤:
A、根据选择规则获取存在冲突的两SA协商过程的特征;并根据获得的特征及选择规则,选择存在冲突的两SA协商过程对应的一个SA。
其中,所述确定两SA协商过程存在冲突为:
当通信方为保护同一IP流量生成了两个SA时,则确定所述两SA存在冲突,根据确定为保护同一IP流量生成的两SA存在冲突而确定两SA对应的SA协商过程存在冲突。
其中,步骤A中,所述选择存在冲突的两SA协商过程对应的一个SA为:根据获得的特征及选择规则,选择存在冲突的两SA协商过程中的一SA协商过程,保留该SA协商过程产生的SA。
另外,设置等待阈值,步骤A之前进一步包括:
计算为保护同一IP流量的两个SA的生成时间差,并判断计算得到的生成时间差是否小于等待阈值,如果计算得到的生成时间差小于等待阈值,执行步骤A;否则,执行现有技术正常流程。
其中,所述确定两SA协商过程存在冲突为:
通信方收到SA协商请求消息时,判断所述SA协商请求消息对应的SA协商过程是否存在冲突,当所述SA协商过程存在冲突时,则确定存在两SA协商过程存在冲突。
其中,步骤A中,所述选择存在冲突的两SA协商过程对应的一个SA为:根据获得的特征及选择规则,选择并保留存在冲突的两SA协商过程中的一SA协商过程,并由保留的SA协商过程产生SA。
其中,步骤A中,所述选择存在冲突的两SA协商过程对应的一个SA为:根据获得的特征及选择规则,选择存在冲突的两SA协商过程中的一SA协商过程,并由选择的SA协商过程对应的发起方重新发起SA协商过程,生成SA。
其中,所述判断所述SA协商请求消息对应的SA协商过程是否存在冲突为:
接收到SA协商请求消息的通信方根据SA协商请求消息中携带的SA识别信息,判断自身是否还存在具有相同SA识别信息的SA协商过程,当自身还具有相同SA识别信息的SA协商过程,则确定所述SA协商过程存在冲突。
其中,所述SA协商过程为:互联网密钥交换协议IKE SA协商过程或IP安全IPsec SA协商过程;
所述SA识别信息为:包括发起端的源IP地址、响应端的目的IP地址、协议号和传输层信息的SA分类信息。
其中,所述SA协商过程为:IKE SA协商过程;
当参与IKE SA协商过程的通信双方均不位于私有网络时,
所述SA识别信息为:源IP地址或目的IP地址;
当参与IKE SA协商过程的通信双方至少有一个位于私有网络时,
所述SA识别信息为:源IP地址和源端口、或目的IP地址和目的端口。
其中,所述选择规则为:选择Cookies值大的SA协商过程或Cookies值小的SA协商过程;
步骤A中,所述根据选择规则获取所述存在冲突的两SA协商过程的特征为:获取两SA协商过程各自使用的Cookies值;
步骤A中,所述选择存在冲突的两SA协商过程中的一SA协商过程:根据选择规则,选择Cookies值大的SA协商过程或Cookies值小的SA协商过程。
其中,所述选择规则包括:选择规则1、选择规则2和选择规则3;所述选择规则1为:选择Cookies值大的SA协商过程或Cookies值小的SA协商过程;所述选择规则2为:选择在私有网络内的通信方发起生成的SA协商过程;所述选择规则3为:选择源IP地址或目的IP地址大的SA协商过程;
该方法进一步包括:通信方从存在冲突的两SA协商过程中获得所述两SA协商过程对应的通信双方的位置信息,
当通信双方均不位于私有网络内,选择选择规则3,获得所述两协商过程的源IP地址或目的IP地址,选择源IP地址或目的IP地址大的SA协商过程;当通信双方有一方位于私有网络内,选择选择规则2,获得位于私有网络内的发起SA协商过程的通信方,选择由私有网络内的通信方发起生成的SA协商过程;当通信双方均位于私有网络内,选择选择规则1,获得所述两SA协商过程的Cookies值,选择Cookies值大的SA协商过程或Cookies值小的SA协商过程。
另外,该方法进一步包括:当软超时时间点到达时,通信方向进行SA协商过程的对端发起安全联盟协商过程。
其中,所述Cookies值为:通信双方在一个SA协商过程中各自生成Cookies值的总和。
本发明所提供的一种协商SA的方法,通过设置选择规则,在确定两安全联盟SA协商过程存在冲突时,根据选择规则获取所述存在冲突的两SA协商过程的特征;并根据获得的特征及选择规则,选择所述存在冲突的两SA协商过程对应的一个SA。通过应用本发明所提供的方法,能够在通信双方为保护同一IP流量而生成两个不同的SA时,或针对保护同一IP流量而进行两个SA协商过程时,使通信双方能够得到匹配的SA,或执行同一个SA协商过程,保证SA的成功协商,同时也保证了业务的正常运行。
具体实施方式
本发明的核心思想是:设置选择规则,确定两SA协商过程存在冲突时,根据选择规则获取所述存在冲突的两SA协商过程的特征,并根据获得的特征及选择规则选择所述存在冲突的两SA协商过程对应的一个SA。
这里,确定两SA协商过程存在冲突可以有两种方法,其一为:当通信方为保护同一IP流量生成了两个SA时,则确定两个SA对应的SA协商过程存在冲突;其二为:通信方收到SA协商请求消息时,判断所述SA协商请求消息对应的SA协商过程是否存在冲突,当所述SA协商过程存在冲突时,则说明在通信方还存在另一针对相同IP流量的SA协商过程,此时则可以确定存在两SA协商过程存在冲突。
这里,所述针对相同的IP流量,对IKE SA协商而言为:通信双方为保护IPsec SA协商过程而生成的SA;对IPsec SA协商而言为:通信双方为保护同一IP数据流量而生成的SA。
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举两个较佳实施例,对本发明做进一步的详细说明。
其中,第一较佳实施例主要针对:所述确定安全联盟协商过程存在冲突为,在通信方为保护同一IP流量前后生成了两个SA的情况;第二较佳实施例主要针对:所述确定安全联盟协商过程存在冲突为,当通信方收到安全联盟协商请求消息时,确定安全联盟请求消息对应的安全联盟协商过程存在冲突的情况。
第一较佳实施例
本实施例以图2所描述的情况为例进行说明,在执行本实施例的流程之前,需预先设置选择规则,这里所述的选择规则用于在SA发生冲突时,通信双方根据选择规则选择保留相同的SA。在本实施例中采用的选择规则为:保留Cookies值大的SA,该选择规则所对应的选择参数为Cookies值,即在通信双方生成的SA发生冲突时,通信方保留Cookies值大的SA。其中,Cookies为SA协商过程中使用的一个随机数。
在此仅介绍通信方B的具体实施过程,通信方A的具体实施过程与通信方B相同,具体过程如图3所示:
步骤301:通信方B在收到通信方A发送的SA协商过程A的SA协商结束消息后,生成SA-B,发现在先生成的SA-A和SA-B为保护同一IP流量而生成的两个SA,则确定当前生成的SA-B存在冲突。
步骤302:通信方B获得SA-B和SA-A所对应的SA协商过程中所使用的Cookies。在此称协商生成SA-B的Cookies为Cookies-B;称协商生成SA-A的Cookies为Cookies-A。
由于,在SA协商过程中通信双方均会产生Cookies,这样在一个SA协商过程中就存在通信双方分别产生的两个Cookies,因此,在本发明中所指的SA协商过程中使用的Cookies值为通信双方所生成的Cookies值的总和。这里,又由于通信方均会保留SA协商过程中使用的一些参数,例如Cookies、SA协商过程的发起者、通信双方的私有网络信息等,因此通信方只需根据SA就能查找得到相应的Cookies,得到SA协商过程中使用的Cookies总和。
步骤303:比较Cookies-B和Cookies-A的大小,如果Cookies-B大于Cookies-A,则通信方B保留Cookies-B对应的SA-B;如果Cookies-B小于Cookies-A,则通信方B保留Cookies-A。
在本实施例中,还可以进一步设置等待阈值,用于区别由于软超时时间点到达发起SA协商过程而造成的SA冲突,和由于通信双方几乎同时发起SA协商过程而造成的SA冲突。如果是由于软超时时间点到达发起SA协商过程而造成的SA冲突,则由于发生冲突的两个SA生成的时间相差较大,因此在删除在先SA的时候就不会发生错误。因此,设置等待阈值,当发生冲突的两个SA生成时间差大于等于等待阈值时,则确定发生冲突的原因是由于软超时时间点到达,在这种情况下,根据现有技术的方法即可以保证通信双方保留匹配的SA;当发生冲突的两个SA生成时间差小于等待阈值时,则确定发生冲突的原因是由于通信双方几乎同时发起SA协商过程造成的,因此就必须按照本发明所提供的方法,才能保证通信双方保留匹配的SA。
这里,具体设置等待阈值的方法,可以根据实际的网络环境、以及经验进行确定,可以为几个毫秒的时间长度。相应的,具体实施方法为:在步骤301中当确定了当前生成的SA-B存在冲突之后,还可以进一步计算SA-B和SA-A生成时间的差值,判断SA-B和SA-A生成时间的差值是否大于预先设置的等待阈值,如果大于或等于,则确定存在冲突的原因是由于软超时时间点到达,因此可以不对这种情况进行处理,按照现有技术的流程执行;否则,执行步骤302。
在本实施例中,根据通信双方所处位置的不同还可以使用不同的选择规则,例如,当通信双方均不在某个私有网络的内部,则可以根据SA所对应的IP地址进行选择,可以选择源IP地址或目的IP地址小的SA,或是源IP地址或目的IP地址大的SA。当通信双方有一方在某个私有网络的内部,而另外一方不在某个私有网络的内部时,则可以选择在私有网络内部的通信方发起SA协商过程生成的SA。
由于,使用IP地址进行选择仅适用于通信双方均不在某个私有网络的内部的情况;同时,保留在私有网络内部的通信方发起生成的SA,也仅适用于通信双方的一方在某个私有网络内部的情况,因此,当SA发生冲突时,还可以进一步根据通信双方当前所处的位置,确定选择规则,再根据选择规则确定保留的SA。
又由于,在SA协商过程中通信双方会根据彼此发起NAT检测,得知通信双方所在的位置,是通信双方均在私有网络之内,或是通信双方中的一方在私有网络之内、或是通信双方均没有在私有网络之内。因此,就可以在SA发生冲突时,根据SA协商过程中确定的通信双方的位置,确定选择规则。
当然,由于使用Cookies适用于任何的网络位置,因此在本发明中,也可以不进行确定选择规则的操作,而直接根据Cookies进行选择。当然,当Cookies作为选择参数时,选择规则也是选择Coolies小SA。
本实施例中介绍的方法,同样适应于IKE SA和IPsec SA发生冲突的情况。
第二较佳实施例
在本实施例,首先介绍IPsec SA的协商过程。假设存在通信方A和通信方B,通信方B针对所要保护的IP流量X向通信方A发送IPsec SA协商请求消息。其中,X相当于IP流量的名称,用来唯一标示当前通信方A和通信方B所要保护的IP流量,同时IPsec SA协商过程由SA分类信息唯一确定。通信方A的具体执行流程如图4所示,包括以下步骤:
步骤401~402:通信方A收到通信方B针对IP流量X发送的IPsec SA协商请求消息,根据收到的IPsec SA协商请求消息,判断针对当前IP流量X的IPsec SA协商过程是否存在冲突,如果是,则执行步骤403;否则,执行步骤404。
这里,判断针对当前IP流量X的IPsec SA协商是否存在冲突,也就是通信方A判断自身是否已经向通信方B发起了针对当前IP流量X的IPsecSA协商过程,具体为:通信方A根据收到的通信方B发送的IPsec SA协商请求消息B中携带的SA分类信息,判断自身正在协商的IPsec SA中,是否存在具有同样SA分类信息的IPsec SA协商过程,如果存在,则通信方A已经向通信方B发起了针对IP流量X的另外一个IPsec SA协商过程,当前针对IP流量X的IPsec SA协商过程存在冲突,通信方A和通信方B同时参与了由通信方A发起的IPsec SA协商过程A、和由通信方B发起的IPsec SA协商过程B;否则,当前针对IP流量X的IPsec SA协商过程不存在冲突,通信方A与通信方B之间针对IP流量X只存在当前通信方B发起的IPsecSA的协商过程。
步骤403:通信方A保留一个与通信方B之间针对当前IP流量X的IPsecSA协商过程;或中止当前与通信方B之间针对IP流量X的所有IPsec SA协商过程,重新建立一个与通信方B之间针对当前IP流量X的IPsec SA的协商过程。结束处理流程。
为了使通信双方保留相同的IPsec SA协商过程,或者使通信双方都能确定具体是由哪方来重新发起针对当前IP流量X的IPsec SA,可以根据预先设置的选择规则确定。
通信双方确定保留的IPsec SA协商过程,或者确定重新发起IPsec SA协商过程的发起方,可以是在确定了针对当前IP流量X的IPsec SA协商过程存在冲突之后进行确定;也可以是在当前存在冲突的两个IPsec SA协商过程完成之后进行确定。
如果是在针对当前IP流量X的IPsec SA协商过程存在冲突之后进行确定,则对于保留相同的IPsec SA协商过程的选择规则可以是:保留Cookies值大的IPsec SA协商过程,相应的选择参数为Cookies;对于重启发起IPsecSA协商过程的通信方,选择规则可以是:选择Cookies值大的IPsec SA协商过程对应的通信方重新发起IPsec SA协商过程。具体的使用方法与第一较佳实施例中的使用方法相同,同样需要在发生冲突的两个IPsec SA协商过程中获得Cookies值,然后进行比较确定,具体过程在此不再详述。
如果在当前存在冲突的两个IPsec SA协商过程完成之后进行确定,则可以根据IPsec SA协商过程中确定的通信双方的位置,选择选择规则,再根据选择规则,获得对应的选择参数,根据获得选择参数以及选择规则确定保留的IPsec SA协商过程,或者确定重新发起IPsec SA协商过程的发起方。这里,同样也可以只采用Cookies值进行确定。
步骤404:通信方A按照正常流程协商IPsec SA。
以上所述的流程同样使用于IKE SA的协商过程。
另外,由于IKE SA自身的特点,IKE SA是为了保护第二阶段的IPsec SA的协商而存在的,即IKE SA协商生成的SA是为了保护第二阶段多个IPsecSA协商过程而存在,因此在通信双方只会存在一个IKE SA的协商过程,如果存在两个IKE SA协商过程,即通信双方的IKE SA协商过程发生冲突。因此,在步骤402的判断中,并不需要与IPsec SA一样根据SA分类信息中的所有参数进行判断是否针对当前的IPsec SA存在冲突,而只需依照具体的网络环境根据SA分类信息中部分参数进行判断即可。
由于通信双方只会存在一个IKE SA协商过程,因此通信双方的IKE SA协商过程可以由通信方的IP地址唯一确定。但是,在某些环境中,当通信方位于私有网络中,通信方必须通过私有网络的NAT与外界进行通信,通信方在通过NAT发送报文、或接收报文时,发送报文和接收报文的源地址将转换成NAT的某一个IP地址,因此在某些环境下,IKE SA协商过程又不能使用通信方的IP地址唯一确定。这样,就可以根据通信双方所处的网络环境的不同,分为这样三类,包括:通信双方均不在私有网络内,通信双方的一方在私有网络内,以及通信双方均在私有网络内。
以下分别针对这三种情况,对IKE SA协商的冲突检测进行详细说明。
当通信双方均不在私有网络内、或同处于一个私有网络,进行IKE SA协商时,通信方可以根据接收到的IKE SA协商请求消息携带的SA分类信息中的源IP地址或目的IP地址,判断针对当前的IKE SA的协商是否存在冲突。
例如,如果通信方A使用的SA信息是源IP地址,通信方A则获得通信方B发送的SA协商请求消息中的源IP地址,即通信方B的IP地址,然后在自身正在协商的IKE SA中查找,是否存在与所述源IP地址信息的目的IP地址的IKE SA协商过程,如果存在,则当前IKE SA协商过程存在冲突;否则,当前IKE SA协商过程不存在冲突。
当通信双方的一方、或双方均位于私有网络内,由于通信方的IP地址已经不能唯一标示一个IKE SA协商过程,因此,在私有网络静态分配端口的情况下,可以利用IP地址和端口唯一标示一个IKE SA协商过程。相应的,判断冲突的方法可以是:根据IKE SA协商请求消息携带的SA分类信息中的源IP地址和源端口、或目的IP地址和目的端口,判断针对当前的IKE SA的协商是否存在冲突。具体判断的方法与利用源IP地址进行判断的方法相似,在此不再详述。
在发明中称用于检测两SA协商过程是否存在冲突的SA分类信息、源IP地址、目的IP地址、源IP地址和源端口、或目的IP地址和目的端口为SA识别信息。该SA识别信息用于识别两个SA协商过程是否存在冲突。
另外,由于现有技术中没有规定通信双方协商出的SA的生命周期必需严格相同,因此可能会导致通信一方的SA已到生命周期,不能再使用协商的SA;而另一方由于没有达到SA的生命周期,还利用相同的SA向对端发送数据,这样就导致了通信双方数据通信的中断以及网络资源的浪费。
生命周期包括两个超时时间点,硬超时时间点和软超时时间点。硬超时时间点为SA的生命周期的结束点,当SA到达硬超时时间点时,SA将无效,通信方即不能使用SA来加密数据,同时也不会接收用超时的SA加密的数据。软超时时间点,为提前协商备用SA的时间点,当通信方到达软超时时间点时,则发起SA协商,以便原先协商出的SA超过硬超时时间点时,能够使用备用的SA,保证数据的正常通信。上述通信双方SA的生命周期不同,是指通信双方的硬超时时间点和/或软超时时间点不同。在现有技术中,通常SA协商过程的发起方才会在到达软超时时间点时,发起备用SA的协商,但当响应方的硬超时时间点原小于发起方SA的软超时时间点时,响应方的SA已过生命周期,而发起方还在继续使用SA,这样就会使通信双方的数据通信终端。
为解决通信双方由于生命周期不同而导致通信双方通信中断这个问题,可以设置通信双方在到达自身的软超时时间点时,均向对端发起备用SA协商过程。在这种情况下,通信双方几乎同时向对端发起SA协商的情况,但是在协商的过程中,只需要使用本发明所提出的协商SA的方法,则可以保证通信双方协商出相同的SA。
由于IKE协议的协商过程包括IKE SA和IPsec SA的协商,这两类SA均存在自身的生命周期,因此当IKE SA或者IPsec SA到达自身的软超时时间点时,均可以发起SA协商。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。