[strongSwan-dev] ISAKMP SA lifetime, Mode Config, and DHCP

[Tobias Brunner]

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