CN1845549A - 一种查询IPSec隧道状态的方法 - Google Patents
一种查询IPSec隧道状态的方法 Download PDFInfo
- Publication number
- CN1845549A CN1845549A CN 200610080569 CN200610080569A CN1845549A CN 1845549 A CN1845549 A CN 1845549A CN 200610080569 CN200610080569 CN 200610080569 CN 200610080569 A CN200610080569 A CN 200610080569A CN 1845549 A CN1845549 A CN 1845549A
- Authority
- CN
- China
- Prior art keywords
- ipsec tunnel
- issuer
- ipsec
- answer party
- query
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种查询IPSec隧道状态的方法,根据要查询IPSec隧道的特征参数,对IPSec隧道的状态进行查询,确定IPSec隧道的状态。本发明所提供的方法,避免了由于间接查询,即通过查询其他的状态来反映当前IPSec隧道的状态,而造成由于错误确定IPSec隧道的状态,使通信中断,系统延时、客户服务质量降低、通信可靠性下降等问题。本发明提供的方法能够准确、快速、可靠的查询到IPSec隧道当前的真实状态,降低了系统延时、提高了通信的可靠性、有力的保证了通信网络的正常运行。
Description
技术领域
本发明涉及网络安全检测技术,尤指一种查询IP安全(IPSec)隧道状态的方法。
背景技术
IPSec是互联网工程任务组(IETF)制定的一个开放的IP层安全框架协议,为一个三层隧道协议。IPSec在网络层起作用,能够为传输敏感数据提供安全保护,对参与IPSec的设备之间传输的IP数据包进行保护和认证。有了IPSec,数据在通过公共网络传输时,不需担心被攻击者监视、窜改以及伪造。
IPSec协议对数据的保护,是通过安全联盟(Security Association,SA)来实现的。IPSec SA中定义了通信双方对通信过程中某些要素的约定,例如,使用哪种协议、协议的操作模式、密码算法、特定流中保护数据的共享密钥、以及密钥的生存周期等。IPSec SA由一个三元组进行唯一标识,该三元组包括:安全参数索引(SPI)、目的IP地址、以及安全协议。
在通信双方建立IPSec隧道后,通信双方必须保持该IPSec隧道的SA一致并同时存在,才能保证协商消息和数据消息正常的进行加密和解密,即才能保证通信双方正常使用该IPSec隧道进行数据通信。因此,就需要某种机制来查询IPSec隧道,即在通信双方的IPSec隧道建立起来后,查询通信双方的IPSec SA是否同时存在,以便在通信双方IPSec SA不同时存在时,触发删除原IPSec隧道,重新建立新的IPSec隧道,保证数据的正常通信。
在现有技术中,对IPSec隧道状态的查询通常是通过互联网密钥交换协议(IKE)中的死亡对端检测(DPD)来实现。
DPD通过检测与IPSec SA对应的IKE SA的状态,来确定IPSec SA的状态,进而确定要查询的IPSec的状态。这里,所述IKE SA或IPSec SA的状态为:IKE SA或IPSec SA是否存在;所述IPSec隧道的状态为:IPSec隧道是否可用。但是,在现有技术中,IKE SA的状态并不能代表对应IPSecSA的状态,也就是说,即使在IKE SA存在的情况下,与IKE SA对应的IPSecSA也不一定会存在。因此通过查询IKE SA的状态确认IPSec隧道的状态并不合理,如果错误确定了IPSec隧道的状态,会使这种检测机制失去作用,并且造成数据通信的中断,使数据通信长时间无法自动恢复,给网络实际运行带来不良影响。
发明内容
有鉴于此,本发明的主要目的在于提供一种查询IPSec隧道状态的方法,应用该方法能够准确、可靠的查询到IPSec隧道当前的状态。
为达到上述目的,本发明的技术方案是这样实现的:
一种查询IPSec隧道状态的方法,该方法包括以下步骤:
A、查询方向应答方发送IPSec隧道查询消息,IPSec隧道查询消息中携带至少一条要查询的IPSec隧道的特征参数;
B、应答方获得IPSec隧道查询消息中携带的特征参数,查询自身是否存在相同的特征参数,并将查询结果返回给查询方;
C、查询方根据应答方返回的查询结果,当应答方存在相同的特征参数时,则确定所述相同的特征参数对应的IPSec隧道可用;当应答方不存在相同的特征参数时,则确定所述不存在相同的特征参数对应的IPSec隧道不可用。
另外,当要查询一条以上IPSec隧道时,步骤B中,所述将查询结果返回给查询方为:
通过一条消息将一条以上IPSec隧道的查询结果返回给查询方;或
针对每条IPSec隧道,分别向查询方返回一条查询结果。
其中,步骤B中,所述将查询结果返回给查询方为:
当应答方存在相同的特征参数时,则针对所述相同的特征参数向查询方返回IPSec隧道查询成功消息;
当应答方不存在相同的特征参数时,则针对所述不存在相同的特征参数向查询方响应失败。
其中,所述响应失败为:应答方向查询方返回IPSec隧道查询失败消息。
另外,进一步设置等待定时器及等待时长,当查询方发送IPSec隧道查询消息时,启动等待定时器;
步骤B中,所述响应失败为:当应答方不存在要查询IPSec隧道的特征参数时,不向查询方返回查询结果;
步骤C为:当等待定时器到达等待时长时,查询方判断是否收到了查询结果,如果收到了查询结果,则确定所述查询结果对应的IPSec隧道可用,否则,确定所述查询结果对应的IPSec隧道不可用。
另外,进一步设置查询定时器以及查询周期,步骤A中当查询方发送IPSec隧道查询消息时,启动查询定时器;
当查询定时器到达查询周期时,判断当前要查询IPSec隧道的状态是否已经确定,如果是,则查询定时器停止计时;否则,查询方针对没有确定状态的IPSec隧道发送IPSec隧道查询消息。
另外,进一步设置最大查询次数,对查询方发送的IPSec隧道查询消息进行计数,
在查询方针对没有确定状态的IPSec隧道发送IPSec隧道查询消息之前,进一步判断当前发送的IPSec隧道查询消息是否小于或等于最大查询次数,如果是,则执行所述发送IPSec隧道查询消息;否则,结束当前处理流程。
另外,在步骤C之前,进一步包括:
判断应答方返回的查询结果是否为当前查询周期内查询方发送查询消息的响应,如果是,则执行步骤C;否则,拒绝处理当前应答方返回的查询结果。
其中,当查询方需要向应答方发送数据或查询周期到达时,执行步骤A。
其中,所述特征参数为:IPSec隧道出方向安全联盟的安全参数索引、目的IP地址、和安全协议;或IPSec隧道入方向安全联盟的安全参数索引、目的IP地址、和安全协议;或IPSec隧道出方向安全联盟的安全参数索引、目的IP地址、和安全协议、和入方向安全联盟的安全参数索引、目的IP地址、和安全协议。
本发明所提供的一种查询IPSec隧道状态的方法,根据要查询IPSec隧道的特征参数,对IPSec隧道的状态进行查询,确定IPSec隧道的状态。本发明所提供的方法,避免了由于间接查询,即通过查询其他的状态来反映当前IPSec隧道的状态,而造成由于错误确定IPSec隧道的状态,使通信中断,系统延时、客户服务质量降低、通信可靠性下降等问题。本发明提供的方法能够准确、快速、可靠的查询到IPSec隧道当前的真实状态,降低了系统延时、提高了通信的可靠性、有力的保证了通信网络的正常运行。
附图说明
图1为本发明实施例一方法的流程图;
图2为本发明实施例二方法的流程图。
具体实施方式
在本发明中通过查询建立IPSec隧道的通信双方是否存在相同的IPSecSA,确定通信双方建立的IPSec隧道是否可用。在建立IPSec隧道时,会同时产生两个IPSec SA,在此假设建立IPSec隧道的双方分别是:A和B,产生的两个IPSec SA分别为1和2;如果IPSec SA1为A的出方向SA、IPSecSA2为A的入方向SA;则IPSec SA1为B的入方向SA、IPSec SA2为B的出方向SA。这里,对每个IPSec隧道的通信方的出方向SA和入方向SA的区别在于,通信方利用出方向SA中的密钥加密发送数据;用入方向SA中的密钥解密接收数据。这里,所述的通信双方存在相同的IPSec SA是指:通信双方同时存在IPSec隧道对应的两个IPSec SA。
由于为建立IPSec隧道而产生的两个IPSec SA是同时存在的,因此在本发明中,可以通过确定通信双方是否同时存在其中一个IPSec SA,确定通信双方是否存在两个相同的IPSec SA,进而确定通信双方建立的IPSec隧道是否可用。
由于,IPSec SA是通过安全参数索引(SPI)、目的IP地址和安全协议组成的三元组来唯一标识。因此,这里IPSec SA相同的含义即为:通信双方具有相同三元组的IPSec SA。由于对应于同一IPSec隧道的两个IPSec SA是同时产生、同时存在、并且相互绑定的,因此这两个IPSec SA三元组均可以单独唯一标识IPSec隧道,因此这两个IPSec SA的三元组均可以称为IPSec隧道的特征参数。
为使本发明的目的、技术方案及优点更加清楚明白,在发明中列举两个实施例,对本发明做进一步的详细说明。
这两个实施例的主要区别在于,实施例一为:在一次查询过程中仅查询通信双方建立的一条IPSec隧道;实施例二为:在一次的查询过程中查询通信双方建立的一条以上的IPSec隧道。以下分别对这两个实施例进行详细说明。
实施例一
当通信双方建立的IPSec隧道长时间没有数据流量时,通信的一方在发起数据传输之前,则必须先确认自身到对端的IPSec隧道是否可用。这里,为方便描述,将通信的发起方,在本发明中为查询的发起方,称为查询方;将通信发起方欲进行数据传输的对端,即查询的应答者,称为应答方。在实际的应用过程中,还可以在查询方每次发起通信之前,均查询自身当前所需使用的IPSec隧道是否可用。具体查询IPSec隧道是否可用的流程如图1所示:
步骤101:查询方向应答方发送IPSec隧道查询消息,IPSec隧道查询消息中携带自身当前即将使用的IPSec隧道的特征参数。
这里的特征参数可以是查询方的出方向SA三元组、也可以是查询方入方向SA三元组。为了简化描述,在下文中将IPSec隧道的两个IPSec SA统称为IPSec隧道SA,如果在IPSec隧道查询消息中使用的特征参数是出方向SA三元组,则相应的IPSec隧道SA为出方向SA;如果在IPSec隧道查询消息中使用的特征参数是入方向SA三元组,则相应的IPSec隧道SA为入方向SA。
IPSec隧道查询消息的数据格式,可以继承IKE DPD消息的格式,也可以采用自定义的格式。如果继承IKE DPD消息格式,则可以采用如表1所示的格式。
下一个载荷 | 保留字段 | 载荷长度 |
解释域 | ||
协议号 | SPI长度 | 消息类型 |
SPI | ||
通知数据 |
表1
表1所示的消息格式沿用了IKE DPD查询消息的消息格式架构。其中,每个字段的含义以及作用,均与原IKE DPD查询消息相同,在此不在赘述。由于本发明是通过查询IPSec SA的状态来确定对应IPSec隧道的状态,因此在查询消息中需携带用于查询IPSec SA状态的信息,进而在查询消息的相应字段内,也会存在不一样的内容,具体说明如下:
解释域(Domain of Interpretation,DOI)中填入的标准代码是用来对消息字段中各种数字含义进行说明,报文中每个数字代表什么样的含义是根据不同的标准确定,在IPSec协议栈中有两个标准,一个是isakmp标准,即IKE标准,代码为0,另一个是IPSec标准,即符合RFC 2407的标准,代码为1,由于本实施例中,是针对IPSec隧道的,因此这里填入1。载荷长度(Payload Length)字段中填入当前查询消息的长度,不包括该消息对应的报文头部。协议号(Protocol-ID)字段中填入当前查询IPSec隧道支持的安全协议,验证头协议(AH)或是封装安全载荷(ESP),即通过协议号字段携带IPSec SA三元组中的安全协议。SPI长度中填入,SPI的长度,为4字节。在消息类型字段中,填入本消息的消息类型,如果是IPSec隧道查询消息则填入IPSec-DPD-Request,如果是IPSec隧道响应消息则填入IPSec-DPD-Response。在SPI字段中,填入当前要查询IPSec隧道的SPI,即通过SPI字段携带IPSec SA三元组中的SPI。下一个载荷(Next Payload)字段填零,表明这个报文中只有一个载荷。保留字段(RESERVED)填零,表明保留位暂时不使用。通知数据(Notification Data)字段,填入这条消息的序列号。
在此,将填入IPSec SA信息的查询消息称为IPSec DPD消息。由表1可以看出,在IPSec DPD消息中没有明显携带IPSec SA三元组中必须的目的IP地址信息,原因是:IPSec DPD消息由IP报文承载,由于IP报文的报文头中必定携带了该消息发往的目的IP地址,因此从节约资源的方面考虑,IPSec DPD就不需要另外设置目的IP地址字段,用来携带IPSec SA三元组中的目的IP地址。
IPSec隧道查询消息还可以采用自定义的消息格式,不论自定义的消息格式采用何种的格式架构,只要在自定义的消息格式中携带需要查询IPSec隧道的SA三元组即可。如果采用自定义格式,则需要预先在通信双方的设备设置这个格式,使通信双方的设备均支持这中自定义的消息格式,以便在接收到该自定义的消息后,对消息进行识别、解析。
步骤102:应答方接收查询方发送给自身的IPSec隧道查询消息,从接收到的IPSec隧道查询消息中获得携带的IPSec SA三元组。根据获得的IPSecSA三元组在自身设备的数据库中查找,判断是否存在相同的IPSec SA三元组,如果存在,则向查询方返回IPSec隧道查询成功消息;否则,则向查询方响应IPSec隧道查询失败消息。这里,IPSec隧道查询成功消息以及IPSec隧道查询失败消息,统称为IPSec隧道查询响应消息。
应答方从接收到的IPSec隧道查询消息中获得IPSec SA三元组为:应答方首先解析接收消息中的消息类型字段,判断是否为IPSec隧道查询消息,如果是,则根据每个字段所占字节数,按照现有技术的方法对IPSec隧道查询消息进行解析,获得其中携带的SPI和安全协议、以及IPSec隧道查询消息报文头中携带的目的IP地址;否则,根据获得消息的类型对接收到的消息进行相应处理。
应答方向查询方返回的IPSec隧道查询响应消息,也可以采用如表1所示的格式,具体为:
当应答方向查询方返回的IPSec隧道查询成功消息时,则将接收到的查询方发送的IPSec隧道查询消息中的消息类型改为IPSec-DPD-Response后,发送给查询方。
当应答方向查询方返回的IPSec隧道查询失败消息,则将接收到的查询方发送的IPSec隧道查询消息中的消息类型改为IPSec-DPD-Response,并将其中的SPI和/或安全协议字段中的内容删除后,发送给查询方。
这里,应答方还可以通过其他的方式向查询方返回IPSec隧道查询响应消息,例如,可以向查询方通过返回一个指令,指令中只需携带成功或者失败的指示。
步骤103:根据应答方返回的IPSec隧道查询响应消息,查询方判断应答方是否存在相同的IPSec SA,即判断是收到了IPSec隧道查询成功消息还是IPSec隧道查询失败消息,如果存在,则确定查询方当前查询的IPSec隧道可用,查询方可以利用该IPSec隧道与应答方进行安全的数据通信;否则,确定查询方当前查询的IPSec隧道不可用,查询方则不能利用该IPSec隧道与应答方进行安全的数据通信,查询方则可以删除该IPSec隧道,以便重新建立与应答方之间的IPSec隧道。
通常情况下,由于网络环境的恶劣、攻击者的攻击,以及其他一些因素,会导致查询方可能不能或延时接收到应答方返回的响应消息。这样就需要在查询方设置等待定时器以及等待时长,当等待定时器到达等待时长时,则视为应答方没有与查询方相同的IPSec SA,查询方则确定当前要查询的IPSec隧道不可用。具体实施过程可以是如下形式:
查询方在发送IPSec隧道查询报文的同时,启动等待定时器;当等待定时器到达等待时长时,查询方判断自身是否已经接收到了应答方返回的IPSec隧道查询响应消息,如果收到了,则根据收到的IPSec隧道查询响应消息确定当前要查询的IPSec隧道的状态;否则,查询方则确定当前要查询的IPSec隧道不可用,结束当前查询IPSec隧道状态的处理流程,即不再处理后续接收到的IPSec隧道查询响应消息。
在充分考虑网络环境的恶劣以及网络攻击的存在,本实施例中在充分考虑当前查询IPSec隧道的有效性和可靠性的情况下,还可以设置查询定时器、查询周期以及最大查询次数,进行重复查询。其中,当查询定时器每次到达查询周期时,查询方则根据当前查询IPSec隧道的情况,确定是否需要再次发送IPSec隧道查询消息。这里,最大查询次数用来规定查询方总共可以发送IPSec隧道查询消息的次数。重复查询具体实施过程可以是如下形式:
查询方在发送IPSec隧道查询报文的同时,启动查询定时器,并开始对查询方向应答方发送的查询消息开始计数。当查询定时器到达查询周期时,查询方则判断自身是否已经确定了要查询IPSec隧道状态,如果已经确定,则查询定时器停止计时,结束当前查询流程;如果没有确定,查询方则再判断当前已经发送IPSec隧道查询消息的次数是否小于或等于设置的最大查询次数,如果不是,则查询定时器停止计时,结束当前查询流程,如果是,则再次向应答方发送IPSec隧道查询消息,并且在已经发送的查询消息数上加1。
在设置查询定时器以及查询周期的情况下,查询方在接收到应答方返回的IPSec隧道查询响应消息时,还可以进一步判断当前收到的响应消息是否为当前周期内发送的查询消息的响应消息,如果是,则处理当前接收到的响应消息;否则,不处理当前接收到的响应消息。为了简化描述,在本文中将IPSec隧道查询消息简称为查询消息;将IPSec隧道查询响应消息简称为响应消息。
这里,判断当前收到的响应消息是否为当前周期内发送查询消息的响应消息,可以根据如下的方法:对每个查询消息进行编号,该编号能唯一标识该查询消息,并建立查询消息编号与查询次数一一对应的关系,在应答方响应查询消息时,在响应消息中携带对应查询消息的编号;查询方接收到应答方返回的响应消息后,判断当前收到的响应消息中携带的编号是否与当前的查询次数对应,如果对应,则处理当前接收到的响应消息;否则,不处理当前接收到的响应消息。其中,查询消息编号可以携带在表1中的通知数据字段内。这里,对查询消息的编号可以是当前记录的查询次数。
这里,还可以仅对查询方收到应答方返回的IPSec隧道查询成功消息进行处理,不对查询方收到应答方返回的IPSec隧道查询失败消息进行处理,因为即使IPSec隧道查询失败消息是攻击者伪造,通信的双方只需重新建立IPSec隧道即可,通信质量以及通信的安全性并不会产生太大的影响。因此,在这种实施方式下,当查询方接收到的消息为IPSec隧道查询成功消息时,再进一步判断当前收到的IPSec隧道查询成功消息是否为当前周期内发送的查询消息的响应消息,如果是,则处理当前接收到的IPSec隧道查询成功消息;否则,不处理当前接收到的IPSec隧道查询成功消息。
在步骤102中,应答方不存在相同的IPSec SA三元组时,还可以不向查询方返回任何消息,即通过不返回消息的方式向查询方表示自身不存在相同的IPSec SA三元组。那么在这种情况下,就需要查询方在发送IPSec隧道查询报文的同时,启动等待定时器;当等待定时器到达等待时长时,查询方判断自身是否已经接收到了应答方返回的IPSec隧道查询响应消息,如果收到了,则根据收到的IPSec隧道查询响应消息确定消息对应的隧道可用;否则,查询方则确定当前要查询的IPSec隧道不可用,结束当前查询IPSec隧道状态的处理流程。
在应答方通过不返回消息的方式向查询方表示自身不存在相同的IPSecSA三元组时,也可以设置查询定时器、查询周期以及最大查询次数,进行重复查询。重复查询的过程如上所述,在此不再赘述。
在本实施例中,除了可以在查询方需要使用与应答方之间的IPSec隧道之前,触发查询方查询自身与应答方之间IPSec隧道的状态,还可以进行周期性的查询,即设置定时器,当定时器到达触发周期时,即触发查询方查询与应答方之间的IPSec隧道。
在本发明中,将周期性对IPSec隧道的查询以及在需要发送消息前对IPSec隧道的查询,称为查询IPSec隧道的时机。
实施例二
本实施例介绍的是:查询方通过一条IPSec隧道查询消息查询一条以上自身与应答方之间的IPSec隧道状态。具体过程如图2所示:
步骤201:查询方向应答方发送IPSec隧道查询消息,IPSec隧道查询消息中携带当前需要查询的一条以上IPSec隧道SA三元组。
IPSec隧道查询消息的数据格式,可以继承IKE DPD消息的格式、也可以采用自定义的格式。如果继承IKE DPD消息格式,则可以采用如表2所示的格式。
下一个载荷 | 保留字段 | 载荷长度 |
解释域 | ||
协议号 | SPI长度 | 消息类型 |
SPI | ||
协议号 | SPI长度 | 保留字段 |
SPI | ||
~~ | ||
协议号 | SPI长度 | 保留字段 |
SPI | ||
通知数据 |
表2
表2中各字段的含义与表1中各字段的含义相同,在此不在赘述。表2与表1相比,只是增加了协议号字段、SPI长度字段、保留字段和SPI字段,用来携带更多的IPSec隧道SA的信息,具体增加的个数可以根据需要查询的IPSec隧道的个数进行确定。其中,增加的保留字段可以填零、也可以去掉。这里,在消息类型字段内,需填入IPSec-DPD-Multi-Request,用来表示查询方是针对多个IPSec隧道进行查询;相应的,应答方在使用相同的消息格式向查询方返回响应消息时,则需要在消息类型字段内填入IPSec-DPD-Multi-Response。
步骤202:应答方接收查询方发送给自身的IPSec隧道查询消息,从接收到的IPSec隧道查询消息中获得其中携带的多个IPSec SA的三元组。根据获得各IPSec SA的三元组在自身的数据库中查找,针对各IPSec SA三元组判断自身是否存在相同的IPSec SA三元组,针对存在相同的IPSec SA三元组向查询方返回IPSec隧道查询成功消息;针对不存在相同的IPSec SA三元组向查询方返回IPSec隧道查询失败消息。
应答方解析收到报文的过程可以按照与实施例一中步骤102中所介绍的方法。
这里,针对存在相同的IPSec SA三元组向查询方返回IPSec隧道查询成功消息;以及针对不存在相同的IPSec SA三元组向查询方返回IPSec隧道查询失败消息,可以是针对不同的IPSec SA三元组分别向查询方返回IPSec隧道查询成功或失败消息。例如,查询方当前查询自身与应答方之间的6个IPSec隧道,其中应答方针对第1、2和3条IPSec隧道均在自身查询到相同的IPSec SA三元组;而针对第4、5和6条IPSec隧道均没有查询到相同的IPSec SA三元组。则此时,应答方分别针对第1、2和3条IPSec隧道向查询方返回IPSec隧道查询成功消息,并同时分别针对第4、5和6条IPSec隧道向应答方返回IPSec隧道查询失败消息。
应答方还可以通过一条消息,将当前查询方和应答方之间各IPSec隧道的查询情况一起返回给查询方。当查询方接收到应答方返回的响应消息时,查询方则可以根据响应消息中携带的内容确定要查询的各IPSec隧道的状态。
应答方通过一条消息向查询方返回响应消息的格式也可以是如表2所示的格式。具体的方法可以是通过在每个SPI字段增加后再一个字段,以表示在前的SPI字段所对应IPSec SA是否查询成功;也可以对于查询成功的IPSec SA保留SPI和协议号,对于查询失败的IPSec SA删除SPI或协议号。
步骤203:查询方接收应答方返回的响应消息,并根据响应消息中各IPSec隧道的查询情况,确定当前需要查询的各IPSec隧道的状态。
例如,如果应答方通过一条消息向查询方返回响应消息,第1、2和3条IPSec隧道均在自身查询到相同的IPSec SA三元组,而针对第4、5和6条IPSec隧道均没有查询到相同的IPSec SA三元组;则查询方根据消息的内容确定,应答方查询IPSec隧道1、2和3成功,而查询IPSec隧道4、5和6失败,则查询方确定IPSec隧道1、2和3的状态为可用,IPSec隧道4、5和6为不可用。
如果应答方针对每条IPSec隧道返回响应消息,则查询方根据每条响应消息,确定该条消息对应的IPSec隧道的状态,在这种情况下,可以参见实施例一中的步骤103。
在实施例二中,当应答方通过一条消息向查询方返回响应消息时,也可以和实施例一相同设置等待定时器以及等待时长,当等待定时器到达等待时长时,判断自身是否已经接收到了应答方返回的IPSec隧道查询响应消息,如果收到了,则根据IPSec隧道响应消息中各IPSec隧道的查询情况,确定当前各IPSec隧道的状态;否则,查询方则确定当前要查询的IPSec隧道不可用,结束当前查询IPSec隧道状态的处理流程。
当应答方采用针对不同IPSec隧道分别向查询方返回IPSec隧道查询成功或失败消息时,也可以和实施例一相同设置等待定时器以及等待时长,当等待定时器到达等待时长时,根据自身当前已收到的响应消息,确定响应消息所对应IPSec隧道的状态;如果针对某些IPSec隧道应答方没有返回响应消息,则确定没有返回响应消息所对应的IPSec隧道不可用,结束当前查询IPSec隧道状态的处理流程。
当应答方采用针对不同IPSec隧道分别向查询方返回IPSec隧道查询成功或失败消息时,在实施例二中,还可以和实施例一相同进行重复查询,设置查询定时器、查询周期以及查询次数。查询方在发送IPSec隧道查询报文的同时,启动查询定时器,并开始对查询方向应答方发送的查询消息开始计数。当查询定时器到达查询周期时,查询方则判断自身是否已经确定了所有要查询IPSec隧道的状态,如果所有要查询IPSec隧道的状态都已经确定,则查询定时器停止计时,结束当前查询流程;在要查询的IPSec隧道中只要存在一条IPSec隧道的状态没有确定,查询方则再判断当前已经发送IPSec隧道查询消息的次数是否小于或等于设置的最大查询次数,如果不是,则查询定时器停止计时,结束当前查询流程,如果是,则再次向应答方发送IPSec隧道查询消息,其中携带当前没有确定可用状态的IPSec隧道的SA三元组,并且在已经发送的查询消息数上加1。
当设置查询定时器以及查询周期的情况下,查询方在接收到应答方返回的IPSec隧道查询响应消息时,还可以进一步判断当前收到的响应消息是否为当前周期内发送的查询消息的响应消息,如果是,则处理当前接收到的响应消息;否则,不处理当前接收到的响应消息。
这里,还可以仅对查询方收到应答方返回的IPSec隧道查询成功消息进行处理,不对查询方收到应答方返回的IPSec隧道查询失败消息进行处理,因为即使IPSec隧道查询失败消息是攻击者伪造,通信的双方只需重新建立IPSec隧道即可,并通信质量以及通信的安全性并不会产生太大的影响。因此,在这种实施方式下,当查询方接收到的消息为IPSec隧道查询成功消息时,才进一步判断当前收到的IPSec隧道查询成功消息是否为当前周期内发送的查询消息的响应消息,如果是,则处理当前接收到的IPSec隧道查询成功消息;否则,不处理当前接收到的IPSec隧道查询成功消息。
在实施例二中,在应答方不存在要查询IPSec的IPSec SA三元组时,也可以采用实施例一中的处理方式,即通过不返回响应消息的方式向查询方表示自身不存在要查询IPSec隧道的IPSec SA三元组。则此时需要设置等待定时器以及等待时长。在应答方通过一条消息向查询方返回响应消息的情况下,当等待定时器到达等待时长时,查询方判断自身是否已经接收到了应答方返回的IPSec隧道查询响应消息,如果收到了,则根据IPSec隧道响应消息中各IPSec隧道的查询情况,确定当前各IPSec隧道的状态;否则,查询方则确定当前要查询的IPSec隧道不可用,结束当前查询IPSec隧道状态的处理流程。在应答方采用针对不同IPSec隧道分别向查询方返回IPSec隧道查询成功或失败消息的情况下,也需要设置等待定时器以及等待时长,当等待定时器到达等待时长时,根据自身当前已收到的响应消息,确定响应消息所对应IPSec隧道的状态;如果针对某些IPSec隧道应答方没有返回响应消息,则确定没有返回响应消息所对应的IPSec隧道不可用,结束当前查询IPSec隧道状态的处理流程。
当应答方针对分别各要查询的IPSec隧道向查询方返回IPSec隧道查询成功消息或不返回响应消息时,也可以设置查询定时器、查询周期以及查询次数进行重复查询,具体过程与实施例二中的重复查询相同,在此不再赘述。
在本发明中,当应答方查询IPSec SA三元组不成功时,有两种实现方式,一种是向查询方返回IPSec隧道查询失败消息,一种是不向查询方返回任何消息,这两种实现方式可以统称为应答方向查询方响应失败。
在本发明中,除了可以通过确定通信双方是否存在其中一个IPSec SA,确定通信双方是否存在两个相同的IPSec SA,进而确定通信双方建立的IPSec隧道是否可用;还可以同时确定通信双方是否存在两个相同的IPSecSA,确定通信双方建立的IPSec隧道是否可用。即在IPSec隧道查询消息中同时携带查询方的出方向SA三元组和入方向SA三元组,再由应答方同时检查两个SA的三元组是否存在,进而确定通信双方建立的IPSec隧道是否可用,这里其他的处理过程与实施例一和实施例二中所述的过程相同,在此不再详述。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。
Claims (10)
1、一种查询IPSec隧道状态的方法,其特征在于,该方法包括以下步骤:
A、查询方向应答方发送IPSec隧道查询消息,IPSec隧道查询消息中携带至少一条要查询的IPSec隧道的特征参数;
B、应答方获得IPSec隧道查询消息中携带的特征参数,查询自身是否存在相同的特征参数,并将查询结果返回给查询方;
C、查询方根据应答方返回的查询结果,当应答方存在相同的特征参数时,则确定所述相同的特征参数对应的IPSec隧道可用;当应答方不存在相同的特征参数时,则确定所述不存在相同的特征参数对应的IPSec隧道不可用。
2、根据权利要求1所述的方法,其特征在于,当要查询一条以上IPSec隧道时,步骤B中,所述将查询结果返回给查询方为:
通过一条消息将一条以上IPSec隧道的查询结果返回给查询方;或
针对每条IPSec隧道,分别向查询方返回一条查询结果。
3.根据权利要求1所述的方法,其特征在于,步骤B中,所述将查询结果返回给查询方为:
当应答方存在相同的特征参数时,则针对所述相同的特征参数向查询方返回IPSec隧道查询成功消息;
当应答方不存在相同的特征参数时,则针对所述不存在相同的特征参数向查询方响应失败。
4、根据权利要求3所述的方法,其特征在于,所述响应失败为:应答方向查询方返回IPSec隧道查询失败消息。
5、根据权利要求3所述的方法,其特征在于,进一步设置等待定时器及等待时长,当查询方发送IPSec隧道查询消息时,启动等待定时器;
步骤B中,所述响应失败为:当应答方不存在要查询IPSec隧道的特征参数时,不向查询方返回查询结果;
步骤C为:当等待定时器到达等待时长时,查询方判断是否收到了查询结果,如果收到了查询结果,则确定所述查询结果对应的IPSec隧道可用,否则,确定所述查询结果对应的IPSec隧道不可用。
6、根据权利要求1、3、4或5所述的方法,其特征在于,进一步设置查询定时器以及查询周期,步骤A中当查询方发送IPSec隧道查询消息时,启动查询定时器;
当查询定时器到达查询周期时,判断当前要查询IPSec隧道的状态是否已经确定,如果是,则查询定时器停止计时;否则,查询方针对没有确定状态的IPSec隧道发送IPSec隧道查询消息。
7、根据权利要求6所述的方法,其特征在于,进一步设置最大查询次数,对查询方发送的IPSec隧道查询消息进行计数,
在查询方针对没有确定状态的IPSec隧道发送IPSec隧道查询消息之前,进一步判断当前发送的IPSec隧道查询消息是否小于或等于最大查询次数,如果是,则执行所述发送IPSec隧道查询消息;否则,结束当前处理流程。
8、根据权利要求6所述的方法,其特征在于,在步骤C之前,进一步包括:
判断应答方返回的查询结果是否为当前查询周期内查询方发送查询消息的响应,如果是,则执行步骤C;否则,拒绝处理当前应答方返回的查询结果。
9、根据权利要求1所述的方法,其特征在于,当查询方需要向应答方发送数据或查询周期到达时,执行步骤A。
10、根据权利要求1所述的方法,其特征在于,所述特征参数为:
IPSec隧道出方向安全联盟的安全参数索引、目的IP地址、和安全协议;
或IPSec隧道入方向安全联盟的安全参数索引、目的IP地址、和安全协议;
或IPSec隧道出方向安全联盟的安全参数索引、目的IP地址、和安全协议,和入方向安全联盟的安全参数索引、目的IP地址、和安全协议。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100805699A CN100488204C (zh) | 2006-05-17 | 2006-05-17 | 一种查询IPSec隧道状态的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100805699A CN100488204C (zh) | 2006-05-17 | 2006-05-17 | 一种查询IPSec隧道状态的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1845549A true CN1845549A (zh) | 2006-10-11 |
CN100488204C CN100488204C (zh) | 2009-05-13 |
Family
ID=37064462
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100805699A Expired - Fee Related CN100488204C (zh) | 2006-05-17 | 2006-05-17 | 一种查询IPSec隧道状态的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100488204C (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101521602B (zh) * | 2008-02-29 | 2012-09-05 | 上海博达数据通信有限公司 | 利用IKE监测IPSec VPN中通信节点状态的实现方法 |
CN103716196A (zh) * | 2012-09-28 | 2014-04-09 | 杭州华三通信技术有限公司 | 一种网络设备及探测方法 |
CN106170949A (zh) * | 2014-12-30 | 2016-11-30 | 华为技术有限公司 | 失效对等体检测方法、IPsec对等体和网络设备 |
CN107682284A (zh) * | 2017-08-02 | 2018-02-09 | 华为技术有限公司 | 发送报文的方法和网络设备 |
CN111641545A (zh) * | 2020-05-15 | 2020-09-08 | 深信服科技股份有限公司 | 一种隧道探测方法及装置、设备、存储介质 |
CN112737965A (zh) * | 2020-12-31 | 2021-04-30 | 网络通信与安全紫金山实验室 | 解决并发访问网元受限问题的方法、系统及计算机可读存储介质 |
-
2006
- 2006-05-17 CN CNB2006100805699A patent/CN100488204C/zh not_active Expired - Fee Related
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101521602B (zh) * | 2008-02-29 | 2012-09-05 | 上海博达数据通信有限公司 | 利用IKE监测IPSec VPN中通信节点状态的实现方法 |
CN103716196A (zh) * | 2012-09-28 | 2014-04-09 | 杭州华三通信技术有限公司 | 一种网络设备及探测方法 |
CN103716196B (zh) * | 2012-09-28 | 2018-10-09 | 新华三技术有限公司 | 一种网络设备及探测方法 |
CN106170949A (zh) * | 2014-12-30 | 2016-11-30 | 华为技术有限公司 | 失效对等体检测方法、IPsec对等体和网络设备 |
CN107682284A (zh) * | 2017-08-02 | 2018-02-09 | 华为技术有限公司 | 发送报文的方法和网络设备 |
CN107682284B (zh) * | 2017-08-02 | 2021-06-01 | 华为技术有限公司 | 发送报文的方法和网络设备 |
US11277391B2 (en) | 2017-08-02 | 2022-03-15 | Huawei Technologies Co., Ltd. | Packet sending method and apparatus |
CN111641545A (zh) * | 2020-05-15 | 2020-09-08 | 深信服科技股份有限公司 | 一种隧道探测方法及装置、设备、存储介质 |
CN112737965A (zh) * | 2020-12-31 | 2021-04-30 | 网络通信与安全紫金山实验室 | 解决并发访问网元受限问题的方法、系统及计算机可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN100488204C (zh) | 2009-05-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108551446B (zh) | 防攻击的syn报文处理方法、装置、防火墙及存储介质 | |
CN102148810B (zh) | 安全关联存活检测方法、装置和系统 | |
CN1845549A (zh) | 一种查询IPSec隧道状态的方法 | |
CN1186906C (zh) | 无线局域网安全接入控制方法 | |
CN1251446C (zh) | 一种防御网络传输控制协议同步报文泛滥攻击的方法 | |
CN106685930B (zh) | 一种传输控制协议选项的处理方法及装置 | |
CN1655552A (zh) | 管理传输控制协议(tcp)连接 | |
CN104853001B (zh) | 一种arp报文的处理方法和设备 | |
CN1536847A (zh) | 鉴权分组有效负荷的方法 | |
CN1819560A (zh) | 多单元发送时的报文序列号检测方法及装置 | |
CN1838590A (zh) | 在会话起始协议信号过程提供因特网密钥交换的方法及系统 | |
WO2010048865A1 (zh) | 一种防止网络攻击的方法及装置 | |
CN1913457A (zh) | 对双向转发链路进行故障检测的方法 | |
CN101594359A (zh) | 防御传输控制协议同步洪泛攻击方法及传输控制协议代理 | |
CN101527729A (zh) | 一种ike可靠报文协商的方法、设备及系统 | |
CN101022458B (zh) | 会话的控制方法及控制装置 | |
US20100250941A1 (en) | Wapi unicast secret key negotiation method | |
US8898466B1 (en) | Secure block acknowledgement mechanism for use in communication networks | |
CN1271823C (zh) | 无线局域网中业务隧道的拆除方法 | |
CN101039312A (zh) | 防止通用鉴权框架中服务功能实体受攻击的方法及装置 | |
CN1881863A (zh) | 一种确定协商中的重传策略的设备和方法 | |
CN1852595A (zh) | 一种无线通信终端接入鉴权方法 | |
EP2211496A1 (en) | Key management method | |
WO2016106589A1 (zh) | 失效对等体检测方法、IPsec对等体和网络设备 | |
CN109600277B (zh) | 基于NAT设备的IPSec隧道保活方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |
|
CP03 | Change of name, title or address | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090513 Termination date: 20200517 |
|
CF01 | Termination of patent right due to non-payment of annual fee |