[Swan-dev] linux: pluto use kernel SA attribute XFRMA_LASTUSED

[Paul Wouters]

On Mon, 6 Feb 2023, Antony Antony wrote:

>> All of this could ofcourse go away if the kernel could send us an "idle"
>> callback, but I think that's still not there right?
>
> I don't know any! I feel there was a lot confusion among us, swan
> programmers, around last used and we came up with workarounds.

Right.

> If you look again, with lastused updated for every packet pluto polling
> would be simple and possibly scalable.

Polling 10k connections every x seconds is pretty horrible :(

> Now pluto can control the rate of
> polling from kernel. Otherwise userspsece/pluto would complain receiving too
> many idle messages!

It should only receive 1 per connection. That's a lot less userland
to/from kernel messages than all the polling messages.

> Think of up link going down, and several 1000s of SAs
> become idle at once. The idle timer for all 1000s of SAs go off at once in
> the kernel, and the kernel would send 1000s of messages, possibly faster
> than pluto would be able to handle them. For each message Pluto would
> create IKE informational message, and send it. Likely retransmit IKE
> message and timeout? And then delete

All of that still happens, except instead of just receiving the idle
time out message, we first need to send a message to the kernel for
getsa_info() and then send a delete message for each SA anyway.
Regardless, losing a link with 1000s of SAs will suck for pluto when
DPD/liveness is configured. We could do something smarter in pluto,
eg rememeber which SAs are on which interface, and if we lose link on
that interface, don't bother sending DPD/liveness probes, and when we
hit timeout, don't try and send Delete messages. Maye even wait with
connection revival until we see the link is back.

> ...  I imagine handling of large number
> of kernel events would get complex very soon...  Uplink going down would
> happen from time time. I feel pluto polling is better.

I'm not convinced.

> Having said that may be there are ways to implement smart timers in kernel
> who knows! In an ideal world lastused update would have been fixed 10 years
> ago!

Yeah, IPsec definitely has some slowness to development, although I do
feel it is getting much better lately. Guess one good thing of WireGuard :)

Paul