[ipsec][strongswan] strongswan源碼分析-- (二)rekey/reauth機制分析

strongwan sa分析(二)


[TOC]html

名詞約定

client / initiator: IKE鏈接的首先發起方。 server / responder: IKE鏈接首先發起方的對方,即響應方。算法

IKE SA: 用於對ISAKMP數據包進行加密的SA。 CHILD SA / IPsec SA: 用於對傳輸數據(用戶數據)進行加密的SA,如加密ESP協議數據。 SA: 包括,IKE SA和CHILD SA。安全

rekey/reauth 機制分析

1 概述

reauth是指從新進行身份認證過程。rekey包含兩個過程。IKESA rekey指協商IKE SA。 CHILD SA rekey是指從新協商CHILD SA。IKEv1與IKEv2在概念上一樣適用。可是須要特別說明的是,IKEv1中沒有實現 IKESA rekey機制。 詳見,官網wiki中的一篇文檔ExpiryRekey講到 IKEv1不支持ikesa的rekey,須要經過reauth實現ikesa rekey。併發

2 reauth

reauth是指從新進行身份認證。基於安全的考慮,由於證書會過時,會被吊銷。Server須要一個機制用來發現 client的身份已經失效了。 reauth過程有兩個方式:dom

  • break-before-make 先斷掉舊的IKE鏈接,再從新協商新的IKE鏈接。
  • make-before-break 先協商新的IKE鏈接,斷掉舊的IKE鏈接。

這兩個方式,是能夠配置的。tcp

2.1 IKEv2

在IKEv2中,整個reauth過程是這樣的。加密

  1. 由Server發送life time給client。 life time由類型爲AUTH_LIFETIME的payload進行傳輸。在一次IKE鏈接過程當中,AUTH_LIFETIME類型的payload應該出如今如下兩個地方中的一個[1]
    • 最後一個IKE_AUTH包中。
    • INFORMATIONAL request包中。 這兩個包,都是由server發送的。 以下圖,在這個例子中配置了 reauthtime爲600秒。 ikev2_auth_lifetime_pcap.png
  2. client發起重連 client須要在server發送過去的 life time以前發起reauth機制,不然server將在life time到達時斷開連接。 以下圖,咱們見到在490秒後,client主動斷掉了IKE鏈接,併發起了新的鏈接。 ikev2_reauth_pcap.png

若是做爲client一方的ipsec實現不支持AUTH_LIFETIME類型的消息,將不會對server進行回覆,這個時候 server在到期以後,會主動斷掉鏈接。client須要手工的重新創建新的鏈接。 若是做爲server的一方ipsec實現不支持AUTH_LIFETIME類型的消息,那麼他將不會發送該消息。這樣的鏈接 也將永遠不會進行reauth[2]spa

基於以上,咱們能夠推論出,IKEv2的鏈接,兩端的客戶端其實都會配置life time。可是,只有server端的 life time會生效。之因此說是推論出的,由於沒有實踐配置過,進行驗證。code

2.2 IKEv1

在IKEv1中,reauth過程簡述以下:server

  1. client在算法協商的proposal裏,包含了life time信息傳輸給server,進行協商。 以下圖:在這個例子中配置了 reauthtime爲600秒。 ikev1_auth_lifetime_pcap.png
  2. server會在衆多proposal裏選定一個發回給client,其中也包含了選定的life time。 ikev1_auth_lifetime_pcap_server.png
  3. 在lifetime到期時,有一方發起新的ike鏈接。 以下圖,由以前步驟裏的server發起了新的鏈接。這個時候,client和server的關係發生了轉變。 ikev2_reauth_pcap.png
  4. 斷掉舊的ike鏈接。 如上圖所示。

2.3 配置

根據內核代碼中的實現,咱們在這裏引入兩個名詞,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

3 CHILD SA rekey

rekey是指從新協商child sa。 在這裏,一樣有soft life time與hard life time兩個值。

3.1 IKEv1

IKEv1的rekey過程在整個原理上與reauth過程十分類似,詳細步驟以下:

  1. IKE SA創建完成以後。
  2. 在快速模式的第一個數據包裏,client會發送多個proposal。 proposal中包含了SA Life Time。 ikev1_sa_lifetime_pcap.png
  3. 在快速模式的第二個包中,server會選中一個proposal,其中包含了被選定的life time. 爲了環保,截圖略。其讀者自行想象。
  4. 100秒後,先到達life time的任意一方會主動發起新的快速模式鏈接。 ikev1_rekey_pcap.png
  5. 緊接着,在新的child sa創建完成數秒後,舊的鏈接會被刪掉。 如上圖中的第26和第32個包。 這裏有一個問題,舊鏈接的刪除由誰發起?

3.2 IKEv2

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協商成功以後。

  1. IPsec的任意一方,在到達各自設置的life time(100秒)以後,向對方發起CREATE_CHILD_SA消息。 包內包含一條message type爲REKEY_SA的notify payload。包含有SPI信息,沒有life time信息。 如圖: ikev2_rekey_pcap.png
  2. 對方回覆CREATE_CHILD_SA response消息。 消息內只包含協商信息,如圖: ikev2_rekey_pcap2.png
  3. N秒後,雙方各自刪除舊的child sa,併發送delete消息給對方,如上圖。 上圖中的N秒很短,是strongswan的默認值。能夠經過以下配置項進行設置。
    charon.delete_rekeyed_delay

這裏須要提到的是,在首次協商階段,child sa並無協商DH group,直到child sa被rekey以後,才從新協商 了新的DH group。這一個特性會影響到PFS(完美前向加密)。

3.3 配置

配置方面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

4 IKE SA rekey

這裏至於IKEv2有關。IKEv1裏沒有這個概念,或者說沒有實現這個概念。 基於以前的知識。在一個實驗的基礎上,講述這個概念。配置了一個300秒的IKE rekey時間。咱們使用tcpdump觀察數據包。 300秒後,rekey過程經過CREATE_CHILD_SA message發起,如圖: ikev2_rekey_ikesa_pcap.png 對比CHILD SA的rekey過程一樣使用CREATE_CHILD_SA消息來完成。二者的區別在於

CHILD SA的rekey message中包含有 REKEY_SA payload。IKE SA的rekey message則沒有。

5 其餘

在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的打印中能夠見到。

相關文章
相關標籤/搜索