[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的打印中能够见到。