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

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过程是这样的。

  1. 由Server发送life time给client。
    life time由类型为AUTH_LIFETIME的payload进行传输。在一次IKE连接过程中，AUTH_LIFETIME类型的payload应该出现在以下两个地方中的一个[1]：
    • 最后一个IKE_AUTH包中。
    • INFORMATIONAL request包中。
      这两个包，都是由server发送的。
      如下图，在这个例子中配置了 reauthtime为600秒。
      ikev2_auth_lifetime_pcap.png
  2. client发起重连
    client需要在server发送过去的 life time之前发起reauth机制，否则server将在life time到达时断开链接。
    如下图，我们见到在490秒后，client主动断掉了IKE连接，并发起了新的连接。
    ikev2_reauth_pcap.png

如果作为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秒。
    ikev1_auth_lifetime_pcap.png
  2. server会在众多proposal里选定一个发回给client，其中也包含了选定的life time。
    ikev1_auth_lifetime_pcap_server.png
  3. 在lifetime到期时，有一方发起新的ike连接。
    如下图，由之前步骤里的server发起了新的连接。这个时候，client和server的关系发生了转变。
    ikev2_reauth_pcap.png
  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。
    ikev1_sa_lifetime_pcap.png
  3. 在快速模式的第二个包中，server会选中一个proposal，其中包含了被选定的life time.
    为了环保，截图略。其读者自行想象。
  4. 100秒后，先到达life time的任意一方会主动发起新的快速模式连接。
    ikev1_rekey_pcap.png
  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信息。
    如图：
    ikev2_rekey_pcap.png
  2. 对方回复CREATE_CHILD_SA response消息。
    消息内只包含协商信息，如图：
    ikev2_rekey_pcap2.png
  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发起，如图：
ikev2_rekey_ikesa_pcap.png
对比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的打印中可以见到。

posted on 2019-08-17 23:09  toong  阅读(6454)  评论(0)  编辑  收藏  举报