CN1777093B - 一种解决因特网密钥协商协议中协商碰撞的方法 - Google Patents
一种解决因特网密钥协商协议中协商碰撞的方法 Download PDFInfo
- Publication number
- CN1777093B CN1777093B CN 200410090887 CN200410090887A CN1777093B CN 1777093 B CN1777093 B CN 1777093B CN 200410090887 CN200410090887 CN 200410090887 CN 200410090887 A CN200410090887 A CN 200410090887A CN 1777093 B CN1777093 B CN 1777093B
- Authority
- CN
- China
- Prior art keywords
- opposite end
- message
- key agreement
- agreement protocol
- internet key
- 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.)
- Active
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
本发明公开了一种解决因特网密钥协商协议中协商碰撞的方法,包括下列步骤:第一步、判断是否发生协商碰撞,如果是则继续,否则结束;第二步、发送端丢弃对端发送过来的第一条协商请求报文;第三步、发送端重发本地的第一条协商请求报文。本发明提出的方法简单易行,通过使用本发明的方法可以有效的解决IP包在和不同的对端系统之间进行通信交互的过程中出现的碰撞问题,并且通过不断增大的随机时延可以减少再次碰撞的概率。
Description
技术领域
本发明涉及因特网密钥协商协议(IKE),具体涉及协议中的协商碰撞处理方法。
背景技术
目前随着Internet的发展,IP安全技术越来越重要,人们对基于IP通信的安全研究也更加深入。当前,Internet工程任务组(IETF)于1998年公布了因特网安全体系结构-IPSec规范,这更加速了这方面的研究和实施。
IPSec是由IETF的IPSec工作组提出的将安全机制引入TCP/IP网络的一系列标准,包括安全协议(验证头AH和封装安全净荷ESP)、安全联盟、密钥管理和安全算法等,它定义了IP数据包格式和相关基础结构,以便为网络通信提供端对端、加强的身份验证、完整性、抗重播和机密性服务等。使用IETF定义的因特网密钥交换(IKE)协议,还提供按需要进行安全协商和自动密钥管理服务。IPSec可保障主机之间、安全网关之间(如路由器或防火墙)或主机与安全网关之间的数据报的安全。IPSec和IKE是两个独立的协议,IPSec负责提供加密解密的处理过程,对于加密解密组件的选择,通过IKE协商来完成。也就是IKE协商提供具体的加密解密的组件选择,在此基础上IPSec运用该组件再进行加密解密的处理。
IPSec/IKE作为一项重要的IP安全技术,已经被作为Ipv6的实现组件。在IKE协议中,RFC规定了基本的报文交互流程,但对于有些问题的实现和解决,并没有给出详细的方案,如碰撞问题。在IKE协商过程中,碰撞问题是不可忽略的,是随机发生的。碰撞情况是指协商双方在发送给对方一个协商请求的报文后,又收到对方一条协商请求报文。碰撞的情况是发生的条件如下:在通信两端的一方发起协商时,当本地发送的第一个协商包还没到达对端的时候,对端发出了一个目的地为本地的一个协商包,即通信两端同时发起协商,从发起方来看,发出一条协商请求报文后又收到一条对端的对方发出的协商请求报文,这时就出现了碰撞的情况。这时,如果双方都进行响应,则会出现在同一对对端之间生成两个第一阶段的保护的情况(IKE SA),造成协商资源的浪费,此外,IKE第一阶段协商效率的降低,还会使后续协商在选择使用第一阶段保护上出现问题,可能导致最终的IK协商失败。
对于目前网络上的大多数协议,尤其是TCP/IP协议族,由于协议本身不要求同一个时间段内只能有一方进行协商,所以对于这类协议不存在协商碰撞的问题。对于IKE这样要求协商在一个时间段内只能有一方作为发起方进行协商的协议来说,就必须解决协商碰撞的问题。对于协商碰撞问题的解决目前尚未见到公开的解决方案。
发明内容
本发明的目的就是提出一种解决因特网密钥协商协议中协商碰撞的方法。
一种解决因特网密钥协商协议中协商碰撞的方法,包括下列步骤:
第一步、判断是否发生协商碰撞,如果是则继续,否则结束;
第二步、发送端丢弃对端发送过来的第一条协商请求报文;
第三步、发送端重发本地的第一条协商请求报文。
所述第三步中发送端既可以经过固定的时间间隔也经过随机的时间间隔后重发本地的第一条协商请求报文,随机时间间隔的计算可以采用以下方法:
其中:T为时间间隔,单位为秒;M为重发最小间隔,一般取2-5秒;N为重发次数,一般取3-5次。
本发明提出的方法简单易行,通过使用本发明的方法可以有效的解决IP包在和不同的对端系统之间进行通信交互的过程中出现的碰撞问题,并且通过不断增大的随机时延可以减少再次碰撞的概率。
附图说明
图1是本发明提出方法的流程图;
图2是对端重传,本地先进行响应的情况示意图;
图3是对端重传,对端先进行响应的情况示意图;
图4是对端不重传,本地先重传,再收到对端响应的情况示意图;
图5是对端不重传,本地先收到对端响应的情况示意图;
图6是对端不处理碰撞的情况示意图。
具体实施方式
下面结合附图进一步详细说明本发明。
图1是本发明提出方法的流程图,如图1所示,本发明提出的方法包括:第一步、判断是否发生协商碰撞,如果是则继续,否则结束;当本地发送出第一条因特网密钥协商协议协商报文以后,如果协商正常,没有发生碰撞,本地将等待对端的响应报文,以进行进一步的协商。如果发生碰撞,本地在没有收到对端响应报文的时候收到一个对端要求因特网密钥协商协议协商的报文,此时,本地应先确认要求协商因特网密钥协商协议的通信对端是自己请求协商的对端,这说明确实发生了碰撞。第二步、发送端丢弃对端发送过来的第一条协商请求报文;第三步、发送端重发本地的第一条协商请求报文。第三步中发送端既可以经过固定的时间间隔也经过随机的时间间隔后重发本地的第一条协商请求报文,随机时间间隔的计算可以采用以下方法:
其中:T为时间间隔,单位为秒;M为重发最小间隔,一般取2-5秒;N为重发次数,一般取3-5次。
对于IPSec/IKE的系统,碰撞的出现是随机的。由于对端通信系统的不可知,所以本地采取的策略应全面考虑不同的对端系统,以使解决方案可以适用不同的通信对端,下面分别就本发明实施时,根据对端的不同处理方式所可能导致的几种情形进行详细说明。图2-图6说明了具体的各种情况。
如图2-图6所示,A表示本地系统,B表示对端系统;MSG1A表示A发出的第一条协商报文;MSG2A表示B对A的第一条协商报文的响应;MSG1B表示B发出的第一条协商报文;TA表示A冲突后的重传时间间隔;TB表示B冲突后的重传时间间隔;虚线箭头表示准备发送的消息,实际上没有发送。
当A重传IKE协商报文的时候(按照本地策略),如果B也重传,则先收到对端重发消息的一方会作为响应方进行协商,进而进入响应方处理流程,相应的,另一方将作为发起方,两端进行IKE协商。图2是对端重传,本地先进行响应的情况示意图,如图2所示,A先收到对端B的重发包MSG1B(B如果先收到A的重发报文,情况类似,见图3),A将作为响应方和对端B进行后续的IKE协商。如果A在重发上一条报文后,没收到B响应,但收到B的重发报文,则A再一次进入冲突过程(同理,B也进入冲突),再次重发,这时会选取随机更长的时间进行重发,直到有一方在重发前先收到对方响应的报文或者重发的协商请求报文,如果到最后一直冲突,则达到重发次数限制而进入协商失败流程,等待下次重新协商。
图3是对端重传,对端先进行响应的情况示意图,如图3所示,如果B进行重传,当B先收到A的重传消息,则会先进行响应,(对于B来讲,在响应A协商请求MSG1A以后,即发送MSG2A后,再进行重发上一条协商请求报文MSG1B,是不会出现的,因为B在响应A协商请求后,状态已经发生变化。)当A收到响应报文的时候,A发现是B的响应报文MSG2A,会取消重发任务,然后A进入发起方的流程,进行发起方处理,那么B将作为响应方和A进行协商。
如果B不重传,直接进行响应,即B在发生碰撞的情况下所做的处理是仅对A的报文响应,而不进行重传。那么,只要B响应,无论A重发的第一条协商报文MSG1A,是在B响应的报文MSG2A的前或者后到达,结果都是相同,即A在收到B的响应报文后都将处理B的响应,那么A进入发起方流程。由于A没有响应B的第一条报文,可知B无法进行B作为发起方的处理流程,所以B只能作为响应方来进行协商,协商完成也只有一个第一阶段,解决了碰撞的问题。对于A来讲,可能是重发了第一条报文,也可能没有重新发送,下面分这两种情况进行说明。图4是对端不重传,本地先重传,再收到对端响应的情况示意图,如图4所示,A先重传,之后收到B的响应报文。A在重发之后收到了B的响应报文,则进入发起方流程,B作为响应方进入响应方协商流程。图5是对端不重传,本地先收到对端响应的情况示意图,如图5所示,由于A在重传之前收到了B的响应报文,所以进入发起方协商流程,不会进行重传第一条协商请求报文。
如果B没有响应,即B对于A重发的报文不进行响应,如图6所示,那么A会重传报文MSG1A,直到重传次数到达最大限度,协商失败。如果出现这种情况,协商失败是不可避免的,只有等再次协商。但从整个数据报文处理流程看,这样处理是合理的。
Claims (5)
1.一种解决因特网密钥协商协议中协商碰撞的方法,其特征在于包括下列步骤:
第一步、当本地发送出第一条因特网密钥协商协议协商报文以后,如果本地在没有收到对端响应报文的时候收到一个对端要求因特网密钥协商协议协商的报文,本地应先确认要求协商因特网密钥协商协议的通信对端是自己请求协商的对端,如果确认是自己请求协商的对端则确定发生了协商碰撞,如果发生协商碰撞则继续,否则结束;
第二步、发送端丢弃对端发送过来的第一条因特网密钥协商协议协商请求报文;
第三步、发送端重发本地的第一条因特网密钥协商协议协商报文。
2.根据权利要求1所述的方法,其特征在于所述第三步中发送端经过固定的时间间隔后重发本地的第一条因特网密钥协商协议协商报文。
3.根据权利要求1所述的方法,其特征在于所述第三步中发送端经过随机的时间间隔后重发本地的第一条因特网密钥协商协议协商报文。
4.根据权利要求3所述的方法,其特征在于所述随机时间间隔的计算方法为:
其中:T为时间间隔,单位为秒,M为重发最小间隔,N为重发次数。
5.根据权利要求4所述的方法,其特征在于所述重发最小间隔取2-5秒;重发次数N取3-5次。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200410090887 CN1777093B (zh) | 2004-11-16 | 2004-11-16 | 一种解决因特网密钥协商协议中协商碰撞的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200410090887 CN1777093B (zh) | 2004-11-16 | 2004-11-16 | 一种解决因特网密钥协商协议中协商碰撞的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1777093A CN1777093A (zh) | 2006-05-24 |
CN1777093B true CN1777093B (zh) | 2010-04-14 |
Family
ID=36766423
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200410090887 Active CN1777093B (zh) | 2004-11-16 | 2004-11-16 | 一种解决因特网密钥协商协议中协商碰撞的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1777093B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1905562B (zh) * | 2006-08-18 | 2010-07-21 | 杭州华三通信技术有限公司 | 一种确定边缘设备串口需配置的链路协议的方法 |
CN104410610B (zh) * | 2014-11-13 | 2018-01-09 | 新华三技术有限公司 | 一种基于IKEv2的初始协商方法及装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1244324A (zh) * | 1997-01-08 | 2000-02-09 | 夸尔柯姆股份有限公司 | 半双工通信系统中的碰撞避免 |
CN1350382A (zh) * | 2001-11-29 | 2002-05-22 | 东南大学 | 基于pki的vpn密钥交换的实现方法 |
-
2004
- 2004-11-16 CN CN 200410090887 patent/CN1777093B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1244324A (zh) * | 1997-01-08 | 2000-02-09 | 夸尔柯姆股份有限公司 | 半双工通信系统中的碰撞避免 |
CN1350382A (zh) * | 2001-11-29 | 2002-05-22 | 东南大学 | 基于pki的vpn密钥交换的实现方法 |
Non-Patent Citations (3)
Title |
---|
刘晓明,宋铁成,沈连丰.基于CSMA/CD的教学实验的设计与实现.电气电子教学学报26 4.2004,26(4),28-32. * |
杨威,苏锦海,张永福.基于IKE的IPSec参数协商过程的研究.计算机工程29 3.2003,29(3),73-75. |
杨威,苏锦海,张永福.基于IKE的IPSec参数协商过程的研究.计算机工程29 3.2003,29(3),73-75. * |
Also Published As
Publication number | Publication date |
---|---|
CN1777093A (zh) | 2006-05-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Loughney et al. | Context transfer protocol (CXTP) | |
Lau et al. | Layer two tunneling protocol-version 3 (L2TPv3) | |
Allman et al. | Ongoing TCP research related to satellites | |
US8285990B2 (en) | Method and system for authentication confirmation using extensible authentication protocol | |
EP2266224B1 (en) | Method of transmitting rlc data | |
US7434258B2 (en) | Method and communication system for controlling security association lifetime | |
CN103731407B (zh) | Ike报文协商的方法及系统 | |
CN107959553B (zh) | 提升蓝牙网络入网速度的方法 | |
US9088416B2 (en) | Method for securely associating data with HTTP and HTTPS sessions | |
US20050268331A1 (en) | Extension to the firewall configuration protocols and features | |
CN103179614B (zh) | 向上层传送pdcp数据单元的方法 | |
CN100512086C (zh) | 一种确定协商中的重传策略的设备和方法 | |
CN101296223A (zh) | 一种实现防火墙芯片参与syn代理的方法 | |
Ohta | Performance comparisons of transport protocols for session initiation protocol signaling | |
CN1777093B (zh) | 一种解决因特网密钥协商协议中协商碰撞的方法 | |
EP1635537A1 (en) | Cookie-based mechanism providing authentication of layer-2 frames | |
US7936773B2 (en) | Communication channel establishment method and system | |
CA2632159A1 (en) | Method for securely associating data with http and https sessions | |
JP2002330168A (ja) | 通信システムにおける再転送タイムアウト時間の設定方法 | |
EP3984191A1 (en) | Key distribution for hop by hop security in iab networks | |
Sallantin et al. | An end‐to‐end alternative to TCP PEPs: Initial Spreading, a TCP fast start‐up mechanism | |
CN105846968A (zh) | 一种实现重传的方法和装置、发送设备和接收设备 | |
Camarillo et al. | Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) | |
Thanthry et al. | A novel mechanism for improving performance and security of tcp flows over satellite links | |
Giuliano et al. | Security implementation in heterogeneous networks with long delay channel |
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 |