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

[ipsec][strongswan] strongswan源码分析-- (二）rekey/reauth机制分析