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
