Implement Max child SA limit per configuration #1856
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR seeks to introduce the ability to control the maximum number of child SAs that are allowed to be negotiated by a responder. This is an optional configuration that maintains the current behavior of unlimited child SAs by default.
This is in relation to discussions per #1725
Duplicate child SA handling and preventing initiating duplicate child SAs was introduced in 5.9.6 and allows the initiator to largely catch and prevent duplicate child SA from being initiated. However, this doesn't help the responder and can hinder a responder that has a limited implementation or a specific use case to only allow a single child SA per IKE SA.
There is currently no provision as confirmed in the discussion thread to limit the number of child SAs negotiated as a responder which leaves the only option to accept or disconnect upon detecting the max child SA count has been exceeded via a listener plugin. This is far from ideal as it only leads to flapping tunnels or undesired multiple child SAs. Also, the behavior may be caused by misbehavior of a client such as a pre-5.9.6 client that negotiates duplicates not desired by customer config that could lead to the tunnel flapping.
The ideal behavior would be to allow configuration to control the maximum number of child SAs per configuration profile specifically and for this limit to be enforced at negotiation time to reject additional child SAs with an appropriate notification by the responder.
The RFC, in fact, outlines this use case and refers to minimal implementations where limiting to a single Child SA is desired but the current code doesn't allow for this by configuration and this change introduces this as an optional configuration.
RFC7296 Section 1.3. The CREATE_CHILD_SA Exchange:
Configuration introduced:
connections.<conn>.children.<child>.max_child_sas = 0