Limit multiple/duplicate child SA negotiation per IKE SA on server (responder)

[anipatel-eng]

In 5.9.6, checks were added as noted in the release notes for IKEv2 as 'Actively initiating duplicate CHILD_SAs within the same IKE_SA is now largely prevented.'  This has proven to prevent Strongswan 5.9.6+ code from initiating duplicates based on our testing.
 
However, for a server running Strongswan, it leaves the server vulnerable to clients running older code that will continue to initiate duplicate child SAs. It would be desirable to block duplicates and ideally control the number of child SAs allowed per IKE SA in general. Also, ideally, we would like to be able to only support a single child SA per IKE SA based on our use case and custom kernel support.
 
Questions:

• There doesn't seem to be a way to configure Strongswan to limit the number of child SAs per IKE SA? Is there a way to control this?

  • If not, having such a knob would allow the server to block support for multiple child SAs including duplicates

• We have looked into checking and blocking from the kernel-ipsec plugin add_sa() call but there isn’t enough context provided to reliably reject adding only multiple/duplicate child SAs since it could be the first child SA or a child SA rekey

• We have implemented a change in child create process/build code to check and reject additional child SAs based on configuration. We would like to push this change if possible unless there are alternatives you could suggest please. Thoughts on pushing such a change

[tobiasbrunner]

it leaves the server vulnerable to clients running older code that will continue to initiate duplicate child SAs.

In what situations do they do so? You might want to investigate and prevent these duplicates in the first place. While there are some (mis-)configurations that are known to potentially trigger duplicates, they should still be considered out of the ordinary.

• There doesn't seem to be a way to configure Strongswan to limit the number of child SAs per IKE SA? Is there a way to control this?

No.

• If not, having such a knob would allow the server to block support for multiple child SAs including duplicates

But it's quite restrictive. In general, there are reasons for having multiple CHILD_SAs per IKE_SA (not duplicates).

• We have implemented a change in child create process/build code to check and reject additional child SAs based on configuration. We would like to push this change if possible unless there are alternatives you could suggest please. Thoughts on pushing such a change

There is some (very old) code in the child-duplicates-replace branch that also deletes duplicates as responder. I'm not sure what the current state of this is exactly, but I guess we could implement something similar that reuses some of the current de-duplication code.

[anipatel-eng]

it leaves the server vulnerable to clients running older code that will continue to initiate duplicate child SAs.

In what situations do they do so? You might want to investigate and prevent these duplicates in the first place. While there are some (mis-)configurations that are known to potentially trigger duplicates, they should still be considered out of the ordinary.

This is reproducible by initiating via the same child SA configuration multiple times (i.e. sudo swanctl --initiate --child ikev2-vpn-child-0) with dpd_action and/or close_action set to start with code prior to 5.9.6 because of the lack of the duplicate check which was added in 5.9.6.
However, with 5.9.6+ code, the initiator rarely runs into this but it's still possible in some timing windows but the duplicate checking for the initiator largely prevents this. 
My concern is more not being able to manage and control all peers connecting to us as a server which exposes the server to these misbehaving older Strongswan peers behavior and being able to reject the duplicate on the responder would allow the client to function since we don’t support multiple/duplicate child SAs in our kernel.
 

• There doesn't seem to be a way to configure Strongswan to limit the number of child SAs per IKE SA? Is there a way to control this?

No.

• If not, having such a knob would allow the server to block support for multiple child SAs including duplicates

But it's quite restrictive. In general, there are reasons for having multiple CHILD_SAs per IKE_SA (not duplicates).

Understood that IKEv2 allows multiple child SAs with or without the same selectors but this would be a knob that is disabled by default and implementations that only support a single child SA or would like to limit the number of child SAs allowed, in general, for a single IKE SA can configure.
 

• We have implemented a change in child create process/build code to check and reject additional child SAs based on configuration. We would like to push this change if possible unless there are alternatives you could suggest please. Thoughts on pushing such a change

There is some (very old) code in the child-duplicates-replace branch that also deletes duplicates as responder. I'm not sure what the current state of this is exactly, but I guess we could implement something similar that reuses some of the current de-duplication code.

I reviewed the code you pointed out and seems like a viable solution to handle duplicates based on child SA configurations and looks like it would definitely allow us to avoid accepting duplicates on the responder also.  I’ll attempt to resurrect the code and apply it to the latest code and see if this would be viable to accept into the code with your review.
 
Thanks for your help!

[tobiasbrunner]

being able to reject the duplicate on the responder would allow the client to function since we don’t support multiple/duplicate child SAs in our kernel.

Hm, where does that limitation come from? The number of SAs? The number of policies? How do you handle rekeying? How multiple IKE_SAs with their CHILD_SAs (which could be duplicate, by the way)?

[anipatel-eng]

Rekeying is handled as a special case but our use case is limited and doesn't require more than 1 set of child SAs. In general, an implementation may want to limit the number of child SAs per IKE SA though.

[cyanideangel2000]

For our usecase, we do limit the number of child-sa per IKE and we do this explicitly in our child_updown callback to meet our specific semantics.
I don't think strongswan should be limiting the number of child-sa per ike in any way.

[anipatel-eng]

Thanks for adding that detail. We've done the same in the child_updown listener call also but this is only called once the child SA is negotiated so we can only queue a delete for the extra child SA which is already loaded to the kernel. This causes some clients to continually attempt to bring up another child SA repeatedly. Ideally, the child SA would be prevented from being negotiated. I think this should be possible without another knob though via existing config while preventing duplicates.