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

strongwan sa分析(二)

---

[TOC]

名詞約定

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過程有兩個方式：

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

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

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秒。
2. client發起重連 client須要在server發送過去的 life time以前發起reauth機制，不然server將在life time到達時斷開連接。 以下圖，咱們見到在490秒後，client主動斷掉了IKE鏈接，併發起了新的鏈接。

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

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

2.2 IKEv1

在IKEv1中，reauth過程簡述以下：

1. client在算法協商的proposal裏，包含了life time信息傳輸給server，進行協商。 以下圖：在這個例子中配置了 reauthtime爲600秒。
2. server會在衆多proposal裏選定一個發回給client，其中也包含了選定的life time。
3. 在lifetime到期時，有一方發起新的ike鏈接。 以下圖，由以前步驟裏的server發起了新的鏈接。這個時候，client和server的關係發生了轉變。
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。
3. 在快速模式的第二個包中，server會選中一個proposal，其中包含了被選定的life time. 爲了環保，截圖略。其讀者自行想象。
4. 100秒後，先到達life time的任意一方會主動發起新的快速模式鏈接。
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信息。 如圖：
2. 對方回覆CREATE_CHILD_SA response消息。 消息內只包含協商信息，如圖：
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裏沒有這個概念，或者說沒有實現這個概念。 基於以前的知識。在一個實驗的基礎上，講述這個概念。配置了一個３００秒的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則沒有。

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