專利名稱：一種解決因特網密鑰協(xié)商協(xié)議中協(xié)商碰撞的方法
技術領域：
本發(fā)明涉及因特網密鑰協(xié)商協(xié)議(IKE)，具體涉及協(xié)議中的協(xié)商碰撞處理方法。
背景技術：
目前隨著Internet的發(fā)展，IP安全技術越來越重要，人們對基于IP通信的安全研究也更加深入。當前，Internet工程任務組(IETF)于1998年公布了因特網安全體系結構-IPSec規(guī)范，這更加速了這方面的研究和實施。
IPSec是由IETF的IPSec工作組提出的將安全機制引入TCP/IP網絡的一系列標準，包括安全協(xié)議(驗證頭AH和封裝安全凈荷ESP)、安全聯(lián)盟、密鑰管理和安全算法等，它定義了IP數(shù)據(jù)包格式和相關基礎結構，以便為網絡通信提供端對端、加強的身份驗證、完整性、抗重播和機密性服務等。使用IETF定義的因特網密鑰交換(IKE)協(xié)議，還提供按需要進行安全協(xié)商和自動密鑰管理服務。IPSec可保障主機之間、安全網關之間(如路由器或防火墻)或主機與安全網關之間的數(shù)據(jù)報的安全。IPSec和IKE是兩個獨立的協(xié)議，IPSec負責提供加密解密的處理過程，對于加密解密組件的選擇，通過IKE協(xié)商來完成。也就是IKE協(xié)商提供具體的加密解密的組件選擇，在此基礎上IPSec運用該組件再進行加密解密的處理。
IPSec/IKE作為一項重要的IP安全技術，已經被作為Ipv6的實現(xiàn)組件。在IKE協(xié)議中，RFC規(guī)定了基本的報文交互流程，但對于有些問題的實現(xiàn)和解決，并沒有給出詳細的方案，如碰撞問題。在IKE協(xié)商過程中，碰撞問題是不可忽略的，是隨機發(fā)生的。碰撞情況是指協(xié)商雙方在發(fā)送給對方一個協(xié)商請求的報文后，又收到對方一條協(xié)商請求報文。碰撞的情況是發(fā)生的條件如下在通信兩端的一方發(fā)起協(xié)商時，當本地發(fā)送的第一個協(xié)商包還沒到達對端的時候，對端發(fā)出了一個目的地為本地的一個協(xié)商包，即通信兩端同時發(fā)起協(xié)商，從發(fā)起方來看，發(fā)出一條協(xié)商請求報文后又收到一條對端的對方發(fā)出的協(xié)商請求報文，這時就出現(xiàn)了碰撞的情況。這時，如果雙方都進行響應，則會出現(xiàn)在同一對對端之間生成兩個第一階段的保護的情況(IKE SA)，造成協(xié)商資源的浪費，此外，IKE第一階段協(xié)商效率的降低，還會使后續(xù)協(xié)商在選擇使用第一階段保護上出現(xiàn)問題，可能導致最終的IKE協(xié)商失敗。
對于目前網絡上的大多數(shù)協(xié)議，尤其是TCP/IP協(xié)議族，由于協(xié)議本身不要求同一個時間段內只能有一方進行協(xié)商，所以對于這類協(xié)議不存在協(xié)商碰撞的問題。對于IKE這樣要求協(xié)商在一個時間段內只能有一方作為發(fā)起方進行協(xié)商的協(xié)議來說，就必須解決協(xié)商碰撞的問題。對于協(xié)商碰撞問題的解決目前尚未見到公開的解決方案。

發(fā)明內容
本發(fā)明的目的就是提出一種解決因特網密鑰協(xié)商協(xié)議中協(xié)商碰撞的方法。
一種解決因特網密鑰協(xié)商協(xié)議中協(xié)商碰撞的方法，包括下列步驟第一步、判斷是否發(fā)生協(xié)商碰撞，如果是則繼續(xù)，否則結束；第二步、發(fā)送端丟棄對端發(fā)送過來的第一條協(xié)商請求報文；第三步、發(fā)送端重發(fā)本地的第一條協(xié)商請求報文。
所述第三步中發(fā)送端既可以經過固定的時間間隔也經過隨機的時間間隔后重發(fā)本地的第一條協(xié)商請求報文，隨機時間間隔的計算可以采用以下方法T(1-M×2N-1)其中T為時間間隔，單位為秒；M為重發(fā)最小間隔，一般取2-5秒；N為重發(fā)次數(shù)，一般取3-5次。
本發(fā)明提出的方法簡單易行，通過使用本發(fā)明的方法可以有效的解決IP包在和不同的對端系統(tǒng)之間進行通信交互的過程中出現(xiàn)的碰撞問題，并且通過不斷增大的隨機時延可以減少再次碰撞的概率。


圖1是本發(fā)明提出方法的流程圖；圖2是對端重傳，本地先進行響應的情況示意圖；圖3是對端重傳，對端先進行響應的情況示意圖；圖4是對端不重傳，本地先重傳，再收到對端響應的情況示意圖；圖5是對端不重傳，本地先收到對端響應的情況示意圖；圖6是對端不處理碰撞的情況示意圖。
具體實施例方式
下面結合附圖進一步詳細說明本發(fā)明。
圖1是本發(fā)明提出方法的流程圖，如圖1所示，本發(fā)明提出的方法包括第一步、判斷是否發(fā)生協(xié)商碰撞，如果是則繼續(xù)，否則結束；當本地發(fā)送出第一條因特網密鑰協(xié)商協(xié)議協(xié)商報文以后，如果協(xié)商正常，沒有發(fā)生碰撞，本地將等待對端的響應報文，以進行進一步的協(xié)商。如果發(fā)生碰撞，本地在沒有收到對端響應報文的時候收到一個對端要求因特網密鑰協(xié)商協(xié)議協(xié)商的報文，此時，本地應先確認要求協(xié)商因特網密鑰協(xié)商協(xié)議的通信對端是自己請求協(xié)商的對端，這說明確實發(fā)生了碰撞。第二步、發(fā)送端丟棄對端發(fā)送過來的第一條協(xié)商請求報文；第三步、發(fā)送端重發(fā)本地的第一條協(xié)商請求報文。第三步中發(fā)送端既可以經過固定的時間間隔也經過隨機的時間間隔后重發(fā)本地的第一條協(xié)商請求報文，隨機時間間隔的計算可以采用以下方法T(1-M×2N-1)其中T為時間間隔，單位為秒；M為重發(fā)最小間隔，一般取2-5秒；N為重發(fā)次數(shù)，一般取3-5次。
對于IPSec/IKE的系統(tǒng)，碰撞的出現(xiàn)是隨機的。由于對端通信系統(tǒng)的不可知，所以本地采取的策略應全面考慮不同的對端系統(tǒng)，以使解決方案可以適用不同的通信對端，下面分別就本發(fā)明實施時，根據(jù)對端的不同處理方式所可能導致的幾種情形進行詳細說明。圖2-圖6說明了具體的各種情況。
如圖2-圖6所示，A表示本地系統(tǒng)，B表示對端系統(tǒng)；MSG1A表示A發(fā)出的第一條協(xié)商報文；MSG2A表示B對A的第一條協(xié)商報文的響應；MSG1B表示B發(fā)出的第一條協(xié)商報文；TA表示A沖突后的重傳時間間隔；TB表示B沖突后的重傳時間間隔；虛線箭頭表示準備發(fā)送的消息，實際上沒有發(fā)送。
當A重傳IKE協(xié)商報文的時候(按照本地策略)，如果B也重傳，則先收到對端重發(fā)消息的一方會作為響應方進行協(xié)商，進而進入響應方處理流程，相應的，另一方將作為發(fā)起方，兩端進行IKE協(xié)商。圖2是對端重傳，本地先進行響應的情況示意圖，如圖2所示，A先收到對端B的重發(fā)包MSG1B(B如果先收到A的重發(fā)報文，情況類似，見圖3)，A將作為響應方和對端B進行后續(xù)的IKE協(xié)商。如果A在重發(fā)上一條報文后，沒收到B響應，但收到B的重發(fā)報文，則A再一次進入沖突過程(同理，B也進入沖突)，再次重發(fā)，這時會選取隨機更長的時間進行重發(fā)，直到有一方在重發(fā)前先收到對方響應的報文或者重發(fā)的協(xié)商請求報文，如果到最后一直沖突，則達到重發(fā)次數(shù)限制而進入?yún)f(xié)商失敗流程，等待下次重新協(xié)商。
圖3是對端重傳，對端先進行響應的情況示意圖，如圖3所示，如果B進行重傳，當B先收到A的重傳消息，則會先進行響應，(對于B來講，在響應A協(xié)商請求MSG1A以后，即發(fā)送MSG2A后，再進行重發(fā)上一條協(xié)商請求報文MSG1B，是不會出現(xiàn)的，因為B在響應A協(xié)商請求后，狀態(tài)已經發(fā)生變化。)當A收到響應報文的時候，A發(fā)現(xiàn)是B的響應報文MSG2A，會取消重發(fā)任務，然后A進入發(fā)起方的流程，進行發(fā)起方處理，那么B將作為響應方和A進行協(xié)商。
如果B不重傳，直接進行響應，即B在發(fā)生碰撞的情況下所做的處理是僅對A的報文響應，而不進行重傳。那么，只要B響應，無論A重發(fā)的第一條協(xié)商報文MSG1A，是在B響應的報文MSG2A的前或者后到達，結果都是相同，即A在收到B的響應報文后都將處理B的響應，那么A進入發(fā)起方流程。由于A沒有響應B的第一條報文，可知B無法進行B作為發(fā)起方的處理流程，所以B只能作為響應方來進行協(xié)商，協(xié)商完成也只有一個第一階段，解決了碰撞的問題。對于A來講，可能是重發(fā)了第一條報文，也可能沒有重新發(fā)送，下面分這兩種情況進行說明。圖4是對端不重傳，本地先重傳，再收到對端響應的情況示意圖，如圖4所示，A先重傳，之后收到B的響應報文。A在重發(fā)之后收到了B的響應報文，則進入發(fā)起方流程，B作為響應方進入響應方協(xié)商流程。圖5是對端不重傳，本地先收到對端響應的情況示意圖，如圖5所示，由于A在重傳之前收到了B的響應報文，所以進入發(fā)起方協(xié)商流程，不會進行重傳第一條協(xié)商請求報文。
如果B沒有響應，即B對于A重發(fā)的報文不進行響應，如圖6所示，那么A會重傳報文MSG1A，直到重傳次數(shù)到達最大限度，協(xié)商失敗。如果出現(xiàn)這種情況，協(xié)商失敗是不可避免的，只有等再次協(xié)商。但從整個數(shù)據(jù)報文處理流程看，這樣處理是合理的。
權利要求
1.一種解決因特網密鑰協(xié)商協(xié)議中協(xié)商碰撞的方法，其特征在于包括下列步驟第一步、判斷是否發(fā)生協(xié)商碰撞，如果是則繼續(xù)，否則結束；第二步、發(fā)送端丟棄對端發(fā)送過來的第一條協(xié)商請求報文；第三步、發(fā)送端重發(fā)本地的第一條協(xié)商報文。
2.根據(jù)權利要求1所述的方法，其特征在于所述第三步中發(fā)送端經過固定的時間間隔后重發(fā)本地的第一條協(xié)商報文。
3.根據(jù)權利要求1所述的方法，其特征在于所述第三步中發(fā)送端經過隨機的時間間隔后重發(fā)本地的第一條協(xié)商報文。
4.根據(jù)權利要求3所述的方法，其特征在于所述隨機時間間隔的計算方法為T(1-M×2N-1)其中T為時間間隔，單位為秒，M為重發(fā)最小間隔，N為重發(fā)次數(shù)。
5.根據(jù)權利要求4所述的方法，其特征在于所述重發(fā)最小間隔取2-5秒；重發(fā)次數(shù)N取3-5次。
全文摘要
本發(fā)明公開了一種解決因特網密鑰協(xié)商協(xié)議中協(xié)商碰撞的方法，包括下列步驟第一步、判斷是否發(fā)生協(xié)商碰撞，如果是則繼續(xù)，否則結束；第二步、發(fā)送端丟棄對端發(fā)送過來的第一條協(xié)商請求報文；第三步、發(fā)送端重發(fā)本地的第一條協(xié)商請求報文。本發(fā)明提出的方法簡單易行，通過使用本發(fā)明的方法可以有效的解決IP包在和不同的對端系統(tǒng)之間進行通信交互的過程中出現(xiàn)的碰撞問題，并且通過不斷增大的隨機時延可以減少再次碰撞的概率。
文檔編號H04L29/06GK1777093SQ20041009088
公開日2006年5月24日 申請日期2004年11月16日 優(yōu)先權日2004年11月16日
發(fā)明者耿航, 彭志威, 蘆東昕, 陳海彬, 趙潔 申請人:中興通訊股份有限公司