[strongSwan] Behavior on receiving NO_ADDITIONAL_SAS

[Patil, Shashidhar 1. (NSN - IN/Bangalore)]

Hi,

We are using strongswan version 4.5.3 and have the following queries

Section 1.3 of RFC 5996 :
   The responder sends a NO_ADDITIONAL_SAS notification to indicate that
   a CREATE_CHILD_SA request is unacceptable because the responder is
   unwilling to accept any more Child SAs on this IKE SA.  This
   notification can also be used to reject IKE SA rekey.  Some minimal
   implementations may only accept a single Child SA setup in the
   context of an initial IKE exchange and reject any subsequent attempts
   to add more.

And  Section 1.3.1 (creating new child SA using create_child_SA)
 failed attempt to create a Child SA SHOULD NOT tear down the IKE
   SA: there is no reason to lose the work done to set up the IKE SA.
   See Section 2.21 for a list of error messages that might occur if
   creating a Child SA fails.


My understanding on this paragraph leads to following scenarios where peer sends the NO_ADDITIONAL_SAS notification
Scenario-1--> No child SA allowed using CREATE_CHILD_SA (apart from the one created during the AUTH exchange)
How does strongswan behave in this case ? will it delete the IKE and try to recreate the IKE & child again?

Scenario-2--> Alreday <N> child SA are created and peer doesn't support N+1th child SA under the given IKE  (is it possible to enforce such restriction?)
How does strongswan behave in this case ? will it delete the IKE and all the child SA under that IKE and try to recreate the IKE & child SAs again?

Scenario-3--> Reject IKE rekeying request using CREATE_CHILD_SA from the peer
How does strongswan behave in this case ? will it delete the IKE and all the child SA under that IKE and try to recreate the IKE & child SAs again?

Scenario-4 --> In case of 1-IKE and multiple child-SA configuration, if the peer rejects the rekey request for any of child(ESP) SA with "NO_ADDITIONAL_SAS"
How does strongswan behave in this case ?

BR,
Shashidhar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130228/29c344e1/attachment.html>