strongwan sa分析(二)
Author： Cao Tong
Date： 2018-12-29
Version： 1.2
文档历史
| 版本 | 日期 | 说明 | 修改人 |
|---|---|---|---|
| 1.0 | 20181229 | 初版 | caotong |
| 1.1 | 20190102 | 修改重要的概念阐述，IKE SA rekey | caotong |
| 1.2 | 20190103 | 修改IPsec SA的名称约定 | caotong |
名词约定
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过程：
- 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的打印中可以见到。