strongwan sa分析(二)
名詞約定
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過程是這樣的。
- 由Server發送life time給client。
life time由類型為AUTH_LIFETIME的payload進行傳輸。在一次IKE連接過程中，AUTH_LIFETIME類型的payload應該出現在以下兩個地方中的一個[1]：- 最后一個IKE_AUTH包中。
- INFORMATIONAL request包中。
這兩個包，都是由server發送的。
如下圖，在這個例子中配置了 reauthtime為600秒。
- 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過程簡述如下：
- client在算法協商的proposal里，包含了life time信息傳輸給server，進行協商。
如下圖：在這個例子中配置了 reauthtime為600秒。
- server會在眾多proposal里選定一個發回給client，其中也包含了選定的life time。
- 在lifetime到期時，有一方發起新的ike連接。
如下圖，由之前步驟里的server發起了新的連接。這個時候，client和server的關系發生了轉變。
- 斷掉舊的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過程十分相似，詳細步驟如下：
- IKE SA建立完成之后。
- 在快速模式的第一個數據包里，client會發送多個proposal。
proposal中包含了SA Life Time。
- 在快速模式的第二個包中，server會選中一個proposal，其中包含了被選定的life time.
為了環保，截圖略。其讀者自行想象。 - 100秒后，先到達life time的任意一方會主動發起新的快速模式連接。
- 緊接着，在新的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協商成功之后。
- IPsec的任意一方，在到達各自設置的life time（100秒）之后，向對方發起CREATE_CHILD_SA消息。
包內包含一條message type為REKEY_SA的notify payload。包含有SPI信息，沒有life time信息。
如圖：
- 對方回復CREATE_CHILD_SA response消息。
消息內只包含協商信息，如圖：
- 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的打印中可以見到。