Thanks for your comments! It sounds to me like the best (practically, nearly the only) way, then, is:
>> 3) Artificially constrain the effective phase 1 SA lifetime server-side so >> that the server tries to renew the phase 1 before the DHCP lease expires. >> This should still trigger a new config pull by the client. >> >> * This is an abstraction violation - the DHCP plugin would have to >> find the relevant client state and mess with it directly, unless the >> plugin's API were changed as per #1 above > > The server can't reauthenticate in all cases (in particular with asymmetric > authentication, or with IKEv2 and virtual IPs). But with > IKEv2 you could pass the lease time to the IKE_SA (via > set_auth_lifetime() method), which would then request the client to > reauthenticate before this (if it supports > RFC 4478, otherwise the server > will close the IKE_SA when it expires if the client did not reauthenticate > before > that). The DHCP provider's acquire method gets the ike_sa so it looks like this should be relatively straightforward. We'll give it a try! My remarks on tying things to the phase 2 SA were based on what may have been a misunderstanding of 3.4 and 4 in the original mode config draft. In any case, it sounds like we may have a method that should work, at least for StrongSwan server and client. Thanks! Thor
