Issue #2708
DPD behavior comformance with RFC7296
Description
I have a few doubts regarding strongSwan's DPD behavior conformance with RFC7296, depicted in https://tools.ietf.org/html/rfc7296#section-2.4
1. It is stated that "An implementation needs to stop sending over any SA if some failure prevents it from receiving on all of the associated SAs."
But it seems that strongSwan will send DPD regardless of whether there is such fatal error, e.g. local IKE endpoint IP has been deleted.
2. It is also stated that "Receipt of a fresh cryptographically protected message on an IKE SA or any of its Child SAs ensures liveness of the IKE SA and all of its Child SAs."
But it seems that strongSwan will regard the peer as live once incoming traffic is received, with the criteria that policy use_time being updated. Actually even an
unencrypted packet can cause the use_time to be updated.
Related issues
History
#1 Updated by Tobias Brunner about 7 years ago
- Status changed from New to Feedback
1. It is stated that "An implementation needs to stop sending over any SA if some failure prevents it from receiving on all of the associated SAs."
But it seems that strongSwan will send DPD regardless of whether there is such fatal error, e.g. local IKE endpoint IP has been deleted.
That might depend on the MOBIKE settings, the roam events, the NAT situation and the strongSwan version. But classic DPDs are in fact just sent in any case.
2. It is also stated that "Receipt of a fresh cryptographically protected message on an IKE SA or any of its Child SAs ensures liveness of the IKE SA and all of its Child SAs."
But it seems that strongSwan will regard the peer as live once incoming traffic is received, with the criteria that policy use_time being updated. Actually even an
unencrypted packet can cause the use_time to be updated.
Correct, we discussed that already in #2400.
#2 Updated by Tobias Brunner about 7 years ago
- Related to Issue #2400: Is DPD supposed to detect dead tunnel, or dead IKE instance added
#3 Updated by c c about 7 years ago
Another issue observed during DPD is that:
When DPD timeout happens(due to disconnectivity), the original IKE SA is cleared and new establishment is attempted with new IKE SA. If both peers are strongSwan then when networking recovers both IKE SAs(and child SAs) will be created successfully and leads to duplicates. If there is disconnectivity again and DPD timeout happens, after recovery there could be 2*2 IKE SAs being established.
It seems to make more sense to keep the same IKE SA during re-negotiation.
#4 Updated by Tobias Brunner about 7 years ago
When DPD timeout happens(due to disconnectivity), the original IKE SA is cleared and new establishment is attempted with new IKE SA.
Only if configured as such, there are other options.
If both peers are strongSwan then when networking recovers both IKE SAs(and child SAs) will be created successfully and leads to duplicates.
Again, only if both peers have a DPD action that triggers that. And it might also depend on the uniqueness policy.
If there is disconnectivity again and DPD timeout happens, after recovery there could be 2*2 IKE SAs being established.
I guess that's possible if DPDs are sent for both SAs by both peers and they have a corresponding DPD action.
It seems to make more sense to keep the same IKE SA during re-negotiation.
How could it be kept?
#5 Updated by Tobias Brunner over 6 years ago
- Category set to configuration
- Status changed from Feedback to Closed
- Assignee set to Tobias Brunner
- Resolution set to No feedback