〇
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