專利名稱：一種ike協(xié)商異常的處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，具體涉及一種IKE協(xié)商異常的處理方法。
背景技術(shù)：
因特網(wǎng)協(xié)議安全(IPSec)是一種由IETF (Internet Engineering Task Force)設計的端到端的確保因特網(wǎng)IP層通信安全的機制，包括網(wǎng)絡認證協(xié)議(AH)、封裝安全載荷協(xié)議(ESP)、密鑰交換協(xié)議(IKE)和用于網(wǎng)絡認證及加密的一些算法等。其中，因特網(wǎng)密鑰交換(IKE)的過程分為第一階段協(xié)商和第二階段協(xié)商兩部分，在協(xié)商中，網(wǎng)絡兩端設備需要進行報文的交互，這些報文用于交換和確認配置、認證、密鑰信息等。在實際交換過程中，當兩端設備配置信息不一致或配置信息錯誤的情況下，會出現(xiàn)下面兩個問題1)一端不斷主動發(fā)起報文協(xié)商，另一端不斷進行錯誤回復，造成網(wǎng)絡上短時間 內(nèi)出現(xiàn)大量的協(xié)商報文，而實際上這些報文都是不必要的；2) IPSec隧道建立通常需要兩端設備進行6次以上的報文交互，有可能最后一個報文出現(xiàn)了錯誤，由于兩端協(xié)商需要創(chuàng)建動態(tài)IPSec隧道狀態(tài)機，會占用系統(tǒng)的內(nèi)存資源和最大IPSec隧道數(shù)資源。

發(fā)明內(nèi)容
(一)要解決的技術(shù)問題本發(fā)明主要解決當IKE協(xié)商異常時，協(xié)商報文依然不斷發(fā)送，過多占用網(wǎng)絡資源和系統(tǒng)內(nèi)存資源的技術(shù)問題。(二)技術(shù)方案本發(fā)明提供了一種IKE協(xié)商異常的處理方法，包括以下步驟A、發(fā)送端發(fā)起協(xié)商報文；B、如果出現(xiàn)異常，則接收端回應發(fā)送端異常信息報文，并將接收端在第一設定時間內(nèi)標記為未激活狀態(tài)；C、所述發(fā)送端接收到上述異常信息報文后，將發(fā)送端在第二設定時間內(nèi)標記為未激活狀態(tài)。其中，所述步驟A中的協(xié)商報文攜帶配置信息，所述配置信息包括加密密鑰和協(xié)商策略。進一步的，所述異常為配置信息錯誤或發(fā)送端和接收端的配置信息不匹配。進一步的，在步驟B之后，還包括以下步驟接收端在所述第一設定時間后，恢復到激活狀態(tài)。進一步的，在步驟C之后，還包括以下步驟發(fā)送端在所述第二設定時間后，恢復到激活狀態(tài)?？蛇x的，步驟B中，所述第一設定時間為I分鐘?？蛇x的，步驟C中，所述第二設定時間為I分鐘。(三)有益效果
本發(fā)明提供了一種IKE協(xié)商異常的處理方法，當IKE協(xié)商異常時，該方法能夠阻止協(xié)商報文不斷地發(fā)送，避免過多占用網(wǎng)絡資源和系統(tǒng)內(nèi)存資源。


圖I是本發(fā)明方法的流程圖；圖2是本發(fā)明實施例的流程圖。
具體實施例方式下面結(jié)合附圖和實施例，對本發(fā)明的具體實施方式
作進一步詳細描述。以下實施例用于說明本發(fā)明，但不用來限制本發(fā)明的范圍。
圖I是本發(fā)明方法的流程圖，包括以下步驟A、發(fā)送端發(fā)起協(xié)商報文；B、如果出現(xiàn)異常，則接收端回應發(fā)送端異常信息報文，并將接收端在第一設定時間內(nèi)標記為未激活狀態(tài)；C、所述發(fā)送端接收到上述異常信息報文后，將發(fā)送端在第二設定時間內(nèi)標記為未激活狀態(tài)。其中，所述步驟A中的協(xié)商報文攜帶配置信息，所述配置信息包括加密密鑰和協(xié)商策略。進一步的，所述異常為配置信息錯誤或發(fā)送端和接收端的配置信息不匹配。進一步的，在步驟B之后，還包括以下步驟接收端在所述第一設定時間后，恢復到激活狀態(tài)。進一步的，在步驟C之后，還包括以下步驟發(fā)送端在所述第二設定時間后，恢復到激活狀態(tài)?？蛇x的，步驟B中，所述第一設定時間為I分鐘?？蛇x的，步驟C中，所述第二設定時間為I分鐘。以使用IPSec隧道配置的網(wǎng)絡系統(tǒng)為例，本發(fā)明方法的具體實施步驟如圖2所示步驟SI，兩個網(wǎng)絡設備進行IPSec隧道配置。步驟S2，當以流量觸發(fā)建立IPSec隧道或者手動觸發(fā)建立IPSec隧道時，其中一個網(wǎng)絡設備作為發(fā)送端發(fā)起IKE協(xié)商報文進行協(xié)商。步驟S3，另一個網(wǎng)絡設備作為接收端對此協(xié)商報文中攜帶的配置信息進行判斷，如果配置信息錯誤(此處所說的配置信息包括加密密鑰和協(xié)商策略)，則接收端回應發(fā)送端異常信息報文，并將接收端的IPSec隧道設備標記為未激活狀態(tài)I分鐘(此時間可以手動設置)，I分鐘后隧道狀態(tài)會恢復，或者可以人為手動激活。接收端設備在未激活狀態(tài)下接收到的協(xié)商報文將直接被丟棄，不進行隧道的初次建立和配置信息判斷等過程。步驟S4，發(fā)送端接收到來自接收端的異常信息報文后，也將發(fā)送端的IPSec隧道設備標記為未激活狀態(tài)I分鐘(此時間可手動設置)，這I分鐘內(nèi)不發(fā)起主動協(xié)商報文，I分鐘后隧道狀態(tài)會恢復，或者可以人為手動激活。
以上所述僅是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明技術(shù)原理的前提下，還可以做出若干改進和替換，這些改進和 替換也應視為本發(fā)明的保護范圍。
權(quán)利要求
1.ー種IKE協(xié)商異常的處理方法，其特征在于，包括以下步驟 A、發(fā)送端發(fā)起協(xié)商報文； B、如果出現(xiàn)異常，則接收端回應發(fā)送端異常信息報文，并將接收端在第一設定時間內(nèi)標記為未激活狀態(tài)； C、所述發(fā)送端接收到上述異常信息報文后，將發(fā)送端在第二設定時間內(nèi)標記為未激活狀態(tài)。
2.如權(quán)利要求I所述的處理方法，其特征在于，所述步驟A中的協(xié)商報文攜帯配置信息，所述配置信息包括加密密鑰和協(xié)商策略。
3.如權(quán)利要求2所述的處理方法，其特征在干，所述異常為配置信息錯誤或發(fā)送端和接收端的配置信息不匹配。
4.如權(quán)利要求I所述的處理方法，其特征在于，在步驟B之后，進ー步包括以下步驟 接收端在所述第一設定時間后，恢復到激活狀態(tài)。
5.如權(quán)利要求I所述的處理方法，其特征在于，在步驟C之后，進ー步包括以下步驟 發(fā)送端在所述第二設定時間后，恢復到激活狀態(tài)。
6.如權(quán)利要求I所述的處理方法，其特征在于，步驟B中，所述第一設定時間為I分鐘。
7.如權(quán)利要求I所述的處理方法，其特征在于，步驟C中，所述第二設定時間為I分鐘。
全文摘要
本發(fā)明公開了一種IKE協(xié)商異常的處理方法，具體包括發(fā)送端發(fā)起協(xié)商報文；如果出現(xiàn)異常，則接收端回應發(fā)送端異常信息報文，并將接收端在第一設定時間內(nèi)標記為未激活狀態(tài)；所述發(fā)送端接收到上述異常信息報文后，將發(fā)送端在第二設定時間內(nèi)標記為未激活狀態(tài)。當IKE協(xié)商異常時，該方法能夠阻止協(xié)商報文不斷地發(fā)送，避免過多占用網(wǎng)絡資源和系統(tǒng)內(nèi)存資源。
文檔編號H04L29/06GK102868522SQ201210336428
公開日2013年1月9日 申請日期2012年9月12日 優(yōu)先權(quán)日2012年9月12日
發(fā)明者陳海濱 申請人:漢柏科技有限公司