strongwan sa分析(二)

名詞約定

client / initiator: IKE連接的首先發(fā)起方。
server / responder: IKE連接首先發(fā)起方的對方，即響應(yīng)方。

IKE SA: 用于對ISAKMP數(shù)據(jù)包進(jìn)行加密的SA。
CHILD SA / IPsec SA: 用于對傳輸數(shù)據(jù)（用戶數(shù)據(jù)）進(jìn)行加密的SA，如加密ESP協(xié)議數(shù)據(jù)。
SA: 包括，IKE SA和CHILD SA。

rekey/reauth 機(jī)制分析

1 概述

reauth是指重新進(jìn)行身份認(rèn)證過程。rekey包含兩個過程。IKESA rekey指協(xié)商IKE SA。
CHILD SA rekey是指重新協(xié)商CHILD SA。IKEv1與IKEv2在概念上同樣適用。但是需要特別說明的是，IKEv1中沒有實(shí)現(xiàn)
IKESA rekey機(jī)制。
詳見，官網(wǎng)wiki中的一篇文檔ExpiryRekey講到
IKEv1不支持ikesa的rekey，需要通過reauth實(shí)現(xiàn)ikesa rekey。

2 reauth

reauth是指重新進(jìn)行身份認(rèn)證?；诎踩目紤]，因?yàn)樽C書會過期，會被吊銷。Server需要一個機(jī)制用來發(fā)現(xiàn)
client的身份已經(jīng)失效了。
reauth過程有兩個方式：

• break-before-make
  先斷掉舊的IKE連接，再重新協(xié)商新的IKE連接。
• make-before-break
  先協(xié)商新的IKE連接，斷掉舊的IKE連接。

這兩個方式，是可以配置的。

2.1 IKEv2

在IKEv2中，整個reauth過程是這樣的。

1. 由Server發(fā)送life time給client。
   life time由類型為AUTH_LIFETIME的payload進(jìn)行傳輸。在一次IKE連接過程中，AUTH_LIFETIME類型的payload應(yīng)該出現(xiàn)在以下兩個地方中的一個[1]：
   • 最后一個IKE_AUTH包中。
   • INFORMATIONAL request包中。
     這兩個包，都是由server發(fā)送的。
     如下圖，在這個例子中配置了 reauthtime為600秒。
     
2. client發(fā)起重連
   client需要在server發(fā)送過去的 life time之前發(fā)起reauth機(jī)制，否則server將在life time到達(dá)時斷開鏈接。
   如下圖，我們見到在490秒后，client主動斷掉了IKE連接，并發(fā)起了新的連接。
   

如果作為client一方的ipsec實(shí)現(xiàn)不支持AUTH_LIFETIME類型的消息，將不會對server進(jìn)行回復(fù)，這個時候
server在到期之后，會主動斷掉連接。client需要手工的從新建立新的連接。
如果作為server的一方ipsec實(shí)現(xiàn)不支持AUTH_LIFETIME類型的消息，那么他將不會發(fā)送該消息。這樣的連接
也將永遠(yuǎn)不會進(jìn)行reauth[2]。

基于以上，我們可以推論出，IKEv2的連接，兩端的客戶端其實(shí)都會配置life time。但是，只有server端的
life time會生效。之所以說是推論出的，因?yàn)闆]有實(shí)踐配置過，進(jìn)行驗(yàn)證。

2.2 IKEv1

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

1. client在算法協(xié)商的proposal里，包含了life time信息傳輸給server，進(jìn)行協(xié)商。
   如下圖：在這個例子中配置了 reauthtime為600秒。
   
2. server會在眾多proposal里選定一個發(fā)回給client，其中也包含了選定的life time。
   
3. 在lifetime到期時，有一方發(fā)起新的ike連接。
   如下圖，由之前步驟里的server發(fā)起了新的連接。這個時候，client和server的關(guān)系發(fā)生了轉(zhuǎn)變。
   
4. 斷掉舊的ike連接。
   如上圖所示。

2.3 配置

根據(jù)內(nèi)核代碼中的實(shí)現(xiàn)，我們在這里引入兩個名詞，soft life time和hard life time。
soft是指server通知給client的最后期限。但是實(shí)際上，在soft時間到達(dá)后，server并不會真的斷掉連接，
而是會等待hard時間到達(dá)后再斷掉。
strongswan中，soft與hard的賦值與計算規(guī)則，如下：

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是指重新協(xié)商child sa。
在這里，同樣有soft life time與hard life time兩個值。

3.1 IKEv1

IKEv1的rekey過程在整個原理上與reauth過程十分相似，詳細(xì)步驟如下：

0. IKE SA建立完成之后。
1. 在快速模式的第一個數(shù)據(jù)包里，client會發(fā)送多個proposal。
   proposal中包含了SA Life Time。
   
2. 在快速模式的第二個包中，server會選中一個proposal，其中包含了被選定的life time.
   為了環(huán)保，截圖略。其讀者自行想象。
3. 100秒后，先到達(dá)life time的任意一方會主動發(fā)起新的快速模式連接。
   
4. 緊接著，在新的child sa建立完成數(shù)秒后，舊的連接會被刪掉。
   如上圖中的第26和第32個包。
   這里有一個問題，舊連接的刪除由誰發(fā)起？

3.2 IKEv2

IKEv2的rekey過程是由消息類型為CREATE_CHILD_AS的消息完成的。在新建好新的child sa之后。發(fā)起端
會發(fā)起刪除舊連接的DELETE消息，從而完成整個rekey過程。
通過抓包分析，發(fā)現(xiàn)child sa的life time沒有在整個ipsec的連接生命周期中交互過，也就是說沒有發(fā)生過通信。
同時發(fā)現(xiàn)，child sa協(xié)商的任何一方都有發(fā)起rekey流程的現(xiàn)象。從而推測ipsec程序保持著各自的child sa
lift time設(shè)置，在各自的life time到期之后，都會自行發(fā)起rekey。
TODO：以上推測應(yīng)該到rfc里確認(rèn)一下。
接下來，是詳細(xì)的ikev2 rekey過程：
0. IKEv2協(xié)商成功之后。

1. IPsec的任意一方，在到達(dá)各自設(shè)置的life time（100秒）之后，向?qū)Ψ桨l(fā)起CREATE_CHILD_SA消息。
   包內(nèi)包含一條message type為REKEY_SA的notify payload。包含有SPI信息，沒有l(wèi)ife time信息。
   如圖：
   
2. 對方回復(fù)CREATE_CHILD_SA response消息。
   消息內(nèi)只包含協(xié)商信息，如圖：
   
3. N秒后，雙方各自刪除舊的child sa，并發(fā)送delete消息給對方，如上圖。
   上圖中的N秒很短，是strongswan的默認(rèn)值?？梢酝ㄟ^如下配置項(xiàng)進(jìn)行設(shè)置。

   charon.delete_rekeyed_delay
   

這里需要提到的是，在首次協(xié)商階段，child sa并沒有協(xié)商DH group，直到child sa被rekey之后，才重新協(xié)商
了新的DH group。這一個特性會影響到PFS（完美前向加密）。

3.3 配置

配置方面rekey與reauth原理相同，我們?nèi)匀灰胹oft和hard兩個概念。計算規(guī)則如下：

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有關(guān)。IKEv1里沒有這個概念，或者說沒有實(shí)現(xiàn)這個概念。
基于之前的知識。在一個實(shí)驗(yàn)的基礎(chǔ)上，講述這個概念。配置了一個３００秒的IKE rekey時間。我們使用tcpdump觀察數(shù)據(jù)包。
300秒后，rekey過程通過CREATE_CHILD_SA message發(fā)起，如圖：

對比CHILD SA的rekey過程同樣使用CREATE_CHILD_SA消息來完成。兩者的區(qū)別在于

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

5 其他

在OS中查看rekey和reauth狀態(tài)的方法，使用swanctl命令。
在命令輸出中能分別看見ike sa與child sa的編號。每一次協(xié)商之后，編號會增加一。同時看能看見rekey
和expire的時間。
在正在發(fā)生rekey或reauth的時候，執(zhí)行這個命令。如果strongswan的行為是先重建后刪除的話，還將看見
同時存在的兩個SA出現(xiàn)在打印信息內(nèi)。
示例如下：

[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的打印中可以見到。