[TOC]html
client / initiator: IKE鏈接的首先發起方。 server / responder: IKE鏈接首先發起方的對方,即響應方。算法
IKE SA: 用於對ISAKMP數據包進行加密的SA。 CHILD SA / IPsec SA: 用於對傳輸數據(用戶數據)進行加密的SA,如加密ESP協議數據。 SA: 包括,IKE SA和CHILD SA。安全
reauth是指從新進行身份認證過程。rekey包含兩個過程。IKESA rekey指協商IKE SA。 CHILD SA rekey是指從新協商CHILD SA。IKEv1與IKEv2在概念上一樣適用。可是須要特別說明的是,IKEv1中沒有實現 IKESA rekey機制。 詳見,官網wiki中的一篇文檔ExpiryRekey講到 IKEv1不支持ikesa的rekey,須要經過reauth實現ikesa rekey。併發
reauth是指從新進行身份認證。基於安全的考慮,由於證書會過時,會被吊銷。Server須要一個機制用來發現 client的身份已經失效了。 reauth過程有兩個方式:dom
這兩個方式,是能夠配置的。tcp
在IKEv2中,整個reauth過程是這樣的。加密
若是做爲client一方的ipsec實現不支持AUTH_LIFETIME類型的消息,將不會對server進行回覆,這個時候 server在到期以後,會主動斷掉鏈接。client須要手工的重新創建新的鏈接。 若是做爲server的一方ipsec實現不支持AUTH_LIFETIME類型的消息,那麼他將不會發送該消息。這樣的鏈接 也將永遠不會進行reauth[2]。spa
基於以上,咱們能夠推論出,IKEv2的鏈接,兩端的客戶端其實都會配置life time。可是,只有server端的 life time會生效。之因此說是推論出的,由於沒有實踐配置過,進行驗證。code
在IKEv1中,reauth過程簡述以下:server
根據內核代碼中的實現,咱們在這裏引入兩個名詞,soft life time和hard life time。 soft是指server通知給client的最後期限。可是實際上,在soft時間到達後,server並不會真的斷掉鏈接, 而是會等待hard時間到達後再斷掉。 strongswan中,soft與hard的賦值與計算規則,以下:
rekey_time = 4h = 240m over_time = 10% * rekey_time = 24m rand_time = over_time = 24m hard = rekey_time + over_time = 264m soft = rekey_time - random(0, rand_time) = [216, 240]m
rekey是指從新協商child sa。 在這裏,一樣有soft life time與hard life time兩個值。
IKEv1的rekey過程在整個原理上與reauth過程十分類似,詳細步驟以下:
IKEv2的rekey過程是由消息類型爲CREATE_CHILD_AS的消息完成的。在新建好新的child sa以後。發起端 會發起刪除舊鏈接的DELETE消息,從而完成整個rekey過程。 經過抓包分析,發現child sa的life time沒有在整個ipsec的鏈接生命週期中交互過,也就是說沒有發生過通訊。 同時發現,child sa協商的任何一方都有發起rekey流程的現象。從而推測ipsec程序保持着各自的child sa lift time設置,在各自的life time到期以後,都會自行發起rekey。 TODO:以上推測應該到rfc裏確認一下。 接下來,是詳細的ikev2 rekey過程: 0. IKEv2協商成功以後。
charon.delete_rekeyed_delay
這裏須要提到的是,在首次協商階段,child sa並無協商DH group,直到child sa被rekey以後,才從新協商 了新的DH group。這一個特性會影響到PFS(完美前向加密)。
配置方面rekey與reauth原理相同,咱們仍然引用soft和hard兩個概念。計算規則以下:
rekey_time = 1h = 60m life_time = 110% * rekey_time = 66m rand_time = life_time - rekey_time = 6m hard = life_time = 66m soft = rekey_time - random(0, rand_time) = [54, 60]m
這裏至於IKEv2有關。IKEv1裏沒有這個概念,或者說沒有實現這個概念。 基於以前的知識。在一個實驗的基礎上,講述這個概念。配置了一個300秒的IKE rekey時間。咱們使用tcpdump觀察數據包。 300秒後,rekey過程經過CREATE_CHILD_SA message發起,如圖: 對比CHILD SA的rekey過程一樣使用CREATE_CHILD_SA消息來完成。二者的區別在於
CHILD SA的rekey message中包含有 REKEY_SA payload。IKE SA的rekey message則沒有。
在OS中查看rekey和reauth狀態的方法,使用swanctl命令。 在命令輸出中能分別看見ike sa與child sa的編號。每一次協商以後,編號會增長一。同時看能看見rekey 和expire的時間。 在正在發生rekey或reauth的時候,執行這個命令。若是strongswan的行爲是先重建後刪除的話,還將看見 同時存在的兩個SA出如今打印信息內。 示例以下:
[root@T9 sbin]# ./swanctl --list-sas net-psk: #1, ESTABLISHED, IKEv1, 906152928fa4269f_i* 544866824e8129e1_r local 't9.tong.local' @ 192.168.7.9[500] remote 't129.tong.local' @ 192.168.7.129[500] AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519 established 361s ago, reauth in 216s net-psk: #5, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA2_256_128 installed 88s ago, rekeying in 3s, expires in 22s in caf1e8e4, 0 bytes, 0 packets out cf137fb2, 0 bytes, 0 packets local 10.9.0.0/16 remote 10.129.0.0/16 net-psk: #6, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA2_256_128 installed 88s ago, rekeying in 10s, expires in 22s in c37872e9, 0 bytes, 0 packets out c0c1138a, 0 bytes, 0 packets local 10.9.0.0/16 remote 10.129.0.0/16 [root@T9 sbin]#
上圖的命令打印中,見不到ike sa的rekey time,ikev2的打印中能夠見到。