Bug #464
Incorrect handling of IKE_SA rekeying collision when one of the peers (client) does not detect collision
Start date:
12.12.2013
Due date:
Estimated time:
Affected version:
5.1.0
Resolution:
Fixed
Description
Hello,
Looks like StrongSwan do not properly handle RFC 5996 (2.8.2).
The part where one of the peers do not detect collision (client in our case).
In that case StrongSwan closes all IKE SAs when got D INFORMATIONAL in rekey.
Associated revisions
History
#1 Updated by John F over 7 years ago
I've seen that occurring several times.
In my opinion, it's strongSwan's worst bug. And it hasn't received the attention from developers it deserves.
#2 Updated by Tobias Brunner about 5 years ago
- Tracker changed from Issue to Bug
- Status changed from New to Assigned
- Assignee set to Tobias Brunner
- Priority changed from High to Normal
- Target version set to 5.5.0
#3 Updated by Tobias Brunner almost 5 years ago
- Subject changed from IKE SA rekeying collision when one of the peers (client) does not detect collision to Incorrect handling of IKE_SA rekeying collision when one of the peers (client) does not detect collision
- Status changed from Assigned to Closed
- Resolution set to Fixed
Merge branch 'exchange-collisions'
Improves the handling of IKEv2 exchange collisions in several corner
cases. TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND notifies that were defined
with RFC 7296 are now handled and sent as appropriate.
The behavior in these situations is tested with new unit tests.
Fixes #379, #464, #876, #1293.