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
