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

[Martin Willi]

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