We could extend the expire event so it includes the last usage values of
the expired SA. One issue with that is that we only get one direction,
so we'd have to query the other direction before we delete the SA (there
could be a race if it expired shortly after the first one - we could
increase the lifetime of one direction a bit, though, so we would have
enough time for this). Also, we currently don't cache usage data on the
child_sa_t object, which we had to do to report the final numbers via
get_usestats(). And we'd also need to actually trigger child_updown
for such SAs even after they were rekeyed (not possible for IKEv2 at
the moment). This may all be a bit overkill as for the general use case
this should not be an issue.
Basically, if the other peer uses an SA after it got rekeyed the usage
numbers won't be accurate. That is, all data transmitted since the last
update before expiration won't be accounted for (child_rekey, or interim
update - so this is less of an issue with interim updates, or with
relatively short rekeymargin). The peer will also only be able to send
data on the inbound SA (from the server's point of view), as the server
will always use the latest outbound SA. But the same problem occurs if
no rekeying is used, as in that case SAs will simply expire at some point
and no current data can be queried anymore (but I guess that's a rather
unusual use case).