[strongSwan] Specifying a "relaxed" ESP encryption/authentication proposal for CHILD_SA setup and rekeying

[Graham Hudspith]

Hello All,

We've a problem here with a couple of errant security-gateways when trying
to connect our strongswan-using software to them.

Originally, we specified a connection to use the following params:

ike=aes-sha-modp1024!
esp=aes-sha1

The first segw was *unhappy* with this, because the CHILD_SA creation
included a LIST of proposals (of all of the possible combinations PREPENDED
by the one we specified, above). The first segw did not like the fact that
we were sending a list instead of just the combination we had agreed.

So, we changed the esp= line:

esp=aes-sha1!


This forced the local end to only propose the specified combination.

The first segw became happy.

Next, the second segw was unhappy. Eventually, they managed to tell us it
was because we were not specifying the diffie-hellman group in the CHILD_SA
creation proposal. So, we changed the esp= line again:

esp=aes-sha1-modp1024!


The second segw became happy. We could set up a tunnel and rekeying
proceeded smoothly.

Unfortunately, the first segw became unhappy again :-(

Initial tunnel setup went okay, rekeying of the IKE_SA went okay, but
rekeying of the CHILD_SA failed. Looking at the strongswan trace, it seemed
that we were proposing to use "AES_CBC_128/HMAC_SHA1_96/MODP_1024" (as
expected) and the segw was responding with a smaller proposal of
"AES_CBC_128/HMAC_SHA1_96".
The local end's strongswan code received this proposal, looked for it in the
list of configured proposals, could not find it and failed the rekey
operation.

I've tried:

esp=aes-sha1-modp1024


but this then failed because we ended up proposing a list of choices, again.
I've also tried:

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
haven't even tried this configuration on the first segw.

The operator of the first segw does not think there is a problem with their
segw and insists that the previous version of our software (using a
different IPsec stack not strongswan) worked fine and that we should make
our latest version of our software compatible with the old version.

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.

Any ideas, anyone ?

I'm tempted to try and argue that the problem is with their segw, because it
specifies the diffie-hellman group during the initial setup of the CHILD_SA
and it is only during the rekeying of the CHILD_SA that they do not specify
the diffie-hellman group.

However, I'm sure they will:

(a) state that they are not breaking any standards by doing so
(b) it is more efficient to NOT specify a new diffie-hellman exchange during
a rekey of the CHILD_SA (or something)
(c) play the old "your new software breaks compatibility with your old
software" card

Is this a problem with strongswan ?

Or, have I configured it wrong ?

Or, will I have to give in with trying to stick to the same connection
configuration for both security-gateways ?

Or, will I have to hack the strongswan code to work around this ?

Any suggestions gratefully received !

Regards,

Graham.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20100420/0458d6ab/attachment.html>