〇
ike协商的过程最终是为了SA的建立, SA的建立后, 在底层中管理过程,也是相对比较复杂的. 这里边也经常会出现失败的情况.
我们以strongswan为例, 在strongswan的底层SA管理由linux kernel实现, 并通过netlink与strongswan进行交互.
当linux kernel收到sa的建立命令,并不幸失败后, 会给strongswan回复一个error消息.
一
我们现在将视角来回到ike协议的交互层面. 来观察一下.
发生〇中的情况时, 我们抓包观察如下:
可以看见, 经过四个包的协商之后. 发起端, 主动回复了一个Delete消息给响应端.
(我们是在发起端人为设置的kernel SA添加失败, 来模拟这个场景.)
二
现在来进行一下分析. 如下图:
1. 我们知道child sa的建立过程是在上边pcap那张图的包3和包4中进行的. 在下边这张手绘图里, pkt1表示包3, pkt2表示包4
2. 整个SA的建立与协商过程是这样的:
a, 为对方分配一个spi
b. 将该spi发给对方.
c. 对方通过收到的spi在本地建立sa
d, 对方为我方申请一个spi
e, 对方将申请到的spi发送给我方.
f. 我方收到spi后, 在本地建立sa.
3. 上边的过程里, 只讲到了建立出方向SA的过程. 实际上每端都需要管理两个方向SA. 对于我方来说,本地SA的建立需要至少在f之前完成, 对于对方来说, 本地SA的建立需要至少在d之前完成.
(无论本地SA的建立在什么情况下完成, 都不影响我们当前讨论的错误处理逻辑.)
三
如上图. 如果process #3中出现了错误, 发起方将发送Delete报文给响应方. 否则不发生, 如最上面的pcap截图.
另一种情况是, 如果process #2中发生错误, 响应方将在报文pkt 2中携带错误信息发送给发起方. 使用 notification 报文段.
见:https://tools.ietf.org/html/rfc7296#section-2.21
If the error occurred on the responder, the notification is returned in the protected response, and is usually the only payload in that response. Although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, that peer needs to treat the information with caution. If the error occurs on the initiator, the notification MAY be returned in a separate INFORMATIONAL exchange, usually with no other payloads. This is an exception for the general rule of not starting new exchanges based on errors in responses.
四
基于之前的信息, 现在做一个测试,查看另一个例子.
修改掉协商一端的SPK(预共享秘钥), 这个时候,将导致身份认证的失败, 我们现在通过如下的截图, 来查看这样的例子.
从上图中, 我们可以看到如(三)中的描述, 响应方通过notification的信息段反馈了认证失败这样的报错信息.
另外, 观察发起方的strongswan日志, 发现如下日志信息:
Aug 26 19:38:06.321 13[NET] received packet: from 192.168.8.129[500] to 192.168.8.103[500] (80 bytes) Aug 26 19:38:06.321 13[IKE] received AUTHENTICATION_FAILED notify error Aug 26 19:38:06.321 13[CHD] CHILD_SA child-sun{2} state change: CREATED => DESTROYING Aug 26 19:38:06.321 13[KNL] deleting SAD entry with SPI c01e421a Aug 26 19:38:06.323 13[KNL] deleted SAD entry with SPI c01e421a Aug 26 19:38:06.323 13[IKE] IKE_SA conn-sun-100[2] state change: CONNECTING => DESTROYING