Subheading: ipsec rekey will lead to loss
author: classic_tong
Foreword
What rekey.
It refers to rekey ipsec ends of the communication mechanism of periodic replacement of encryption keys channel.
For safety considerations, as the secret key used delay time, the possibility of symmetric keys to be cracked will gradually increase. Therefore, periodic replacement
Symmetrical secret key, is a necessary means to ensure the ipsec security.
We know that there are two key key, IKE sa the key and child sa (ipsec sa) of the key. So rekey also has two, ike rekey
和child rekey。
Here only discuss the child sa rekey.
All content, all from here: https://tools.ietf.org/html/rfc7296#section-2.8
A concept
refers to rekey, rekey condition once (soft condition) is satisfied, sends a request message to the CREATE_CHILD_SA other end, the other end of the return
CREATE_CHILD_SA a response message. In order to negotiate a new sa process.
This time, the old SA is not deleted, once deleted withhold conditions (hard condition), the old SA will be satisfied for some conditions, triggered by deleting INFORMATION conditions.
rekey trigger conditions in three, time-triggered, count off the trigger, the number of bytes trigger. Each of which has been divided into soft and hard two conditions. It was used to describe the top of the trigger.
For example: If a time trigger 100 seconds. It refers to the child sa 100 seconds after consultation established, will start rekey process.
In this example, an example has been achieved in strongswan, hard = 100 sec + random seconds. soft = hard × 90%
That is, soft seconds, one end will create a new sa. The hard second time will remove the old sa.
It reported that the number and the number of bytes Similarly, soft will always arrive before the hard conditions.
Here. Please note that this time difference (hard - soft), which is a potential mechanism to rekey conditions. In this period, we must do two things in order to ensure
Smooth rekey process, that is, ESP packet is not lost.
The first thing is to establish complete both ends of the new SA.
The second thing is the traffic at both ends to complete the switch from the old to the new SA SA.
In ikev2, the above trigger conditions is provided at both ends of the local ipsec. Not consult with each other. Whoever conditions in the end, who will initiate rekey.
In ikev1, the above condition is negotiation process. We only discuss ikev2.
Two processes
Conventional process logic rekey is not going to lead to loss of use of the figure below, do explain the details:
The left side of the figure is the first party to rekey occurs, the right is the other ipsec link.
1. rekey left to reach the soft trigger condition.
2. The left transmitting a request message to the new sa.
3. After receiving the right message, to start creating a new SA locally.
Sending a response message 4. The right side of the new sa. But there is one condition before sending the package, must ensure that the new local SA has been fully in place and ready for use.
After that, it must still send the right message using the old ESP SA.
5. left response message is received, the process of creating a new SA locally.
After the new SA is set up, the right to switch the ESP to send a message to end the use of the new SA.
After the news of the new SA 6. received the right to send over, and the decryption is successful. This time description of the new SA is left in place up.
So the right side of the traffic is switched from the old to the new SA SA to above.
7. The right of the ESP can send messages using the new SA.
So far, the new SA has completed the process of establishing and switching, and does not lead to loss.
8. The left reach the hard conditions rekey
9. left to send a request to delete the old SA.
10, delete the old SA the right to respond to the request.
So far, rekey process is complete.
Of particular note is that they can during rekey, left and did not need each other when the ESP packets sent. It will send a fake in the past, triggering them to switch SA.
Or, if the right has not received any new SA of ESP packets, but received a request from the old SA, which will be switched SA. (That figure did not receive 5 directly received nine)
In summary, here are two key logic at the edge 4 and 6 above.
只要是正确的ipsec实现，4上面都不会有问题。所以在6的一些特殊情况下，会导致rekey期间的丢包。
比如，hard减去soft的时间过短，短到左边的sa创建流程没有及时完成，便触发了右边的流量切换。
三 多出来的SA
第一小节中random的作用是为了防止两端同时rekey的出现。
例如我们一般在配置两边的ipsec隧道时，通常会采用相同的配置，如rekey time=3600秒。
这个时候如果没有random时间，两边会同时发起rekey。
同时发起rekey的情况下，两侧的新建sa都会成功，这个时候会出现三个SA。
每一端都会各自独立检测这个场景，然后发现同时rekey的出现。然后会由发起的人来删除nonce比较小的那个一个SA。
以此到达删除重复sa的目的。
四 其他
RFC里，读到一句话，也不知道什么情况下会出现TS和算法会和就的SA不同。
Note that, when rekeying, the new Child SA SHOULD NOT have different Traffic Selectors and algorithms than the old one.