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
_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
