Re: [strongSwan] Query on Child SA Creation
Hi, > But I actually wanted this as a separate SA which can be enabled > disabled separately. You can initiate/terminate specific CHILD_SAs using curly brackets, e.g. ipsec down connxy{}. > And just wanted to know what is the criteria for deciding that a > config should be a child of another one ? Configurations from ipsec.conf get merged if the IKE_SA specific parameters match (i.e. identities and addresses). To initiate each CHILD_SA in a seperate IKE_SA, you may specify the strongswan.conf option charon.reuse_ikesa = no. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Specifying a "relaxed" ESP encryption/authentication proposal for CHILD_SA setup and rekeying
Hi Graham, > esp=aes-sha1-modp1024,aes-sha1! > > but this seems to confuse the SECOND segw (after successful initial > tunnel setup, the second segw goes into an infinite immediate rekeying > loop). I did a test with this proposal, but it seems that we did not support such mixed ESP proposals properly. If we proposed/received a DH group in the request, we didn't accept a proposal without a DH group. After reading IKEv2-bis again, I think the proper way is to just ignore a proposed KE payload if the selected proposal does not contain a DH group. I checked in a fix at [1], maybe your setup works with this patch applied. > I haven't even tried this configuration on the first segw. Technically, this is a (short) LIST of proposals. So I hope your first gateway is happy with _short_ lists :-). This is probably the only IKEv2-compatible way to implement CHILD_SA rekeying using a single proposal for a gateway that requires and a gateway that does not support CHILD_SA rekeying within a DH exchange. > Looking at the old version, it made the same proposal as the new one > ("AES_CBC_128/HMAC_SHA1_96/MODP_1024") and when it received the same > responding proposal ("AES_CBC_128/HMAC_SHA1_96") warned that the > remote end had not specified the diffie-hellman group BUT it would > carry on anyway and set up the new CHILD_SA. I think this is a violation of IKEv2. A responder must select the full proposal: If MODP_1024 is specified, it has to use it. If the proposal contains aes128-sha1 and aes128-sha1-modp1024, it is allowed to chose one of them. In this case the initiator will propose KE, but will accept a response without KE if the responder has selected the appropriate proposal. Regards Martin [1]http://git.strongswan.org/?p=strongswan.git;a=commit;h=1f6a707d ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Query on Child SA Creation
Hi Martin > To initiate each CHILD_SA in a seperate IKE_SA, you may specify the > strongswan.conf option charon.reuse_ikesa = no. Thanks for the update One more observation related to this . If I set reuse_ikesa=no then for bringing up the connection I can use "ipsec up" without the "{ }" suffix in the connection name. But I see that for bringing down the connection I need to specify the connection name with { } suffix otherwise the connection does not terminate. Is this the known behavior ? Regards Shyam -Original Message- From: Martin Willi [mailto:mar...@strongswan.org] Sent: Wednesday, April 21, 2010 11:34 AM To: Shyamsundar Purkayastha (WT01 - Telecom Equipment) Cc: users@lists.strongswan.org Subject: Re: [strongSwan] Query on Child SA Creation Hi, > But I actually wanted this as a separate SA which can be enabled > disabled separately. You can initiate/terminate specific CHILD_SAs using curly brackets, e.g. ipsec down connxy{}. > And just wanted to know what is the criteria for deciding that a > config should be a child of another one ? Configurations from ipsec.conf get merged if the IKE_SA specific parameters match (i.e. identities and addresses). To initiate each CHILD_SA in a seperate IKE_SA, you may specify the strongswan.conf option charon.reuse_ikesa = no. Regards Martin Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Specifying a "relaxed" ESP encryption/authentication proposal for CHILD_SA setup and rekeying
Martin, Thanks for that. Using the config param: esp=aes-sha1-modp1024,aes-sha1! and a strongSwan rebuilt with your patch, everything now works. Both SeGWs are happy. Phew! Cheers, Graham. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users