[strongSwan-dev] support for {left,right}allowany in charon?

[Tobias Brunner]

Hi Mirko,

> The DNS information for the other direction is assumed to be up-to-date.
> Since both gateways are set up as potential initiators, it is hoped that
> the IKE SA can be rebuilt quickly by the gateway which has the
> up-to-date DNS information.
> 
> When the initiator of the original IKE SA changes its IP address and has
> up-to-date DNS information of its peer, this works.
> However, it breaks when the responder changes its IP address and is
> expected to take over initiation of the new IKE SA.

An interesting bit is that during reauthentication, after the responder
changed its IP address, the DELETE is sent to the new address, but the
following IKE_SA_INIT is sent to the old address, even though the
previous addresses are copied to the new IKE_SA created during
reauthentication.  The problem is that the hosts were re-resolved
unconditionally in 4.6.3 and before so here you get the old address
again (as the DNS info is not up-to-date yet).  In the master branch
this is already fixed - for existing releases you can apply the
corresponding patch [1].

Now, why does the responder not initiate a new IKE_SA?  Well, it has
simply no reason to do so.  The initiator properly deleted the existing
IKE_SA and there is no closeaction=restart to tell the responder to
reestablish the SA upon a proper DELETE.  As you can imagine
closeaction=restart is not fully compatible with reauthentication, as
the proper delete before the reinitiation would trigger an additional
IKE_SA - which would then be closed due to uniqueness checks -
triggering yet another IKE_SA and so on (so uniqueids=no would be
necessary for this to work at least partly).

The question is, do you actually require reauthentication or would
regular IKE_SA rekeys do too, if so, you can configure reauth=no to
avoid reauthentication altogether.

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=a994050e