Hi Thor, > 2) Mode Config supports an "address lifetime" key but because of #1 above, we > don't and can't easily feed this to the client -- it gets an address only, > with no notion of expiry.
It's irrelevant anyway as IKEv1 is dead and the attribute (INTERNAL_ADDRESS_EXPIRY) was removed from IKEv2 with RFC 5996, which states (it's also repeated in RFC 7296): This document removes discussion of the INTERNAL_ADDRESS_EXPIRY configuration attribute because its implementation was very problematic. Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old value for INTERNAL_ADDRESS_EXPIRY. There are also some comments about it in RFC 4718, for instance: Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when the client has gone away. However, in IKEv2 this is known, and the gateway can simply free the address when the IKE_SA is deleted. > 3) IKEv2 Mode Config is pull-only, so the server can't later tell the client > a new address It's theoretically possible to push configuration attributes via CFG_SET/CFG_ACK configuration payloads, but strongSwan does not support that (not sure if any other implementation does). RFC 7296 says about this: There are currently no defined uses for the CFG_SET/CFG_ACK exchange, though they may be used in connection with extensions based on Vendor IDs. An implementation of this specification MAY ignore CFG_SET payloads. > 3) We can _minimize_ this issue by configuring long DHCP lease times and > short Phase 1 SA lifetimes, but not eliminate it. In failover DHCP > configurations, per the standard, factors such as the MCLT (max client lead > time) will result in some clients receiving shorter-than-default leases until > their first renewal, and this will eventually trigger the pathology detailed > above. With IKEv2 you could request the client to reauthenticate before the DHCP lease times out by configuring this appropriately (if the client supports that extension, although, the server will close the SA if the client does not reauthenticate in time, which releases the lease too). > 1) Feed the client an address-lifetime attribute along with its address. > Then the client will trigger a new DORA cycle at a more appropriate time. > > * Clients may not support this attribute (does StrongSwan? We haven't yet > looked) No, and since it's IKEv1-only there is not much point considering this. > * This requires a change to the API for all plugins which supply addresses, > to return the lifetime along with the address. > * But it does seem most correct, since it does tell the client the lease is > not eternal. It's very specific to DHCP, though, all other backends tie their leases to the IKE_SA. The DHCP server could do that too, I guess, as the DHCP plugin sends a DHCP RELEASE when the IKE_SA is terminated, so leases wouldn't have to time out (there might be some refcounting required in the plugin to handle IKEv2 make-before-break reauthentication properly, though - not sure if anybody ever tested this combination). > 2) Add more state and a timer to the DHCP plugin such that it knows all > addresses it's handled and tries to renew them itself. > > * This is fairly heavy > * Not clear what to do if renewal fails The leases are cached in the plugin, so I guess this could be implemented somehow. But yeah, if a renewal fails (why should it though?) this could be tricky (I suppose, you'd have to close the SA somehow, there is currently no direct link to them from the leases, though). So not letting leases time out is preferable. > 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). > 4) Change the client to do a config pull at each Phase 2 renewal instead > > * Some other clients do this (or so the comments in the standard say) What are you referring to? What comments? What standard? Anyway, strongSwan currently only supports exchanging configuration attributes during IKE_AUTH. And traffic selectors are not supposed to change this way during a rekeying so you'd have to negotiate new CHILD_SAs instead. Regards, Tobias
